รู้เบื้องต้นเกี่ยวกับการต่อสู้

ประวัติการต่อสู้

ตั้งแต่การเผยแพร่รายงาน "การจัดการการพัฒนาระบบซอฟต์แวร์ขนาดใหญ่" ของ Winston Royce ในปี 1970 หลายคนพยายามหาวิธีการที่สามารถขจัดข้อเสียของรูปแบบการพัฒนา Waterfall ได้ อีกทางเลือกหนึ่งนอกเหนือจาก "น้ำตก" คือวิธี Scrum ซึ่งจะกล่าวถึงในตอนนี้

Scrum มีชื่อในปี 1986 จากงานของ Takeuchi และ Nonaki เรื่อง The New Rules for New Product Development เอกสารนี้ระบุว่าวิธีที่มีประสิทธิภาพที่สุดในการบรรลุเป้าหมายคือการให้แผนปฏิบัติการที่ชัดเจนแก่นักพัฒนา

ในปี 1995 คู่มือฉบับอื่น "การพัฒนาซอฟต์แวร์ด้วย Scrum" โดย Sutherland และ Schweiber ได้ปรากฏขึ้น สิ่งพิมพ์นี้ได้รับการปรับปรุงหลายครั้ง ตอนนี้ถือเป็นแนวทางหลักในการพัฒนาวิธีนี้ Scrum Guide เวอร์ชันปัจจุบันประกอบด้วยข้อมูลที่อัปเดตในปี 2020

บทบัญญัติหลักของ Scrum Guide แนะนำว่าเทมเพลตการจัดการโครงการควรขึ้นอยู่กับข้อเท็จจริงที่ว่านักพัฒนาส่งมอบผลิตภัณฑ์สำเร็จรูปภายในกรอบเวลาที่ตกลงกัน - เร่งความเร็ว สำหรับการใช้งาน Scrum ให้ประสบความสำเร็จ ขอแนะนำให้ใช้โครงสร้างที่ประกอบด้วยองค์ประกอบหลายอย่าง: บทบาท เหตุการณ์ กฎ และสิ่งประดิษฐ์

บทบาทในการต่อสู้

มีสามบทบาทใน Scrum ซึ่งทั้งหมดเป็นทีม Scrum:

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

นักพัฒนาได้รับความไว้วางใจในการดำเนินงานด้านเทคนิคซึ่งการทำงานข้ามสายงานนั้นขึ้นอยู่กับขอบเขตของแอปพลิเคชัน นักพัฒนายุ่งอยู่กับการสร้าง Sprint Backlog, เขียนโค้ด, ปรับแต่งโครงการตามเป้าหมาย Sprint และงานอื่นๆ

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

เหตุการณ์ในการต่อสู้

เหตุการณ์การต่อสู้มี 5 ประเภท:

Sprint เป็นส่วนสำคัญที่สุดของ Scrum ซึ่งรวมถึงการวางแผนสปรินต์ การสแตนด์อัพรายวัน (การต่อสู้รายวัน) การทบทวนและการย้อนหลังของสปรินต์

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

Daily Scrum เป็นกิจกรรมการต่อสู้สั้นๆ รายวัน ไม่เกิน 15 นาที โดยปกติจะทำเพื่อวางแผนการทำงานของตัวเข้ารหัสสำหรับวันนี้หรือพรุ่งนี้ ที่ Daily Scrum คุณสามารถพูดคุยประเด็นปัจจุบันได้ นักพัฒนาซอฟต์แวร์ทั้งหมดที่เกี่ยวข้องกับโครงการจะต้องเข้าร่วมในการประชุมเชิงปฏิบัติการดังกล่าว อนุญาตให้มี Scrum Master ได้ แต่ไม่จำเป็น

Sprint Review (Demo) - แสดงผลที่สร้างขึ้นระหว่างการวิ่ง โดยปกติเหตุการณ์นี้จะเกิดขึ้นในขั้นตอนสุดท้าย ผู้สนใจทุกท่านมีส่วนร่วม

