ในการสัมภาษณ์หลายครั้ง คุณอาจถูกถามเกี่ยวกับวิธีการ นี่ไม่ใช่คำถามที่สำคัญหรือยากที่สุด แต่การมีเอกสารแนะนำก็เป็นเรื่องที่ดี ในบทความนี้เราจะพยายามถ่ายทอดวิธีการพัฒนาและเปรียบเทียบ วิธีการพัฒนาซอฟต์แวร์เป็นกระบวนการที่ใช้ในการพัฒนาผลิตภัณฑ์เฉพาะ กล่าวคือเป็นวิธีหนึ่งในการจัดระเบียบการพัฒนาโดยทีมนักพัฒนา มีรูปแบบการพัฒนาที่แตกต่างกันมากมาย ซึ่งแต่ละรูปแบบจะกำหนดแนวทางของตัวเอง ไม่สามารถพูดได้ว่าใครควรใช้สำหรับทุกโครงการ แนวทางที่ถูกต้องขึ้นอยู่กับสถานการณ์ทั้งหมด ฉันตั้งใจที่จะพิจารณาสามคนในรายละเอียดมากขึ้น
ข้อดี:
ฉันจะพยายามอธิบายสั้น ๆ ถึงสาระสำคัญของวิธีการโดยใช้คำง่าย ๆ แต่มีคำศัพท์มากมาย ฉันคิดว่าสิ่งที่สำคัญที่สุดคือต้องเข้าใจสาระสำคัญ คุณจะจำคำศัพท์ด้วยประสบการณ์ การพัฒนาทั้งหมดแบ่งออกเป็นช่วงวิ่ง (โดยปกติจะใช้เวลา 2-3 สัปดาห์) มีงานค้าง อยู่(รายการงาน) สำหรับช่วงการพัฒนาทั้งหมดและสำหรับแต่ละสปรินต์ที่แยกจากกัน แต่ละงานมีจุดเรื่องราวของตัวเอง (ระดับความยาก) ผู้เข้าร่วมแต่ละคนในกระบวนการมีบทบาท:
น้ำตก
วิธีการของน้ำตกเป็นหนึ่งในวิธีที่เก่าแก่ที่สุดและเกี่ยวข้องกับการดำเนินการตามลำดับอย่างเคร่งครัด: แต่ละขั้นตอนจะต้องเสร็จสิ้นก่อนที่ขั้นตอนถัดไปจะเริ่มต้นขึ้น กล่าวอีกนัยหนึ่ง การเปลี่ยนไปยังขั้นตอนถัดไปหมายความว่างานของขั้นตอนที่แล้วเสร็จสมบูรณ์ 100% รูปภาพแสดงวิธีการทำงาน: ขั้นแรก เราวิเคราะห์ปัญหา (งานเอกสาร หารือเกี่ยวกับความท้าทาย) จากนั้นเราออกแบบ (โครงสร้างของโครงการเป็นรูปเป็นร่างในขั้นตอนนี้) จากนั้นเราเขียนโค้ดและทดสอบ ไม่อนุญาตให้ย้อนกลับไปยังขั้นตอนก่อนหน้า วิธีนี้แนะนำสำหรับโครงการขนาดเล็กที่ทราบข้อกำหนดล่วงหน้าและไม่น่าจะเปลี่ยนแปลง
- เอกสารครบถ้วนและสอดคล้องกันในแต่ละขั้นตอน
- สะดวกในการใช้
- ข้อกำหนดที่มั่นคง
- มีการกำหนดงบประมาณและกำหนดเวลาไว้ล่วงหน้า
- เอกสารจำนวนมาก
- ไม่ค่อยคล่องตัว
- ลูกค้าไม่สามารถดูรุ่นสาธิตของผลิตภัณฑ์ได้
- ไม่มีตัวเลือกให้ถอยหลัง
การต่อสู้
Scrum เป็นวิธีการพัฒนาซอฟต์แวร์ที่แบ่งกระบวนการทั้งหมดออกเป็นการวนซ้ำ เมื่อสิ้นสุดการโต้ตอบแต่ละครั้ง ทีมงานก็พร้อมที่จะจัดเตรียมเวอร์ชันสาธิตของผลิตภัณฑ์ รูปภาพแสดงให้เห็นว่าทีมงานดำเนินการในทุกขั้นตอนของการพัฒนาแบบคู่ขนาน ทำให้สามารถมีส่วนที่เสร็จสมบูรณ์ของโครงการเมื่อสิ้นสุดการทำซ้ำแต่ละครั้ง
- ทีมต่อสู้ประกอบด้วยมืออาชีพ (นักพัฒนา ผู้ทดสอบ นักออกแบบ) ที่ทำงานในโครงการ
- หัวหน้าการต่อสู้คือบุคคลที่ทำให้แน่ใจว่าหลักการของการต่อสู้ได้รับการเคารพ
- เจ้าของสินค้าคือลูกค้า
- Stand-up – เป็นการประชุมสั้นๆ ที่จัดขึ้นทุกวัน ซึ่งสมาชิกในทีมทุกคนมีส่วนร่วม ผู้เข้าร่วมแต่ละคนตอบคำถาม 3 ข้อ: ฉันทำอะไร ฉันจะทำอย่างไร และมีปัญหาการปิดกั้นอะไรบ้าง?
- การประชุมวางแผน – การประชุมนี้จัดขึ้นในช่วงเริ่มต้นของการวิ่ง งานที่ต้องดำเนินการในการวิ่งครั้งต่อไปจะถูกระบุในการประชุมครั้งนี้
- ย้อนหลัง - การประชุมนี้จัดขึ้นเมื่อสิ้นสุดการวิ่งและจุดประสงค์คือการระบุสิ่งที่ทำได้ดีและสิ่งที่สามารถปรับปรุงได้
- ลูกค้าสามารถเห็นผลลัพธ์ในระหว่างขั้นตอนการพัฒนา
- การตรวจสอบกระบวนการพัฒนาทุกวัน
- ความสามารถในการปรับเปลี่ยนระหว่างการพัฒนา
- สร้างการสื่อสารกับสมาชิกในทีมทั้งหมด
- เอกสารจำนวนเล็กน้อย
- ยากที่จะประเมินแรงงานและค่าใช้จ่ายอื่นๆ ที่จำเป็นสำหรับการพัฒนา
- ยากที่จะระบุคอขวดก่อนที่จะเริ่มการพัฒนา
- ความต้องการให้ทุกคนมีส่วนร่วมในงานของสมาชิกในทีมคนอื่นๆ
คันบัง
Kanban เป็นวิธีการแสดงภาพความคืบหน้าในการทำงานของทีมให้สำเร็จ แนวคิดหลักคือการลดจำนวนงานที่กำลังดำเนินการอยู่ (ในคอลัมน์ "กำลังดำเนินการ") ในการต่อสู้ ทีมมุ่งเน้นไปที่การทำสปรินต์ให้สำเร็จ ใน Kanban งานครองตำแหน่งที่โดดเด่น สิ่งนี้ดีสำหรับโปรเจกต์ที่อยู่ในขั้นตอนการบำรุงรักษา ซึ่งมีการใช้งานฟังก์ชันพื้นฐานไปแล้ว และยังคงมีการปรับปรุงและแก้ไขจุดบกพร่องเพียงเล็กน้อย ใน Kanban งานจะถูกมอบหมายทีละรายการ งานจะต้องผ่านขั้นตอนทั้งหมดบนกระดาน โดยไม่ขึ้นกับงานอื่นๆ และเมื่อเสร็จสิ้นแล้ว จะสามารถแสดงให้ลูกค้าเห็นได้ บอร์ด Kanban ประกอบด้วยคอลัมน์ ซึ่งแต่ละคอลัมน์แสดงถึงกระบวนการพัฒนาที่แยกจากกัน บางคอลัมน์ (เช่น "กำลังดำเนินการ") จำกัดจำนวนงานที่ทำได้ ช่วยให้ค้นหาพื้นที่ปัญหาได้อย่างรวดเร็วและง่ายดายในการกระจายงาน รูปภาพแสดงตัวอย่างของบอร์ดดังกล่าว จำนวนคอลัมน์และชื่ออาจแตกต่างกันไป ฉันจะนำเสนอสิ่งที่พบบ่อยที่สุด:
- สิ่งที่ต้องทำ – รายการงานที่ต้องทำ
- กำลังดำเนินการ - งานที่กำลังดำเนินการอยู่
- Code Review – งานที่ทำเสร็จแล้วและถูกส่งไปตรวจสอบแล้ว
- กำลังทดสอบ – งานพร้อมสำหรับการทดสอบ
- เสร็จสิ้น - งานที่เสร็จสิ้นแล้ว
- สะดวกในการใช้
- ทัศนวิสัย (ช่วยระบุตำแหน่งคอขวด ลดความซับซ้อนในการทำความเข้าใจ)
- การมีส่วนร่วมของทีมสูงในกระบวนการเอง
- การพัฒนาที่มีความยืดหยุ่นสูง
- รายการงานที่ไม่แน่นอน
- นำไปใช้กับโครงการระยะยาวได้ยาก
- ขาดกำหนดเวลาอย่างหนัก
GO TO FULL VERSION