ความท้าทายต่อแนวทาง Agile ในโครงการของรัฐบาล


24

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

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

  • ให้คุณสมบัติ X ตรงตามที่ร้องขอ

  • คำขอคุณสมบัติจะถูกโยนข้ามกำแพงไม่ต้องรบกวนเราเราไม่ต้องการได้ยิน

  • ไม่มีแนวคิดของคุณลักษณะที่สำคัญในใจของลูกค้าพวกเขาทั้งหมดมีความสำคัญหรือเราจะไม่ถามพวกเขา

  • โครงการจะไม่เสียค่าใช้จ่ายมากและไม่น้อยกว่า Y โดยไม่คำนึงถึงการรุกล้ำหรือกำหนดเวลา

  • กำหนดส่งมอบงานที่แน่นอนสมบูรณ์เข้มงวดสุดท้ายและไม่สามารถต่อรองได้

เราไม่เคยทำงานกับลูกค้ารายนี้มาก่อน แต่เงินในโครงการดีเกินกว่าจะผ่านไปได้ เราต้องการงานนี้

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

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


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

@ThomasOwens ฉันหวังว่าคุณจะ ... โปรดกลับมาและให้คำตอบเมื่อคุณได้รับโอกาส!
maple_shaft

1
"โครงการจะไม่มีค่าใช้จ่ายเพิ่มและไม่ต่ำกว่า Y โดยไม่คำนึงถึงการใช้งานเกินกำหนดหรือกำหนดเวลา" - คุณไม่ได้ทำงานในโครงการด้านไอทีใด ๆ สำหรับรัฐบาลสหราชอาณาจักรใช่ไหม ;)
Cocowalla

คำตอบ:


9

ฉันคิดว่าสิ่งแรกที่ต้องตระหนักคือความแตกต่างระหว่างการมีความคล่องตัวและความคล่องตัว เทคนิคและคุณลักษณะที่คล่องตัวช้า ๆ - ทีมข้ามสายงาน, การวางแผนแบบปรับตัว, การส่งแบบวิวัฒนาการ / ส่วนเพิ่ม, การวนซ้ำแบบกำหนดเวลาและแม้แต่การแนะนำแนวคิดจากLeanนั้นแตกต่างจากการแนะนำ Extreme Programming, Scrum หรือ Crystal

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

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

หากคุณคิดว่าคุณมีความต้องการทั้งหมดของคุณล่วงหน้าคุณก็ไม่มีโอกาส ข้อกำหนดมีการเปลี่ยนแปลง เพียงเพราะคุณมีข้อกำหนด "เสร็จสิ้นและลงชื่อออก" ไม่ได้หมายความว่าตั้งค่าไว้ในรูปแบบของหิน ระบุสิ่งที่คุณต้องการเอกสารจับพวกเขาว่าคุณรู้สึกสะดวกสบายและ / หรือในลักษณะที่ระบุไว้ในสัญญาและส่งมอบข้อกำหนดการออกแบบและสถาปัตยกรรม นอกจากนี้ดูว่าคุณสามารถปฏิบัติต่อเอกสารเหล่านี้ได้หรือไม่ (เอกสารการออกแบบที่ฉันเห็นในวันนี้ในที่ทำงานมีป้ายกำกับว่า Revision G ซึ่งหมายความว่าเป็นฉบับปรับปรุงครั้งที่ 8) ถามว่าคุณสามารถออกจาก TBD เป็นจำนวนเท่าใดในการวนซ้ำที่กำหนดไว้และเท่าไหร่ที่ต้องได้รับการยืนยันในตอนนี้ - อาจมีการให้และรับบางอย่าง

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

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

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

การพูดของเงินเรามีปัญหาต้นทุนคงที่และ / หรือกำหนดเวลาแน่นอน

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

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

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


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

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

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

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

11

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

Agile ถูกสร้างขึ้นเพื่อแก้ไขปัญหาที่คุณไม่มี: ความเสี่ยงเนื่องจากความไม่แน่นอนในข้อกำหนด

เป็นเรื่องจริงที่ลูกค้าอาจขอเปลี่ยนแปลง แต่คุณทำตามหนึ่งในสองเส้นทาง:

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

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

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


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

10

