นักแปลอิสระสามารถใช้การพัฒนาที่คล่องตัวได้หรือไม่?

ฉันต้องการปรับปรุงวิธีการพัฒนาซอฟต์แวร์ ฉันต้องการที่จะพัฒนาเร็วขึ้นและเป็นรหัสที่ยอดเยี่ยม! วันนี้ฉันใช้วิธีน้ำตกเป็นอิสระเขียนเนื้อหาเว็บ (เว็บไซต์ระบบ ฯลฯ ) มีวิธีใช้การพัฒนาแบบว่องไว (XP, SCRUM และอื่น ๆ ) ทำงานด้วยวิธีนี้หรือไม่? ฉันไม่รู้อะไรเลยเกี่ยวกับการพัฒนาที่คล่องตัวฉันควรเริ่มจากที่ไหน ขอบคุณมาก.

... นอกจากการเขียนโปรแกรมคู่แน่นอน ;-)

อย่างจริงจังฉันก็เป็นนักแปลอิสระเช่นกันและฉันก็ใช้เทคนิคที่คล่องตัวมากเท่าที่จะทำได้ มันใช้งานได้ดีมาก ฉันใช้ประโยชน์อย่างมากจาก TDD

ไม่มีใครที่ไหนใช้ 100% ของ XP หรือ Scrum แต่ทุกคนใช้บางส่วนของมันพยายามที่จะนำมาใช้ให้มากที่สุด ในความคิดของฉันยิ่งคุณยอมรับมากเท่าไรคุณก็ยิ่งดีเท่านั้น

สิ่งที่ฉันคิดถึงมากที่สุดคือการเขียนโปรแกรมคู่ วิธีที่คุณเอาชนะนั่นคือ

1. ไปที่การประชุมกลุ่มผู้ใช้จำนวนมาก
2. ค้นหาคนที่คุณเคารพในฐานะนักพัฒนา
3. ขอให้พวกเขาพบคุณทางกาแฟหรืออะไรที่จะเขียนโค้ด ให้ส่วนหนึ่งของค่าจ้างรายชั่วโมงของคุณเป็นครั้งคราวหากคุณรู้สึกว่าจำเป็นหรือตอบสนองต่อการทำงานกับรหัสของพวกเขา
4. เข้าร่วมหรือสร้างสับคลับเช่นนี้: http://www.DallasHackClub.org

นี่คือทรัพยากรที่ฉันใช้:

• Extreme Programming - ออนไลน์อย่างรวดเร็ว แต่ให้คำแนะนำอย่างละเอียดผ่าน XP
• ภาพรวมการต่อสู้ที่ดี
• ที่ยอดเยี่ยมและหนังสือสั้น สมบูรณ์แบบสำหรับคุณ!

ดังนั้นฉันจะบอกว่ามี "คะแนนยอดเยี่ยม" หลักสามประการในการใช้ Agile ในฐานะอิสระ:

1. สำหรับลูกค้าขนาดใหญ่ให้ทำงาน / เรียกเก็บเงินซ้ำ ในตอนท้ายของการทำซ้ำลูกค้าสามารถทำงานต่อในโครงการหรือสิ้นสุดโครงการ (เช่น: มันบรรลุเป้าหมาย) ฉันรู้ (จากประสบการณ์) ฉันไม่สามารถประมาณการได้ดีกว่าสองถึงสามสัปดาห์และการจ่ายต่อการทำซ้ำยังช่วยให้กระแสเงินสดเข้ามามันสนุกที่จะอยู่ที่ 6 เดือนของโครงการ 3 เดือนและรอ เพื่อสิ้นสุดโครงการเพื่อให้คุณสามารถ ...

2. เปรียวหมายถึงการเปลี่ยนแปลงที่เกิดขึ้น ฉันได้ทำโครงการประมูลแบบตายตัว (ซึ่งคุณคิดว่าคุณสามารถทำกับน้ำตกได้) ซึ่งทำให้ฉันสูญเสียเงินเนื่องจากมีคำขอของลูกค้าในระหว่างรอบ การเปลี่ยนแปลงเกิดขึ้น: ลูกค้าสามารถลดความสำคัญของตั๋วเพื่อให้งานอื่น ๆ เสร็จเร็วขึ้นหรือคุณอาจคาดการณ์ผิดและไม่ได้ทำมากเท่าที่คุณคาดหวัง

