Scrum สามารถปรับให้เข้ากับการตั้งค่าอาสาสมัครได้อย่างไร

ฉันเพิ่งเข้าร่วมแฮกเกอร์สเปซอายุน้อยยังอยู่ในขั้นตอนการตั้งค่า เราโชคดีเพราะพื้นที่มีโครงการภายในไม่กี่แห่งที่ต้องทำงานและไม่มีอาสาสมัครทำงานให้

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

แม้ว่าฉันจะเห็นว่าการต่อสู้แบบ Scrum ทำงานได้ดีสำหรับทีมเต็มเวลาขนาดเล็ก แต่ลักษณะขององค์กรนี้แตกต่างกัน:

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

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

• หากเราเปลี่ยน Sprints ให้มีขนาดเรื่องจุดคงที่ แต่ระยะเวลาของเหลว (เวลา) เรายังสามารถได้รับประโยชน์จากการเผยแพร่ซ้ำโดยไม่กดดันต่อการส่งที่ไม่สมจริงใน devs ของอาสาสมัคร
• เราสามารถทิ้งแผนภูมิการเผาไหม้และการคำนวณความเร็ว หากฉันเข้าใจถูกต้องสิ่งเหล่านี้เป็นเครื่องมือและตัวชี้วัดที่ทำงานเป็นสะพานเชื่อมระหว่างทีม dev และฝ่ายจัดการ พวกเขาทำหน้าที่รายงานความคืบหน้าในรูปแบบที่มีความหมายต่อทั้งนักพัฒนาและผู้มีส่วนได้เสีย พิจารณาว่าเราไม่มีใครรายงาน (ไม่มีผู้จัดการโครงการไม่มีเจ้าของผลิตภัณฑ์และไม่มีผู้มีส่วนได้เสียภายนอก) ฉันเชื่อว่าเราสามารถทำสิ่งนี้ได้ทั้งหมด

สิ่งที่ฉันคิดว่าเราจะได้รับจากการที่ไม่ต้องใช้การปรับแต่ง:

• การรวบรวมความต้องการประชุม (s) ที่ที่ทุกคนนั่งรอบโต๊ะและพูดคุยเรื่องราวของผู้ใช้ร่างภาพ mocks UI และสร้าง Backlog ของผลิตภัณฑ์
• Sprint Retrospectives นี่จะเป็นวิธีที่น่าสนใจสำหรับเราที่จะมาบรรจบกันในกระบวนการพัฒนาที่เหมาะกับเราในฐานะทีมอาสาสมัคร

สิ่งที่ฉันไม่แน่ใจเกี่ยวกับ:

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

คำถามของฉัน:

Scrum สามารถปรับให้เข้ากับสภาพแวดล้อมที่เป็นอาสาสมัครได้หรือไม่?
และแนวทางที่วางแผนไว้ของฉันจะไปในทิศทางที่ถูกต้องหรือไม่?

มองเข้าไปที่ Kanban มันเหมาะสมกว่า SCRUM สำหรับข้อ จำกัด ของคุณ

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

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

คุณอาจมีการลงคะแนนจากงานในมือแม้ว่าจะมีอาสาสมัครในการตั้งค่าบางคนก็ทำงานในสิ่งที่พวกเขาต้องการ

(และใช่ TDD, CI ทั้งหมดความคิดเห็นและแนวคิดการเขียนโปรแกรมเพียร์เป็นความคิดที่ดี)

ในการแก้ไขความแตกต่างที่คุณต้องทราบก่อน:

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

เกี่ยวกับการดัดแปลงที่เสนอของคุณโดยเฉพาะอย่างยิ่งเมื่อทำงานกับอาสาสมัครฉันขอแนะนำอย่างยิ่งให้รักษาระยะเวลาการวิ่งคงที่ ด้วยวิธีนี้อาสาสมัครรู้แน่นอนว่าช่วงเวลาใดที่พวกเขาเลิกสัญญา

ฉันจะไม่ทิ้งชาร์ตการเผาไหม้ทันที พวกเขายังสามารถเป็นประโยชน์สำหรับทีมตัวเองเพื่อดูว่าพวกเขากำลังทำตามความมุ่งมั่นของพวกเขา ฉันจะปล่อยให้ทีมตัดสินใจที่จะเก็บหรือทิ้งไว้ เช่นเดียวกันสำหรับการคำนวณความเร็ว โดยเฉพาะอย่างยิ่งกับความแปรปรวนจำนวนมากใน manhours ที่มีอยู่ในแต่ละ sprint พวกเขาสามารถพิสูจน์ได้ว่ามีประโยชน์มาก (โดยเฉพาะถ้าคุณคำนวณจำนวนคะแนนที่เสร็จสมบูรณ์ต่อ manhour) ในการประเมิน sprints ในอนาคต

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

แนวทางปฏิบัติของ XP ที่คุณพูดถึงนั้นสามารถนำมาใช้หรือไม่เป็นอิสระจากการใช้ Scrum และอาจถูกนำเสนอในระหว่างการหวนกลับ

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

Agile เป็นเรื่องเกี่ยวกับการสื่อสารและการทำงานร่วมกัน มีเหตุผลทำไมมี 2 คะแนนจาก 4 ในการพูดคุยเปรียวมัน

บุคคลและการมีปฏิสัมพันธ์เหนือกระบวนการและเครื่องมือ

การทำงานร่วมกันของลูกค้าในการเจรจาสัญญา

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

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

