#priwreadbooks Release Planning — Tuning Product Development การวางแผนเปิดตัว และปรับแต่งแผนอยู่เสมอ

บทความนี้อ่านและสรุปจากหนังสือ The Professional ScrumMaster’s Handbook บทที่สอง Release Planning — Tuning Product Development

การวางแผนเปิดตัว และปรับแต่งแผนอยู่เสมอ

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

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

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

น่าเสียดายที่ไม่มีทีมใด (หรือนักพยากรณ์อากาศคนใด) สามารถทำนายอนาคตได้

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

ตัวอย่างเช่น หากโครงการเปลี่ยนทิศทางตอนที่ดำเนินการไปแล้วครึ่งทาง เนื่องจากความต้องการของลูกค้าเปลี่ยนไป ถือเป็นความล้มเหลวหรือไม่? ทีม Agile จะบอกว่า “ไม่” และจริงๆ แล้ว การตอบสนองต่อความต้องการที่เปลี่ยนแปลงไปนั้น ถือเป็นเรื่องที่ประสบความสำเร็จ

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

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

แผนทำให้เรารู้สึกปลอดภัย จนกว่ามันจะถูกเปลี่ยน

คำแนะนำคือ

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

ขั้นแรก คิดให้แตกต่างเกี่ยวกับการวางแผน

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

“การปรับตัวอย่างต่อเนื่อง” เป็นการปรับตัวทางธุรกิจที่ทันสมัยอย่างแท้จริง

Mary Poppendieck ผู้เขียน Lean Software Development: An Agile Toolkit กล่าวว่า บริษัทที่ประสบความสำเร็จไม่ได้สร้างแผนและดำเนินการ แต่พวกเขาสร้างความสามารถและตอบสนองต่อความเป็นจริงเมื่อมันปรากฎขึ้น

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

การวางแผน

• release planning สำหรับระยะยาว
• sprint planning สำหรับระยะสั้น

ทั้งคู่ใช้ product backlog เป็นข้อมูลในการวางแผน

Scrum framework คือ Deming Cycle incarnate: plan-do-check-act ความรู้เกี่ยวกับ ข้อกำหนด เทคโนโลยี และการโต้ตอบส่วนบุคคล เกิดขึ้นตลอดวงจรชีวิตของโครงการ

การวางแผนโดยมีรายละเอียดเพียงพอสำหรับกรอบเวลาสั้นๆ และผลลัพธ์ที่คาดหวังนั้นจึงสมเหตุสมผล

แผนระยะยาวมีความหยาบในการวางแผนและการประมาณการณ์ ในขณะที่แผนระยะสั้นมีรายละเอียดมากกว่า

• แผนงานระยะยาว (ปี ในบางกรณี)
• แผนการ Release มักจะใช้เวลาหนึ่งถึงสามเดือน (อาจจะนานกว่านั้น) ซึ่งเกี่ยวกับสิ่งที่ทีมจะไม่ทำ พอๆ กับ สิ่งที่พวกเขาพยายามจะทำ
• แผนระดับ Sprint เพื่อให้ทีมมุ่งมั่นกับงานจำนวนหนึ่ง เพื่อเป้าหมายระยะสั้น (1–4 สัปดาห์)

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

• Release planning แสดงถึงทิศทาง เป้าหมาย หรือผลลัพธ์ ที่ทีมควรเห็นพ้องต้องกัน
• Sprint planning คือการวางแผนสำหรับสิ่งที่เราสามารถทำได้เป็นเวลาหนึ่ง สอง หรือสี่สัปดาห์

เทคนิคการวางแผนแบบปรับเปลี่ยนได้ = การปรับการพัฒนาผลิตภัณฑ์ให้ตรงตามความต้องการของผู้ใช้และลูกค้า

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

เนื่องจากความต้องการเหล่านี้มีการเปลี่ยนแปลงอยู่เสมอ

Start at the beginning — product backlog

Product backlog คือ รายการคุณสมบัติหรืองานที่จะดำเนินการ ที่ถูกจัดลำดับ มันอาจมีความยาวไม่สิ้นสุด อาจมีข้อกำหนดใหม่อยู่เสมอ เจ้าของผลิตภัณฑ์คือลูกค้าจริงหรือตัวแทนภายในองค์กร มีหน้าที่ดูแล อัปเดต จัดการ และจัดอันดับงาน ด้วยการวิจัยตลาด คำชี้แจงเกี่ยวกับวิสัยทัศน์ผลิตภัณฑ์ การวิเคราะห์อุตสาหกรรม นวัตกรรมทางเทคนิค หรือแม้แต่แนวคิดที่อยากจะทดสอบ