3. เครื่องมือการทำงานร่วมกันของลูกค้าที่ดี การประเมินมาตรฐานของฉัน (สำหรับบางสิ่งที่เล็กกว่าค่าใช้จ่ายในการทำซ้ำ) เป็นชุดของขั้นตอนการพัฒนาพฤติกรรมขับเคลื่อนซึ่งได้มาจากความคาดหวังของลูกค้า ฉันส่งสิ่งนี้ให้ลูกค้าและพูดว่า "ถูกต้องหรือไม่ ทำให้แน่ใจว่าทุกคนอยู่ในหน้าเดียวกัน

4. สิ่งที่ง่ายที่สุดที่อาจเป็นไปได้ โปรดระลึกไว้เสมอว่าคุณกำลังทำงาน: อย่ากลัวที่จะกลับไปหาลูกค้าและพูดว่า "นี่จะง่ายกว่ามาก (หรือมีประสิทธิภาพมากกว่าหรืออะไรก็ตาม) ถ้าเราทำแบบนี้ ... "

5. การต่อสู้เป็นสิ่งสำคัญ ฉันชอบส่งอีเมลถึงลูกค้าทุกวันที่ฉันทำงานในโครงการของพวกเขา นี่คือการต่อสู้ของฉันกับพวกเขา: "สิ่งที่ฉันทำในวันนี้", "อะไร / เมื่อฉันจะทำงานในโครงการของพวกเขาต่อไปหรือไม่", "มีอะไรในทางของฉัน?" และ "โดยรวมแล้ว ?"

6. การพัฒนาระบบทดสอบนั้นมีประโยชน์จริง ๆ เช่นกันแม้ในฐานะโปรแกรมเมอร์คนเดียว "การประมาณการกับเรื่องราวใน BDD ของฉัน" ช่วยฉันให้ฟีดกระบวนการนี้

วิธีที่ดีในการเริ่มต้นการเดินทางแบบ Agile ของคุณคือการตั้งค่าเวิร์กโฟลว์ของคุณโดยใช้ระบบ KANBAN

เรามี 3 swimlanes:

1. สิ่งที่ต้องทำหรืองานในมือ
2. สิ่งที่เรากำลังทำงานหรือกำลังดำเนินการอยู่
3. สิ่งที่เราทำเสร็จหรือทำ

เวิร์กโฟลว์ Agile ง่าย ๆ นี้เป็นวิธีเริ่มต้นที่ดี

ในแง่ของการเขียนโปรแกรมฉันขอแนะนำให้ใช้การพัฒนาที่ขับเคลื่อนด้วยการทดสอบ (TDD) เรารวมลิงค์ที่ยอดเยี่ยมมากมายที่อธิบาย TDD ไว้ในบทความของเรา แต่จะคัดลอกลิงก์ใหม่ที่นี่:

สำหรับข้อมูลเพิ่มเติมตรวจสอบแหล่งข้อมูลต่อไปนี้:

• AgileData.org - ทรัพยากรที่ยอดเยี่ยมสำหรับการพัฒนาที่ขับเคลื่อนด้วยการทดสอบ
• JamesShore.com - อีกความล้มเหลวที่ยอดเยี่ยมสำหรับ TDD
• Net Tuts - สนุกกับการแนะนำ TDD ที่ชอบ!
• Artima - สัมภาษณ์กับ Martin Fowler
• Games From Inside - กรณีศึกษา TDD ที่ดี
• DaniWeb - ข้อมูลเบื้องต้นเกี่ยวกับ TDD สำหรับนักพัฒนา
• Mark Levison - บทความเกี่ยวกับ TDD

