ในบทความก่อนหน้าของฉัน ฉันเริ่มอภิปรายเกี่ยวกับนิสัยที่พัฒนาไม่ดีภายในทีมต่อสู้ซึ่งในที่สุดจะนำไปสู่ความล้มเหลวในการส่งมอบ (ไม่ช้าก็เร็ว) ในบทความนี้ ฉันต้องการขยายหัวข้อนี้อีกครั้งและมุ่งเน้นไปที่กระบวนการทำงานภายในทีม
สิ่งเหล่านี้มีความสำคัญเช่นเดียวกันกับความเป็นเลิศทางเทคนิคของทีม แม้ว่าคนในนั้นจะมีความชำนาญเป็นพิเศษสำหรับงานที่พวกเขากำลังจะส่งมอบ แต่ก็ยังมีบางพื้นที่ที่สามารถทำลายความพยายามของพวกเขาเพื่อความสมบูรณ์แบบได้ และจะไม่ใช่ความผิดของพวกเขามากนัก เนื่องจากจะเป็นความรับผิดชอบโดยตรงของการตัดสินใจในการบริหารโครงการและความสามารถของพวกเขาในการให้บริการทีมด้วยกระบวนการที่เหมาะสมสำหรับวัตถุประสงค์เพื่อสนับสนุนทีมด้วยความตั้งใจที่ชัดเจนและกิจกรรมที่คาดการณ์ได้
ทีมที่มีการแบ่งแยกสูงพร้อมชุดทักษะที่แตกต่าง
ลองนึกภาพว่าทีมมีนักพัฒนาที่มีทักษะ เป็นอิสระอย่างสมบูรณ์และสามารถรักษาสัญญาและส่งมอบเนื้อหา Sprint ที่ตกลงไว้ได้ทันเวลาก่อนสิ้นสุด Sprint แม้ในสถานการณ์ที่สมบูรณ์แบบเช่นนี้ (ซึ่งไม่น่าจะเกิดขึ้นได้) ทีมจะมีปัญหาในการติดตามคุณสมบัติงานค้าง (ที่เติบโตขึ้นเรื่อยๆ) หากทักษะถูกแยกออกจากกันอย่างเคร่งครัดระหว่างสมาชิกในทีม
ตัวอย่างบางส่วน
- ทีมมีวิศวกร DevOps 1 หรือ 2 คนที่สามารถเปลี่ยนแปลงท่อส่งอัตโนมัติหรือดูแลบริการภายในแพลตฟอร์มได้ แต่ทีมที่เหลือไม่มีเงื่อนงำเกี่ยวกับเรื่องดังกล่าว จากนั้นการพูดคุยเกี่ยวกับเรื่องราวเหล่านั้นในพิธีการต่อสู้เช่นการปรับแต่งจะนำไปสู่การเสียเวลาโดยส่วนใหญ่ของทีมโดยการหยุดการประชุมโดยไม่มีส่วนร่วมใด ๆ และในทางกลับกัน นักพัฒนา DevOps จะไม่มีความสนใจในเรื่องราวที่เน้นการใช้งานส่วนที่เหลือ และ เวลาในการประชุมก็จะเสียไปโดยส่วนใหญ่เช่นกัน
- มีผู้เชี่ยวชาญด้านฐานข้อมูลคนเดียวสำหรับทั้งทีม ขึ้นอยู่กับความซับซ้อนและการใช้งานโซลูชันข้อมูลในระบบที่ทีมกำลังพัฒนา บุคคลนี้อาจมีงานล้นมืออย่างต่อเนื่องกับเรื่องราวที่พวกเขาไม่มีโอกาสทำให้เสร็จโดยเร็ว โดยเฉพาะอย่างยิ่งเมื่อต้องคำนึงถึงลำดับความสำคัญของพวกเขา ที่แย่ไปกว่านั้น เรื่องราวอื่นๆ ก็ต้องรอเช่นกัน เนื่องจากขึ้นอยู่กับแหล่งข้อมูลที่จัดทำโดยเรื่องราวในฐานข้อมูล
- เมื่อผลิตภัณฑ์ใดผลิตภัณฑ์หนึ่งมุ่งเน้นไปที่การพัฒนาแบ็กเอนด์เป็นส่วนใหญ่ นักพัฒนาฟรอนต์เอนด์เพียงรายเดียวจะอยู่ในกรณีนี้ (เพราะในบางครั้ง จำเป็นต้องมีการเปลี่ยนแปลงเล็กน้อยแม้แต่ในแอปพลิเคชัน UI ก็ตาม) ในกรณีนั้น พิธีการต่อสู้ส่วนใหญ่จะทำให้สมาชิกในทีมเสียเวลาโดยเปล่าประโยชน์ เนื่องจากความรู้ของพวกเขาจำกัดอยู่แค่ส่วนหน้าเท่านั้น และอย่างอื่นไม่สำคัญ
มันสรุปที่ไหน
ในกรณีใดๆ ข้างต้น ผลลัพธ์คือผู้คนเสียเวลาเปล่า หรืออีกทางหนึ่งคือพวกเขาไม่สามารถรับมือกับความต้องการที่ค้างอยู่ได้ พวกเขากำลังปิดกั้นทีมที่เหลือไม่ให้เริ่มทำงานในเรื่องราวถัดไป หรือกำลังลดประสิทธิภาพโดยรวมของทีมต่อสู้อย่างมีประสิทธิภาพเพราะมีเวลามากเกินไปที่ไม่ได้ใช้ในการวิ่ง
อย่างไรก็ตามทีมยังคงมีนักพัฒนาจำนวนนี้ จากภายนอก จะมองไม่เห็น (แม้จะไม่อยากเปิดเผย) ว่าคนในทีมไม่สามารถรับเรื่องราวบางอย่างเพียงเพราะพวกเขามุ่งเน้นไปที่ชุดทักษะเฉพาะบางอย่างมากเกินไป ดังนั้นพวกเขาจึงไม่สามารถช่วยสมาชิกในทีมคนอื่นๆ เล่าเรื่องได้ แม้ว่าความสามารถของพวกเขาจะเอื้ออำนวยก็ตาม และลำดับความสำคัญของเรื่องราวก็สนับสนุนเช่นกัน
เป็นเรื่องยากสำหรับเจ้าของผลิตภัณฑ์ในการเขียนเนื้อหา Sprint ที่มีความหมายสำหรับทีม เนื่องจากเจ้าของผลิตภัณฑ์ต้องคำนึงเสมอว่าจะมีกี่คนที่สามารถทำงานได้ในทุก ๆ เรื่อง และหากมีการนำเรื่องราวที่คล้ายคลึงกันมาก ๆ มาสู่ Sprint ในเวลาเดียวกัน ในที่สุดความสามารถของทีมก็ล้นออกมา แม้ว่าในความเป็นจริงจะมีคนที่สามารถทำงานในเรื่องราวเหล่านั้นได้ แต่พวกเขาไม่มีทักษะที่จะเริ่มต้นกับสิ่งเหล่านั้น
การแก้ปัญหาภาวะที่กลืนไม่เข้าคายไม่ออก
เป็นภาวะที่กลืนไม่เข้าคายไม่ออกที่ต้องแก้ไข และผู้จัดการโครงการจะต้องทราบถึงเส้นทางที่จะเลือก โดยเฉพาะอย่างยิ่ง ตัวเลือกระหว่าง:
- การมีนักพัฒนาแบบฟูลสแต็กจำนวนมากที่สามารถทำงานกับเนื้อหาที่กว้างขึ้นได้ แต่ไม่เชี่ยวชาญในหลายๆ หัวข้อ จึงสามารถไปได้กว้างแต่ไม่ลึก จากนั้นการส่งมอบสามารถดำเนินการได้อย่างรวดเร็ว แต่คุณภาพอาจลดลง
- มีผู้เชี่ยวชาญเฉพาะด้านสำหรับแต่ละเทคโนโลยี แต่ก็ยอมรับข้อจำกัดและทำงานหนักขึ้นเพื่อเนื้อหาการพิมพ์ที่เหมาะสมกว่า จากนั้นผู้คนสามารถลงลึกและสร้างเรื่องราวที่ยอดเยี่ยมได้ แต่เรื่องราวจะต้องได้รับการติดต่อตามลำดับ จึงใช้เวลานานกว่าในการนำเสนอ
เจ้าของผลิตภัณฑ์ที่อ่อนแอ
สิ่งนี้ไม่จำเป็นต้องเป็น “ปัญหากระบวนการ” ตามคำจำกัดความ แต่ฉันปฏิบัติเช่นนั้นเพียงเพราะการสร้างเรื่องราวที่มั่นคงสามารถเข้าใจได้ว่าเป็นกระบวนการที่ทีมควรต้องการให้มีความแข็งแกร่งและเข้ากันได้กับทีมพัฒนา
สิ่งที่ฉันหมายถึงโดยผู้อ่อนแอไม่จำเป็นต้องหมายถึงคุณสมบัติความรู้ของบุคคล แต่หมายถึงความสามารถของเจ้าของผลิตภัณฑ์ในการให้บริการเรื่องราวของทีมซึ่งนักพัฒนาสามารถเข้าใจได้และเข้าใจได้ชัดเจนจากมุมมองของแผนงานผลิตภัณฑ์ ทั้งสองอย่างนี้มีความสำคัญมากสำหรับทีมการต่อสู้ที่ประสบความสำเร็จ
หากเรื่องราวขาดรายละเอียดสำหรับนักพัฒนาเพื่อให้สามารถเข้าใจวัตถุประสงค์ มูลค่าการทำงาน หรือความคาดหวังทางเทคนิคได้อย่างชัดเจน สถานการณ์โดยทั่วไปอาจเกิดขึ้นได้สองกรณี:
- นักพัฒนาจะสร้างสิ่งที่แตกต่างจากที่เจ้าของผลิตภัณฑ์ต้องการจริงๆ มันยากที่จะจับได้ในระหว่างการวิ่ง เพราะเจ้าของผลิตภัณฑ์ส่วนใหญ่ไม่มีความสามารถในการติดตามความคืบหน้าของเรื่องราวในระดับที่ละเอียดขนาดนั้น และส่วนใหญ่ PO จะคาดหวังว่าสิ่งนี้จะเกิดขึ้น (อย่างน่าอัศจรรย์)
- นักพัฒนาจะใช้เวลามากเกินไปในการอธิบายเรื่องราวและพูดคุยซ้ำแล้วซ้ำอีกแทนที่จะเริ่มสร้างมันขึ้นมา สิ่งนี้เกี่ยวข้องกับการเรียกเพิ่มเติมหลายครั้ง ข้อตกลงซ้ำๆ และการเลื่อนงานไปสู่ระยะสปรินต์ล่าช้า ถึงจุดที่ไม่สามารถพิจารณาการประมาณการเดิมของเรื่องราวได้อย่างถูกต้องอีกต่อไป และเรื่องราวต่างๆ ไม่สามารถปิดลงได้ภายในการวิ่ง และกำลังเข้าสู่การวิ่งครั้งต่อไป ในกรณีที่เลวร้ายที่สุด สถานการณ์จะเกิดขึ้นซ้ำในการวิ่งครั้งต่อไป
เวลาสำหรับการทบทวนตนเอง
โดยปกติแล้วยากที่จะยอมรับ แต่เจ้าของผลิตภัณฑ์ควรหาเวลาไตร่ตรอง ดูเรื่องราวที่ค้างอยู่ที่สร้างขึ้น และท้ายที่สุดให้เปรียบเทียบกับวิสัยทัศน์ของแผนงานผลิตภัณฑ์ หากยังมีความเชื่อมโยงที่เหมาะสมระหว่างสองสิ่งนี้ หากมีแผนงานใดๆ เลย ถ้าไม่นั่นคือสิ่งแรกที่ต้องแก้ไข บางครั้ง วิธีแก้ไขคือต้องยอมรับว่า Product Owner อยู่ห่างจากทีมมากเกินไป และห่างจากเป้าหมายของตัวเองมากเกินไป
ในกรณีเช่นนี้ จะต้องแก้ไขส่วนของเจ้าของผลิตภัณฑ์ในทีม หากไม่มีอะไรอื่น การนำนักวิเคราะห์ธุรกิจที่มั่นคงเข้ามาร่วมทีมโดยมุ่งเน้นที่เนื้อหาของทีมมากกว่าเนื้อหาทางธุรกิจ (ในกรณีนี้ เรามีเจ้าของผลิตภัณฑ์อยู่แล้ว) อาจเป็นตัวเลือกที่ถูกต้อง แม้สำหรับราคาของ เพิ่มต้นทุนรวมของทีม
กระบวนการทดสอบโดยไม่มีไทม์ไลน์ที่แน่นอน
จะเป็นอย่างไรหากกิจกรรมการทดสอบไม่แน่นตามกำหนดการที่เป็นรูปธรรมภายในการต่อสู้แบบสครัมสปรินต์
เมื่อมองแวบแรก สิ่งนี้อาจดูเหมือนเป็นสิ่งที่ดีที่เราต้องการสำหรับทีมที่คล่องตัว/การต่อสู้ ยินดีต้อนรับความยืดหยุ่นเสมอและฟังดูดีเมื่อนำเสนอภายนอก
ประสบการณ์ของฉันแสดงให้เห็นว่าผลลัพธ์ของอิสรภาพนี้คือความวุ่นวายมากกว่าความยืดหยุ่น ไม่ได้หมายความว่าวิธีแก้ปัญหานี้ควรเป็นการสร้าง “น้ำตกภายในการวิ่ง” โดยมีขั้นตอนการทดสอบเฉพาะตามหลังการพัฒนาเสร็จสิ้น นี่ไม่ใช่แนวทางที่ถูกต้องในกรณีนี้ คุณสามารถอ่านเพิ่มเติมเกี่ยวกับเรื่องนี้ได้ในโพสต์ของฉันเกี่ยวกับกลยุทธ์การทดสอบการต่อสู้และวงจรชีวิตการทดสอบที่คล่องตัว
เรายังคงสามารถยืดหยุ่นได้และเลือกกำหนดการทดสอบตามที่เห็นสมควรที่สุดสำหรับทีมพัฒนาปัจจุบันและคุณสมบัติผลิตภัณฑ์ที่กำหนดที่ทีมนำเสนอ อย่างไรก็ตาม มีเป้าหมายหลักสองประการที่ควรทำให้สำเร็จด้วยตัวเลือกนี้:
หากตรงตามเงื่อนไขเหล่านั้น ทีมงานจะปรับให้เข้ากับกระบวนการฟิตติ้งโดยธรรมชาติ และกำหนดการส่งมอบจะไม่ได้รับผลกระทบจากกิจกรรมการทดสอบที่ยืดเยื้อโดยไม่ได้วางแผน
ในท้ายที่สุด สิ่งที่สำคัญที่สุดก็คือ Sprint Release ที่น่าเชื่อถือและคาดการณ์ได้ ซึ่งนำฉันไปสู่จุดสุดท้ายของบล็อกนี้
กระบวนการวางจำหน่ายที่ไม่ได้กำหนด
นี่เป็นสิ่งที่ชัดเจนมากสำหรับทีมการต่อสู้แต่ละทีม ยังน่าแปลกที่มันมักจะเป็นหนึ่งในกระบวนการที่ถูกประเมินต่ำที่สุด
บ่อยครั้งที่ทีม Scrum จะบอกว่าการปล่อยตัวจะเกิดขึ้นหลังจากการวิ่งแต่ละครั้ง แต่มันไม่ได้สำรองไว้โดยกระบวนการที่มั่นคง สิ่งที่เกิดขึ้นในความเป็นจริงคือกิจกรรมที่วุ่นวายและคาดเดาไม่ได้มากมายที่จะเกิดขึ้นในช่วงเวลาปล่อยตัว จู่ๆ ทุกคนก็หมกมุ่นอยู่กับ “งานรีลีส” และไม่มีใครสามารถจดจ่อกับการพัฒนาเรื่องราวการวิ่งใหม่ๆ ต่อไปได้ การวัด Sprint ปิดอยู่ และการปล่อยดูเหมือนเป็นกิจกรรมแบบสุ่มที่คาดเดาไม่ได้จากมุมมองของบุคคลที่สาม (โดยปกติคือไคลเอนต์)
ผู้คนต่างจดจ่อกับงานค้าง เนื้อหา Sprint การพัฒนา การทดสอบ และท้ายที่สุดก็แสดงผลลัพธ์จนลืมไปว่าเมื่อทำทั้งหมดนี้เสร็จแล้ว Sprint ถัดไปก็ดำเนินต่อไปแล้ว และพวกเขาก็เสียเวลาไปแล้ว
กำลังมองหาช่วงเวลาที่ดีในการปลดปล่อย
เมื่อไหร่ที่ทีมควรจะปล่อยสู่การผลิตจริงกันแน่? สิ่งสำคัญสิ่งเดียวที่สำคัญในตอนท้าย
คำตอบสำหรับคำถามนั้นอยู่ในกระบวนการโดยสมมติว่าคุณมี ขึ้นอยู่กับ:
- ความซับซ้อนของเนื้อหาที่ทีมกำลังผลิตในการวิ่ง
- ระยะเวลาของการวิ่ง
- จำนวนส่วนประกอบที่ได้รับผลกระทบในระบบ
- จำนวนผู้ใช้และขอเปลี่ยนแปลง
ควรมีการสร้างกระบวนการเผยแพร่ซ้ำและปฏิบัติตามต่อไป กฎที่แน่นอนของกระบวนการสามารถยืดหยุ่นในการกำหนดได้อีกครั้ง แต่เนื่องจากเป็นกิจกรรมการทดสอบ การทำให้มันกลายเป็นนิสัยที่มั่นคงซึ่งสามารถคาดเดาได้และกำหนดเวลาสำหรับวันที่เป็นรูปธรรมในอนาคต ทำให้เป็นสิ่งที่ต้องพึ่งพาและอ้างถึง
ตัวเลือกที่จะเลือก
รูปแบบที่เป็นไปได้ของกระบวนการดังกล่าวอาจเป็นรูปแบบใดรูปแบบหนึ่งต่อไปนี้หรืออื่นๆ:
- ทำการทดสอบคุณสมบัติจากสปรินต์ปัจจุบันให้เสร็จสิ้นระหว่างสปรินต์ต่อไปนี้ และปล่อยเนื้อหาเมื่อสิ้นสุดสปรินต์นั้น (เมื่อการทดสอบเสร็จสิ้น) ซึ่งหมายความว่าแต่ละรีลีสจะไม่มีเนื้อหาใดๆ จากสปรินต์สุดท้าย แต่จะมีเรื่องราวจาก 2 สปรินต์ก่อนหน้า
- การวิ่งครั้งสุดท้ายก่อนปล่อยมีไว้เพื่อทดสอบเนื้อหาจากการวิ่งสองครั้งก่อนหน้านี้เสมอ
- นี่ไม่ได้หมายความว่าการพัฒนาในช่วง “ทดสอบการวิ่ง” จะหยุดลง มันบอกเพียงเนื้อหาที่พัฒนาขึ้นในการทดสอบการวิ่งนั้นจะไม่รวมอยู่ในรุ่นถัดไป
- หากมีกิจกรรมการทดสอบอัตโนมัติเพียงพอแล้ว ให้พยายามเผยแพร่หลังจากสิ้นสุดการวิ่งแต่ละครั้ง นี่ต้องเป็นกระบวนการที่เคร่งครัดมากโดยบุคลากรที่ทุ่มเทมุ่งเน้นไปที่สองสามวันนั้น 100% มันไม่ควรส่งผลกระทบต่อทีมพัฒนาที่เหลือ แต่อย่างใด
- คุณยังสามารถเลือกที่จะปล่อยหนึ่งครั้งต่อเดือนหรือหนึ่งครั้งต่อ N เดือน โดยหลักแล้วหากเป็นเช่นนั้นก็ไม่เป็นไรจากมุมมองของผู้ใช้ปลายทาง สิ่งนี้จะเพิ่มความพยายามในด้านการทดสอบสำหรับการวิ่งแต่ละครั้ง (เนื่องจากเนื้อหาจะใหญ่ขึ้นสำหรับแต่ละรุ่น) แต่ในทางกลับกัน มันจะหมายถึงกิจกรรมซ้ำๆ เมื่อเวลาผ่านไปน้อยลง ซึ่งในกรณีนี้อาจมีประโยชน์ต่อทีม ผลที่ได้คือช่วยให้ทีมสร้างฟีเจอร์ใหม่ๆ ได้มากขึ้นระหว่างการเผยแพร่ แม้ว่าฟีเจอร์ดังกล่าวจะเข้าสู่กระบวนการผลิตจริงด้วยจังหวะที่ช้าลงก็ตาม
แต่ดังที่ได้กล่าวไว้ก่อนหน้านี้สองสามครั้ง การเลือกกระบวนการใดในกระบวนการเหล่านั้นไม่สำคัญมากนัก มันสำคัญกว่ามากที่ทีมจะปฏิบัติตามกระบวนการนั้นได้ดีเพียงใดและจะทำให้มันเป็นนิสัยที่ทำงานหนัก
คุณยังสามารถอ่านคู่มือนี้เกี่ยวกับกระบวนการและหลักปฏิบัติในการจัดการรุ่น
