การต่อสู้สร้างค่าใช้จ่ายเพิ่มเติมสำหรับโครงการที่ความต้องการไม่เปลี่ยนแปลงหรือไม่?

ฉันอ่านScrum - คู่มือพ็อกเก็ตโดย Gunther Verheyenและมันบอกว่า:

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

ดังนั้นฉันจึงทะเลาะกับเพื่อนร่วมงานคนหนึ่งของฉันที่บอกว่าสำหรับบางโครงการ (เช่นยา / การทหารที่ความต้องการไม่เปลี่ยนแปลง) Agile (และโดยเฉพาะ Scrum) มีค่าใช้จ่ายในการประชุมทั้งหมด ฯลฯ และมันมีเหตุผลมากกว่า ตัวอย่างเช่นใช้น้ำตก

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

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

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

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

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

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

คำตอบที่สมบูรณ์มากขึ้นคือ:

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

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

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

เพื่อนำกลับมาสู่ Scrum Scrum ได้รับการออกแบบมาเพื่อแก้ปัญหาด้วย Emperical Process control ดังนั้นใช่มันมีค่าใช้จ่ายมากกว่าวิธีอื่น ๆ อย่างไรก็ตามเนื่องจากโครงการส่วนใหญ่ต้องการวิธีการนี้จึงเป็นข้อโต้แย้งที่สงสัย

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

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

แต่โครงการซอฟต์แวร์ส่วนใหญ่ไม่ได้เป็นเช่นนี้

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

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

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

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

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

ฉันคิดว่านี่อาจเป็นการถอดความสิ่งที่ @Cort Ammon พูด แต่นี่คือสิ่งที่ฉันต้องทำ:

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

พิจารณาว่า:

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

• ข้อกำหนดบางอย่างอาจกว้างเกินไปหรือคลุมเครือ: "ใช้งานง่าย", "ปลอดภัย" เป็นการยากที่จะวิเคราะห์ว่าระบบความปลอดภัยหรือการใช้งานของระบบนั้นยังไม่เสร็จสมบูรณ์ บางคนอาจมีความหมายที่ซ่อนอยู่หรืออาจไม่เข้าใจ

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

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

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

• การส่งสิ่งที่เร็วกว่านี้จะช่วยในการรวมและจะแสดงว่าโครงการนี้สามารถให้ผลลัพธ์ได้

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

ดังนั้นจึงมีกระบวนการในการพัฒนา "วิธีการ" ซึ่งอยู่ภายในกับ บริษัท หรือทีมที่ปฏิบัติตามข้อกำหนด การสังเกตุอย่างชัดเจนเราพึ่งพาวิธีการลำดับขั้นที่ทีมนักออกแบบออกแบบระบบระดับสูงเพื่อตอบสนองความต้องการเหล่านั้นจากนั้นใช้ระบบเฉพาะในระดับสูงนั้นเพื่อให้ "ความต้องการ" แก่ทีมขนาดเล็ก

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

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

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