มีทางเลือกที่เป็นไปได้ในวิธีการพัฒนาแบบว่องไวหรือไม่?

สองวิธีการพัฒนาซอฟต์แวร์ที่โดดเด่นคือน้ำตกและความคล่องตัว เมื่อพูดถึงสองสิ่งนี้มักจะให้ความสำคัญกับการปฏิบัติที่แตกต่าง (การเขียนโปรแกรมคู่, TDD, ฯลฯ กับข้อมูลจำเพาะการทำงานการออกแบบขนาดใหญ่ด้านหน้า ฯลฯ )

แต่ความแตกต่างที่แท้จริงนั้นลึกซึ้งยิ่งกว่านั้นการปฏิบัติเหล่านี้มาจากปรัชญา

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

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

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

แน่นอนว่าน้ำตกเป็นไปได้ มันนำเราไปสู่ดวงจันทร์!

และมันก็เป็นโค้ชที่คล่องแคล่วพูดคุยที่นี่!

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

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

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

ก่อนอื่นฉันจะไม่เห็นด้วยกับข้อความของคุณ:

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

การตีความของฉันคือ:

Waterfall พูดว่า: ลูกค้ารู้ว่าพวกเขาต้องการอะไร
Agile พูดว่า: ลูกค้าไม่รู้ว่าพวกเขาต้องการอะไรเราจะต้องสร้างเวอร์ชั่นที่แตกต่าง

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

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

คุณเริ่มต้นด้วยการพูดว่า:

สองปรัชญาการพัฒนาซอฟต์แวร์ที่โดดเด่นคือน้ำตกและความคล่องตัว

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

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

ดังนั้นใช่แน่นอนมีทางเลือกที่ปฏิบัติได้เพื่อความคล่องตัว

ใช่เทคนิคการพัฒนาซอฟต์แวร์ที่หลากหลายนั้นขึ้นอยู่กับโดเมนปัญหาของคุณ มันคือ "Horses for Courses"

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

สร้าง UI ทางการตลาดบนเว็บ 2.0 / 3.0 / buzzy ล่าสุดหรือไม่ Agile เป็นวิธีที่ดีกว่ามากในการดำเนินการ (คุณต้องการความคิดเห็นและการเปลี่ยนแปลงที่รวดเร็ว)

มีสิ่งที่ฉันจะเรียกหลักการฝีมือซอฟต์แวร์ที่ยังคงสามารถนำไปใช้ไม่ว่าจะเป็นวิธีการเช่น:

• การควบคุมแหล่งที่มา
• สร้างและ CI
• การเขียนโปรแกรมคู่
• TDD
• ฉันให้ ^% $$ &

และอื่น ๆ.

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

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

การเปลี่ยนแปลงซอฟต์แวร์ ซอฟต์แวร์เปลี่ยนแปลงอย่างรวดเร็ว กฎของมัวร์ระบุว่าจำนวนทรานซิสเตอร์บนชิปเพิ่มเป็นสองเท่าทุกๆ 18-24 เดือน ในข้อสรุปจำนวนบรรทัดของรหัสในโปรแกรมยังเป็นสองเท่า ความซับซ้อนในระหว่างบรรทัดของโค้ดเหล่านั้นจึงเพิ่มขึ้นด้วย bigO ของบางอย่างเช่น 2 ^ (2t)

ซอฟต์แวร์เปลี่ยนแปลงอย่างรวดเร็วและความซับซ้อนเพิ่มขึ้นอย่างทวีคูณ

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

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

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

อย่างไรก็ตาม 2 เซ็นต์ของฉัน

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

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

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

และถ้า OPEN / Metis ซ้ำแล้วซ้ำอีกและเพิ่มขึ้นสำหรับฉันมันดูเหมือนว่าจะมีปรัชญาว่องไวแม้ว่ามันจะไม่เชื่อมโยงกับการปฏิบัติเปรียวทั่วไปอื่น ๆ

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

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

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

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

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

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

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

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

มันเป็นสิ่งหนึ่งที่จะพูดว่า "โอเคตอนนี้เราเป็น Agile" และอีกสิ่งหนึ่งที่จะใช้ชีวิตและทำงานตามปรัชญาที่ Agile เป็นจริง ไม่ว่าคุณจะใช้น้ำตกที่เพิ่มขึ้น, เกลียว, การต่อสู้, XP, FDD หรือวิธีการอื่น ๆ ที่คุณมีพื้นเปรียวที่คุณคุ้มค่า:

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

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

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

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

Waterfall พูดว่า: การเปลี่ยนแปลงมีค่าใช้จ่ายสูงดังนั้นจึงควรลดให้น้อยที่สุด

Agile พูดว่า: การเปลี่ยนแปลงหลีกเลี่ยงไม่ได้ดังนั้นจงทำการเปลี่ยนแปลงให้ถูก

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

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

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

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