กำหนดเวลามีความคล่องตัวหรือไม่

เพื่อความชัดเจนกำหนดเวลาคือ:

การ จำกัด เวลาหรือกำหนดเวลาเป็นเขตเวลาที่แคบหรือเป็นช่วงเวลาใดเวลาหนึ่งที่ต้องบรรลุวัตถุประสงค์หรือภารกิจ

^{จากวิกิพีเดีย}

อาชีพการพัฒนาซอฟต์แวร์ทั้งหมดของฉันฉันได้ทำ "Agile" ซึ่งทุกที่ดูเหมือนจะมีความหมายอย่างน้อยปฏิบัติตามต่อไปนี้:

• การวิ่งรายสัปดาห์หรือรายปักษ์
• การวางแผน Sprint ย้อนหลัง
• เจ้าของผลิตภัณฑ์
• การทะเลาะกัน
• เรื่องราวของผู้ใช้

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

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

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

งานจะขยายเพื่อเติมเวลาให้เสร็จสมบูรณ์

กล่าวอีกนัยหนึ่งหากโครงการของคุณสามารถดำเนินต่อไปได้ตลอดไป

ในความสัมพันธ์กับกำหนดเวลา Agile พยายามทำบางสิ่ง:

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

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

ใช่. "Agile" และ "กำหนดเวลา" สามารถเข้ากันได้อย่างสมบูรณ์แบบ

กำหนดเวลาเป็นความจริงของชีวิต มีบางสิ่งที่มีวันที่แน่วแน่มาก

เราต้องการซอฟต์แวร์โดย Comdex

หรือ

เกมจะต้องวางจำหน่ายตามร้านในวัน Black Friday

และไม่ชอบ อย่างใดอย่างหนึ่งไม่สามารถเลื่อน Comdex หรือ Black Friday - ส่วนที่เหลือของโลกไม่ได้ทำงานอย่างนั้น

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

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

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

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

ตกลงเราพลาดทุกสิ่งที่เราต้องการเพื่อให้ใช้งานซอฟต์แวร์ภาษีได้ในวันที่ 15 เมษายน แต่เรามี 75% และสิ่งที่เรามีงานและทำงานมาตั้งแต่เราเริ่มเมื่อเดือนพฤศจิกายนปีที่แล้ว เรารู้ว่าเราจะไม่สามารถปรับใช้ชุดคุณลักษณะทั้งหมดตั้งแต่กลางเดือนธันวาคมและมุ่งเน้นความพยายามของเราในฐานลูกค้า 80%

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

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

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

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

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

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

"มีเพียงข้อตกลงของ Sith ในการทำให้สมบูรณ์"

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

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

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

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

TL; DR

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

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

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

ทีมงานพัฒนา (D): "คุณช่วยจัดลำดับความสำคัญของคุณสมบัติที่คุณต้องการให้ส่งด้วยสำคัญที่สุดก่อนหรือไม่"

ลูกค้า (C): "ทุกอย่างมีความสำคัญลำดับที่ 1 - ฉันต้องการให้พวกเขาทำเสร็จภายในสิ้นเดือนหน้า"

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

C: "ถ้าฉันให้เงินคุณมากกว่านี้ล่ะ?"

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

C: "โอเคฉันต้องการปุ่มใหญ่ แต่ทำให้มันใหญ่จริง ๆ แล้วก็ ... ฯลฯ "

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

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

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

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

เปรียวแถลงการณ์ฯ :

บุคคลและการมีปฏิสัมพันธ์เหนือกระบวนการและเครื่องมือ

ซอฟต์แวร์ที่ทำงานผ่านเอกสารที่ครอบคลุม

การทำงานร่วมกันของลูกค้าในการเจรจาสัญญา

การตอบสนองต่อการเปลี่ยนแปลงการติดตามแผน

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

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

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

ฉันจะบอกว่าการส่งมอบการวิ่งแต่ละครั้งไม่สามารถต่อรองได้ คุณประเมินงานคุณวางขนาดการ์ดและโหลดให้เพียงพอเพื่อให้ทีมของคุณไม่ว่างจนกว่าการวิ่งจะสิ้นสุดลง (และการวิ่งควรจะมีขนาดเล็ก - ทุกสัปดาห์ตั้งแต่หนึ่งเดือนถึงหนึ่งเดือน) "กำหนดเวลาส่งมอบ" ควรขึ้นอยู่กับแนวโน้มทางประวัติศาสตร์ของงานที่ทำเสร็จกับงานที่คาดการณ์ไว้ Agile เพิ่ม / ลบอะไรจากแนวคิดข้อ จำกัด "ราคา / เวลา / ขอบเขต" แบบเดิมมันใช้ขอบเขตเป็นวิธีที่ต้องการในการจัดการ slippage บนพื้นฐานที่การจัดลำดับความสำคัญที่ดีกว่ากับขอบเขตโดยทั่วไปจะดีกว่าที่จะใช้จ่ายเงินหรือเวลามากขึ้น

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

TL; DR

กำหนดเวลา [a] gile เป็นอย่างไร ... [D] eadlines ถูกมองว่าจะไปด้วยกันกับการพัฒนา [a] gile

คำตอบมากมายที่นี่มีแนวโน้มที่จะมุ่งเน้นด้านวิศวกรรมของคำถาม ฉันจะจัดการเรื่องนี้จากมุมมองการจัดการโครงการแทน

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

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

