ความคล่องตัวสำหรับนักพัฒนาเดี่ยว

บางคนจะใช้แนวคิดกระบวนการ Agile ในฐานะนักพัฒนาเดี่ยวได้อย่างไร Agile ดูเหมือนจะมีประโยชน์สำหรับการพัฒนาแอพพลิเคชั่นในเวลาอันรวดเร็ว แต่ก็ดูเหมือนว่าทีมจะมุ่งเน้น ...

• โดยทำการทดสอบพัฒนา
• โดยการพัฒนาในการวิ่งเล็ก ๆ
• โดยมีการติดต่อกับลูกค้าเป็นจำนวนมาก

ฉันจำได้ว่าอ่านวิทยานิพนธ์เกี่ยวกับการพัฒนาของคาวบอยซึ่งเป็นสิ่งจำเป็น Agile สำหรับนักพัฒนาเดี่ยว แต่ฉันจำไม่ได้ว่าอยู่ที่ไหน

นอกเหนือจากคำตอบจาก klez (คำแนะนำที่ดีทั้งหมด) ฉันขอแนะนำสิ่งต่อไปนี้:

• การคงค้างของผลิตภัณฑ์การคงค้างของ
  ผลิตภัณฑ์นั้นเป็นรายการของรายการทั้งหมดที่คุณตั้งใจจะทำในบางช่วงสำหรับผลิตภัณฑ์นี้
• การบำรุงรักษา sprint burndown และ product burndown
  การ sprint sprint เริ่มต้นด้วยรายการงานทั้งหมดที่คุณตัดสินใจที่จะทำให้เสร็จใน sprint นี้ (ส่วนหนึ่งของ backlog ผลิตภัณฑ์ของคุณจะเสร็จสมบูรณ์ภายในระยะเวลาที่กำหนดเช่น 2 สัปดาห์) พร้อมกับ การประเมินงานที่ต้องการ ในขณะที่คุณทำเครื่องหมายสิ่งต่าง ๆ ออกไป ดังนั้นการลด (หรือการเผาไหม้) งานที่เหลืออยู่สำหรับการวิ่งนั้น
  ในทำนองเดียวกันการเผาไหม้ผลิตภัณฑ์ติดตามงานที่เหลืออยู่สำหรับงานในมือทั้งหมด
• การใช้แนวคิดของการประมาณค่าแบบสัมพันธ์และความเร็ว
  การประมาณค่าแบบสัมพันธ์เป็นเทคนิคการประมาณค่าที่ใช้งานอื่น ๆ (หรือเรื่อง) เป็นแนวทาง ตัวอย่างเช่นถ้าคุณรู้ว่างาน A นั้นง่ายกว่างาน B และซับซ้อนกว่างาน C ประมาณสองเท่าคุณต้องแน่ใจว่า "คะแนน" สำหรับงาน A นั้นถูกต้องเมื่อเทียบกับความคาดหวังเหล่านั้น
  การเน้นไม่ได้อยู่ที่การคาดเดาปริมาณงานที่ต้องการอย่างถูกต้อง แต่การประมาณให้สอดคล้องกัน
  Velocity เป็นการวัดจำนวน "คะแนน" ที่คุณทำในการวิ่ง หากการประมาณค่าแบบสัมพัทธ์ของคุณรับรองความมั่นคงความเร็วนี้สามารถใช้เพื่อประเมินว่างานใดที่คุณน่าจะทำในการวิ่งที่กำลังจะมาถึง โปรดทราบว่าควรปรับความเร็วอย่างต่อเนื่อง