Product backlog แสดงถึง สิ่งที่เจ้าของผลิตภัณฑ์คิดว่า นี่คือไอเดียและฟีเจอร์ที่มีคุณค่าที่สุดของผลิตภัณฑ์

เมื่อทีมได้เลือก วางแผน และกำหนด backlog items ให้กับ Sprint แล้ว เจ้าของผลิตภัณฑ์จะไม่สามารถเปลี่ยนแปลงรายการเหล่านั้นได้ อย่างไรก็ตาม เจ้าของผลิตภัณฑ์สามารถ จัดเรียงลำดับความสำคัญ เปลี่ยนข้อกำหนด และลบบางรายการออกได้ ถ้า items นั้นยังไม่ถูกเลือกเข้า Sprint

เจ้าของผลิตภัณฑ์ ต้องจัดลำดับและเตรียมรายละเอียดสำหรับ backlog items ของผลิตภัณฑ์ที่สำคัญที่สุดสำหรับ Sprint planning ครั้งต่อไป และควรจัดลำดับความสำคัญและเตรียมกลุ่มฟีเจอร์ที่ต้องการสำหรับการ release หน้า เพื่อนำไปใช้ใน Release planning ด้วย

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

Product backlog เป็นข้อมูลพื้นฐานสำหรับการวางแผนทั้งระยะยาวและระยะสั้น

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

วิธีการที่ลีนที่สุดคือ ดึงรายการบนสุดจาก backlog เอาไปดำเนินการให้เสร็จสิ้น แล้วส่งขึ้น Production ตามด้วยรายการถัดไป “one item at a time”

Focus product backlogs on users and values

เขียน product backlogs และวางแผน release ด้วยผลิตภัณฑ์หรือฟีเจอร์ ไม่ใช่ส่วนประกอบของระบบ เช่น “ผู้ใช้สามารถดูรายการผลิตภัณฑ์ในหน้าหลักได้” ไม่ใช่เขียนว่า “อัปเดต CSS เพื่อจัดการรูปแบบอักษร”

การมีแผนของผลิตภัณฑ์ในมุมมองและภาษาเดียวกับผู้ใช้ ช่วยให้เจ้าของผลิตภัณฑ์เชื่อมโยงแผนการ release เข้ากับจังหวะของตลาดได้ ในหลายกรณี การวางแผนในระดับที่สูงกว่าซึ่งเรียกว่า product roadmap จะมาก่อน release plan

Product backlogs, roadmaps และ release plans ช่วยให้เจ้าของผลิตภัณฑ์และทีมเห็นภาพทั้งหมด

แนวคิดแบบลีน เตือนให้เราถอยกลับไปมองภาพรวมเป็นครั้งคราว ไม่ใช่แค่รายละเอียดในแต่ละวัน

• Product Backlog A วางแผนจากผู้ใช้งานว่า สามารถทำอะไรได้ ช่วยให้เจ้าของผลิตภัณฑ์ลงรายละเอียดคุณสมบัติ จัดลำดับความสำคัญตามคุณค่าได้
• Product Backlog B อาจจะเหมาะสมสำหรับ Sprint Backlog ซึ่งติดตามกันแบบวันต่อวันโดยทีมพัฒนา

สิ่งสำคัญคือ เจ้าของผลิตภัณฑ์และทีม เข้าใจถึงความสำคัญของ product backlog items ที่แสดงถึง สิ่งที่ผู้ใช้จะได้รับคุณค่า

Product backlog items อาจจะมีชื่อเรียกหลายชื่อ แต่สิ่งสำคัญคือ เขียนด้วยภาษาที่ทุกคนเข้าใจ พยายามใช้ภาษาของผู้ใช้หรือภาษาฝั่งธุรกิจ

Product backlog ควรมีรายละเอียดอย่างน้อยสามเรื่องคือ rank/order, a description, and an estimate (or cost)

Product backlog เป็นการวางแผน และเครื่องมือสื่อสารที่ผู้คนจำนวนมากที่มีทักษะและความรับผิดชอบต่างกันจะเข้ามาดู

Engage the team early

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

การทำ Paper prototyping ช่วยทีม brainstorm ได้ ทำงานร่วมกันและทำความเข้าใจว่าผู้ใช้จะใช้ระบบอย่างไร นอกจากนี้ยังสามารถดูได้ว่า พวกเขาพลาดเรื่องราวที่สำคัญจุดไหนของผู้ใช้หรือไม่

