การเขียนซ้ำซอฟต์แวร์โดยใช้วิธีการ Agile

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

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

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

ทำลายมันลงในมหากาพย์ระดับสูง ใช้แต่ละส่วนของแอปพลิเคชั่นทีละขั้นตอน

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

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

เมื่อคุณปล่อยส่วนประกอบหนึ่งไปยังการผลิตให้ย้ายไปยังองค์ประกอบถัดไป

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

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

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

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

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

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

• เมื่อคุณมี 20-50 มหากาพย์ให้ทีมประเมินพวกเขา

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

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

ปล่อยทันทีหากคุณทำได้

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

โรม (และเปรียว) ไม่ได้ถูกสร้างขึ้นในหนึ่งวัน

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

เป็น Bootstrapper ใช้ซ้ำ

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

ทำไมปล่อยก่อนและบ่อยครั้ง?

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

การเปิดตัวล่วงหน้าเป็นเรื่องไม่เป็นธรรมชาติ

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

อย่าวิจารณ์ทีมก่อนหน้า

ในขณะที่มันอาจตั้งค่านักพัฒนาที่ใช้เวลาเขียนใหม่เป็น heros และความรอดของโครงการฉันคิดว่ามีค่าใช้จ่ายในการวิจารณ์ความสำเร็จของทีมก่อนหน้านี้

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

ได้รับคำสั่งจากความคิดเห็นโดย @Chuck และการอ้างอิงถึง Netscape เป็นหลักว่าอย่าเขียนซ้ำและการตอบสนองที่ถูกต้องซึ่งตอบโต้ว่าเขา OP ไม่ได้ถามว่าควรหรือไม่ - วัฏจักรการพัฒนาซอฟต์แวร์ที่มีความคล่องตัวอย่างแท้จริงทำให้ไม่สามารถเขียนซ้ำได้ การเขียนซ้ำมักจะทำลายหลักการจำนวนมากที่อยู่เบื้องหลัง Agile การใช้ซอฟต์แวร์ปัจจุบันเป็นบรรทัดหลักหลักการ Agile เหล่านี้ (จากAgile Manifesto ) ไม่สามารถพบกับการเขียนซ้ำได้

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

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

คำถามนั้นตั้งอยู่บนสมมติฐานที่ผิด - การเขียนซ้ำนั้นอาจพิจารณาได้ว่า Agile

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

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

แอปพลิเคชันบนเดสก์ท็อปอาจมีความซับซ้อนมากขึ้น แต่มักจะเป็นไปได้

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

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

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

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

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

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

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