ใครบ้างที่รู้สึกว่าการแย่งชิงกันของ Scrum นั้นไม่คล่องตัว?


41

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

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

ผู้จัดการโครงการรักมัน

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

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

การประชุมที่ยอดเยี่ยม

การประชุมที่โดดเด่นในสถานที่ก่อนหน้านี้ที่ฉันทำงานนั้นเป็นฝันร้าย ทุกวันเราต้องอธิบายสิ่งที่เราทำเมื่อวานนี้และสิ่งที่เราจะทำในวันนั้น ถ้าเราไปในเวลา "ประเมิน" ของเราสำหรับงานผู้จัดการโครงการจะเตะเหม็นและอ้างอิง Sprint Backlog เป็นวิธีการแสดงความสามารถที่คุณไม่ได้ปฏิบัติตามระยะเวลา

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

ข้อสรุป

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

คิดว่าทุกคน?


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

7
ใช่. แม้แต่หนึ่งใน "บรรพบุรุษ" แห่งเปรียวก็ไม่เห็นด้วยว่าการต่อสู้นั้นคล่องแคล่วจริงๆ: youtube.com/watch?v=hG4LH6P8Syk
Euphoric

18
ดังนั้นสิ่งที่คุณกำลังพูดก็คือคุณไม่ได้ทำ Scrum และคุณก็ทราบดีว่า แต่แล้วคุณก็ประหลาดใจที่ Notscrum นั้นเป็น Notagile ด้วย?
pdr

2
ฉันไม่เคยใช้เวลามากขึ้นในการประชุมที่พูดถึงกระบวนการมากกว่าทีม "เปรียว" ทุกครั้งที่ฉันเข้าร่วม แต่ฉันยังคงชอบมันมากกว่าทางเลือก
Rob

11
จากประสบการณ์ของฉัน Scrum นั้นเป็นความพยายามที่จะทำให้ Waterfall ดูเปรียวโดยแบ่งออกเป็นหน่วยเล็ก ๆ ในความเป็นจริง sprints ควรเรียกว่า "cascades" แบบสมจริงยิ่งขึ้น
Berislav Lopac

คำตอบ:


25

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

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

ฉันไม่สามารถความเครียดนี้พอ: ถ้าคุณต้องการที่จะทำ Scrum คุณต้องโค้ชที่มีความสามารถที่สามารถแสดงเส้นทางให้คุณ การอ่าน Essential Scrum ยังไม่เพียงพอจากนั้นแค่ดูว่ามันทำให้คุณ ...


16
standup รายวันแตกต่างจาก micromanagement อย่างไร
Giorgio

10
จุดยืนของทีมคือการจัดการเวลาของพวกเขาเพื่อที่พวกเขาจะไม่ได้อยู่ในทางซึ่งกันและกัน มันไม่เหมาะสมอย่างยิ่งที่จะพูดถึงการประมาณการเวลาที่ผ่านไปในภารกิจที่ผ่านมา ฯลฯ - แน่นอนว่าผู้จัดการโครงการ
Julia Hayward

10
@Gorgio: ขึ้นอยู่กับสิ่งที่คุณหมายถึงโดยการจัดการขนาดเล็ก เป้าหมายของความโดดเด่นประจำวันใน SCRUM คือการแจ้งให้ทุกคนทราบถึงสิ่งที่คนอื่นกำลังทำไม่ใช่เพื่อให้โอกาสสำหรับผู้จัดการโครงการที่จะลงโทษผู้คนที่ไม่ได้คาดการณ์ ในความเป็นจริงไม่มีผู้จัดการโครงการใน SCRUM การติดตามและการปรับประมาณการเป็นงานของทีมและหากพวกเขาไม่พบคำถามที่จะถามคือ "สิ่งที่ทำให้เกิดและวิธีที่เราสามารถหลีกเลี่ยงหรืออนุญาตในอนาคต? "ไม่ใช่" ความผิดของใครและเราจะทำให้เขารู้สึกแย่แค่ไหน "
Michael Borgwardt

3
@ErikReppen ตามที่มีอยู่ไม่ว่าอะไรก็ตามคุณมีคนกลุ่มเล็ก ๆ ที่มีการพัฒนาที่คุ้มค่าแล้วคุณจะได้กลุ่มที่ใหญ่กว่ามากที่ต้องการสร้างรายได้จากมัน แต่ฉันก็ห่างไกลจาก Scrum Alliance และธุรกิจการรับรอง
Stefan Billiet

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

20

