วิธีการทำให้ Scrum ทำงานกับทีมที่มีบทบาทที่กำหนดไว้อย่างไร

ข้อมูลพื้นหลังบางส่วน

ฉันเป็นส่วนหนึ่งของทีมพัฒนาซอฟต์แวร์ภายในองค์กร มันประกอบด้วย

• นักพัฒนา 5 คน (ด้วยประสบการณ์ตั้งแต่ 2 ถึง 5 ปีฉันเป็นหนึ่งในนั้น)
• 3 เจ้าหน้าที่ดำเนินงาน (พวกเขาทำการปรับใช้ซอฟต์แวร์และฝึกอบรม)
• และผู้จัดการโครงการ 1 คน

เราพัฒนาโครงการขนาดเล็กถึงขนาดกลางจำนวนมากและระยะเวลาของโครงการมักจะทับซ้อนกัน การพัฒนาเป็นเช่นนี้:

1. "ลูกค้า" ทำให้เรามีชุดของความต้องการเริ่มต้น
2. เราพัฒนาระบบเพื่อสเปคดังกล่าว
3. นำเสนอระบบดังกล่าวเพื่อ "ลูกค้า"
4. "ลูกค้า" ให้ข้อกำหนดเพิ่มเติมแก่เราตามการนำเสนอดังกล่าว
5. ทำซ้ำ 2-4 จนกระทั่ง "ไคลเอนต์" หมดข้อกำหนดใหม่หรือวันที่เป้าหมายการปรับใช้ใกล้จะหมด
6. ตั้งค่าและปรับใช้ระบบ

สิ่งนี้พร้อมกับความจริงที่ว่ามันเป็น "ลูกค้า" ที่จัดการกับกำหนดเวลาส่วนใหญ่ (ซึ่งเป็นธงสีแดงจากสิ่งที่ฉันเห็นที่นี่ในโปรแกรมเมอร์และ PM.SE) และเราไม่ปฏิบัติตามวิธีการพัฒนาที่ชัดเจน เพื่อการเข้ารหัสโคบาลรหัสใกล้เคียงและข้อบกพร่องที่ได้รับจากการผลิตเหนือสิ่งอื่นใด นั่นเป็นเหตุผลที่เราเลือกใช้วิธีการแบบ Agile-based เช่น Scrum

ทำไมต้องแย่งชิงกัน?

มันเป็นความคิดริเริ่มของผู้จัดการของเราและทุกคนดูเหมือนจะเห็นด้วยกับสถานการณ์ปัจจุบันของเรา

มีปัญหากับการแย่งชิงกัน

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

คำถาม

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

อันที่จริงวิธีการทำงานในปัจจุบันของคุณไม่ได้ห่างไกลจากการต่อสู้อย่างที่คุณคิด

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

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

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

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

คุณขอทางเลือกอื่นดังนั้นฉันจะบอกว่า eXtreme Programming (XP) ฉันคิดว่าการเขียนโปรแกรมคู่อาจช่วยคุณได้ที่นี่

ด้วยการจับคู่ผู้คนที่มีทักษะแตกต่างกันเข้าด้วยกันมันไม่สำคัญว่าทักษะอะไร: การทำกาแฟการทดสอบการฝึกอบรมและอื่น ๆ คุณสามารถกระจายทักษะรอบ ๆ ทีม

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

วิธีการทำให้ Scrum ทำงานกับทีมที่มีบทบาทที่กำหนดไว้อย่างไร

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

บางสิ่งที่คุณอาจต้องการที่อยู่:

ลมพัด

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

แก้ไขกำหนดเวลา

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

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

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

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

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

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

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

“ การพัฒนาพฤติกรรมที่ขับเคลื่อนด้วย” โดยเจ้าหน้าที่ปฏิบัติงานจะเขียนตัวอย่างที่ใช้ในการทดสอบอาจได้ผล

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