การทำ Paper prototyping session ช่วยให้ทีมมองเห็นผลิตภัณฑ์ การทำงานร่วมกันเป็นทีม ความเข้าใจกัน และร่วมกันสร้าง product backlog items

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

Prioritization can be useful for other things

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

จากภาพจะเห็นว่ามัน high level มาก

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

Release planning — when will you set your features free?

เมื่อองค์กรต้องการให้ทีมคาดการณ์ขอบเขตและช่วงเวลาสำหรับการ release พวกเขาจะต้องวางแผน

Timing of releases and release planning

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

เจ้าของผลิตภัณฑ์น่าจะมีแนวคิดเกี่ยวกับกรอบเวลาการเปิดตัว ก่อนที่งานใดๆ จะเริ่มขึ้น

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

การวางแผนการ release จะเกิดขึ้นก่อนที่โครงการจะเริ่มขึ้น หรือบางทีก็ผ่านไปหลาย Sprint จนได้ Velocity ของทีม ไม่ว่ามันจะเกิดขึ้นเมื่อใดหรืออย่างไร เจ้าของผลิตภัณฑ์และทีมควรทบทวน release plan ตลอดระยะเวลาของโครงการ เนื่องจากสถานการณ์จะเปลี่ยนแปลงอยู่เสมอ

Don’t create the software big dig

Boston’s Central Artery/Tunnel project

• ค่าใช้จ่ายประมาณการโครงการ เริ่มต้นคือ 2.5 พันล้านดอลลาร์ โดยคาดว่าจะแล้วเสร็จในปี 2541
• ประมาณการเพิ่มขึ้นเป็น 14 พันล้านดอลลาร์ภายในปี 2549
• เปลี่ยนหลอดไฟที่เสื่อมสภาพ 25,000 ชิ้นจนถึงทุกวันนี้ โดยคิดเป็นเงินเพิ่มอีก 54 ล้านดอลลาร์

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

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

มีความไม่แน่นอนและความซับซ้อนอยู่มากในช่วงเริ่มต้นของโครงการ เป็นเรื่องโง่เขลาที่ผู้รับเหมารายใดจะเสนอราคาตามจำนวนที่กำหนด และเป็นเรื่องโง่เขลาที่ Massachusetts Turnpike Authority จะยอมรับเช่นนั้น

อย่างไรก็ตาม เราอยู่ในโลกที่การเสนอราคาต่ำและสัญญาที่ไม่ชัดเจน มักจะชนะสัญญา

Integrate early and often to mitigate risks

การรวมร่าง(โค้ด) กันบ่อยๆ ตั้งแต่ต้นโครงการและตลอดการพัฒนา

ฟีเจอร์จะเสร็จสิ้นเมื่อโค้ดของคนๆ หนึ่ง ทำงานร่วมกับโค้ดของคนอื่นๆ และผ่านการทดสอบทั้งหมด

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

การไม่ปฏิบัติตามนี้จะขัดขวางความสามารถขององค์กรในการตอบสนองความต้องการเร่งด่วนที่สุดของลูกค้า

Make buffers visible

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

ถ้าทีมประเมินบัฟเฟอร์ไว้มากเกินไป พวกเขาสามารถดึงเรื่องราวอีกสองสามเรื่องเพิ่มเข้าสู่การ release ได้ ซึ่งดีกว่าการโดนตัดเรื่องราวออกอย่างแน่นอน

การบัฟเฟอร์สำหรับความไม่แน่นอน หมายถึง
การไม่วางแผน Sprint แต่ละครั้งให้มีความจุสูงสุด 100%
อาจจะวางแผนเพียง 75%

หากพวกเขาต้องรับผิดชอบและโดนยัดเยียดให้วางแผนเต็ม 100% หลังจากสองสามรอบ Sprint พวกเขาจะตระหนักได้ว่า “ทุ่มเทมากเกินไป” และทำได้เพียงชะลอการสนทนาที่หลีกเลี่ยงไม่ได้นี้ออกไปเท่านั้น

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

ยิ่งทีมและเจ้าของผลิตภัณฑ์มีความไม่แน่นอนมากเท่าไร พวกเขาก็ยิ่งควรบัฟเฟอร์มากขึ้นเท่านั้น

บางทีมใช้บัฟเฟอร์โดยเว้นว่างไว้ทั้งสปรินต์หรือสองอันในตอนท้าย

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

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

ทีม Scrum ควรเป็นพันธมิตรกับเจ้าของผลิตภัณฑ์ ในความสัมพันธ์ที่เป็นหุ้นส่วนกันนี้ ทั้งสองฝ่ายควรดำเนินการด้วยความโปร่งใส

