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

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

หมายเหตุสำหรับผู้เริ่มต้น: รูปแบบ วิธีการ และความสับสนทั่วไป

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

1. วิธีการต่อสู้

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

ข้อดี:

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

ข้อเสีย:

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

เหมาะกับใคร:

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

2. วิธีการคัมบัง

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

ข้อดี:

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

ข้อเสีย:

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

เหมาะกับใคร:

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

3. วิธีการ RUP

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

ข้อดี:

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

ข้อเสีย:

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

เหมาะกับใคร:

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

วิธีการมากมาย แนวโน้มเดียว

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

บรรทัดล่าง

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