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