Release planning ไม่ใช่กิจกรรมบังคับ เอกสาร Scrum Guide เดิมไม่ได้กล่าวถึงด้วยซ้ำ

ถ้าทีมมีความสามารถเอางานขึ้น production เวลาใดก็ได้ มีเจ้าของผลิตภัณฑ์ที่มีความยืดหยุ่นกับวันที่และขอบเขตงาน ก็ไม่ต้องมีกิจกรรมนี้ก็ได้

• Release planning เป็นการพยากรณ์ คุณสมบัติบางอย่างอาจต้อง traded-off หรือยกเลิก
• Release planning ไม่ได้เป็นแค่สิ่งที่ทีมจะค้นหาว่าจะมีอะไรอยู่ใน release นั้น แต่รวมถึงการตัดสิ่งที่จะไม่อยู่ใน release นั้นด้วย

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

เป้าหมายของเกมนี้คือ การจัดเรียงรายการใน backlog ให้อยู่ในกรอบเวลาที่เหมาะสม เพื่อตอบสนองความต้องการทางธุรกิจ

ในวงการเทคโนโลยี สิ่งต่างๆ ไม่เคยเข้ากันได้อย่างสมบูรณ์

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

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

How to conduct a release planning event?

Release planning จะจัดขึ้นเพียงครั้งเดียว พยายามพบปะแบบเห็นหน้ากัน

• พื้นที่ประชุมมีกระดานไวท์บอร์ด ปากกาไวท์บอร์ด ฟลิปชาร์ต ปากกามาร์คเกอร์ กระดาษโน้ตจำนวนมาก
• release date ที่ต้องการ คุณอาจได้รับสิ่งนี้จากเจ้าของผลิตภัณฑ์
• เจ้าของผลิตภัณฑ์มี product vision และข้อมูลเกี่ยวกับผู้ใช้ ตลาด ลูกค้า personas และอื่นๆ เป็นประโยชน์สำหรับทีมในการทำความเข้าใจภาพรวม ปัญหาโดยรวมที่พวกเขาพยายามแก้ไข หรือวิธีที่พวกเขาจะทำให้ลูกค้าพึงพอใจ เมื่อสมาชิกในทีมพัฒนาเห็นภาพรวมทั้งหมด พวกเขามักจะคิดไอเดียใหม่ๆ ขึ้นมา
• ต้องใช้กี่ sprints ในการทำงาน แต่ละ sprint มีความยาวหนึ่ง สอง สาม หรือสี่สัปดาห์
• ใครจะเป็นคนยุติ release
• ทีมงานมีใครคอยจัดการกับ คำจำกัดความของ Done หรือไม่? ถ้าไม่ พวกเขาสามารถใช้วิธีแก้ปัญหาใดได้บ้าง
• มีขั้นตอนการผลิตหรือโปรโตคอลที่ทีมงานต้องปฏิบัติตามหรือไม่? เช่น การได้รับเครื่อง การตั้งค่าสภาพแวดล้อมการพัฒนา กรอบการทดสอบ และอื่นๆ
• มี release process ก่อนเอาขึ้น production หรือไม่? มันคืออะไร ส่งผลต่อ release plan อย่างไร?
• ทีมมี Velocity หรือไม่? ถ้าไม่ จะต้องมีการฝึกวางแผนกำลังการผลิต
• ถ้าทีมมีปัญหาหรืออุปสรรค จะแจ้งเรื่องราวกับใคร?
• product backlog จะเก็บไว้ที่ใด เจ้าของผลิตภัณฑ์ทำให้ทีมมองเห็นได้หรือไม่?
• ทีมเข้าใจ Scrum framework หรือไม่?
• เราจะเก็บ Sprint Backlogs และ Burndowns ไว้ที่ไหน? ข้อมูลโครงการอื่นๆ ล่ะ?
• เราควรเชิญผู้มีส่วนได้เสียอื่นๆ หรือไม่?
• ความเสี่ยงใดที่มีอยู่ใน release ปัจจุบัน? เรารู้หรือไม่ว่ามีอุปสรรคใดๆ ที่เรามีในวันนี้? สมาชิกในทีมคนใดจะหายไปนานหรือไม่?

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

Facilitating the release planning meeting

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

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

สิ่งสำคัญคือ แม้ว่าจะมีผู้มีส่วนได้ส่วนเสียรายอื่นเข้าร่วม แต่เจ้าของผลิตภัณฑ์ยังคงเป็นเจ้าของลำดับและรายละเอียดเชิงลึก (depth) ของ product backlog items

