การต่อสู้: วิธีการทำงานกับเรื่องหนึ่งครั้ง

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

ตัวอย่างเช่นเรามีเรื่องราวในการสร้างบทสนทนาใหม่ เราสร้างงานต่อไปนี้:

• สร้างคลาสของโมเดล
• อ่านข้อมูลโมเดลจากฐานข้อมูล
• เชื่อมต่อคลาสโมเดลด้วยมุมมอง
• ใช้การจัดการกล่องโต้ตอบ
• บันทึกข้อมูลเมื่อปิด
• เอกสารทดสอบ
• คำอธิบายโซลูชัน

งานเหล่านี้สามารถทำได้หลายคนพร้อมกันหรือไม่ งาน - มากหรือน้อย - สร้างต่อกัน หรือเราออกแบบงานในทางที่ผิด?

ทำไมทุกทีมควรทำงานเรื่องเดียว?

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

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

สิ่งที่เราทำโดยทั่วไปคือแยกย่อยเรื่องราวออกเป็นงานย่อย dev / infra / analist

1. โดยทั่วไปสิ่งใดก็ตามที่ทำงานมากกว่าหนึ่งวันเป็นเรื่องราว

2. เมื่องานถูกทำลายลงหนึ่งในนักพัฒนาสูงสุดหนึ่งหรือสองคนทำงานในเรื่องขึ้นอยู่กับจำนวน: ของงานในมือ มักจะเป็นหนึ่ง

3. เราบันทึกเวลาที่ใช้และอัปเดตการประมาณการที่เหลือในตอนท้ายของวันก่อนที่เราจะออกจากหรือก่อนที่จะมีการยืนประจำวัน

4. งานย่อยถูกสร้างขึ้นสำหรับปัญหาใหม่ ๆ ที่เกิดขึ้นขณะทำงาน

5. เรื่องที่มีผลงานมากกว่า 2 สัปดาห์ถือว่าเป็นมหากาพย์

6. มหากาพย์สามารถประกอบด้วยเรื่องราวมากมาย

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

• ทีมข้ามการทำงาน, collocated
• เรื่องไม่สำคัญ
• คำจำกัดความของ "เสร็จสิ้น" ซึ่งแสดงถึงการมีส่วนร่วมของทีมทั้งหมด

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

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

คุณอาจต้องการอ่านทีมของ Swarmของ Mike Cohn ในรายการ Backlog หนึ่งรายการในแต่ละครั้ง? หรือบทความที่ฉันเขียน (เมื่อวานนี้) ซึ่งเกี่ยวข้องกับข้อบกพร่องโดยเฉพาะอย่างยิ่ง: เพื่อจับกลุ่มหรือไม่รุม

ส่วนใหญ่ของ SCRUM คือทีมควรทำการตัดสินใจประเภทนี้ ผู้ทำงานในมือควรมีเรื่องราวของผู้ใช้ที่มีข้อมูลมากพอที่จะสร้างงานได้

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

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

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

งานของคุณตามที่ระบุดูเหมือนจะ 'เล็ก' มากพอที่จะแจกจ่าย แต่มีข้อต่อระหว่างงานเช่นงานเกี่ยวกับการสร้างแบบจำลองข้อมูลและดึงข้อมูลจากฐานข้อมูล

สิ่งที่เป็นไปได้คือการแบ่งออกเป็นสามสิ่งหลักที่ผู้คนสามารถทำงานพร้อมกันได้ด้วยการทำงาน / การตั้งค่าพิเศษบางอย่าง:

• ส่วนหลัง (ฐานข้อมูลรุ่น ฯลฯ )
• Front-end (ใช้ข้อมูลจำลอง)
• การทดสอบ (การตั้งค่าความคาดหวังสถานการณ์ ฯลฯ )

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

คุณควรให้ความสำคัญกับทีมของคุณใช่ แต่ในเวลาเดียวกันคุณต้องทำให้ทุกคนยุ่งและทุกคนที่เกี่ยวข้อง

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