• จำกัด งานระหว่างทำ (นอกเหนือจากเวลาชกมวย) แม้ว่าคุณจะใช้วิธีวนซ้ำ (เทียบกับ Kanban) สมมติว่าความเร็วของคุณคือ 8 คะแนนต่อการวนซ้ำ อย่าเริ่มทำงานกับทั้ง 8 ในครั้งเดียว การ จำกัด งานระหว่างทำด้วยจำนวนเรื่องหรือคะแนนเรื่องราวก็ใช้ได้
• มีการทดสอบการยอมรับอัตโนมัติสำหรับเรื่องราวทั้งหมดของผู้ใช้ของคุณ ทำให้มากที่สุดเท่าที่คุณสามารถทำได้โดยอัตโนมัติ
• ผิดพลาดด้านการทำให้เรื่องราวของผู้ใช้มีขนาดเล็กเกินไป ตามกฎของหัวแม่มือให้อัตราส่วนของที่ใหญ่ที่สุดในเรื่องที่เล็กที่สุด 3: 1 หากคุณประมาทเรื่องราวใน Scrum และมันใหญ่เกินไปนักพัฒนาหลายคนสามารถจับกลุ่มมันเพื่อให้มันกลับมาติดตามได้ แต่คุณมีคนไม่พอ
• หากในบริบทของทีมขนาดปกติคุณจะลังเลว่าจะแยกเรื่องราวของผู้ใช้ออกหรือไม่ในบริบทของทีมเดี่ยวหรือทีมเล็ก ๆ ให้ทำอย่างรวดเร็วโดยไม่ลังเล สิ่งนี้ช่วยให้เรื่องราวเล็กลงและคาดเดาได้มากขึ้น
• Retrospectives มีความสำคัญโดยทั่วไป Agile ดังนั้น Kanban (นั่นคือ Personal Kanban) ทำคะแนนพิเศษที่นี่เพราะกระบวนการย้อนหลังนั้นใช้ข้อมูลมากขึ้น เป็นการยากที่จะเล่น Triple Nickels เมื่อคุณมีคนไม่พอ

สิ่งเหล่านี้อาจนำไปใช้กับสถานการณ์เดี่ยวและทีมเล็ก (2 หรือ 3 นักพัฒนา) สถานการณ์

เพิ่ม: บางครั้งหลังจากที่ฉันเขียนคำตอบนี้ฉันพบการสนทนาการประชุมครั้งนี้และประทับใจมาก: Kanban ส่วนบุคคล: การเพิ่มประสิทธิภาพของ Coder ส่วนบุคคล

• ทำงานเพื่อกำหนด sprints ที่ดีหรือเลือกแนวทาง Kanban โดยเจตนา อย่าเผลออยู่ใน Kanban
• บักก่อนคุณสมบัติที่สอง
• ยังคงให้ความสำคัญกับ Value กับคุณลักษณะที่ขยายตัว (YAGNI มากกว่าการชุบทอง)
• การหวนกลับเป็นสิ่งที่มีค่า และที่สำคัญคือทำการเปลี่ยนแปลงกระบวนการในกลุ่มย่อย ๆ อย่าตัดสินใจว่าวันนี้คุณจะเริ่มใช้ TDD, Mock และ IoC ในภาพเดียวเว้นแต่ว่าคุณจะไม่มีคุณสมบัติภายนอกในการส่ง ATM นำมาหนึ่งครั้ง

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

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

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

หากคุณปฏิบัติตาม BDD / TDD อนุญาตให้ความต้องการของคุณเปลี่ยนไปตามลมและสามารถปรับลำดับความสำคัญของคุณสมบัติของคุณตามลำดับหากคุณสร้างระบบทั้งหมดของคุณและทำการทดสอบทั้งหมดบ่อยครั้งและถ้าคุณส่งรหัสการทำงานเมื่อสิ้นสุดการวิ่งแต่ละครั้ง คุณว่องไวอยู่แล้ว

ว้าว. ฉันพยายามเก็บเพื่อนไว้ในเบ็ดที่ฉันสามารถโทรหาเมื่อฉันมีปัญหา - และพูดคุยผ่านปัญหาการเข้ารหัส คุณรู้ว่าสิ่งที่ฉันหมายถึง ... เพียงแค่การอธิบายปัญหาดัง ๆ นำมาสู่ความคิดของฉัน 90% ของเวลา