ฉันเป็นนักพัฒนาที่ทำงานกับแอพมือถือใหม่สำหรับ Android และ iOS ที่มีส่วนประกอบแบ็คเอนด์ขนาดใหญ่ เราอยู่ในการวิ่งสามครั้งของโครงการนี้และเราใช้ Scrum กับพิธีทั้งหมดของมัน (การปรับแต่งการวางแผนรายวันรายวันย้อนหลัง ฯลฯ )

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

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

1. นี่เป็นรูปแบบที่ยอมรับได้ / ทั่วไปของ Scrum ที่ฉันไม่ทราบหรือไม่?

2. คุณแนะนำให้ฉันทำสิ่งนี้อย่างไร

บางสิ่งที่โดดเด่นสำหรับฉัน

แนวคิดที่ว่าฝ่ายบริหารมีความมุ่งมั่นในการทำงานนั้นไม่สอดคล้องกับ Scrum Guide เวอร์ชั่นล่าสุด คำว่า "กระทำ" หรือ "คำมั่นสัญญา" ใช้เพียงสองครั้งในฉบับล่าสุด (พฤศจิกายน 2017) ของคู่มือการแย่งชิงกัน - หนึ่งครั้งเมื่อแสดงรายการค่าการแย่งชิงกันและอีกครั้งเพื่อแสดงว่า "

ความคิดเกี่ยวกับเป้าหมายมีความสำคัญต่อการแย่งชิงกัน องค์กรและทีมไม่เพียง แต่มีเป้าหมายในวงกว้างเท่านั้น แต่ใน Scrum แต่ละ Sprint มีเป้าหมาย Sprint ที่กำหนดไว้ใน Sprint Planning เพื่อเป็นการทำงานร่วมกันระหว่างเจ้าของผลิตภัณฑ์และทีมพัฒนา บรรลุเป้าหมาย Sprint โดยการใช้รายการจาก Backlog ผลิตภัณฑ์ แต่มันไม่ได้เป็นเพียง "เสร็จสิ้นการทำงานของร่างกายนี้" และมักจะไม่ได้เป็นตัวแทนของ Sprint Backlog ที่สมบูรณ์ นั่นคือคุณควรจะสามารถบรรลุเป้าหมาย Sprint โดยไม่ต้องกรอกข้อมูลของสินค้าค้างทุกรายการที่เลือกสำหรับ Sprint หรือทุกรายการใน Sprint Backlog ความคิดปัจจุบันของฉันคืองานที่จำเป็นเพื่อให้บรรลุเป้าหมาย Sprint ควรจะอยู่ที่ประมาณ 60-70% ของความสามารถของทีมของคุณ องค์กรที่แตกต่างกันจะแตกต่างกัน แต่นั่นคือ '

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

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

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

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

คุณสามารถทำอะไรได้บ้างขึ้นอยู่กับบทบาทของคุณ

หากคุณเป็นนักพัฒนาซอฟต์แวร์สิ่งที่ดีที่สุดที่คุณสามารถทำได้คือ

• (เรียกรวมกันว่าเป็นทีมพัฒนา) ปฏิเสธที่จะ "กระทำ" เพื่อทำงานมากกว่าที่คุณจะมั่นใจได้อย่างแน่นอนว่าคุณสามารถจัดส่งภายในระยะเวลาอันสั้น นี่อาจเป็นวิธีที่น้อยกว่าที่ฝ่ายบริหารต้องการให้คุณทำ
• มุ่งเน้นไปที่งานที่เสร็จสิ้นแล้วแทนที่จะเริ่มงานใหม่ หากคุณเห็นว่างานบางอย่างไม่สามารถดำเนินการได้ให้ระบุโดยเร็วที่สุดเพื่อให้สามารถปรับแผนได้

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

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

PM ของคุณไม่มีธุรกิจที่เกี่ยวข้องกับการต่อสู้ของคุณ

PM ของคุณไม่มีธุรกิจที่ขอให้คุณทำงานล่วงเวลาค้างชำระ

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

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

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

มากเกินไปในการวิ่ง

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

การจัดสรรทรัพยากร

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

การประมาณค่าความแปรปรวน

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

ความเร็ว

หากความเร็วถูกติดตามอย่างถูกต้องจำนวนเรื่องจริงควรชัดเจน ไม่ได้หมายความว่าพวกเขาจะทำในเวลาเสมอ แต่ควรทำให้สิ่งต่าง ๆ ง่ายขึ้นมาก

ความปรารถนาดี

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

spikes

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

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

หากคุณจะเป็น Agile คุณต้องมีความยืดหยุ่นในการปล่อยเรื่องจาก Sprint ที่คุณไม่สามารถดำเนินการให้ตรงเวลา วิธีหนึ่งในการทำเช่นนี้คือขอให้เจ้าของผลิตภัณฑ์ของคุณประเมินเรื่องราวโดยใช้การจัดลำดับความสำคัญ MoSCoW สิ่งนี้จะเกี่ยวข้องกับการเลือกไม่มากไปกว่า 60% ของเรื่องราว (ตามคะแนนเรื่องราวทั้งหมด) เช่น Must Haves ที่จะแล้วเสร็จ 20% ตามที่ควรมีที่คุณควรทำตามโครงการสรุปและผลิตภัณฑ์ขั้นต่ำที่ใช้งานได้เปิดตัว 20% อาจมีประการที่อาจเสร็จสมบูรณ์หากคุณมีเวลาและสิ่งใดก็ตามที่อยู่นอกขอบเขตของการวางจำหน่ายในปัจจุบันเช่น Wonna Haves สิ่งสำคัญที่ควรทราบคือเมื่อรวมกันแล้ว Must Haves ควรมีเนื้อกระดูกเพียงพอที่จะสร้างผลิตภัณฑ์ขั้นต่ำได้โดยไม่จำเป็นต้องรวมรายการใด ๆ จากหมวดอื่น ๆ

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

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

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

แต่วิธีการของเขาไม่ใช่วิธีที่ดี

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

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

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

นี่เป็นรูปแบบที่ยอมรับได้ / ทั่วไปของ Scrum ที่ฉันไม่ทราบหรือไม่?

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

คุณแนะนำให้ฉันทำอย่างไรกับเรื่องนี้?

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

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

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

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

ความมุ่งมั่นที่พบบ่อย

พฤติกรรมนี้เป็นปกติหรือไม่

ฉันไม่แน่ใจ.

มันน่าแปลกใจใช่ไหม

ไม่บางคนมักจะเข้าใจ"ความมุ่งมั่น"เพื่อหมายถึงทุกสิ่งในความมุ่งมั่นที่ต้องทำให้สำเร็จ

มันเป็นความคิดที่ดีหรือไม่?

ไม่การพัฒนาที่คล่องตัวนั้นมีความยั่งยืนเป็นหัวข้อหลัก: ทำงานได้มาก / ยาว / ยากเท่าที่จะทำได้อย่างไม่มีกำหนด นั่นเป็นความคิดที่สมเหตุสมผลตลอดเวลา (หากผู้บริหารของคุณไม่ยอมรับสิ่งนี้พวกเขาไม่ควรเรียกองค์กรของพวกเขาว่องไว)

เราควรทำอย่างไร

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

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

ฉันไม่เห็นด้วยกับทีมผู้บริหารของคุณ พวกเขาไม่ควรทำให้คุณทำงานล่วงเวลาเพื่อให้การวิ่งเสร็จสิ้น

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

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

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