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

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

ข้อ จำกัด เหล่านี้ดูเหมือนจะขัดแย้งกับหลักการพื้นฐานของการพัฒนาที่คล่องตัวใช่ไหม?

การแย่งชิงกันเพียงในสภาพแวดล้อมดังกล่าวหรือไม่?

คุณอยากแนะนำอะไรกับองค์กรนี้

การแย่งชิงกันอาจไม่เหมาะสมสำหรับองค์กรนี้

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

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

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

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

• การปรับปรุงผลลัพธ์ของรัฐบาลผ่านรูปแบบสัญญาที่คล่องตัว
• ข้อตกลงซื้อผ้าห่มแบบว่องไว
• การทำสัญญาแบบแยกส่วน (การแบ่งโครงการขนาดใหญ่ออกเป็นโมดูลขนาดเล็กที่มีการพัฒนาแบบคล่องตัว)
• โครงการของคุณใช้“ ความคล่องตัว” หรือไม่?

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

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

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

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

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

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

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

ดังนั้นจึงไม่มีความขัดแย้งกับ Agile หรือ Scrum ใด ๆ มันเป็นคนที่ไม่ได้รับบทบาทของพวกเขา มันเป็นวิธีการทำงานของรัฐบาลที่ก่อให้เกิดสิ่งนี้

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

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

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

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

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

"ผู้ซื้อกำลังมองหาซื้อการพัฒนา 10 สัปดาห์ 2 สัปดาห์จากทีม SCRUM ที่มีประสบการณ์ซึ่งประกอบด้วยนักพัฒนา 5 คนและผู้ที่ได้รับการรับรอง SCRUM หลัก (ผู้ซื้อจะกรอกข้อมูลในบทบาทผู้มีส่วนได้เสีย) Sprint จะเริ่มตั้งแต่เดือนมีนาคม 2018 ถึงกรกฎาคม 2018" เริ่มต้นของการประกวดราคา คุณจะต้องแสดงรายการทักษะของทีมที่จำเป็นและให้แนวคิดเกี่ยวกับโครงการที่พวกเขาจะทำงาน แต่มันก็เป็นที่ยอมรับได้อย่างสมบูรณ์แบบที่จะมีการประกวดราคาเพื่อจ้างทีม

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

มันยาก.

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

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

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

หากคุณอนุญาตให้มีความยืดหยุ่นคุณสามารถปรับปรุงได้

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

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

มันขึ้นอยู่กับ แต่อาจจะใช่

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

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

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

คุณอยากแนะนำอะไรกับองค์กรนี้

ณ จุดนี้ไม่มีอะไร

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

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

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

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