การใช้ Agile ผิดหรือไม่เมื่อความต้องการของลูกค้าไม่เปลี่ยนแปลงเลย?

12

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

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

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

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

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

agile development-process

— InformedA
แหล่งที่มา

2

@ สุ่ม: จริง ๆ แล้ว IMHO คุณไม่ควรลองน้ำตกที่บริสุทธิ์หากคุณต้องการสร้างผลิตภัณฑ์ที่ใช้งานได้ซึ่งต้องการความพยายามมากกว่าหนึ่งสัปดาห์

— Doc Brown

10

กรุณาให้ลูกค้าของคุณ

— razethestray

7

ฉันจะมอบ 2x ให้กับลูกค้าของคุณมากกว่า @razethestray

— Euphoric

2

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

— Doc Brown

3

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

— Doc Brown

16

นี่ถือว่าเป็นสิ่งที่ไม่ดีโคบาลโค้ดต่อต้านรูปแบบหรือไม่

คำตอบสั้น ๆ : ไม่ การทำ "เปรียว" อย่างถูกต้องนั้นไม่ได้หมายความว่า "ไม่มีการวางแผน" แต่ก็ไม่ได้หมายถึงการวิเคราะห์สิ่งต่าง ๆ มากเกินไป

หนึ่งในเหตุผลสำคัญที่ทำให้การใช้งาน Agile นั้นเป็นเพราะลูกค้ามักเปลี่ยนแปลงข้อกำหนด

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

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

— หมอบราวน์
แหล่งที่มา

3

การทำ "น้ำตก" อย่างถูกต้องไม่ได้หมายความว่า "วางแผนทุกอย่าง" แต่ก็ไม่ได้หมายความว่าจะทำสิ่งที่ไม่ดี

— Giorgio

1

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

— Doc Brown

6

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

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

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

B) อาจจะดีพอสำหรับพวกเขาที่จะมีความสุขอยู่แล้วปล่อย

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

— SpoonerNZ
แหล่งที่มา

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

— Giorgio

1

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

— SpoonerNZ

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

— Giorgio

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

— SpoonerNZ

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

— Giorgio

3

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

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

— Bart van Ingen Schenau
แหล่งที่มา

1

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

— user99561

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

— Doc Brown

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

— user99561

0

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

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

— Silviu Burcea
แหล่งที่มา

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

— InformedA