Scrum - นักพัฒนาทำงานนอก Sprint

ทีมการต่อสู้

• 3 x นักพัฒนา
• 2 x ผู้ทดสอบ
• 1 x นักวิเคราะห์ทดสอบอัตโนมัติ

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

ขณะนี้เราดำเนินการสองสัปดาห์

ในช่วงเริ่มต้นของการวิ่งทุกคนไม่ว่างนักพัฒนากำลังเริ่มงานพัฒนาและผู้ทดสอบกำลังเตรียมการทดสอบ (การเขียนกรณีทดสอบ ฯลฯ )

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

นักพัฒนาได้รับเท้าที่นี่และเริ่มทำงานกับรายการใน backlog ซึ่งอยู่นอกการวิ่งปัจจุบัน สิ่งนี้สร้างผลกระทบแปลก ๆ โดยที่เรามักจะพัฒนา sprints ถัดไปทำงานใน sprint ปัจจุบัน สำหรับฉันมันไม่ถูกต้อง

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

นี่ถือว่าเป็นปัญหาในการต่อสู้หรือไม่? มีวิธีแก้ปัญหานี้หรือไม่? การต่อสู้กับทีมมัลติฟังก์ชั่นเท่านั้นหรือไม่

ฉันอยากจะรู้ว่าคนอื่นมีประสบการณ์กับสิ่งนี้ถ้าเป็นไปได้ :)

นั่นเป็นปัญหาที่ค่อนข้างพบบ่อยเกิดจากpipelining ทีมเป็นแบบมัลติฟังก์ชั่น แต่แน่นอนว่ามีไซโลภายในซึ่งทำให้ประสิทธิภาพลดลง

ประการแรกฉันต้องการบันทึกสองสิ่งที่ฉันคิดว่าสำคัญ:

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

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

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

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

สิ่งที่ใช้ได้ผลดีมากสำหรับฉันคือเครื่องมือทั้งสองนี้:

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

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

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

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

เรามักจะพัฒนา sprints ถัดไปทำงานใน sprint ปัจจุบัน

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

ยังคงเป็นเรื่องที่น่าสนใจที่จะเรียนรู้เกี่ยวกับวิธีการสร้างสรรค์ใหม่ ๆ ที่องค์กรคิดค้นเพื่อการก่อวินาศกรรม

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

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

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

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

ฉันคิดว่าปัญหาสำคัญที่นี่คือต่อไปนี้:

นักพัฒนาส่วนใหญ่มีความเห็นว่าการทดสอบอยู่ด้านล่าง

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

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

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

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

ในทางทฤษฎีสมาชิกทุกคนในทีม SCRUM ควรมีความรู้เหมือนกันเพื่อให้สมาชิกแต่ละคนสามารถทำงานทุกอย่างจากสมาชิกคนอื่น ๆ ถ้าไม่คุณควรกระจายความรู้

แต่ในทางปฏิบัติมักมีความเชี่ยวชาญบางประเภทอยู่เสมอ ซอฟต์แวร์อาจมีความซับซ้อนสมาชิกในทีมมีทักษะที่แตกต่างกัน ฯลฯ การแบ่งทีมออกเป็นนักพัฒนาและผู้ทดสอบเป็นเพียงตัวอย่างหนึ่งของความเชี่ยวชาญ

การกระจายความรู้อาจใช้เวลามากกว่าที่ฝ่ายบริหารต้องการยอมรับ

จากประสบการณ์ของฉันคุณสามารถทำสิ่งต่าง ๆ :

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

คำแนะนำเหล่านี้อาจไม่ใช่ทฤษฎี SCRUM 100% แต่ก่อนอื่นคุณต้องพัฒนาต่อไป SCRUM เป็นเพียงกล่องเครื่องมือ

ดูเหมือนว่าคุณจำเป็นต้องแยกแยะทีมของคุณ เช่นนั้น:

   Test.   -------s1 -----------s2
   Dev.        --------s1 -----------s2

ถ้าฉันเข้าใจคนทดสอบอัตโนมัติต้องเริ่มต้นไม่กี่วันก่อน

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