จิตวิญญาณของการประชุม release planning คือ สมาชิกในทีมและเจ้าของผลิตภัณฑ์แบ่งปันวิสัยทัศน์และร่วมกันสร้างแผน

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

• Short introduction
• Review the roles and responsibilities for release planning
• Product vision and business goals, high-level walkthrough of the highest priority user stories
• High-level release schedule
• Team members’ allocations to the release, percentage of dedication to the effort, and include a risk
• Review the Definition of Done and refine it if necessary
• Understand velocity ถ้ายังไม่มีใช้ “Gut” method หรือ “Value of 1” method
• Place stories into sprints
• ‘walk the wall’ and voice any concerns or risks
• commit to the release forecast

จำเป็นอย่างยิ่งที่เจ้าของผลิตภัณฑ์จะต้องเข้าร่วมและมีส่วนร่วมในระหว่างการทำ release planning เพราะถ้าเขาไม่มา ทีมอาจส่งมอบฟีเจอร์ที่ไม่ถูกต้อง และมันถือเป็นความเสี่ยง

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

The physical space

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

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

• มีเก้าอี้เพียงพอสำหรับทุกคนและหันหน้าเข้าหากัน
• วางปากกาและกระดาษโน้ตไว้บนโต๊ะ มีเพียงพอสำหรับทุกคน
• วางฟลิปชาร์ตไว้บนผนังเพื่อเก็บข้อมูลและแสดงข้อมูลชี้นำใดๆ เช่น คำจำกัดความของ DoD ระเบียบวาระการประชุม และกฎพื้นฐาน
• สมุดบันทึกเพื่อจดบันทึกและเตือนความจำ
• หาก product backlog อยู่ในรูปแบบอิเล็กทรอนิกส์ให้เขียนลงในกระดาษโน้ต
• ตรวจสอบกำหนดการ มองหาโอกาสสำหรับกิจกรรมกลุ่ม
• รับแสงธรรมชาติ ห้องมีอุณหภูมิที่ดี
• หากมีสมาชิกทีมทางไกลสองสามคน ให้ส่งคำเชิญ รับสมัครอาสาสมัคร (ไม่ใช่สมาชิกในทีม) เข้าร่วมการประชุม เพื่อ stream planning artifacts และ work products ไปยังสมาชิกในทีมทางไกล

Definition of Done (DoD)

“คำจำกัดความของ Done” สำหรับการ release และสำหรับแต่ละ Sprint นั้นจำเป็นต่อการกำหนดความคาดหวัง และให้สอดคล้องกับ Mindset ของการสร้างสิ่งที่มีคุณภาพ นอกจากนี้ ยังป้องกันความสับสนมากมาย ยกตัวอย่าง DoD เช่น

• ไม่มีข้อบกพร่องหลงเหลือ (ระดับความรุนแรง 1, 2 หรือ 3)
• เวลาในการโหลดหน้าเว็บไซต์น้อยกว่าหนึ่งวินาที
• integration tests are automated

Release planning output

อาจจะออกมาหน้าตาแบบนี้

หรือ ใช้เส้นคาดใน product backlog

• เหนือเส้นตัดสำหรับสิ่งที่จะได้รับการ release
• อะไรก็ตามที่ต่ำกว่าเส้น จะไม่ release

Backlog ของผลิตภัณฑ์ที่มีรายละเอียดเพิ่มเติม

ช่วยแสดงสถานะของรายการได้อย่างง่ายดาย มีการเพิ่ม จำนวนสปรินต์ที่วางแผนไว้และสปรินต์ที่ใช้ทำจริง รวมถึง Velocity ที่วางแผนไว้และที่ทำได้จริง

และไทม์ไลน์ release planning ที่แสดงข้อมูลระดับสูง (หรือฟังก์ชันการทำงานบางส่วน) พร้อมลำดับเวลาการส่งมอบโดยประมาณ

สิ่งนี้มีประโยชน์สำหรับการสื่อสารกับผู้บริหาร

ในการประชุมกับผู้มีส่วนได้ส่วนเสีย คุณควรพูดว่า

“นี่คือการคาดการณ์ของเรา ตามสิ่งที่เรารู้ในวันนี้”

ทุกๆ Sprint ทำให้แผนโปร่งใส และจัดการความคาดหวังของผู้มีส่วนได้ส่วนเสีย อย่าจมอยู่กับแรงกดดันขององค์กรที่มีอยู่

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

ทีมงานและเจ้าของผลิตภัณฑ์ ต้องทบทวนแผนเป็นระยะ และทำงานร่วมกันเพื่อมอบคุณลักษณะที่สร้างความพึงพอใจให้กับลูกค้า