สายมีความหมายใด ๆ ในระเบียบวิธี Agile หรือไม่?


10

นี่มาจากคำตอบและความเห็นบางส่วนของคำถามอื่น (อันนี้ )

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

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

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

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

(เห็นได้ชัดว่าฉันเข้าใจว่าการวิ่งอาจย่ำแย่ แต่ฉันกำลังพูดถึงเรื่องนั้น)

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

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


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

ฉันคิดว่านี่เป็นคำถามที่น่าสนใจมาก มันตัดตรงไปยังหลักของสิ่งที่ทำให้เปรียวแตกต่าง
Martin Wickman

คำตอบ:


9

ฉันไม่เห็นด้วยว่าโครงการ Agile ไม่มีแผนล่วงหน้า

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

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

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


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

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

6

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

คุณเรียนรู้จากมันและปรับสำหรับการทำซ้ำต่อไป

ความแตกต่างคือสิ่งนี้สามารถเกิดขึ้นได้ทุก 2-4 สัปดาห์ดังนั้นบทเรียนจะได้เรียนรู้และกระบวนการได้รับการปรับตัวอย่างรวดเร็ว


1
+1 "สุนัขของคุณกิน bytecode ของฉัน" (ต้องใช้บางครั้ง) - แต่ข้อเสนอแนะที่จริงจังของข้อผิดพลาดอย่างรวดเร็วเป็นกุญแจสำคัญในวิธีการเปรียว
Gary Rowe

4

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

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


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

4

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

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

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

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

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

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

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

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


0

Agile SCRUM มีสองประเภท "ช้า"

  1. Carryover - เรื่องราวที่ไม่ "เสร็จสิ้น" ในตอนท้ายของการวิ่งนักพัฒนา "ส่งมอบ" เพื่อทำ PBI ให้เสร็จดังนั้นเมื่อไม่ดำเนินการ

  2. Roadmap - สมมติว่าองค์กรของคุณมีแผนงานและสมมติว่ามีวันที่หากไม่สามารถส่งมอบงานที่สำคัญสำหรับวันที่เหล่านั้นได้ถือได้ว่าเป็น "ล่าช้า"

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