ตั้งแต่บุคคลของคุณจะดีที่สุดที่คุณวิธีการวิธีการเปรียวเป็นบางสิ่งบางอย่างที่มีเพื่อช่วยให้คุณ grok เอาสิ่งที่ดีที่สุดสำหรับคุณ พวกเขาอยู่ที่นั่นเพื่อช่วยให้คุณเข้าถึงว่า "ไม่มีช้อน" ที่ราบสูง แต่วิธีการที่จะเกิดขึ้นนั้นขึ้นอยู่กับคุณและสิ่งที่คุณเกิดขึ้นในตอนท้ายจะทับซ้อนกับวิธีการในระดับต่าง ๆ อย่างมาก มันจะเป็นสิ่งที่สมบูรณ์แบบของคุณ

เนื่องจากคุณพยายามหาวิธีของคุณเองในการทำสิ่งต่าง ๆ เพื่อปรับปรุงประสิทธิภาพโดยรวมของคุณนี่คือตัวชี้บางอย่างที่สามารถช่วยคุณอย่างน้อยก็ไม่ได้ทำผิดพลาดแบบเดียวกันกับที่ฉันทำ:

ทิ้งโซลูชันซอฟต์แวร์ทั้งหมดที่กำหนดเป้าหมายไปที่ระเบียบวิธีแบบว่องไวโดยเฉพาะตราบเท่าที่คุณสามารถทำได้

ความจริงที่ว่าพวกเขาเหมาะสมกว่าสำหรับการอำนวยความสะดวกในการทำงานร่วมกันของทีมอยู่ข้างประเด็น ต่อต้านสิ่งล่อใจ คุณไม่ได้ทำกล่องเองในการทำสิ่งต่าง ๆและหวังว่าการนำมันไปใช้จะได้ผลดีที่สุด ไม่มันแค่ทำให้คุณหงุดหงิด คุณต้องหาวิธีในการทำสิ่งต่าง ๆก่อนแล้วจึงค้นหาโซลูชันซอฟต์แวร์ที่เหมาะสม ฉันลงเอยด้วยการใช้ไวท์บอร์ด (เริ่มต้นด้วย แต่ตอนนี้ฉันมีสองในห้องของฉัน) สำหรับการติดตาม / พัฒนาเรื่องราวและเทคนิค Pomodoro | รายการสิ่งที่ต้องทำในวันนี้เพื่อติดตามงานพัฒนาของฉันและมันเป็น friggin 2011 ทำตามขั้นตอนพื้นฐานจนกว่าเราจะได้รับอินเทอร์เฟซบางอย่างเช่น Iron Man 2 หรือรถบินเริ่มปรากฏ

การสะท้อนการสะท้อนการสะท้อนกลับ

นี่คือสิ่งที่ฉันมาทำความเข้าใจเพื่อเป็นส่วนสำคัญที่สุดของวิธีการสำหรับบุคคล มันเกี่ยวกับการพัฒนาเวิร์กโฟลว์นี้ที่ให้มุมมองแบบองค์รวมของโครงการของคุณเพื่อให้คุณสามารถติดตามสิ่งที่ต้องทำและเมื่ออยู่ในรูปแบบที่สามารถจัดการได้ง่ายและในกรณีที่การตัดสินใจที่ไม่ดีเกิดขึ้นบ่อยและโดดเด่นเพื่อให้สามารถแก้ไขได้อย่างรวดเร็ว ก่อนที่มันจะสร้างความเสียหายใด ๆ ... แต่คุณไม่สามารถเลือกมันออกจากชั้นวางได้ เริ่มจากที่ใดก็ได้ คุณติดกับมันตราบเท่าที่มันทำงาน ลงทุนเพื่อติดตามความดีความเลวและความพินาศ ปรับปรุงสมมติฐานของคุณจากนั้นปรับวิธีการทำสิ่งต่าง ๆ ให้เหมาะสม นั่นเป็นวิธีเดียวที่คุณจะพัฒนา

อย่าลืมกำหนดเวลามุ่งเน้นไปที่ความรวดเร็วในการทำสิ่งต่างๆ

