บางโครงการที่เราใช้ภายในใช้คือ Scrum ในขณะที่ยังคงเป็น "แก้ไขทุกอย่าง" ให้กับลูกค้า เราประสบกับความสำเร็จที่หลากหลายในส่วนของเรา (ลูกค้าชอบการมองเห็นแผนภูมิการเผาไหม้) ประเภทของโครงการที่เราทำงานสามารถทำได้สำเร็จโดยใช้วิธีการแบบว่องไวหรือไม่
บางโครงการที่เราใช้ภายในใช้คือ Scrum ในขณะที่ยังคงเป็น "แก้ไขทุกอย่าง" ให้กับลูกค้า เราประสบกับความสำเร็จที่หลากหลายในส่วนของเรา (ลูกค้าชอบการมองเห็นแผนภูมิการเผาไหม้) ประเภทของโครงการที่เราทำงานสามารถทำได้สำเร็จโดยใช้วิธีการแบบว่องไวหรือไม่
คำตอบ:
ดีฉันทำงานส่วนใหญ่ในสภาพแวดล้อม "เปรียว" (แม้ว่าเราจะไม่ใช้ศัพท์แสง) และฉันได้ทำสิ่งที่แน่นอนค่าใช้จ่าย โดยทั่วไปสิ่งที่เป็นจำนวนเงินคือค่าใช้จ่ายบวกเนื่องจากไม่มี บริษัท ใดที่สามารถทำทุกอย่างได้ฟรีและความต้องการจะเปลี่ยนแปลงและพัฒนาตามที่ลูกค้าระบุสิ่งที่พวกเขาต้องการได้ชัดเจนยิ่งขึ้น
ความต้องการเริ่มต้นสำหรับส่วนต้นทุนคงที่จะต้องทำอย่างระมัดระวังมากกว่าที่ทำในสภาพแวดล้อมแบบวนซ้ำทั่วไปทำให้กระบวนการทำซ้ำค่อนข้างน้อย ส่วน "บวก" ของสัญญาสามารถทำซ้ำได้มากขึ้นหากเราได้ทำส่วนต้นทุนคงที่ให้กับลูกค้าเป็นที่น่าพอใจมากขึ้นหรือน้อยลง
ฉันต้องการถามคำถามแบบตอบโต้:
สามารถคงขอบเขต + เส้นตายคง + การแก้ไขสัญญาราคาเคยได้รับการสร้างขึ้นมาเพื่อการทำงานระยะเวลา ?
คำว่า "ดี / เร็ว / ถูก - เลือกสอง" ไม่ได้เป็นเพียงเรื่องตลกทางวิศวกรรมที่ไร้สาระ ผู้จัดการโครงการทุกคนที่มีค่าควรรู้เกี่ยวกับสามเหลี่ยมการบริหารโครงการ :
คุณกำลังบอกเราว่าค่าใช้จ่ายขอบเขตและกำหนดการทั้งหมดได้รับการแก้ไขแล้ว นั่นทำให้ไม่มีที่ว่างสำหรับความคล่องแคล่วหรือข้อผิดพลาด ไม่มีเลย คุณสามารถเลือกที่จะดู "คุณภาพ" เป็นแอตทริบิวต์ แต่ไม่ใช่แอตทริบิวต์ "ของจริง" มันเป็นเหมือนแอตทริบิวต์ meta ที่มาจากแอตทริบิวต์อื่น ๆ (ราคา / ขอบเขต / ตารางเวลา)
ปัญหาคือสิ่งนี้ไม่เคยเกิดขึ้นจริงตราบใดที่โครงการของคุณกำลังวางแผนและดำเนินการโดยมนุษย์
ข้อกำหนดและข้อมูลจำเพาะไม่ครอบคลุมทุกกรณีที่เป็นขอบเว้นแต่ว่าพวกเขาจะถูกวาดขึ้นในรายละเอียดอันยิ่งใหญ่โดยสถาปนิกและนักออกแบบที่มีคุณสมบัติซึ่งในกรณีนี้โครงการได้ทำไปแล้วครึ่งหนึ่ง และถึงตอนนั้นก็ยังมีข้อผิดพลาดอยู่
ค่าใช้จ่ายที่ไม่คาดคิดจะปรากฏขึ้นซึ่งนำไปสู่การใช้จ่ายเกินงบประมาณ การสมัครหมดอายุแล้ว ผู้ผลิตหยุดการสนับสนุนผลิตภัณฑ์ที่คุณใช้และคุณต้องค้นหาผลิตภัณฑ์ใหม่ ผู้รับเหมารายชั่วโมงเพิ่มอัตราของเขาภายใต้การคุกคามของการจากไป ทีมงานทั้งหมดของคุณเพิ่งหยุดงานประท้วงเรียกร้องการเพิ่มขึ้น 10% และอีกหนึ่งสัปดาห์แห่งการพักผ่อน
สลิปกำหนดการ ปัญหาที่คาดเดาไม่ได้เกิดขึ้น องค์ประกอบการสร้างแผนภูมิที่คุณใช้มา 5 ปีติดต่อกันไม่สามารถใช้งานได้กับ Windows 95 ซึ่งลูกค้าของคุณยังคงใช้งานอยู่ จุดบกพร่องที่คลุมเครือใน Windows 64 บิตทำให้เกิดข้อบกพร่องของ UI อย่างรุนแรงและคุณใช้เวลาเกือบหนึ่งสัปดาห์ในการติดตามและพัฒนาวิธีแก้ปัญหา (นี่เกิดขึ้นกับฉันจริงๆ) นักพัฒนาอาวุโสของคุณโดนรถบัสและคุณต้องไปรับสมัครและฝึกอบรมคนใหม่ วันที่จัดส่งโดยประมาณของคุณผิดเสมอ เสมอ.
กฎของ Hofstadter: มันใช้เวลานานกว่าที่คุณคาดไว้เสมอถึงแม้คุณจะคำนึงถึงกฎหมายของ Hofstadter
วิธีการที่คล่องตัวนั้นเกี่ยวกับการเล่นปาหี่ในเรื่องต้นทุนตารางเวลาและขอบเขต โดยส่วนใหญ่แล้วพวกเขาจะเกี่ยวกับการเล่นปาหี่รอบขอบเขตและบางครั้งกำหนดการซึ่งเป็นสาเหตุที่คุณเริ่มต้นด้วยเรื่องราวของผู้ใช้ที่คลุมเครือและวางแผนแก้ไขแทนที่จะเป็นเวอร์ชั่นเต็ม วิธีการที่แตกต่างกันใช้คำศัพท์ที่แตกต่างกัน แต่มันก็เป็นพื้นฐานเดียวกันทั้งหมด: การออกบ่อยและการปรับสมดุลของตารางและขอบเขตของการปล่อยแต่ละครั้ง
นี้จะทำให้รู้สึกไม่กับโครงการที่เป็น (หรือเรียกร้องจะ) ทั้งขอบเขตคงที่หรือเวลาที่คงที่
หากมีการแก้ไขแอตทริบิวต์โครงการหนึ่งรายการ (ราคา / ขอบเขต / ตารางเวลา) ฉันจะบอกคุณว่าอาจไม่เหมาะกับวิธีการแบบเปรียว
ถ้าสองแอตทริบิวต์ของโครงการได้รับการแก้ไขแล้วโครงการของคุณแน่นอนไม่ได้เป็นแบบที่ดีสำหรับวิธีการเปรียว
หากแอตทริบิวต์ทั้งสามได้รับการแก้ไขแล้วโครงการของคุณอาจจะล้มเหลว ถ้ามันจัดส่งจริงตารางเวลาเดิมอาจถูกทำให้ยุ่งเหยิงอย่างมากหรือลูกค้ามีการจัดการที่จะหลอกลวงตัวเองโดยคิดว่าคุณส่งมอบจริงตามที่สัญญาไว้
หากสัญญานี้ยังคงอยู่บนโต๊ะฉันขอให้คุณปฏิเสธ และถ้าคุณยอมรับมันไปแล้วพระเจ้าก็อาจทรงเมตตาคุณ
ฉันรักคำพูดนี้:
“ การแย่งชิงนั้นยอดเยี่ยมสำหรับขอบเขตของตัวแปรวันที่คงที่หรือ“ ขอบเขตคงที่” (ซึ่งเติบโตตลอดเวลา) ตัวแปรวันที่ หากคุณกำลังทำขอบเขตคงที่ฉันขอแนะนำ Waterfall หรือ RUP ซึ่งจะซื้อหาคุณสองสามเดือนเพื่อหางานใหม่” ~ Michael James
แน่นอนว่าตราบใดที่แถบคุณภาพของคุณยังคงอยู่ในระดับต่ำอย่างน่าทึ่ง ฉันเป็นผู้เชื่อในสามเหลี่ยมเหล็กเก่าของ "เวลาส่งมอบ / คุณภาพ / ราคา" ที่คุณสามารถเลือกได้สองอัน แต่อีกอันหนึ่งลอย ดูเหมือนว่าคุณได้กำหนดเวลาส่งมอบและราคา (รวมถึงคุณสมบัติ) ดังนั้นสิ่งเดียวที่สามารถให้ได้คือคุณภาพ
ที่กล่าวว่าหากคุณกำลังใช้แผนภูมิเบิร์นดาวน์และคุณมีรายการที่มีลำดับความสำคัญสูงที่สุดก่อนคุณอาจยอมรับรายการสำคัญที่สุดจำนวนหนึ่งในช่วงเวลาที่กำหนดตามจำนวนเงินที่ระบุ อย่างน้อยที่สุดลูกค้าของคุณจะเห็นว่าคุณกำลังควบคุมกระบวนการอยู่บ้างด้วยการส่งมอบเมื่อสิ้นสุดการทำซ้ำแต่ละครั้งและพวกเขามีความสามารถในการพูดสิ่งที่สำคัญที่สุด
ไม่อย่างนั้นฉันคิดว่าการทำเวลาที่แน่นอนการกำหนดคุณสมบัติและราคาเป็นสิ่งที่โง่เขลาและจะนำไปสู่ความพยายามอย่างกล้าหาญทำให้คุณภาพต่ำลงและรหัสที่บำรุงรักษาได้น้อยลง เปรียวไม่ใช่ฝุ่นนางฟ้าวิเศษ
ราคาคงที่ / กำหนดเวลาตายตัว / ขอบเขตคงที่สามารถทำได้อย่างน้อยก็คล่องแคล่วเช่นเดียวกับในน้ำตก
ในน้ำตกการประเมินเวลาไม่ถูกต้องและรายละเอียดสิ้นสุดลงจะถูกนำไปใช้งานแตกต่างจากข้อกำหนดดั้งเดิม กล่าวอีกนัยหนึ่งไม่สามารถทราบกำหนดเวลา / ขอบเขตล่วงหน้าอย่างแน่นอน
ในเปรียวคุณสามารถทำ sprint zero เพื่อสร้าง backlog ของเรื่องราวของผู้ใช้และทำการประมาณ จากนั้นตกลงที่จะตอบสนองเรื่องราวมูลค่าสำหรับราคาคงที่ตามกำหนดเวลาคงที่ ขอบเขตได้รับการแก้ไขในแง่ของเรื่องราวคุณค่าที่คุณตั้งใจจะทำให้สำเร็จและไม่มีสัญญาใด ๆ เกี่ยวกับเรื่องราวของผู้ใช้
กล่าวอีกนัยหนึ่งคุณสัญญาว่าจะส่งมอบสิ่งที่สำคัญและหลีกเลี่ยงการทำสัญญาเกี่ยวกับการตัดสินใจออกแบบเฉพาะที่ไม่เกี่ยวข้องกับรายได้ / การออม / ฯลฯ โครงการควรจะส่งมอบ
ฉันเห็นด้วยกับบรูซในระดับหนึ่ง แม้ว่าฉันจะไม่คุ้นเคยกับน้ำตกหรือโฟโต้มากนักและก็ไม่สามารถออกความเห็นได้
สิ่งที่ฉันอ่านเมื่อเร็ว ๆ นี้และฉันคิดว่าพูดได้ดีจริงๆคือแม้ใน Agile เราก็ละเลยการวางแผน เซสชั่นการวางแผนอย่างละเอียดเมื่อทำซ้ำดีมาก - ไม่จำเป็น - แต่เพื่อวางแผนตลอดการทำซ้ำ
ฉันทำงานในอุตสาหกรรมบันเทิงที่มีการเปลี่ยนแปลงอยู่ตลอดเวลา ทีมต้องการความผ่อนปรน / ความยืดหยุ่นในระดับหนึ่งซึ่งจะช่วยให้พวกเขา "วางแผนใหม่" เรื่องราวในช่วงกลางของการวิ่งเพื่อให้สอดคล้องกับเป้าหมายใหม่หรือเป้าหมายที่แก้ไข
ฉันชอบความคิดในการวางแผนอย่างต่อเนื่องเนื่องจากนักพัฒนาซอฟต์แวร์มักจะบอกเจ้าของผลิตภัณฑ์ให้หายตัวไปเมื่อพวกเขากำลังทำงานกับเรื่องราวตอนกลางคัน นี่เป็นสิ่งที่ยอดเยี่ยมถ้าทีมของคุณทำงานในเรื่องราวที่ยังใช้งานได้และเจ้าของผลิตภัณฑ์ของคุณกำลังสร้างความรำคาญ แต่ในบางกรณีเรื่องราวจะซ้ำซ้อนในระหว่างการวิ่งและจำเป็นสำหรับเจ้าของผลิตภัณฑ์ที่จะมองเห็นสิ่งนี้และสำหรับทีมที่จะปรับแนวเป้าหมาย / เรื่องราวที่เปลี่ยนแปลงไป - นั่นไม่ใช่ความว่องไวอะไร