คิดว่ากล่องเวลาไม่กำหนดเวลา

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

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

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

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

การวางแผนการวางจำหน่ายตามกรอบเวลา

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

ตัวอย่างเช่นโครงการอาจมุ่งมั่นที่จะปล่อย v1.0 ของโครงการเมื่อสิ้นสุดการทำซ้ำ 20 ครั้ง ขอบเขตของสิ่งที่เผยแพร่อาจเปลี่ยนแปลงตลอดอายุของโครงการ (ตามขอบเขตคุณลักษณะและลำดับความสำคัญสามารถเปลี่ยนแปลงได้ในช่วงเริ่มต้นของ Sprint ทุกเครื่อง) แต่วันที่เป้าหมายสำหรับแต่ละรุ่นจะได้รับการแก้ไขในแผนโครงการ ทีมมุ่งมั่นที่จะส่งมอบที่เพิ่มขึ้นอาจเกิดขึ้นในแต่ละ Sprint และคำจำกัดความของการกระทำรวมถึงการตรวจสอบคุณภาพเช่นการรวมอย่างต่อเนื่องเพื่อให้แน่ใจว่าโครงการอยู่ในสถานะ releasable ในตอนท้ายของ Sprint แต่ละ

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

ดูสิ่งนี้ด้วย

• วิธีการวางแผนการวางจำหน่ายแบบคล่องตัว

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

ความคล่องตัวที่เกิดขึ้นคือสิ่งที่เกิดขึ้นระหว่างนั้น แทนที่จะมีเอกสารข้อกำหนดข้อกำหนดซอฟต์แวร์ที่เข้มงวดซึ่งกำหนดว่าคุณควรส่งคุณลักษณะ A ซึ่งประกอบด้วยคุณลักษณะย่อย B, C, D และ E ในวันที่กำหนดคุณตกลงที่จะส่งมอบคุณสมบัติ A สำหรับวันที่กำหนดโดยกำหนดที่ ช่วงแรกคุณและลูกค้าของคุณไม่ทราบว่าจะมีลักษณะอย่างไรหรือมีคุณลักษณะย่อย B, C, D และ E หรืออาจ B และ C หรือคุณสมบัติย่อยอื่น ๆ อีกโหล

ลองนึกภาพ บริษัท ที่ก่อนหน้านี้ส่งมอบสินค้าให้กับ บริษัท ขนาดเล็กเท่านั้นและเพิ่งเซ็นสัญญากับ บริษัท ขนาดใหญ่ บริษัท ขนาดใหญ่นี้ใช้ EDIFACT และปรากฏว่าซอฟต์แวร์บัญชีปัจจุบันที่ บริษัท ของคุณใช้ไม่ได้จัดการ EDIFACT คุณกำลังขอให้สร้างปลั๊กอินซึ่งไม่ว่าที่ระบุว่าสัญญาที่ บริษัท ของคุณควรจะพร้อมสำหรับ 15 เมษายนTH

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

คุณควรเข้าใจมุมมองของลูกค้าด้วย:

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

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

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

โปรแกรม eXtremeระบุเกี่ยวกับการวางแผนการปล่อย:

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

ซึ่งดูเหมือนว่ายุติธรรม นอกจากนี้ยังระบุว่า

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

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

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

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

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

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

กำหนดเวลาไม่กระฉับกระเฉงพวกเขาคือ:

1) น้ำตกและ 2) ผิด

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

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

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

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

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

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

คำตอบ "อาจจะไม่"

Project_management_triangleระบุว่าค่าใช้จ่ายเวลาและขอบเขต (และคุณภาพ) ขึ้นอยู่กับแต่ละอื่น ๆ ("เลือกสองและรับที่ 3")

การต่อสู้แบบกระทุ้งเลือกเวลาที่แน่นอน (เช่น 7 วัน = ความยาวของการวิ่ง) และค่าใช้จ่าย (เช่นงบประมาณสำหรับสมาชิกในทีม 7 คน) และประมาณการขอบเขต (จำนวนเรื่องที่ต้องทำในการวิ่ง)

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

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

สิ่งนี้ไม่สามารถตอบได้อย่างเรียบง่ายและโดยตรงหรือไม่

ไม่มีกำหนดเวลาไม่คล่องตัว

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

กำหนดเวลาคือ "คุณต้องส่งมอบ x โดย y" ซึ่งล้มเหลวในการนับทั้งที่คุณสัญญาว่าจะส่งมอบคงที่ใน timescale ที่กำหนดไว้ล่วงหน้า (ที่เปรียวบอกว่าเราไม่แน่ใจว่าสิ่งที่เรากำลังพยายามที่จะส่งมอบและ การเรียนรู้จากเปรียวสอนเราว่าแม้ว่าเราจะรู้ว่ามันยากมากที่จะมีความมั่นใจเกี่ยวกับ timescales - หรือเป็นปัญหาที่แก้ไขแล้วและเราไม่ควรทำมันต่อไป)

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

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

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

"Agile" นั้นดีสำหรับสิ่งที่มันเป็น "Agile" sorta หมายถึง "เปิดกว้างควบคู่ไปกับความสามารถที่เพียงพอ" มันเป็นคำรามที่ด้านล่างที่จะต้องมีความคล่องตัวมากที่สุด

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

แต่เช่นเดียวกับความสนใจตนเองที่รู้แจ้งมันไม่มีอยู่จริง