ฉันอาจเป็นคนที่แต่งตัวประหลาดต่อไปเมื่อฉันเริ่มวันที่ไล่ แผนภูมิเหนื่อยหน่าย? ฉันเคยคิดว่าพวกเขาเป็นวิธีที่จะเห็นภาพการพัฒนาของฉันกับกำหนดเวลา มันเป็นประสิทธิภาพไม่ใช่แบบจำลองโดยประมาณ เวลาอยู่ที่นั่นเพื่อวัดประสิทธิภาพของคุณโดยสะท้อนให้เห็นถึงงานที่คุณทำภายในกรอบเวลาที่กำหนดไม่ใช่เพียงค่าความโง่เพื่อแสดงระยะทางก่อนที่จะขัดขวางกำหนดเวลา ความจริงก็คือสิ่งที่ได้รับการทำเมื่อมันเสร็จและวิธีการของคุณควรคำนึงถึงสิ่งนั้น

เบี่ยงเบนตาม

ในท้ายที่สุดใครบอกว่าคุณต้องใช้เรื่องราวของผู้ใช้หรืออะไรก็ตามที่เรารู้ในเรื่องนั้น? อย่าคิดอย่างนั้น หากคุณรู้สึกสบายใจกับการคิดในคุณลักษณะต่าง ๆ โดยทั่ว ๆ ไปจะเป็นการท้าทายชุมชนการพัฒนาระดับโลกและทำสิ่งที่คุณทำเพราะการทำสิ่งต่าง ๆ เป็นเรื่องที่สำคัญในตอนท้ายของวัน หากคุณรู้สึกว่าทำสิ่งที่ผิดไปแสดงความยินดี - คุณเพิ่งสรุปได้ว่าถึงเวลาแล้วที่จะต้องก้าวไปสู่สิ่งอื่น มันเกี่ยวกับอะไรไม่ใช่ชำนาญ

ฉันจะตอบว่า "คุณต้องการปรับปรุงวิธีการพัฒนาซอฟต์แวร์อย่างไร" สำหรับโมเดลธุรกิจของคุณปัญหาที่ใหญ่ที่สุดที่คุณพบโดยใช้วิธีน้ำตกคืออะไร

เป้าหมายของคุณคือการพัฒนาที่เร็วขึ้นรหัสที่แข็งแกร่งยิ่งขึ้นนำมาใช้ใหม่ได้มากขึ้นมีการประชุม / ปรับตัวให้เข้ากับข้อกำหนดที่เปลี่ยนแปลง ฯลฯ วิธีการต่าง ๆ มีอยู่เพื่อเอาชนะปัญหาต่าง ๆ

แน่นอนว่าการใช้วิธีการออกแบบอื่นนอกเหนือจาก Waterfall อาจมีประโยชน์อย่างมากในการจัดการวงจรชีวิตของโครงการได้อย่างมีประสิทธิภาพขึ้นอยู่กับความต้องการทางธุรกิจของคุณ สำหรับการพัฒนาที่คล่องตัวนั้นมีทรัพยากรจำนวนมากทางออนไลน์ ฉันจะพิจารณาAUP (Agile Unified Process) ซึ่งรวมเอา TDD (Test Driven Development) สิ่งนี้มีประโยชน์อย่างยิ่งเมื่อสร้าง / จัดการระบบที่ปรับขยายได้ขนาดใหญ่

ไม่มี 'ขนาดเดียวที่เหมาะกับทุกคน' และนี่คือเหตุผลหลักสำหรับวิธีการที่แตกต่างกันมากมาย ฉันจะเริ่มคิดถึงที่ที่คุณรู้สึกว่าคอขวดอยู่ในกระบวนการพัฒนาของคุณในขณะนี้จากนั้นลองใช้วิธีการใหม่เพื่อเอาชนะปัญหานี้

ตัวอย่างเช่นคุณมักจะล้มเหลวในการทำตามกำหนดเวลา? ฟีเจอร์ใหม่มีข้อบกพร่องจำนวนมากหรือไม่? ข้อกำหนดใหม่ทำให้เกิดการพัฒนาที่สำคัญหรือไม่ ธุรกิจจำเป็นต้องมีระบบการทำงานปกติหรือไม่ เช็คเอาต์: เปรียว , ซ้ำและเปรียว Intro