กระบวนการใน Scrum

การวางแผนการวิ่ง

การวางแผน Sprint เป็นขั้นตอนเริ่มต้นในการวิ่งแบบ Scrum กำหนดขอบเขตและวิธีการทำงานระหว่างการวิ่ง ทีม Scrum ทั้งหมดมีส่วนร่วมในการวางแผน

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

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

หากมีการวางแผนการวิ่งไม่ดี สิ่งนี้อาจทำให้ทีมล้มเหลวได้ นักพัฒนาจะไม่สามารถรับมือกับความคาดหวังที่วางไว้ได้ เนื่องจากงานกลายเป็นสิ่งที่ไม่สมจริง

คำถามที่ต้องพิจารณาเมื่อวางแผนการวิ่ง:

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

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

การประเมินผลงาน

การประเมินความซับซ้อนของงานไม่จำเป็นต้องหักโหม กระบวนการวางแผนไม่จำเป็นต้องแม่นยำ แต่อย่างน้อยการประเมินความซับซ้อนของการพัฒนาโดยประมาณ ทีมไม่เพียงต้องเข้าใจเป้าหมายของการวิ่งเท่านั้น แต่ยังต้องเปรียบเทียบเป้าหมายกับความสามารถของทีมด้วย

เพื่อประเมินความซับซ้อน คุณสามารถใช้ขนาดเสื้อผ้าปกติสำหรับทุกคน (L, XL, XXL) แน่นอนว่าสิ่งนี้ไม่ได้รับประกันความถูกต้อง แต่ก็ยัง

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

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

ประเมินความยากเป็นคะแนน คะแนน และชั่วโมง

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

คะแนนจะมอบให้ตามความซับซ้อนและปริมาณงาน นอกจากนี้ยังคำนึงถึงความเสี่ยงที่อาจเกิดขึ้นด้วย การให้คะแนนด้วยวิธีนี้ช่วยให้สามารถแบ่งงานออกเป็นขั้นตอนย่อย ๆ ได้อย่างมีประสิทธิภาพ

ด้วยการใช้วิธีการให้คะแนน (คะแนน) อย่างสม่ำเสมอในการวางแผน ทีมจะมีความเข้าใจที่ดีขึ้นและแม่นยำยิ่งขึ้นว่าพวกเขาต้องใช้เวลาเท่าใดในการทำงานให้เสร็จ นอกจากนี้ยังมีข้อดีอื่นๆอีกด้วย

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

ข้อเสียของการประมาณค่าความซับซ้อนคือมักใช้ผิด เช่นไม่สามารถใช้วิธีนี้ในการประเมินพนักงานได้

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

การประชุมการต่อสู้รายวัน

การประชุมเชิงปฏิบัติการมีความสำคัญ: สมาชิกในทีมจะแบ่งปันความคิดเห็น สื่อสาร และตกลงร่วมกันในการดำเนินการต่อไป จำเป็นต้องมีการประชุมการต่อสู้รายวันเพื่อยกระดับจิตวิญญาณของทีมและประกาศข่าวปัจจุบัน

Stand-up คือการประชุมสั้นๆ ของผู้เข้าร่วมโครงการหลัก ได้แก่ เจ้าของซอฟต์แวร์ โปรแกรมเมอร์ และปรมาจารย์ด้านการต่อสู้ โครงสร้างของการยืนขึ้นประกอบด้วยคำถามสามข้อ

• เมื่อวานเราทำอะไรได้บ้าง?
• วันนี้เราทำงานอะไร
• อะไรขัดขวางเราจากการบรรลุผล?

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

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

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

ก่อนอื่นคุณต้องเลือกเวลาที่เหมาะกับทุกคน โดยปกติแล้วการสแตนด์อัพสำหรับทีมจากสำนักงานเดียวกันจะจัดขึ้นในช่วงเริ่มต้นของวันทำการ - ระหว่าง 9 ถึง 10 โมงเช้า ทำให้คุณมีเวลาวางแผนตารางเวลาในแต่ละวันได้ดียิ่งขึ้น หากสมาชิกในทีมทำงานในภูมิภาคต่างๆ เวลาจะถูกเลือกให้เหมาะกับทุกคน ตัวอย่างเช่น หากสมาชิกในทีมบางคนอาศัยอยู่ในแคลิฟอร์เนียและซิดนีย์ สแตนด์อัพจะเริ่มในเวลา 15:30 น. ตามเวลาแคลิฟอร์เนีย แน่นอนว่าการยืนขึ้นหลังอาหารเย็นไม่สะดวกสำหรับทุกคน แต่ทำให้สามารถติดต่อกับเพื่อนร่วมงานที่อยู่อีกฝั่งของมหาสมุทรได้

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

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

รีวิวการวิ่ง

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

การตรวจสอบผลลัพธ์ของ Sprint มีองค์ประกอบดังต่อไปนี้:

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

ผลลัพธ์คืองานในมือที่อัปเดตพร้อมเป้าหมายใหม่สำหรับการวิ่งครั้งต่อไป งานค้างสามารถเปลี่ยนแปลงได้หากสถานการณ์ต้องการ

Sprint ย้อนหลัง

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

เป้าหมายหลักของ Sprint Retrospective ได้แก่:

• การวิเคราะห์ Sprint (ผลงานของผู้เข้าร่วม ผลลัพธ์ และปัญหา)
• หารือเกี่ยวกับแนวทางแก้ไขที่เป็นไปได้เพื่อปรับปรุงเวิร์กโฟลว์ในการวิ่งครั้งต่อๆ ไป
• การสร้างแผนสำหรับการดำเนินการปรับปรุงโดยสมาชิกในทีมในระหว่างการดำเนินโครงการ

Scrum Master เชิญสมาชิกในทีมให้เสนอแนะวิธีปรับปรุงประสิทธิภาพการพัฒนา ทีมงานจะหารือเกี่ยวกับข้อเสนอและแนะนำวิธีการและเทคนิคบางอย่างสำหรับการนำไปปฏิบัติ

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

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