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

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

เรียนผู้เริ่มต้น! แบบจำลอง วิธีการ และความสับสนทั่วไป

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

1. การต่อสู้

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

ข้อดี:

• ความสามารถในการเปิดตัวโครงการอย่างรวดเร็วด้วยงบประมาณที่ต่ำที่สุด
• การติดตามความคืบหน้ารายวัน การสาธิตโครงการบ่อยครั้ง
• ความสามารถในการปรับเปลี่ยนระหว่างโครงการ

จุดด้อย:

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

สำหรับใคร?

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

2. คัมบัง

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

ข้อดี:

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

จุดด้อย:

• ไม่ทำงานกับทีมมากกว่าห้าคน
• ไม่ได้มีไว้สำหรับการวางแผนระยะยาว
• ไม่เหมาะกับทีมที่ไม่มีแรงจูงใจ Kanban ไม่มีกำหนดเวลาสำหรับทุกรายการงาน วิธีการไม่ได้กำหนดบทลงโทษสำหรับความล่าช้า

สำหรับใคร?

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

3. กระบวนการรวมเหตุผล (RUP)

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

ข้อดี:

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

จุดด้อย:

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

สำหรับใคร?

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

มีหลายวิธี แต่มีแนวโน้มเดียว

นอกจาก Scrum และ Kanban ซึ่งได้รับความนิยมอย่างปฏิเสธไม่ได้และยึดตามหลักการที่คล่องตัวเช่นเดียวกับวิธีการ RUP ที่ทนทานและทำซ้ำแล้วซ้ำอีก บริษัทต่างๆ ยังใช้วิธีการที่หลากหลาย บริษัทหนึ่งอาจใกล้เคียงกับการเขียนโปรแกรมขั้นสุดโต่งและตัดสินใจได้เร็วและง่ายที่สุด อีกอันหนึ่งอาจใกล้เคียงกับการพัฒนาเพื่อการทดสอบ อีกคนอาจชอบการพัฒนาแอปพลิเคชันอย่างรวดเร็ว (RAD) ที่กล่าวว่ามีแนวโน้มที่แข็งแกร่งและไม่ต้องสงสัยในการใช้หลายวิธีพร้อมกัน. หรือแม้กระทั่งการรวมโมเดลและวิธีการเข้าไว้ในระบบการจัดการที่ไม่เหมือนใคร บริษัทในปัจจุบันพยายามขจัดอุปสรรคของระบบราชการและสร้างบรรยากาศของการทำงานเป็นทีมที่เป็นเอกภาพภายในองค์กร โดยไม่มีการเปลี่ยนความรับผิดชอบระหว่างแผนกและหน่วยงานในองค์กร ตามScrum Alliance70% ของบริษัทไอทีใช้การต่อสู้ ในบรรดายักษ์ใหญ่เช่น Google, Amazon, Salesforce, Microsoft และ Adobe สตาร์ทอัพและโครงการใหม่มีแนวโน้มที่จะใช้ Kanban มากกว่า แต่ Toyota และเกมเมอร์ที่ Wargaming ก็ใช้เช่นกัน Scrum เป็นเครื่องมือในการวางแผน ในขณะที่ Kanban ใช้สำหรับติดตามความคืบหน้า สำหรับ RUP มักใช้โดยบริษัทตะวันตกที่มีพนักงาน 50-200 คนและรายได้ 1-10 ล้านดอลลาร์ อย่างไรก็ตาม IBM ได้แก้ไข RUP เพื่อให้เข้าใกล้หลักการแบบอไจล์มากขึ้น โดยปล่อยระเบียบวิธี OpenUP (RUP แต่คล่องตัว) วิธีการ ที่คล่องตัวโอ้อวดนี้กำลังขับเคลื่อนโลกไอที นี่ไม่ใช่แค่กระแสนิยมที่ผ่านไปเท่านั้น แต่ยังเป็นนวัตกรรมใหม่ และอันที่จริงแล้ว มันถูกนำไปใช้ในบริษัทขนาดใหญ่หลายแห่ง Agile ใช้ใน Silicon Valley Facebook และ Uber ใช้มัน

บรรทัดล่างสุด

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