วิธีการพัฒนาแบบ Agile "Scrum"

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

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

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

เมื่อพวกเขาพูดถึงระเบียบวิธีของ Scrum พวกเขามักจะหมายถึงวิธีการพัฒนาซอฟต์แวร์ที่คล่องตัวซึ่งสร้างขึ้นบนพื้นฐานของกฎและแนวทางปฏิบัติของ Scrum ดังนั้นจึงอาจกลายเป็นว่า Scrum ของคุณเจ๋งกว่า Scrum ของฉัน และยังห่างไกลจากมันด้วย VAZ 7 มาจาก BMW 7 Series :)

บทบาทใน Scrum

มีบทบาทพื้นฐาน 3 ประการใน Scrum แบบคลาสสิก:
-เจ้าของผลิตภัณฑ์
-Scrum master
-ทีมพัฒนา

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

เครื่องมือ PO หลักอย่างหนึ่งคือ Product Backlog Product Backlog ประกอบด้วยงานที่ต้องทำให้เสร็จ (เช่น Story, Bug, Task ฯลฯ) โดยเรียงตามลำดับความสำคัญ (เร่งด่วน)

Scrum master(SM) เป็นผู้นำคนรับใช้ งานของ Scrum Master คือการช่วยให้ทีมมีประสิทธิผลสูงสุดโดยขจัดอุปสรรค ช่วยเหลือ สอน และจูงใจทีม ช่วย PO

ทีมพัฒนา(ทีมพัฒนา DT) ประกอบด้วยผู้เชี่ยวชาญที่ทำงานโดยตรงกับผลิตภัณฑ์ที่ผลิต ตาม The Scrum Guide (เอกสารที่เป็นคำอธิบายอย่างเป็นทางการของ Scrum จากผู้เขียน) DT ต้องมีคุณสมบัติและลักษณะดังต่อไปนี้:
- จัดระเบียบตัวเอง ไม่มีใคร (รวมทั้ง SM และ PO) สามารถบอกทีมถึงวิธีการแปลง Product Backlog เป็นผลิตภัณฑ์ที่ใช้งานได้
-เป็นมัลติฟังก์ชั่น มีทักษะที่จำเป็นทั้งหมดเพื่อปล่อยผลิตภัณฑ์ที่ใช้งานได้
-ทั้งทีมรับผิดชอบงานที่ทำ ไม่ใช่สมาชิกในทีมรายบุคคล

ขนาดทีมที่แนะนำคือ 7 (บวกหรือลบ 2) คน ตามอุดมการณ์ของ Scrum ทีมขนาดใหญ่ต้องการทรัพยากรในการสื่อสารมากเกินไป ในขณะที่ทีมขนาดเล็กจะเพิ่มความเสี่ยง (เนื่องจากอาจขาดทักษะที่จำเป็น) และลดปริมาณงานที่ทีมสามารถทำได้ต่อหน่วยเวลา

กระบวนการต่อสู้

พื้นฐานของ Scrum คือ Sprint ซึ่งทำงานบนผลิตภัณฑ์ เมื่อสิ้นสุด Sprint ควรได้รับผลิตภัณฑ์เวอร์ชันที่ใช้งานได้ใหม่ Sprint มีเวลาจำกัดเสมอ (1-4 สัปดาห์) และมีระยะเวลาเท่ากันตลอดอายุการใช้งานของผลิตภัณฑ์

ก่อนเริ่ม Sprint แต่ละครั้ง จะมีการดำเนินการ Sprint Planning ซึ่งประเมินเนื้อหาของ Product Backlog และสร้าง Sprint Backlog ซึ่งประกอบด้วยงาน (Story, Bugs, Tasks) ที่ต้องทำให้เสร็จใน Sprint ปัจจุบัน การวิ่งแต่ละครั้งควรมีเป้าหมายที่จูงใจและทำได้โดยทำภารกิจจาก Sprint Backlog ให้สำเร็จ

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

ในตอนท้ายของ Sprint จะมีการผลิต Sprint Review และ Sprint Retrospective ซึ่งงานคือการประเมินประสิทธิภาพ (productivity) ของทีมใน Sprint ที่ผ่านมาเพื่อคาดการณ์ประสิทธิภาพที่คาดหวัง (productivity) ใน Sprint ถัดไป ระบุปัญหาที่มีอยู่ ประเมินความเป็นไปได้ในการทำงานที่จำเป็นทั้งหมดเกี่ยวกับผลิตภัณฑ์ให้เสร็จสิ้น และอื่นๆ ...

การแสดงแผนผังของกระบวนการแสดงในรูปต่อไปนี้:

คุณสมบัติที่สำคัญมักถูกมองข้าม

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

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

2. ความสำคัญของการทำงานเพื่อให้แน่ใจว่าแรงจูงใจของทีมถูกประเมินต่ำไป
ทีมอเนกประสงค์ที่จัดระเบียบตนเองได้เป็นหนึ่งในหลักการสำคัญของ Scrum จากการวิจัยของนักสังคมวิทยา จำนวนพนักงานที่มีแรงจูงใจในตนเองที่สามารถจัดการตนเองได้ไม่เกิน 15% ของประชากรที่ทำงาน
ดังนั้น พนักงานเพียงเล็กน้อยเท่านั้นที่สามารถทำงานอย่างมีประสิทธิภาพใน Scrum โดยไม่มีการเปลี่ยนแปลงที่สำคัญในบทบาทของ Scrum master และ Product Owner ซึ่งขัดแย้งกับอุดมการณ์ Scrum และอาจนำไปสู่การใช้ Scrum อย่างไม่ถูกต้องหรือไม่สมบูรณ์

3. Scrum ใช้สำหรับผลิตภัณฑ์ ซึ่งเป็นข้อกำหนดที่ขัดแย้งกับอุดมการณ์ Scrum
Scrum อยู่ในตระกูล Agile ดังนั้น Scrum จึงยินดีต้อนรับการเปลี่ยนแปลงข้อกำหนดทุกเมื่อ (ผลิตภัณฑ์ในมือสามารถเปลี่ยนแปลงได้ตลอดเวลา) ซึ่งทำให้ยากต่อการใช้ Scrum ในโครงการที่มีต้นทุนคงที่/เวลาคงที่ อุดมการณ์ Scrum ระบุว่า เป็นไปไม่ได้ที่จะคาดการณ์ล่วงหน้าถึงการเปลี่ยนแปลงทั้งหมด จึงไม่มีประโยชน์ในการวางแผนโครงการทั้งหมดล่วงหน้า โดยจำกัดตัวเองให้อยู่ในการวางแผนแบบทันท่วงที นั่นคือ การวางแผนเฉพาะงานที่ต้องทำ ใน Sprint ปัจจุบัน มีข้อ จำกัด อื่น ๆ เช่นกัน

ข้อดีข้อเสีย

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

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

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

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

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

รายการแหล่งที่ใช้

คู่มือการต่อสู้ คู่มือฉบับสมบูรณ์ของ Scrum: กฎของเกม (เคน ชวาเบอร์, เจฟฟ์ ซัทเธอร์แลนด์)
จิตวิทยาการจัดการ คู่มือการเรียน (เอ เอ ทรัส)
วิธีที่ผู้จัดการโครงการดั้งเดิมเปลี่ยนไปเป็น Scrum: PMBOK vs. การต่อสู้ (เจฟฟ์ ซัทเทอร์แลนด์, นาฟิส อาหมัด)

ขอขอบคุณล่วงหน้าสำหรับข้อผิดพลาดและความไม่ถูกต้องที่ระบุ!

 

อาจเป็นประโยชน์ในการอ่าน: