มีความคล่องตัวมากกว่าน้ำตกขนาดเล็กหรือไม่?

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

ความเข้าใจของฉันถูกต้องหรือมากกว่านั้นใช่ไหม ปรัชญาที่ว่องไวคืออะไร

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

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

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

บุคคลและการมีปฏิสัมพันธ์เหนือกระบวนการและเครื่องมือ

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

ซอฟต์แวร์ที่ทำงานผ่านเอกสารที่ครอบคลุม

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

การทำงานร่วมกันของลูกค้าในการเจรจาสัญญา

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

ตอบสนองต่อการเปลี่ยนแปลงมากกว่าการทำตามแผน

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

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

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

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

หากคุณจริงจังกับ Agile นี่คือเว็บคาสต์ที่ดี (และยาว) ที่คุณอาจสนใจ:

http://autumnofagile.net/

ลืมความคล่องตัวไปหนึ่งนาทีคิดว่า "น้ำตก" มีความหมายอย่างไร

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

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

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

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

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

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

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

สำหรับภาพรวมที่ดีของสิ่งที่วิธีการเปรียวพยายามที่จะทำผมขออยากแนะนำให้ Allistair เบิร์นของAgile Software Development: สหกรณ์เกม

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

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

เป็นสิ่งที่ถูกต้องหรือมีมากกว่านั้น

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

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

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

รายการเปรียวเน้นความแตกต่างบางอย่างระหว่างเปรียวและน้ำตก (ตามที่รับรู้โดยผู้ที่ลงนาม)

จริงๆ "เปรียว" มักจะหมายถึงน้ำตก 1-2 วันไม่ใช่สัปดาห์ นั่นไม่ได้หมายความว่าคุณไม่ได้ทำตามแผนโดยรวมและวัฏจักรการปล่อยแท้จริงคือ 1-2 วัน แต่คุณควรพยายามมีผลิตภัณฑ์ที่ใช้งานได้ทดสอบทุกวันและคุณสามารถปล่อยมัน - ตามทฤษฎี - ทุกวัน

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