ใช่. แม้แต่หนึ่งใน "บรรพบุรุษ" แห่งเปรียวก็ไม่เห็นด้วยว่าการแย่งชิงกันอย่างคล่องแคล่วจริงๆ: youtube.com/watch?v=hG4LH6P8Syk - Euphoric

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


2
สิ่งนี้ (สิ่งที่คุณเขียนไม่ใช่สิ่งที่ลุงบ๊อบพูด) เป็นสิ่งที่ไม่เลื่อมใส เพียงเพราะบางสิ่งบางอย่างเป็นกระบวนการการจัดการไม่ได้ทำให้มันไม่ใช่ Agile
Dave Hillier

9
คุณสามารถมีแมวสีน้ำตาลและสุนัขสีน้ำตาล แต่แมวสีน้ำตาลไม่สามารถเป็นสุนัขสีน้ำตาลได้ ไม่ใช่เพราะมันไม่ใช่สีน้ำตาล แต่เป็นเพราะไม่ใช่สุนัข กระบวนการจัดการ Agile ในทำนองเดียวกันไม่สามารถเป็นกระบวนการพัฒนาซอฟต์แวร์ Agile ไม่ใช่เพราะไม่ใช่ Agile แต่เนื่องจากไม่ใช่กระบวนการพัฒนาซอฟต์แวร์ซึ่งเป็นสิ่งที่เรากำลังพูดถึง
winarama

1
จากนั้นคุณอาจต้องการอัปเดตคำถามของคุณชื่อ "มีใครบ้างที่รู้สึกว่าสกัลไม่คล่องแคล่วใช่ไหม"
Dave Hillier

ขอขอบคุณที่แบ่งปันวิดีโอ ฉันพบว่ามันแจ่มใสจริงๆ
MickJ

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

13

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

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

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


12

คุณอาจคาดหวังว่าจะมีคนหนึ่ง แต่เพียงเพราะบางคน (หลายคน) ใช้การต่อสู้ในทางที่ไม่คล่องแคล่วไม่ได้หมายความว่าการต่อสู้ไม่ใช่แบบว่องไว

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

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

จากคู่มือการแย่งชิง :

ติดตามความคืบหน้าของ Sprint

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


หลีกเลี่ยงไม่ได้ที่จะกลายเป็นวัฒนธรรมที่มุ่งเน้นการตำหนิแม้การแย่งชิงกันจะเป็นทฤษฎีทางการเมืองที่ถูกต้อง 100%
รัก

2

scrum เป็นวิธีการจัดการโครงการ

เปรียวเป็นวิธีการพัฒนาซอฟต์แวร์ (-ish)

scrum + agile ทำงานได้ดีมาก

ทะเลาะกันอย่างคล่องแคล่ว ... ไม่มาก


3
มันน่าสนใจที่ Scrum เคยเป็นวิธีการพัฒนาซอฟต์แวร์ แต่เมื่อเวลาผ่านไปได้พัฒนาเป็นวิธีการจัดการโครงการ
winarama

2
ฉันคิดว่ามันเป็นสิ่งที่หลีกเลี่ยงไม่ได้ ผู้พัฒนาไม่มีความรู้สึกเป็นเจ้าของในกระบวนการ (ไม่ต้องการ) ในการทบทวนการวิ่งเมื่อเร็ว ๆ นี้ฉันได้ถามคำถามเกี่ยวกับวัตถุประสงค์ของทีม: เขียนซอฟต์แวร์หรือทำให้แผนภูมิเบิร์นดาวน์ดูดี ฉันทำประเด็นของฉันแล้ว แต่ PMs ทั้งหมดในห้องต้องไปไกลมากเพื่อเน้นความสำคัญของ blah blah blah ฮ่า ๆ!
Rob

2
@ T-Pane: น่าสนใจยิ่งกว่าเดิมที่ Scrum ถูกเสนอให้เป็นวิธีการพัฒนาผลิตภัณฑ์ใหม่ - hbr.org/1986/01/the-new-new-new-product-development-game/ar/1
Steven A. Lowe

2
@ StevenA.Lowe Ah Scrum มันเป็นการเดินทางของการค้นพบตัวเอง
winarama

1
ฉันรู้ว่ามันเก่า แต่คำตอบนี้เป็นเท็จอย่างสมบูรณ์ การแย่งชิงกันเป็นกรอบซึ่งรูปแบบที่เหมาะสม Agile เป็นชุดของค่านิยมและหลักการ
Venture2099
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.