ก้าวเล็กๆ มากมาย

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

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

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

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

หากคุณนึกถึงวิธีการแบบ Agile/Lean ทั้งหมดจะพูดถึงการเพิ่มขึ้นทีละน้อยและบ่อยครั้ง การเพิ่มขึ้นทีละน้อยเหล่านี้มีประโยชน์มากมาย:

• ความเสี่ยงน้อยลง จำนวนของสิ่งที่ผิดพลาดจะลดลงหากเราเปลี่ยนแปลงบางสิ่ง
• เร็วกว่าในการผลิตเนื่องจากจำนวนรายละเอียดที่ต้องจำและนำมาพิจารณามีน้อย ( ภาระความรู้ความเข้าใจต่ำ )
• พวกเขาผลักดันให้เราทบทวนกระบวนการของเราครั้งแล้วครั้งเล่าเพื่อไปสู่การผลิต เพราะเมื่อเราพัฒนาเร็วขึ้น เราก็ต้องไปยังขั้นตอนอื่นๆ ในกระบวนการเร็วขึ้นด้วย การระบุคอขวดต่อไปในระบบจะง่ายกว่า (มีข้อ จำกัด ในระบบเสมอhttps://www.leanproduction.com/theory-of-constraints/)

เมื่อเราพูดถึงแผนใน Agile เรากำลังพูดถึง User Stories

เรื่องราวของผู้ใช้คือคำมั่นสัญญาสำหรับการสนทนา
https://en.wikipedia.org/wiki/User_story

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

แต่เรื่องราวของผู้ใช้ที่ดีควรเป็น:

• “ฉัน” อิสระ (จากคนอื่นทั้งหมด)
• “N” ตกลงกันได้ (ไม่ใช่สัญญาเฉพาะสำหรับคุณสมบัติ)
• “V” aluable (หรือแนวตั้ง)
• “E” stimable (เป็นการประมาณที่ดี)
• ห้างสรรพสินค้า “เอส” (เพื่อให้พอดีกับส่วนเพิ่ม)
• “T” estable (โดยหลักการแล้วแม้ว่าจะยังไม่มีการทดสอบก็ตาม)

มีทางเลือกอื่นที่พยายามทำให้ปัญหาง่ายขึ้นในอีกมิติหนึ่งในขณะที่เรากำลังพัฒนา

การพัฒนา

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

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

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

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

เครื่องมือ/แนวทางปฏิบัติใดบ้างที่จะช่วยให้เราทำงานในขั้นตอนเล็กๆ ได้?

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