... รัฐบาลทำสัญญางานตัวอย่างเช่นสัญญาที่เข้มงวดอย่างเข้มงวดทำให้ บริษัท ต้อง:

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

หน่วยงานภาครัฐมีความคล่องตัวในทางที่ช้าและไม่มีประสิทธิภาพ คุณต้องเขียน (และต่อรอง) คำสั่งการเปลี่ยนแปลงอย่างเป็นทางการและมีรายละเอียดตลอดเวลา

ให้คุณสมบัติ X ตรงตามที่ร้องขอ

จนกว่าจะถูกแก้ไขโดยลำดับการเปลี่ยนแปลง

คำขอคุณสมบัติจะถูกโยนข้ามกำแพงไม่ต้องรบกวนเราเราไม่ต้องการได้ยิน

ช่องทางการสื่อสารคือลำดับการเปลี่ยนแปลง งบประมาณและผลกระทบกำหนดการ

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

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

นี่เป็นปัญหาที่ยาก

โครงการจะไม่เสียค่าใช้จ่ายมากและไม่น้อยกว่า Y โดยไม่คำนึงถึงการรุกล้ำหรือกำหนดเวลา

ยกเว้นคำสั่งเปลี่ยนแปลง ซึ่งแก้ไข Y และกำหนดเวลา

กำหนดส่งมอบงานที่แน่นอนสมบูรณ์เข้มงวดสุดท้ายและไม่สามารถต่อรองได้

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

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

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

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

มันทำให้วิธี Agile ที่ถูกต้องเป็นเรื่องยาก

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


+1 สำหรับจนกว่าการแก้ไขตามคำสั่งเปลี่ยนแปลง ข้อกำหนดคงที่คือการเข้าใจผิดและนี่เป็นกรณีของสัญญารัฐบาลเมื่อขอบเขตสามารถมหาศาล
Cocowalla

7

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

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

ดังนั้นจงคล่องแคล่วที่สุดเท่าที่จะทำได้:

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

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


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

3

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

ให้คุณสมบัติ X ตรงตามที่ร้องขอ

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

คำขอคุณสมบัติจะถูกโยนข้ามกำแพงไม่ต้องรบกวนเราเราไม่ต้องการได้ยิน

หากคุณรู้ว่าสิ่งที่พวกเขาต้องการไปและสร้างมัน

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

คุณไม่สามารถสูญเสียในนี้ สร้างพวกเขาตามที่เห็นสมควร

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

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


2

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

ฉันได้รับประโยชน์จากการเพิ่งทำโปรเจคที่คล้ายกันในหลาย ๆ สถานการณ์ที่คุณอธิบายเช่น

  1. แก้ไขกำหนดเวลา (ในก้อนหินมาลงนรกหรือสูง - น้ำ)
  2. หน้าที่ความต้องการเอกสาร ("พระคัมภีร์") ไม่น่าแปลกใจที่ไม่เพียงพอ
  3. บทบาทดั้งเดิม: ผู้จัดการโครงการนักวิเคราะห์ธุรกิจ
  4. ผู้ใช้ทางธุรกิจที่มีส่วนร่วมอ่อนแอ (คุณสามารถพูดว่า "ไม่มีสปอนเซอร์ผลิตภัณฑ์" ได้หรือไม่)

... และแน่นอนว่าทีมพัฒนาที่คิดไปข้างหน้ากำลังพยายามทำงานอย่างว่องไวแม้จะอยู่เหนือ:

  1. ทำซ้ำ 2 สัปดาห์
  2. สแตนด์อัพ;
  3. retrospectives;
  4. การเขียนโปรแกรมคู่
  5. TDD;
  6. บูรณาการอย่างต่อเนื่อง

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

คำตอบที่คนอื่น ๆ ให้ไว้ข้างต้นนั้นมีระดับการประนีประนอมที่มากกว่าหรือน้อยกว่า ในความคิดของฉันเปรียว (ไม่ว่า "เปรียว" หรือ "เปรียว") คือ "ทำใน" ในอันตรายเมื่อเราประนีประนอม ในความเห็นของฉัน:

ไม่มีการประนีประนอมหรือไม่มีความคล่องตัว

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


1

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

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

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

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

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


0

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.