สิ่งสุดท้ายคือฉันเชื่อว่าคุณควรมีอย่างน้อยคนน้อยที่ทำงานในโครงการเต็มเวลา คนเหล่านั้นควรมีบทบาทเฉพาะ:

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

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

1. มีการแก้ไขซ้ำแล้วซ้ำอีก เพื่อให้คุณสามารถวัดความก้าวหน้าของคุณ สิ่งนี้ไม่ได้มีไว้สำหรับการจัดการเท่านั้น แต่ยังสำหรับทีมที่จะ“ รู้” ว่ามันมีประสิทธิภาพอย่างไร
2. ขออาสาสมัครแบ่งปันความสามารถเมื่อเริ่มต้นการทำซ้ำ ทุกทีมต้องการสิ่งที่สมาชิกกระทำมิฉะนั้นสมาชิกบางคนอาจออกจากทีมเพื่อทำงานที่ทำอย่างมืออาชีพ
3. ไม่มีกำหนดเวลาเป็นเรื่องปกติ การแย่งชิงกันไม่ได้บังคับว่าสิ่งที่คุณทำในตอนท้ายของการทำซ้ำแต่ละครั้งควรมีความเป็นไปได้ สิ่งนี้จะช่วยให้คุณตัดสินใจว่าจะทำอย่างไรต่อไปโดยขึ้นอยู่กับสิ่งที่คุณทำจนถึงตอนนี้ (ซึ่งใช้งานได้)
4. การไม่มีเจ้าของผลิตภัณฑ์ก็สามารถทำงานได้เช่นกัน .. คุณสามารถมีระบบการลงคะแนนแบบเรียงซ้อนเพื่อจัดอันดับยอดค้างและยอมรับ / ปฏิเสธงานที่ทำ
5. การรวบรวมความต้องการไม่ได้เป็นส่วนหนึ่งของการต่อสู้ คุณสามารถทำมันต่อไปที่คุณต้องการ แต่อย่ารวมว่าเป็นส่วนหนึ่งของขอบเขตการทำซ้ำ มีความจุแยกต่างหากสำหรับสิ่งนั้น ดังนั้นสำหรับการทำซ้ำให้วางแผนเฉพาะงานที่ต้องการความชัดเจนเช่นทีมรู้ถึงเกณฑ์การยอมรับ
6. ย้อนหลังเป็นสิ่งที่ดี ดังนั้นเริ่ม Scrum ตามนั้น แต่ใช้ retrospective ดูว่าอะไรทำงานและอะไรที่ไม่ใช่เช่นคุณอาจต้องเปลี่ยนขนาดการวนซ้ำคุณอาจต้องกำจัดอาสาสมัครบางคนที่ลากคนอื่น ..
7. สถานะประจำวันจะต้อง ที่เปิดโอกาสให้ทีมทำข้อมูลให้ตรงกันซึ่งกันและกันคือพวกเขาจะปรับความพยายามของพวกเขาเพื่อไม่ให้งานถูกบล็อกโดยไม่จำเป็นเนื่องจากไม่สามารถส่งมอบของสมาชิกคนอื่นได้
8. XP เป็นสิ่งที่ดี มีคำจำกัดความที่เข้มงวดของการทำตาม XP เช่นไม่มีรหัสเข้าไปเว้นแต่จะมีการตรวจสอบ ทำน้อยลงเพื่อทำมากขึ้น ..

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

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

สิ่งนี้ทำให้ฉันนึกถึงกระบวนการพัฒนาที่เน้นไปที่โครงลวดและต้นแบบ

คุณสามารถมีกลุ่มของไอเท็มงานที่พร้อมใช้งานและสนับสนุนให้ผู้คนเขียนโครงลวดสำหรับสิ่งเหล่านั้น คุณสามารถใช้สิ่งเหล่านี้เป็น Tracer Bullets (คำศัพท์ที่ยืมมาจาก Pragmatic โปรแกรมเมอร์) เพื่อฝึกฝนความคิดและสร้างแรงบันดาลใจให้กับผู้คน จากนั้นคุณสามารถเปลี่ยนความคิดที่ประสบความสำเร็จให้เป็นต้นแบบได้อีกครั้งโครงการเหล่านี้เป็นโครงการขนาดเล็กมากที่ออกแบบมาเพื่อช่วยให้ผู้คนเรียนรู้เพิ่มเติมเกี่ยวกับโครงการ หลังจากนั้นตอนนี้คุณมีความคิดเล็ก ๆ ที่ถูกสร้างขึ้นโดยคนจำนวนมากที่คุณสามารถส่งมอบให้กับทีมที่มีความกระตือรือร้นมากขึ้นและพวกเขาสามารถทำงานเพื่อรวมแนวคิดเหล่านั้นเข้ากับระบบของคุณ

ฉันคิดว่า Kanban น่าจะเหมาะกว่าสำหรับสถานการณ์นี้

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

Kanban ให้ประโยชน์ค่อนข้างมากเหมือนกับ Scrum โดยไม่มีข้อเสีย มันสามารถทำให้คุณต้นแบบรวดเร็ว รูปแบบที่สามารถเรียกใช้ก่อนการประชุม นอกจากนี้ยังให้ TDD สำหรับรหัสที่เปลี่ยนแปลงได้และการทดสอบการถดถอย การเขียนโปรแกรมจับคู่สามารถทำให้ผู้มาใหม่และผู้ไม่ธรรมดาเข้าสู่ฐานรหัสได้ง่ายขึ้นโดยการถ่ายโอนความรู้

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