10 เคล็ดลับการพัฒนา Agile ที่ผ่านการทดสอบและทดสอบแล้ว

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

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

ที่มาของภาพ: โปสเตอร์ Agile Manifesto โดย Adam Weisbart

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

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

ฮาร์ดแวร์ที่ยอดเยี่ยมสำหรับนักพัฒนาและผู้ทดสอบของคุณ

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

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

มุ่งเน้นที่ผลลัพธ์

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

ด้วยรูปแบบการจัดการจากบนลงล่างนี้ ทีมพัฒนาจึงคาดว่าจะได้ผลลัพธ์ที่เป็นรูปธรรมและวัดผลได้ พวกเขาต้องสามารถแสดงผลงานของตนได้ ไม่ใช่แค่ในโค้ดเท่านั้น แต่มีบางอย่างที่ใช้งานได้จริงตามที่ตั้งใจไว้ สิ่งนี้จะอยู่ภายใต้การสั่นคลอนผ่าน Test Driven Development (TDD) ซึ่งเป็นกระบวนการที่มีบทบาทสำคัญในการพัฒนา Agile

ดำเนินการจัดส่งอย่างต่อเนื่องก่อน

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

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

รับการสนับสนุนสำหรับผู้บริหารระดับสูง

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

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

ย้ายไปสู่การพัฒนาที่สั้นลงและรอบการทดสอบ

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

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

บรรลุการทำงานอัตโนมัติตั้งแต่วันแรก

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

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

อัตราส่วนทีมที่มีประสิทธิภาพ

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

วางแผนปัญหาที่เปิดกว้าง

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

ขอคำติชม

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

การประเมินกระบวนการของคุณ

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