Sprint Retrospective - การอภิปรายผลของการวิ่ง สมาชิกในทีมแบ่งปันความคิดเห็นเกี่ยวกับวิธีที่พวกเขารับมือกับงานที่ได้รับมอบหมายและวิธีปรับปรุงผลงานในอนาคต

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

สิ่งประดิษฐ์

สิ่งประดิษฐ์การต่อสู้เป็นงานที่เกิดขึ้นในตอนท้ายของโครงการหรือการวิ่ง มีสามส่วน - งานค้างของผลิตภัณฑ์ งานค้าง sprint และส่วนเพิ่ม แต่ละคนมีความจำเป็นสำหรับการส่งมอบซอฟต์แวร์ให้กับผู้ใช้อย่างทันท่วงที นอกจากนี้ยังมีสิ่งประดิษฐ์เสริม (แผนภูมิเบิร์นดาวน์และอื่น ๆ )

ส่วนประกอบที่รวมอยู่ในสิ่งประดิษฐ์วิ่ง:

งานค้างของผลิตภัณฑ์ - อินเทอร์เฟซและคุณสมบัติแบ็กเอนด์

sprint backlog คือรายการงานที่ต้องทำระหว่างการวนซ้ำ พวกเขาตกลงกันก่อนเริ่มวิ่ง

การเพิ่ม - จำนวนรายการซอฟต์แวร์ที่ค้างทั้งหมดที่สร้างขึ้นระหว่างการวิ่งและมูลค่าของการเพิ่มที่ทำขึ้นก่อนหน้า จะต้องแสดงส่วนเพิ่มใหม่ที่ทำเสร็จก่อนสิ้นสุดการวิ่ง ซึ่งหมายความว่าคุณมีเวอร์ชันการทำงานที่ตรงตามข้อกำหนดของทีมการต่อสู้

รายการค้างของผลิตภัณฑ์ - จะต้องดำเนินการให้เสร็จสิ้นระหว่างการวนซ้ำ ตามกฎแล้ว องค์ประกอบจะถูกแบ่งออกเป็นงานเล็กๆ หลายงาน

เป้าหมายการวิ่งคืองานที่ต้องทำให้เสร็จ (สร้างรายการงานค้างหรืองานอื่นๆ)

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

Product Release/Product Burn-Down Chart เป็นแผนภูมิที่วาดโดย Scrum Master ก่อนสิ้นสุดการวิ่งครั้งต่อไป แกนนอนคือ sprints แกนตั้งคือปริมาณงานที่เหลืออยู่

กฎกรอบการต่อสู้

บทบาท เหตุการณ์ และสิ่งประดิษฐ์เป็นพื้นฐานของ Scrum แต่ยังมีกฎอื่นๆ นอกเหนือจากนี้ ล้วนช่วยเพิ่มประสิทธิภาพกระบวนการทำงาน นี่คือรายการของกฎเหล่านี้:

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

ข้อจำกัดในการต่อสู้

นอกจากข้อดีที่ชัดเจนแล้ว Scrum ยังมีข้อเสีย:

• การต่อสู้กันมักจะทำให้ปริมาณงานที่ทำลดลงเนื่องจากไม่มีกำหนดเส้นตายร่วมกัน
• ด้วยการมีส่วนร่วมน้อยหรือไม่เต็มใจที่จะให้ความร่วมมือระหว่างผู้เข้าร่วมโครงการ มีโอกาสมากที่จะล้มเหลวในผลลัพธ์
• โครงสร้าง Scrum ใช้งานยากในทีมขนาดใหญ่ แต่ก็ยังเป็นไปได้ มีเฟรมเวิร์กการปรับขนาดสำหรับสิ่งนี้: LeSS, SAFe, Nexus และอื่นๆ
• การจากไปของสมาชิกหนึ่งคนหรือมากกว่าจากทีมในช่วงกลางของโครงการไม่ส่งผลกระทบต่อโครงการมากนัก