อุตสาหกรรมคอมพิวเตอร์เต็มไปด้วยภาษาที่คลุมเครือ ศัพท์แสงที่รุนแรง และแนวคิดที่ซับซ้อนซึ่งยากต่อการเข้าใจ และสามารถส่งความคิดของคุณไปสู่ความบ้าคลั่งของการบัฟเฟอร์เชิงคำนวณ
น้ำตก? การต่อสู้? เปรียว?
หากวลีเหล่านี้ต่างไปจากเดิมอย่างสิ้นเชิง ไม่ต้องกังวล ทีมผู้เชี่ยวชาญด้านเทคโนโลยี HashDork พร้อมให้ความช่วยเหลือคุณในการทำความเข้าใจความแตกต่างระหว่างขั้นตอนสำคัญเหล่านี้ของกระบวนการพัฒนาเพื่อให้คุณมีความรู้
เทคนิค Agile, Scrum และ Waterfall จะกล่าวถึงในบล็อกโพสต์นี้ พร้อมกับวิธีที่แต่ละวิธีสามารถช่วยทีมของคุณโดยรวมได้
เริ่มจาก Agile ก่อน แล้วเราจะลุยกันต่อไป
Agile คืออะไร?
การพัฒนาซอฟต์แวร์แบบ Agile เป็นไปตามแนวทางแบบวนซ้ำและเพิ่มขึ้นเรื่อยๆ แทนที่จะต้องเตรียมการอย่างกว้างขวางในช่วงเริ่มต้นของโปรเจ็กต์ เทคนิค Agile มีความยืดหยุ่นต่อความต้องการที่เปลี่ยนแปลงตลอดเวลา และส่งเสริมการตอบรับอย่างต่อเนื่องจากผู้ใช้ปลายทาง
ทีมข้ามสายงานทำงานกับการทำซ้ำผลิตภัณฑ์เมื่อเวลาผ่านไป และงานนี้ถูกจัดประเภทเป็นงานในมือและจัดลำดับความสำคัญตามมูลค่าทางธุรกิจหรือลูกค้า วัตถุประสงค์ของการทำซ้ำแต่ละครั้งคือการสร้างผลิตภัณฑ์ที่ใช้งานได้
ภาวะผู้นำส่งเสริมความร่วมมือ ความรับผิดชอบ และการสื่อสารแบบเห็นหน้ากันในระเบียบวิธีแบบ Agile
ผู้มีส่วนได้ส่วนเสียทางธุรกิจและนักพัฒนาต้องร่วมมือกันเพื่อให้แน่ใจว่าผลิตภัณฑ์ตอบสนองความต้องการของผู้บริโภคและเป้าหมายของบริษัท
วลี "การพัฒนาที่คล่องตัว" หมายถึงวิธีการและกรอบการทำงานที่หลากหลายซึ่งอยู่บนพื้นฐานของอุดมการณ์และหลักที่ร่างไว้ใน ประกาศเปรียว.
ผู้เชี่ยวชาญแนะนำให้ปฏิบัติตามหลักการและค่านิยมที่คล่องตัว และใช้เป็นแนวทางในการตัดสินใจดำเนินการที่เหมาะสมในสภาพแวดล้อมเฉพาะในขณะที่เข้าใกล้การพัฒนาซอฟต์แวร์
ทีมงานที่ทำงานร่วมกันและจัดระเบียบตนเองเป็นประเด็นหลักสำหรับชุมชนการพัฒนาซอฟต์แวร์ที่คล่องตัว
ทีมได้รับอนุญาตให้ตัดสินใจด้วยตนเองว่าจะจัดการกับโครงการใดโครงการหนึ่งอย่างไร แต่นั่นไม่ได้หมายความว่าหัวหน้างานจะไม่มีอยู่จริง ทีม Agile จึงเป็นแบบข้ามสายงาน
ในกระบวนทัศน์ที่คล่องตัว ผู้จัดการยังคงมีความจำเป็น พวกเขาทำให้แน่ใจว่าสมาชิกในทีมทุกคนมีหรือได้รับความสามารถที่จำเป็นสำหรับโครงการ
ผู้จัดการในกรอบงานที่คล่องตัวทำงานโดยสร้างบรรยากาศที่นำสิ่งที่ดีที่สุดในทีมออกมา แต่แทนที่จะเป็นผู้นำ พวกเขามักจะนั่งเบาะหลังและให้ทีมตัดสินใจว่าจะส่งมอบสิ่งของอย่างไร
ผู้จัดการจะมีส่วนร่วมก็ต่อเมื่อทีมพยายามแก้ไขปัญหาซ้ำแล้วซ้ำเล่าไม่ประสบผลสำเร็จ
วัฏจักรการพัฒนาเปรียว
ขั้นตอนของวัฏจักรการพัฒนา Agile มีดังต่อไปนี้ สิ่งสำคัญคือต้องจำไว้ว่าขั้นตอนเหล่านี้ไม่ควรเกิดขึ้นตามลำดับเนื่องจากมีความยืดหยุ่นและเปลี่ยนแปลงอยู่ตลอดเวลา หลายขั้นตอนเหล่านี้เกิดขึ้นพร้อมกัน
- การวางแผน: หลังจากที่ทีมโครงการตัดสินใจว่าแนวคิดนั้นใช้ได้จริงและใช้งานได้จริง พวกเขาก็เริ่มมองหาคุณสมบัติ ขั้นตอนนี้มีจุดมุ่งหมายเพื่อจัดลำดับความสำคัญของคุณลักษณะแต่ละอย่างและกำหนดให้มีการทำซ้ำหลังจากแบ่งแนวคิดออกเป็นชิ้นงานขนาดเล็กลง (คุณลักษณะ)
- การวิเคราะห์ความต้องการ: เพื่อกำหนดข้อกำหนดทางธุรกิจ ขั้นตอนนี้เกี่ยวข้องกับการหารือหลายครั้งกับผู้จัดการ ผู้มีส่วนได้ส่วนเสีย และผู้ใช้ ผู้ที่จะใช้ผลิตภัณฑ์และวิธีการใช้นั้นอยู่ในรายละเอียดที่ทีมต้องรวบรวม มาตรฐานเหล่านี้ต้องมีความเฉพาะเจาะจง นำไปใช้ได้ และเชิงปริมาณ
- ออกแบบ: ข้อกำหนดที่พบในขั้นตอนก่อนหน้านี้ใช้เพื่อเตรียมระบบและการออกแบบซอฟต์แวร์ ทีมงานต้องพิจารณาถึงรูปลักษณ์ของผลิตภัณฑ์หรือโซลูชัน กลยุทธ์หรือแผนสำหรับการทดสอบได้รับการพัฒนาโดยทีมทดสอบ
- การนำไปใช้ การเข้ารหัส หรือการพัฒนา: จุดเน้นของขั้นตอนนี้อยู่ที่การสร้างและประเมินคุณลักษณะและการวางแผนการปรับใช้การวนซ้ำ (ตามแนวทางการพัฒนาแบบวนซ้ำและแบบเพิ่มส่วน [IID]) เนื่องจากไม่มีการจัดเตรียมคุณสมบัติ การวนซ้ำ 0 ของระยะเวลาการพัฒนาจึงเริ่มต้นขึ้น โดยการทำกิจกรรมต่างๆ เช่น การทำสัญญา การตั้งค่า และเงินทุน การทำซ้ำนี้เป็นรากฐานสำหรับการเติบโตในอนาคต
- การทดสอบ: หลังจากสร้างโค้ดแล้ว จะมีการทดสอบกับข้อกำหนดเพื่อให้แน่ใจว่าผลิตภัณฑ์ตอบสนองความต้องการของผู้ใช้อย่างแท้จริงและตรงตามวัตถุประสงค์ทางธุรกิจ การทดสอบหน่วย การบูรณาการ ระบบ และการยอมรับได้ดำเนินการในขั้นตอนนี้
- การใช้งาน: หลังจากการทดสอบ ผลิตภัณฑ์จะถูกส่งไปยังลูกค้าเพื่อให้สามารถใช้งานได้ โครงการยังไม่เสร็จสิ้นหลังจากการปรับใช้ ลูกค้าอาจพบปัญหาเพิ่มเติมหลังจากเริ่มใช้ผลิตภัณฑ์ ซึ่งจะต้องให้ทีมโครงการค้นหาวิธีแก้ไข
ข้อดี
- การจัดส่งที่รวดเร็วและมีคุณภาพสูงขึ้น: โดยการแบ่งโปรเจ็กต์ออกเป็นแบบวนซ้ำ (หน่วยที่จัดการได้) ทีมงานจะสามารถมุ่งความสนใจไปที่การทำงานร่วมกัน การพัฒนา และการทดสอบที่มีคุณภาพสูงขึ้น เมื่อทำการทดสอบด้วยการวนซ้ำแต่ละครั้งจะพบปัญหาและแก้ไขปัญหาได้รวดเร็วยิ่งขึ้น นอกจากนี้ ด้วยการแก้ไขอย่างต่อเนื่องและตามมา ซอฟต์แวร์คุณภาพสูงนี้สามารถจัดหาได้รวดเร็วยิ่งขึ้น
- ยินดีต้อนรับการเปลี่ยนแปลง: แม้ว่ารอบการวางแผนจะสั้นลง แต่ก็ง่ายที่จะยอมรับและรองรับการเปลี่ยนแปลงในทุกจุดของโครงการ งานในมือสามารถปรับปรุงและจัดลำดับความสำคัญใหม่ได้เสมอ ทำให้ทีมสามารถเปลี่ยนแปลงโครงการได้ภายในสองสามสัปดาห์
- เป้าหมายสุดท้ายอาจไม่เป็นที่รู้จัก: Agile นั้นยอดเยี่ยมสำหรับโครงการเมื่อเป้าหมายสุดท้ายไม่ชัดเจน เมื่อโครงการดำเนินต่อไป วัตถุประสงค์จะชัดเจน และการพัฒนาจะสามารถตอบสนองความต้องการที่เปลี่ยนแปลงไปเหล่านี้ได้อย่างง่ายดาย
- พัฒนาอย่างต่อเนื่อง: โปรแกรม Agile ส่งเสริมการป้อนข้อมูลของผู้ใช้และทีมในทุกขั้นตอนของโครงการ ทำให้สามารถประยุกต์ใช้สิ่งที่เรียนรู้เพื่อทำซ้ำต่อไปได้ดียิ่งขึ้น
- ความคิดเห็นของลูกค้ามีค่า: มีโอกาสมากมายที่ลูกค้าจะได้ชมงานที่ทำเสร็จแล้ว ให้ข้อเสนอแนะ และส่งผลต่อผลลัพธ์สุดท้ายจริงๆ การมีปฏิสัมพันธ์อย่างใกล้ชิดกับทีมโครงการอาจทำให้พวกเขาพัฒนาความรู้สึกเป็นเจ้าของได้
- ทีมงานที่แข็งแกร่ง: Agile เน้นย้ำถึงความสำคัญของการสื่อสารเป็นประจำและการเผชิญหน้ากันแบบตัวต่อตัว ผู้คนสามารถรับผิดชอบและเป็นเจ้าขององค์ประกอบโครงการบางอย่างเมื่อทำงานเป็นทีม
ข้อเสีย
- สมาชิกในทีมต้องมีความรู้e: ทีม Agile มักมีขนาดเล็ก ดังนั้นสมาชิกในทีมจึงต้องมีทักษะที่หลากหลาย นอกจากนี้พวกเขาจะต้องเข้าใจและรู้สึกสบายใจโดยใช้เทคนิค Agile ที่เลือก
- การวางแผนอาจแม่นยำน้อยลง: บางครั้งอาจเป็นเรื่องยากที่จะระบุวันที่จัดส่งที่แน่นอน Agile สร้างขึ้นจากการส่งมอบตามเวลาที่กำหนด และผู้จัดการโครงการมักจัดลำดับความสำคัญของงานใหม่ ดังนั้น จึงเป็นไปได้ว่าการส่งมอบบางส่วนที่กำหนดไว้สำหรับการจัดส่งในตอนแรกจะไม่เสร็จสิ้นตรงเวลา นอกจากนี้ อาจมีการเพิ่ม sprint เพิ่มเติมที่จุดใดก็ได้ตลอดโครงการ ซึ่งจะทำให้กำหนดการทั้งหมดยาวนานขึ้น
- เอกสารอาจถูกละเว้น: สมาชิกในทีมบางคนอาจเชื่อว่าการจดจ่อกับเอกสารมีความสำคัญน้อยกว่า เนื่องจาก Agile Manifesto สนับสนุนซอฟต์แวร์ที่ใช้งานได้ดีกว่าการจัดทำเอกสารอย่างละเอียด ทีม Agile ควรมีความสมดุลในอุดมคติระหว่างเอกสารและบทสนทนา แม้ว่าเอกสารอย่างละเอียดจะไม่สามารถรับประกันความสำเร็จของโครงการได้ด้วยตัวเอง
- ผลลัพธ์สุดท้ายอาจแตกต่างกันอย่างมาก: อาจไม่มีกลยุทธ์ที่ชัดเจนสำหรับโครงการ Agile เริ่มต้น ดังนั้นผลลัพธ์ที่ได้อาจเปลี่ยนแปลงไปอย่างมากจากที่คาดการณ์ไว้ในตอนแรก ผลลัพธ์สุดท้ายที่แตกต่างกันอย่างมากอาจเป็นผลมาจากการเพิ่มการวนซ้ำใหม่โดยพิจารณาจากการเปลี่ยนแปลงอินพุตของไคลเอ็นต์ เนื่องจาก Agile สามารถปรับเปลี่ยนได้มาก
- ความมุ่งมั่นด้านเวลาของนักพัฒนา: ทีมพัฒนาต้องทุ่มเทอย่างเต็มที่กับโครงการเพื่อให้คล่องตัวมีประสิทธิภาพ วิธีการแบบ Agile ซึ่งใช้เวลานานกว่าวิธีการทั่วไปนั้นต้องการการมีส่วนร่วมและความร่วมมืออย่างต่อเนื่อง นอกจากนี้ยังหมายความว่านักพัฒนาต้องกระทำตามความยาวของโครงการทั้งหมด
น้ำตกคืออะไร?
วงจรชีวิตการพัฒนาระบบ (SDLC) ที่ได้รับความนิยมมากที่สุดสำหรับวิศวกรรมซอฟต์แวร์และโครงการไอทีเรียกว่า "แนวทางของน้ำตก" ซึ่งเป็นไปตามขั้นตอนเชิงเส้นที่ต่อเนื่องกัน
แผนภูมิแกนต์ ซึ่งเป็นรูปแบบของแผนภูมิแท่งที่แสดงวันที่เริ่มต้นและสิ้นสุดของแต่ละงาน ใช้ในการวางแผนเป็นครั้งคราว
ทีมพัฒนาจะก้าวไปสู่ระดับต่อไปหลังจากเสร็จสิ้นหนึ่งในแปดขั้นตอน ทีมไม่สามารถกลับไปยังขั้นตอนก่อนหน้าโดยไม่ต้องเริ่มต้นขั้นตอนทั้งหมดใหม่
นอกจากนี้ ลูกค้าอาจต้องประเมินและยอมรับข้อกำหนดก่อนที่ทีมจะสามารถไปยังระดับถัดไปได้
แบบจำลองน้ำตกได้รับการพัฒนาในสภาพแวดล้อมที่มีการจัดระเบียบอย่างดีของภาคการผลิตและการก่อสร้าง ซึ่งการปรับเปลี่ยนอาจมีราคาแพงมากหรือเป็นไปไม่ได้เลย
เทคนิคน้ำตกมีชื่อมากเพราะตั้งใจให้ไหลไปในทิศทางเดียว—ลง—เหมือนน้ำตก ขั้นตอนต่างๆ ได้แก่ การวิเคราะห์ การเริ่มต้น การทดสอบ การออกแบบ การสร้าง การใช้งาน การบำรุงรักษา และการทดสอบ
เทคนิคน้ำตกมีข้อดีหลายประการ เช่นเดียวกับกลยุทธ์อื่นๆ หนึ่งคือขั้นตอนของการวางแผนและออกแบบโครงการมีความชัดเจนมากขึ้น
ลูกค้าและทีมพัฒนามีความสอดคล้องกันมากขึ้นเมื่อพูดถึงผลงานของโครงการในขณะที่ใช้การพัฒนาซอฟต์แวร์ Waterfall เนื่องจากคุณทราบขอบเขตของโครงการตั้งแต่เริ่มต้น การพัฒนาน้ำตกจึงทำให้ง่ายต่อการติดตามความคืบหน้า
กระบวนการวอเตอร์ฟอลใช้ผู้เชี่ยวชาญ นักพัฒนา นักวิเคราะห์ และผู้ทดสอบเพื่อมุ่งความสนใจไปที่งานของตนในโครงการ แทนที่จะให้ทั้งทีมเน้นขั้นตอนเดียว
ขั้นตอนของน้ำตก
หกขั้นตอนของน้ำตกจะต้องเกิดขึ้นทีละขั้น:
- ข้อกำหนดในการรวบรวมและจัดเก็บ: คุณควรรวบรวมความรู้อย่างละเอียดเกี่ยวกับสิ่งที่โครงการนี้ต้องการในเวลานี้ มีเทคนิคหลายอย่างในการรวบรวมข้อมูลนี้ รวมถึงการสัมภาษณ์ การสำรวจ และการระดมความคิดร่วมกัน ความต้องการของโครงการควรชัดเจนเมื่อสิ้นสุดระยะนี้ และทีมของคุณควรได้รับสำเนาเอกสารข้อกำหนดแล้ว
- การออกแบบระบบ: ระบบได้รับการออกแบบโดยทีมงานของคุณโดยใช้ข้อกำหนดที่กำหนดไว้ล่วงหน้า ในระหว่างขั้นตอนนี้ จะไม่มีการเข้ารหัสใดเสร็จสิ้น แต่ทีมงานได้กำหนดข้อกำหนดสำหรับฮาร์ดแวร์หรือภาษาการเขียนโปรแกรม
- การดำเนินงาน: ขั้นตอนนี้เกี่ยวข้องกับการเข้ารหัส โปรแกรมเมอร์ใช้ข้อมูลของขั้นตอนก่อนหน้าเพื่อสร้างผลิตภัณฑ์ที่ใช้งานได้ โค้ดมักใช้เป็นส่วนย่อยๆ ที่รวมกันในช่วงท้ายของเฟสหนึ่งหรือตอนเริ่มต้นของอีกเฟสหนึ่ง
- การทดสอบ: ผลิตภัณฑ์สามารถเริ่มทดสอบได้หลังจากรหัสเสร็จสมบูรณ์ ปัญหาใด ๆ จะพบและรายงานโดยผู้ทดสอบอย่างพิถีพิถัน โปรเจ็กต์ของคุณอาจต้องกลับไปที่เฟสแรกเพื่อประเมินใหม่ หากมีปัญหาสำคัญปรากฏขึ้น
- จัดส่ง/ปรับใช้: ผลิตภัณฑ์เสร็จสิ้น ณ จุดนี้ และทีมของคุณจะส่งสิ่งที่ส่งมอบสำหรับการปรับใช้หรือเผยแพร่
- ซ่อมบำรุง: ลูกค้าได้รับสินค้าแล้วและกำลังใช้งานอยู่ ทีมของคุณอาจต้องพัฒนาโปรแกรมแก้ไขและอัปเดตเมื่อปัญหาปรากฏขึ้นเพื่อแก้ไข อีกครั้ง ปัญหาสำคัญสามารถเรียกร้องให้กลับสู่ขั้นตอนที่หนึ่ง
ข้อดี
- ใช้งานง่ายและจัดการ: แนวทาง Waterfall นั้นใช้และเข้าใจได้ง่าย เนื่องจากแต่ละโครงการได้รับการจัดการในลักษณะที่ต่อเนื่องกัน ก่อนเริ่มโครงการ Waterfall ทีมงานไม่จำเป็นต้องมีความเชี่ยวชาญหรือการฝึกอบรมมาก่อน ทางเข้าน้ำตกนั้นเข้มงวดมาก แต่ละขั้นตอนมีชุดของการส่งมอบและการทบทวน ทำให้ง่ายต่อการดูแลและบำรุงรักษา
- จำเป็นต้องมีระเบียบวิธีที่ได้รับการจัดทำเป็นเอกสารไว้อย่างดี: เอกสารที่จำเป็นสำหรับวิธีน้ำตกช่วยชี้แจงเหตุผลเบื้องหลังการทดสอบและโค้ด นอกจากนี้ยังสร้างเส้นทางกระดาษในกรณีที่ผู้มีส่วนได้ส่วนเสียต้องการข้อมูลเพิ่มเติมในบางช่วงหรือสำหรับการริเริ่มในอนาคต
- การบังคับใช้วินัย: ทุกขั้นตอนในโครงการ Waterfall มีจุดเริ่มต้นและจุดสิ้นสุด ทำให้ง่ายต่อการสื่อสารความคืบหน้าไปยังผู้มีส่วนได้ส่วนเสียและลูกค้า ทีมงานสามารถลดความเป็นไปได้ที่จะพลาดกำหนดเวลาโดยใส่ข้อกำหนดและการออกแบบก่อนการผลิตโค้ด
ข้อเสีย
- การรวบรวมความต้องการที่แม่นยำอาจเป็นเรื่องยาก: การพูดกับผู้บริโภคและผู้มีส่วนได้ส่วนเสียเพื่อกำหนดความต้องการของพวกเขาเป็นหนึ่งในขั้นตอนเริ่มต้นของโครงการ Waterfall ในช่วงเริ่มต้นของโครงการนี้ อาจเป็นการท้าทายในการค้นหาข้อกำหนดเฉพาะของพวกเขา ลูกค้ามักเรียนรู้เกี่ยวกับความต้องการของตนในขณะที่โครงการพัฒนาขึ้น แทนที่จะแสดงออกมาล่วงหน้า
- การเปลี่ยนแปลงเป็นเรื่องยากที่จะรองรับ: ลูกเรือไม่สามารถทำงานต่อได้หลังจากเสร็จสิ้นขั้นตอน เป็นการยากและมีราคาแพงมากที่จะกลับไปซ่อมแซมหากพวกเขาเรียนรู้ในระหว่างขั้นตอนการทดสอบว่าฟังก์ชันขาดหายไปในระหว่างกระบวนการข้อกำหนด
- ซอฟต์แวร์มีให้หลังจากวันครบกำหนด: สองถึงสี่ขั้นตอนของโครงการต้องเสร็จสิ้นก่อนที่จะเริ่มการเข้ารหัสจริง ผู้มีส่วนได้ส่วนเสียจะไม่เห็นซอฟต์แวร์ที่ใช้งานได้จนกว่าจะสิ้นสุดวงจรชีวิต
Scrum คืออะไร?
เฟรมเวิร์กกระบวนการที่ได้รับความนิยมมากที่สุดสำหรับการนำ Agile ไปปฏิบัติคือ Scrum ซึ่งเป็นชุดย่อยของ Agile
เป็นกระบวนทัศน์แบบวนซ้ำสำหรับการจัดการการสร้างซอฟต์แวร์และผลิตภัณฑ์ที่ซับซ้อน Sprints ซึ่งเป็นการวนซ้ำแบบความยาวคงที่ซึ่งใช้เวลาหนึ่งถึงสองสัปดาห์ ทำให้ทีมสามารถเผยแพร่ซอฟต์แวร์ตามกำหนดเวลาปกติ
ผู้มีส่วนได้ส่วนเสียและสมาชิกในทีมรวมตัวกันเพื่อหารือเกี่ยวกับขั้นตอนต่อไปหลังจากการวิ่งแต่ละครั้ง บทบาท ความรับผิดชอบ และการประชุมใน Scrum ยังคงไม่เปลี่ยนแปลง
ตัวอย่างเช่น Scrum ระบุการวางแผนการวิ่ง การยืนขึ้นรายวัน การสาธิตการวิ่ง และการย้อนรอยการวิ่งเป็นพิธีกรรมทั้งสี่ที่ให้โครงสร้างการวิ่งแต่ละครั้ง
ทีมจะใช้สิ่งประดิษฐ์ที่มองเห็นได้ เช่น กระดานงานหรือแผนภูมิการเบิร์นดาวน์ระหว่างการวิ่งแต่ละครั้งเพื่อแสดงความคืบหน้าและรับข้อเสนอแนะที่เพิ่มขึ้น
ในการต่อสู้ ทีมงานและเจ้าของผลิตภัณฑ์ทำงานร่วมกันอย่างใกล้ชิดเพื่อระบุและจัดลำดับความสำคัญการทำงานของระบบ พวกเขาบรรลุสิ่งนี้โดยการสร้างงานในมือซึ่งมีงานทั้งหมดที่จำเป็นในการผลิตซอฟต์แวร์ที่ทำงานตามที่ตั้งใจไว้
โปรแกรมแก้ไขข้อบกพร่อง ข้อกำหนดที่ไม่สามารถใช้งานได้ และคุณลักษณะทั้งหมดควรรวมอยู่ในคิว ทีมข้ามสายงานต้องประมาณการและลงทะเบียนเพื่อส่งมอบซอฟต์แวร์ที่เพิ่มขึ้นตลอด Sprints ที่ต่อเนื่องกัน ซึ่งโดยทั่วไปจะใช้เวลา 30 วัน เมื่อมีการกำหนดวัตถุประสงค์แล้ว
เฉพาะทีมเท่านั้นที่สามารถเพิ่มฟังก์ชันการทำงานให้กับ Sprint หลังจากส่งงานในมือสำหรับ Sprint นั้น
การส่งมอบ Sprint ถัดไป จะมีการประเมิน Backlog ของผลิตภัณฑ์ และหากจำเป็น ให้จัดลำดับความสำคัญ และเลือกชุดที่ส่งมอบต่อไปนี้ให้เป็นส่วนหนึ่งของ Sprint ต่อไปนี้
กระบวนการต่อสู้
- สินค้าที่ขายแล้ว: ในการสั่งซื้อสินค้าใน backlog ของผลิตภัณฑ์ Product Owner และ Scrum Team จะพบ (งานเกี่ยวกับ backlog ของผลิตภัณฑ์มาจากเรื่องราวของผู้ใช้และข้อกำหนด) งานในมือคือรายการคุณลักษณะทั้งหมดที่ต้องการสำหรับผลิตภัณฑ์ แทนที่จะเป็นรายการงานที่ต้องทำให้เสร็จ จากนั้นทีมพัฒนาจะเลือกงานจากงานในมือเพื่อดำเนินการตลอดแต่ละการวิ่ง
- การวางแผน Sprint: ก่อนการวิ่งแต่ละครั้ง Product Owner จะจัดส่งรายการอันดับต้นๆ ใน Backlog ให้กับทีมในการประชุมวางแผนการวิ่ง จากนั้นกลุ่มจะเลือกรายการจาก Backlog ของผลิตภัณฑ์ที่สามารถดำเนินการให้เสร็จสิ้นระหว่างการวิ่งและย้ายไปยัง Backlog ของ Sprint (ซึ่งเป็นรายการงานที่ต้องทำให้เสร็จใน Sprint)
- การปรับแต่ง/ดูแลงานในมือ: เพื่อให้แน่ใจว่ามีการเตรียมงานในมือสำหรับการวิ่งครั้งต่อไป ทีมงานและเจ้าของผลิตภัณฑ์จะพบกันที่จุดสิ้นสุดของการวิ่งครั้งเดียว ทีมงานสามารถละทิ้งเรื่องราวของผู้ใช้ที่ไม่เกี่ยวข้องแล้ว เพิ่มเรื่องราวใหม่ แก้ไขลำดับที่ควรแก้ไข หรือแบ่งเรื่องราวของผู้ใช้ออกเป็นงานย่อยๆ ในระหว่างการประชุม "การดูแล" นี้ จะทำให้แน่ใจว่างานในมือประกอบด้วยสิ่งที่เกี่ยวข้อง เจาะลึก และสอดคล้องกับเป้าหมายของโครงการเท่านั้น
- ประชุม Scrum ทุกวัน: ในการประชุมแบบสแตนด์อัพ 15 นาทีที่เรียกว่า Daily Scrum สมาชิกในทีมแต่ละคนจะอภิปรายถึงวัตถุประสงค์และปัญหาที่เกิดขึ้น ทุกวันตลอดการวิ่ง ทีมงานจะเข้าร่วม Daily Scrum ซึ่งช่วยให้ทุกคนมีภารกิจ
- ประชุมประเมินผลการวิ่งt: ทีมนำเสนองานของพวกเขาในการประชุมทบทวนการวิ่งเมื่อสิ้นสุดการวิ่งแต่ละครั้ง แทนที่จะเป็นรายงานหรืองานนำเสนอ PowerPoint การประชุมนี้ควรมีการสาธิตจริง
- การประชุมวิ่งย้อนหลัง: ทีมงานจะอภิปรายถึงการปรับเปลี่ยนใดๆ ที่ต้องทำใน sprint ต่อไปนี้ รวมทั้งว่า Scrum ทำงานได้ดีเพียงใดในตอนจบของแต่ละ sprint ทีมงานสามารถหารือเกี่ยวกับแง่บวก แง่ลบ และพื้นที่สำหรับการปรับปรุงของ Sprint
ข้อดี
- ความรับผิดชอบเพิ่มเติมจากทีมงาน: ไม่มีผู้จัดการโครงการที่สอนทีม scrum ว่าต้องทำอะไรและเมื่อไหร่ งานที่สามารถทำได้ในแต่ละ sprint จะถูกตัดสินโดยทีมโดยรวม พวกเขาทั้งหมดให้ความร่วมมือและเอื้อเฟื้อซึ่งกันและกัน ส่งเสริมการทำงานเป็นทีมและส่งเสริมความเป็นตัวของตัวเองในสมาชิกในทีมแต่ละคน
- ปรับปรุงการมองเห็นโครงการและความโปร่งใส: มีความเข้าใจผิดและความไม่แน่นอนน้อยลงเนื่องจากทุกคนในทีมตระหนักถึงความรับผิดชอบของตนเนื่องจากมีการประชุมยืนขึ้นบ่อยครั้ง ทีมสามารถจัดการกับปัญหาก่อนที่จะควบคุมไม่ได้ เนื่องจากปัญหาจะถูกตรวจพบล่วงหน้า
- ลดต้นทุนที่เพิ่มขึ้น: การสื่อสารอย่างต่อเนื่องช่วยให้ทีมทราบถึงปัญหาหรือการเปลี่ยนแปลงใด ๆ ทันทีที่เกิดขึ้น ซึ่งช่วยประหยัดค่าใช้จ่ายและปรับปรุงคุณภาพ ฟีเจอร์ก้อนเล็กลงให้ข้อเสนอแนะอย่างต่อเนื่องและอนุญาตให้แก้ไขข้อผิดพลาดก่อนกำหนด ก่อนที่ข้อผิดพลาดขนาดใหญ่จะแพงเกินไปที่จะแก้ไข
- ง่ายต่อการปรับให้เข้ากับการเปลี่ยนแปลง: ง่ายกว่าในการจัดการและปรับให้เข้ากับการเปลี่ยนแปลงเมื่อมีลูปป้อนกลับบ่อยครั้งและการวิ่งระยะสั้น ตามภาพประกอบ หากทีมพบเรื่องราวของผู้ใช้ใหม่ล่าสุดระหว่างการวิ่งครั้งเดียว พวกเขาจะสามารถเพิ่มคุณสมบัตินั้นไปยัง Sprint ต่อไปนี้ในการประชุมปรับแต่งงานค้างได้อย่างรวดเร็ว
ข้อเสีย
- ขอบเขตการคืบคลานอันตราย: เนื่องจากไม่มีวันที่กำหนดเสร็จ โปรเจ็กต์ Scrum บางโปรเจ็กต์อาจเผชิญกับการคืบคลานขอบเขต ผู้มีส่วนได้ส่วนเสียอาจถูกล่อลวงให้เรียกร้องคุณสมบัติเพิ่มเติมต่อไปหากไม่มีกำหนดเส้นตายในการทำให้เสร็จ
- Scrum Master ที่ไม่ดีอาจทำให้ทุกอย่างพังได้: ผู้จัดการโครงการไม่เหมือนกับ scrum master Scrum Master ต้องไว้วางใจทีมที่พวกเขากำลังดูแลและไม่เคยให้คำแนะนำแก่พวกเขา Scrum Master ไม่มีอำนาจเหนือทีม โปรเจ็กต์จะล้มเหลวหาก scrum master พยายามจัดการทีม
- ปัญหาความแม่นยำอาจเป็นผลมาจากงานที่ระบุไม่ดี: หากไม่มีการระบุงานอย่างชัดเจน ค่าใช้จ่ายและกำหนดการของโครงการจะไม่ถูกต้อง การวางแผนกลายเป็นเรื่องท้าทายและการวิ่งอาจใช้เวลานานกว่าที่คาดการณ์ไว้หากไม่มีการกำหนดเป้าหมายเริ่มต้น
- ประสบการณ์และความทุ่มเทเป็นสิ่งจำเป็นสำหรับทีม: เพื่อให้ทีมประสบความสำเร็จ ต้องกำหนดบทบาทและหน้าที่ให้ชัดเจน ทีม Scrum ต้องการสมาชิกในทีมที่มีทักษะทางเทคนิคเนื่องจากไม่มีบทบาทที่กำหนดไว้อย่างชัดเจน (ทุกคนทำทุกอย่าง) ทีมยังต้องมุ่งมั่นที่จะเข้าร่วมในเซสชั่น Scrum รายวันและอยู่ด้วยกันตลอดชีวิตของโครงการ
เปรียว Vs Scrum
แม้ว่า Agile และ Scrum จะใช้วิธีการเดียวกัน แต่ก็มีความแตกต่างกันระหว่างทั้งสอง แถลงการณ์ Agile จะสรุปชุดหลักการสำหรับการสร้างซอฟต์แวร์ผ่านการพัฒนาซ้ำๆ
ในทางกลับกัน Scrum เป็นชุดแนวทางที่ต้องปฏิบัติตามในขณะที่ทำการพัฒนาซอฟต์แวร์ Agile Agile เป็นแนวคิด ในขณะที่ Scrum เป็นเทคนิคในการนำไปปฏิบัติ
Scrum เป็นวิธีการนำ Agile มาใช้งาน ดังนั้นทั้งสองจึงมีสิ่งที่เหมือนกันหลายอย่าง ทั้งสองวิธีเป็นแบบวนซ้ำ จัดลำดับความสำคัญของการส่งมอบซอฟต์แวร์ตั้งแต่เนิ่นๆ และบ่อยครั้ง และยอมรับการเปลี่ยนแปลง พวกเขายังสนับสนุนการเปิดกว้างและการพัฒนาอย่างต่อเนื่อง
Agile Vs น้ำตก
แข็งและยืดหยุ่นอธิบายความแตกต่างระหว่างกระบวนการ Waterfall และ Agile ได้ดีที่สุด ในขณะที่ Agile นั้นลื่นไหลและเปลี่ยนแปลงอยู่ตลอดเวลา Waterfall นั้นเป็นวิธีการที่เข้มงวดกว่าและเข้มงวดกว่ามาก
ความแตกต่างเพิ่มเติมระหว่างพวกเขามีดังนี้:
- Agile ไม่ต้องการแนวทางเชิงเส้นในขณะที่ Waterfall เป็นแบบต่อเนื่อง
- แม้ว่าความต้องการมักจะถูกกำหนดไว้ล่วงหน้าในโปรเจ็กต์ Waterfall แต่คาดว่าความต้องการจะเปลี่ยนแปลงและปรับตัวในการริเริ่มแบบ Agile
- ตรงกันข้ามกับ Agile โปรเจ็กต์ Waterfall ไม่อนุญาตให้ทำการปรับเปลี่ยนกับงานที่เสร็จสมบูรณ์ในขั้นตอนก่อนหน้า
- น้ำตกเป็นขั้นตอนที่เป็นระเบียบซึ่งคุณต้องทำแต่ละขั้นให้เสร็จก่อนที่จะไปต่อในขั้นต่อไป อย่างไรก็ตาม Agile เป็นวิธีการที่ยืดหยุ่นซึ่งช่วยให้คุณดำเนินการโครงการได้ตามต้องการ
Agile Vs Waterfall Vs Scrum
- น้ำตกจะเพิ่มความไว้วางใจในสิ่งที่จะได้รับในไม่ช้าหลังจากที่มีการวางแผน Agile อาศัยแนวทางปฏิบัติที่ดีที่สุดของสภาพแวดล้อมการพัฒนา ที่นี่ ความเสี่ยงของโครงการจำนวนหนึ่งสามารถจัดการได้ดีเนื่องจากมีการประเมินผลลัพธ์อย่างต่อเนื่อง
- วอเตอร์ฟอลไม่ได้คาดว่าทีมงานและโครงการจะอยู่ในสถานที่เดียวกัน ในขณะที่ Scrum และ Agile ต้องการ co-location ของพนักงาน
- Agile มุ่งเน้นไปที่การลดการทำงานซ้ำของโปรเจ็กต์และสนับสนุนการเปลี่ยนแปลงที่จะรวมไว้ก่อนหน้านี้มาก ตรงกันข้ามกับน้ำตกซึ่งตอบสนองต่างกัน Scrum ยังช่วยให้ค้นพบการเปลี่ยนแปลงได้ตั้งแต่เนิ่นๆ
- พิมพ์เขียวที่กะทัดรัดยิ่งขึ้นสำหรับผลิตภัณฑ์ขั้นสุดท้ายมีให้โดยความคล่องตัวและการต่อสู้ สิ่งนี้สร้างปัญหากับคำสัญญาที่ทำกับผู้ซื้อ ในทางตรงกันข้าม กราฟิกแบบน้ำตกช่วยให้ลูกค้าและนักพัฒนาประทับใจกับผลงานที่เสร็จแล้วได้ดียิ่งขึ้น
- แต่ละเทคนิคเหล่านี้มีชุดเครื่องมือสำหรับการจัดระเบียบและจำลองงานที่เกี่ยวข้องกับการสร้าง
สรุป
หากคุณได้ปฏิบัติตามและมั่นใจในความรู้ของคุณเกี่ยวกับความแตกต่างระหว่างกระบวนการ Waterfall, Agile และ Scrum คุณควรทราบแล้วว่ากลยุทธ์ใดจะได้ผลดีที่สุดสำหรับคุณและทีมของคุณ
เทคนิค Waterfall ซึ่งใช้สำหรับโครงการที่มีขอบเขต ระยะเวลา และงบประมาณที่แน่นอน อาจเป็นทางเลือกที่ดีที่สุดของคุณ หากคุณชอบกฎและขั้นตอนที่เข้มงวด และพบว่าสิ่งเหล่านี้นำมาซึ่งความชัดเจน
ในทางกลับกัน หากอิสระและความสามารถในการปรับตัวของ Agile สร้างแรงบันดาลใจให้กับคุณ มันก็อาจเป็นจุดที่คุณควรให้ความสนใจ
Scrum เป็นวิธีที่จะไป หากคุณต้องการวินัยเล็กน้อยภายในกรอบการทำงานที่ยืดหยุ่น
อย่างไรก็ตาม คุณต้องพิจารณาแนวทางเหล่านี้ในแง่ของโครงการที่คุณกำลังดำเนินการอยู่และผลลัพธ์สุดท้ายของคุณ
เขียนความเห็น