"We're Agile" กลายเป็นวิธีที่ดูน่าเชื่อถือในการปฏิเสธการให้วันที่คณะกรรมการโครงการยังคงต้องการทราบว่าจะมีอะไรส่งมอบและอะไรที่ไม่ส่งมอบก่อนหน้าต่างกฎระเบียบครั้งถัดไป การเปิดตัวผลิตภัณฑ์ หรือการจัดสรรทุน ผู้สนับสนุนการเปลี่ยนแปลงยังคงถูกถามหาคำมั่นสัญญาในภาษาที่ผู้บริหารเข้าใจ การเคลื่อนไหวที่ซื่อสัตย์คือไม่สร้างวันที่ส่งมอบเดียวพร้อม contingency แบบเงียบ ๆ แต่เป็นการแลกเปลี่ยนความแน่นอนเท็จด้วยความน่าจะเป็นที่ชัดเจน: คุณลักษณะ X ภายในวันที่ Y ด้วยความมั่นใจประมาณ 87 เปอร์เซ็นต์ โดยอิงจากวิธีที่ทีมส่งมอบงานจริง ๆ
องค์กรที่ผ่านการฝึกแบบ Waterfall มักเข้าใจ Agile ว่าเป็นการอนุญาตให้หยุดให้คำมั่นสัญญา การตีความนี้สะดวกแต่ผิด Agile เปลี่ยนหน่วยของการวางแผน ความยาวของวง feedback และความซื่อสัตย์ของการพยากรณ์ แต่ไม่ได้ลบความจำเป็นสำหรับรายการผลลัพธ์ที่จัดลำดับความสำคัญหรือคำตอบที่รับได้สำหรับคำถาม "เมื่อไหร่"
สิ่งที่ Agile เปลี่ยนแปลงจริง ๆ (และสิ่งที่ไม่เปลี่ยน)
สิ่งที่เปลี่ยนแปลงคือรูปแบบของคำสัญญา คุณหยุดการแช่แข็งแผนการแบ่งงาน 12 เดือนที่แสร้งว่าความไม่แน่นอนถูกกำจัดแล้ว คุณเริ่มทำงานกับ backlog ที่จัดอันดับ คุณส่งมอบชิ้นส่วนบ่อยพอที่ผลิตภัณฑ์และธุรกิจสามารถปรับทิศทางได้ คุณอัปเดตการพยากรณ์เมื่อมีข้อมูลการส่งมอบเข้ามา
สิ่งที่ไม่เปลี่ยนคือความรับผิดชอบ ยังคงมีคนรับผิดชอบผลลัพธ์ ยังคงมีคนตัดสินใจสิ่งที่อยู่ในและนอกขอบเขตเมื่อความน่าจะเป็นที่จะถึงวันที่ลดลง ผู้กำกับดูแล คณะกรรมการ และคู่สัญญายังคงใช้ปฏิทิน การเรียกโปรแกรมว่า Agile ไม่ได้ทำให้ปฏิทินเหล่านั้นเป็นทางเลือก
โหมดล้มเหลวในธนาคารและบริษัทประกันภัยสามารถคาดเดาได้ ผู้นำนำชื่อพิธีกรรมมาใช้ รักษาปฏิทินการกำกับดูแลแบบ waterfall แล้วถือว่าคำขอวันที่ใด ๆ เป็นการต่อต้าน Agile ทีมส่งมอบปกป้องตัวเองด้วย "ขึ้นอยู่กับ" ผู้สนับสนุนเติมช่องว่างด้วยละคร Gantt: หนึ่งไมล์สโตนรูปเพชร แถบสีเขียวหนึ่งอัน และทะเบียนความเสี่ยงที่ไม่มีใครเชื่อ ไม่มีใครโกหกในความหมายที่น่าทึ่ง ทุกคนกำลังใช้ภาษาการวางแผนที่ไม่สามารถแสดงความไม่แน่นอนได้โดยไม่ดูไร้ความสามารถ
ระบบปฏิบัติการขั้นต่ำ
มีสามสิ่งที่ไม่สามารถต่อรองได้
ประการแรก รายการผลลัพธ์ที่จัดลำดับความสำคัญและงานที่ทำให้เกิดผลลัพธ์นั้น หากทุกอย่างเป็น P1 ก็ไม่มีอะไรเป็นลำดับความสำคัญ ลำดับความสำคัญคือการตัดสินใจของผลิตภัณฑ์และธุรกิจ ไม่ใช่การต่อรองระหว่าง squads ว่าตั๋วของใครดังกว่า
ประการที่สอง ผลิตภัณฑ์และธุรกิจให้ feedback ทุก sprint (หรือช่วงเวลาสั้นที่เทียบเท่า) การพยากรณ์โดยปราศจากการนำทางยังคงเป็นละคร หากผู้ที่สามารถลดขอบเขตหรือเปลี่ยนเกณฑ์การยอมรับปรากฏตัวเฉพาะที่ขอบเขต PI คุณจะเผา sprint กับงานที่ผิดแล้วโทษการพยากรณ์
ประการที่สาม แสดงความน่าจะเป็นตามวันที่ "เราจะพยายามที่สุด" ไม่ใช่การพยากรณ์ "เสร็จภายในวันพฤหัสบดีด้วยความมั่นใจ ~87 เปอร์เซ็นต์ โดยพิจารณาจากขอบเขตปัจจุบันและ throughput ในอดีต" คือการพยากรณ์ที่ใครบางคนสามารถจัดการได้ ลดความมั่นใจลงและคุณมักจะดึงวันที่ขึ้นไปข้างหน้าหรือขยายขอบเขตได้ เพิ่มความมั่นใจขึ้นและคุณมักต้องการเวลามากขึ้น ขอบเขตน้อยลง หรือความจุมากขึ้น นั่นคือการสนทนาระดับการจัดการ ไม่ใช่ศาสนา
จาก initiative ไปสู่งานที่สามารถปฏิบัติได้
โปรแกรมขนาดใหญ่ยังคงต้องการขอบเขตการวางแผนที่คร่าว ๆ PI planning หรือ big-room planning มีประโยชน์เมื่อสร้างชุดผลลัพธ์ที่จัดอันดับสำหรับประมาณสามเดือนข้างหน้า โดยมี T-shirt sizing ที่ดีพอที่จะจัดสรรความจุและเผยให้เห็น dependency มันไม่เป็นประโยชน์เมื่อมันแช่แข็งแผน pseudo-waterfall ที่แต่งตัวด้วยศัพท์ Agile
หลังจากการดึงแบบคร่าว ๆ ทีมจะจัดทำงานระยะใกล้ให้เป็น stories นำ story points (หรือขนาดสัมพัทธ์ที่สม่ำเสมออื่น ๆ) มาใช้ และดำเนินการใน sprint Predicted เทียบกับ actual จึงกลายเป็นวัตถุดิบสำหรับการพยากรณ์ จุดประสงค์ของ story points ในโมเดลนี้ไม่ใช่ความแม่นยำลึกลับ แต่เป็นมาตราส่วนสัมพัทธ์ที่เสถียรเพื่อให้ "เราเสร็จ 34 points เมื่อ sprint ก่อน" มีความหมายที่เปรียบเทียบได้กับ sprint ก่อนหน้า โดยมี hygiene ที่เหมาะสม
รักษาแผนคร่าว ๆ และแผนละเอียดให้เชื่อมโยงกัน ผลลัพธ์ที่ชนะ PI slot ต้องกลายเป็นรายการ backlog ที่มีเจ้าของ Dependency ที่เรียกในห้องต้องกลายเป็นข้อจำกัดที่ติดตาม ไม่ใช่ slideware เมื่อ predicted และ actual แตกต่างกัน ให้ปรับขอบเขตหรือลำดับก่อน อย่าเขียนประวัติศาสตร์ใหม่แบบเงียบ ๆ เพื่อให้ Gantt ยังคงเป็นสีเขียว
การสร้างทีมเทียบกับทีมที่พยากรณ์ได้
Tuckman ไม่ใช่การสร้างแบรนด์ ทีมที่กำลัง forming และ storming ยังไม่มีสัญญาณการส่งมอบที่เสถียร ทีมที่ norming เริ่มมี ทีม performing ที่มีข้อมูล throughput ที่สะอาดหลายเดือน (หรือ points ที่เสร็จต่อ sprint) สามารถปกป้องคำกล่าวความน่าจะเป็นได้
อย่าขายละคร Bayesian ในเดือนแรก Squad ใหม่ที่มีสมาชิกหมุนเวียน Definition of Done ที่ไม่ชัดเจน และ backlog ที่ยังสร้างอยู่จะผลิตตัวเลขที่ดูวิทยาศาสตร์แต่มีความหมายน้อย สร้างระบบปฏิบัติการก่อน: ลำดับความสำคัญ feedback และการบันทึกการเสร็จสิ้นที่สม่ำเสมอ จากนั้นจึงพยากรณ์
ทีมที่จัดตั้งแล้วเป็นเรื่องต่างออกไป เมื่อคุณมีชุดงานขนาดใกล้เคียงกันที่เสร็จภายใต้ข้อจำกัดที่คล้ายกัน throughput ในอดีตคือ prior ที่ถูกต้อง Monte Carlo sampling จากประวัตินั้นตอบคำถาม "เมื่อไหร่" และ "เท่าไหร่" ได้ดีกว่าค่าเฉลี่ย velocity เดียว การอัปเดต Bayesian แบบเลือกได้สามารถทำให้ภาพชัดขึ้นเมื่อ sprint ใหม่มาถึง แต่เฉพาะหลังจากข้อมูลพื้นฐานซื่อสัตย์เท่านั้น ก่อนหน้านั้น ให้ถือการพยากรณ์ช่วงแรกเป็นเพียงแนวทางและบอกให้ชัดเจน
การนำข้อมูลเข้าไปในทีม
บันทึกสิ่งที่เสร็จ เมื่อไหร่ที่เสร็จ และด้วยขนาดเท่าไหร่ (หากคุณใช้ points) บันทึกวันที่เริ่มและเสร็จสำหรับมุมมอง cycle-time หากคุณสนใจ flow บันทึกเวลาที่ถูกบล็อกและเวลารอ dependency หากแรงเสียดทานข้ามทีมคือเรื่องจริง Hygiene ดีกว่าชุดเครื่องมือ สเปรดชีตที่มีวันที่ done ที่ซื่อสัตย์ดีกว่าชุด Jira เต็มไปด้วยตั๋วที่ย้ายไป Done ในวันสุดท้ายของ sprint เพื่อปกป้องภาพ velocity
ตกลงกันว่าหมายถึง "done" อะไรและอย่าย้ายเส้นชัยเพื่อทำให้แผนภูมิดูดี รักษาขนาดงานให้ใกล้เคียงกันหรือแยก outliers ออก หลีกเลี่ยงการเล่นเกม points ชุดเครื่องมือเป็นเรื่องรอง: การวิเคราะห์สไตล์ ActionableAgile ชาร์ต Jira ดั้งเดิม หรือ Python notebook สั้น ๆ ล้วนใช้ได้เมื่อมีประวัติ งบประมาณประมาณหนึ่งถึงสองเดือนของการดำเนินการที่สะอาดก่อนที่จะถือการพยากรณ์เป็นระดับคณะกรรมการ นั่นไม่ใช่การชะลอเพื่อตัวมันเอง แต่เป็นขั้นต่ำเพื่อให้ตัวอย่างหยุดเป็นเพียงเสียงรบกวน
การพยากรณ์ด้วยข้อมูล: Monte Carlo (และ Bayesian) โดยปราศจากความลึกลับ
การพยากรณ์ Monte Carlo ในรูปแบบที่ได้รับความนิยมสำหรับการส่งมอบแบบ Agile โดยผู้ปฏิบัติเช่น Daniel Vacanti และแนวทาง Actionable Agile ไม่ใช่ความลึกลับ คุณนำ throughput ในอดีต (รายการหรือ points ที่เสร็จต่อวันหรือต่อ sprint) มาสุ่มจากประวัตินั้นหลายพันครั้งและถามว่าการทำงานที่เหลือจะเสร็จภายในวันที่เป้าหมายบ่อยแค่ไหน ผลลัพธ์คือการกระจาย ไม่ใช่คำทำนาย
ภาพสเก็ตช์สั้น ๆ เพื่อเข้าใจ:
# remaining = งานที่ยังต้องทำ (รายการหรือ points)
# history = รายการ throughput ในอดีตต่อช่วงเวลา (sprint/วัน)
# target = จำนวนช่วงเวลาจนถึงวันที่คุณสนใจ
trials_done = 0
for trial in 1..N: # เช่น N = 10_000
remaining_sim = remaining
for period in 1..target:
remaining_sim -= sample(history) # สุ่ม throughput ในอดีตหนึ่งครั้ง
if remaining_sim <= 0:
trials_done += 1
break
P(done by date) ≈ trials_done / Nหากประมาณ 8,700 จาก 10,000 การทดลองเสร็จขอบเขตที่เหลือในหรือก่อนวันพฤหัสบดี คุณจะพูดว่า: คุณลักษณะ X ภายในวันพฤหัสบดีด้วยความมั่นใจ ~87 เปอร์เซ็นต์ นั่นคือประโยคที่คณะกรรมการสามารถใช้ได้ นอกจากนี้ยังเป็นประโยคที่บังคับการสนทนาเรื่องขอบเขตเมื่อตัวเลขอยู่ที่ 40 เปอร์เซ็นต์
มุมมองแบบสะสมคือแนวคิดเดียวกันในหนึ่งบรรทัด ให้ \(T\) เป็นเวลาที่เสร็จสมบูรณ์จากการจำลองโดยการสุ่ม resampling ของ throughput ในอดีต แล้ว:
P(T \le t_{\text{Thursday}}) \approx \frac{1}{N}\sum_{i=1}^{N}\mathbf{1}[T_i \le t_{\text{Thursday}}]การอัปเดต Bayesian แบบเลือกได้ถือ sprint ล่าสุดเป็นหลักฐานใหม่ที่เปลี่ยนความเชื่อของคุณเกี่ยวกับ throughput มีประโยชน์เมื่อชุดข้อมูลเสถียรแล้ว แต่เป็นเพียงเครื่องประดับก่อนหน้านั้น ควรใช้การนับ throughput เมื่อทำได้ เพราะมันเปลี่ยนแปลงน้อยกว่าคะแนนและเชื่อมโยงกับการคิดแบบ flow ของ Little's Law ได้ดี คะแนนยังใช้ได้หากมาตราส่วนของทีมสม่ำเสมอและคุณปฏิเสธการขยาย ไม่ว่าจะอย่างไร หน่วยในประวัติต้องตรงกับหน่วยของงานที่เหลือ
เอกสารการเขียนเครื่องมือสาธารณะ (เอกสาร ActionableAgile และบล็อกผู้ปฏิบัติที่เกี่ยวข้อง) มักแสดงเปอร์เซ็นไทล์การวางแผนเช่น p50, p85 และ p95: เหรียญโยน, commit และนอนหลับได้อย่างสบายใจ ตัวอย่าง ~87 เปอร์เซ็นต์อยู่ใกล้กับแถบ commit ที่หลายทีมถือว่า board-safe ถือภาพหน้าจอจากผู้ขายและค่าเริ่มต้นเปอร์เซ็นไทล์เป็นแนวปฏิบัติในอุตสาหกรรม ไม่ใช่มาตรฐานที่ถูกควบคุม
เหตุใดวิธีนี้จึงดีกว่าโรงละครการวางแผนแบบ waterfall
โรงละครการวางแผนแบบ waterfall ขายวันที่เดียวและซ่อน contingency ใน buffer การทำงานล่วงเวลา และการลดขอบเขตแบบเงียบ ๆ เมื่อวันที่ล่าช้า ความเชื่อมั่นก็ระเหยเพราะแผนไม่เคยยอมรับความไม่แน่นอน Agile แบบ probabilistic ขายคำถามปฏิทินเดียวกันพร้อมช่วง: นี่คือสิ่งที่ 50 เปอร์เซ็นต์ดูเหมือน นี่คือสิ่งที่ ~87 เปอร์เซ็นต์ดูเหมือน นี่คือสิ่งที่คุณต้องลดหรือเพิ่มเพื่อย้ายระหว่างกัน
โมเดลที่สองยากกว่าในห้องประชุมห้านาทีและง่ายกว่าสำหรับหกเดือน ผู้สนับสนุนสามารถเลือกความเสี่ยงได้ ผลิตภัณฑ์สามารถแลกเปลี่ยนขอบเขตกับวันที่ วิศวกรรมสามารถแสดง dependency ใดที่ย้ายเปอร์เซ็นไทล์ การตรวจสอบและความเสี่ยงได้รับร่องรอย: การพยากรณ์ หน้าต่างข้อมูล สมมติฐาน และการตัดสินใจ นั่นคือการกำกับดูแลแบบผู้ใหญ่ Gantt ที่จะล่าช้าอยู่แล้วไม่ใช่
ข้อควรระวัง
คะแนนขยะผลิตความน่าจะเป็นขยะ หาก story points ขยายตัวหลังการประชุมวางแผนทุกครั้ง Monte Carlo ของคุณจะพยากรณ์สิ่งไร้สาระอย่างมั่นใจ แก้ไขมาตราส่วนหรือเปลี่ยนไปใช้การนับรายการ
Dependency ข้ามทีมทำลายการพยากรณ์แบบง่าย ๆ ทีมที่เสร็จ stories ของตัวเองตรงเวลายังล่าช้าได้หาก platform squad หน้าต่างการเปลี่ยนแปลง หรือผู้ขายนั่งบน critical path จงสร้างแบบจำลอง dependency อย่างชัดเจนหรือขยายแถบความมั่นใจจนกว่าจะทำได้
การ roll-up ระดับพอร์ตโฟลิโอไม่ใช่ "รวมความมั่นใจ" สามทีมแต่ละทีมที่ 87 เปอร์เซ็นต์บนส่วนที่ขึ้นต่อกันไม่ได้ให้ผลลัพธ์โปรแกรม 87 เปอร์เซ็นต์ Correlation และโครงสร้าง dependency สำคัญ Roll-up ด้วยการจำลองพอร์ตโฟลิโอหรือด้วยความซื่อสัตย์ของ critical-path อย่างชัดเจน ไม่ใช่ด้วย optimism แบบเลขคณิต
พิธีกรรมโดยปราศจากลำดับความสำคัญยังคงล้มเหลว แผนภูมิ throughput ที่สมบูรณ์แบบบน backlog ที่ไม่ได้จัดอันดับจะพยากรณ์งานที่ผิดด้วยความแม่นยำที่น่าประทับใจ ลำดับความสำคัญและ feedback ยังคงเป็นระบบปฏิบัติการ Monte Carlo คือเครื่องมือวัด
การ rollout แบบ pragmatic สำหรับองค์กรที่มีการกำกับดูแล
เลือกทีมผลิตภัณฑ์ที่จัดตั้งแล้วหนึ่งทีมที่มีผลลัพธ์จริงบนปฏิทิน ไม่ใช่ transformation squad ใหม่ทั้งหมด บันทึกการเสร็จสิ้นเป็นเวลาสี่ถึงแปด sprint ด้วยเกณฑ์ Done ที่ตกลงกัน รักษา PI หรือการวางแผนรายไตรมาสสำหรับผลลัพธ์คร่าว ๆ และความจุแบบ T-shirt หยุดใช้มันเป็นตารางเวลาแบบละเอียดปลอม สอนผู้สนับสนุนให้ถามหาคำมั่นสัญญาแบบเปอร์เซ็นไทล์ ("วันที่ไหนที่ ~85–90 เปอร์เซ็นต์?") แทนวันที่เดียวแบบเงียบ ๆ
วางการพยากรณ์เคียงข้างการกำกับดูแลที่มีอยู่แทนที่จะสร้างลัทธิขนาน Risk และ change committee ยังต้องการวันที่ ให้พวกเขาด้วยความน่าจะเป็นที่มีวันที่และสมมติฐานขอบเขตด้านล่าง เอกสารหน้าต่างข้อมูล วิธีการสุ่มตัวอย่าง และใครสามารถเปลี่ยนขอบเขตเมื่อความมั่นใจลดลง สำหรับทีมใหม่ เผยแพร่เพียงช่วงแนวทางและบอกเมื่อการพยากรณ์ระดับ board เริ่ม หลีกเลี่ยงการกระจายเครื่องมือ: เส้นทางการวิเคราะห์หนึ่งเส้น Definition of Done หนึ่งอัน และเจ้าของหนึ่งคนสำหรับ hygiene ของการพยากรณ์
ธนาคารและบริษัทประกันภัยรู้วิธีพูดถึงความน่าจะเป็นในด้านเครดิต การประกันภัย และความเสี่ยงจากการดำเนินงานอยู่แล้ว การพยากรณ์การส่งมอบคือการเคลื่อนไหวทางปัญญาเดียวกันที่นำไปใช้กับ throughput อุปสรรคทางวัฒนธรรมไม่ใช่คณิตศาสตร์ แต่เป็นนิสัยในการถือเพชร Gantt ว่าปลอดภัยกว่าช่วงที่ซื่อสัตย์
ขั้นตอนถัดไปทันที
ตั้งชื่อผลลัพธ์ที่จัดลำดับความสำคัญสำหรับ ~90 วันข้างหน้าและกำจัด P1 ที่ซ้ำซ้อน
เลือกทีมที่จัดตั้งแล้วหนึ่งทีม แช่แข็งเกณฑ์ Done บันทึก throughput หรือ points ที่เสร็จสำหรับสองเดือนข้างหน้าโดยไม่เล่นเกม
แทนที่คำขอวันที่จากคณะกรรมการครั้งถัดไปด้วยคำมั่นสัญญาแบบเปอร์เซ็นไทล์: ขอบเขต X ภายในวันที่ Y ที่ ~87 เปอร์เซ็นต์ (หรือแสดงการลดที่จำเป็นเพื่อให้ถึงที่นั่น)
นำ dependency ข้ามทีมสามอันดับแรกที่อาจทำให้ตัวอย่างไม่ถูกต้องขึ้นมาและมอบหมายเจ้าของ
จากนั้นจึงเลือกเครื่องมือ สเปรดชีตก่อนก็ได้
ปฏิเสธวันที่และคุณจะฝึกองค์กรให้สร้างมันโดยไม่มีคุณ สร้างความแม่นยำปลอมและคุณจะฝึกให้มันเพิกเฉยคุณเมื่อแถบกลายเป็นสีแดง คำมั่นสัญญาแบบความน่าจะเป็นคือทางสายกลางแบบผู้ใหญ่: Agile เปลี่ยนวิธีที่คุณวางแผนและให้คำมั่นสัญญา แต่ไม่ได้ยกเลิกทั้งสองอย่าง