จุดใดของความล้มเหลวที่พบเมื่อ บริษัท ของคุณตัดสินใจแทนที่กระบวนการปัจจุบันด้วย SCRUM
คุณช่วยยกตัวอย่างบางสิ่งที่ผิดไปจริง ๆ เมื่อ บริษัท พยายามแนะนำ SCRUM ได้ไหม? ฉันต้องการได้ยินเกร็ดเล็กเกร็ดน้อยของคุณบางสิ่งที่คุณประสบด้วยตัวคุณเองความล้มเหลวครั้งใหญ่ที่คุณเห็นมา แต่ไม่สามารถป้องกันได้
ฉันได้ยินความกังวลมากมายเกี่ยวกับเอกสารที่หายไปเกี่ยวกับการตัดสินใจเกี่ยวกับรายละเอียดการใช้งานและเกี่ยวกับขนาดเรื่องราวและระดับรายละเอียดของเรื่องราว
คำตอบ:
ปัญหาที่ใหญ่ที่สุดคือความเข้าใจผิด ความล้มเหลวทั่วไปคือ:
มีเพียงทีมเดียวที่กำลังทำ Scrum แต่ บริษัท อื่น ๆ (รวมถึงฝ่ายขายฝ่ายบริหารทรัพยากรบุคคล) ยังคงคิดแบบเดิมอยู่ ตัวอย่าง:
การมีปฏิสัมพันธ์อย่างต่อเนื่องกับลูกค้าและการมีส่วนร่วมของลูกค้าเป็นสิ่งสำคัญมาก
ฝ่ายทรัพยากรบุคคลต้องเข้าใจว่าการทำงานเป็นทีมนั้นมีความสำคัญต่อประสิทธิภาพของบุคคล KPI ต้องเปลี่ยนเป็นอย่างนั้น
การกำหนดคุณสมบัติเป็นกระบวนการต่อเนื่อง คำจำกัดความของโครงการจะพัฒนาในระหว่างการพัฒนาโดยความคิดเห็นของลูกค้า เนื่องจากกำหนดเวลาสิ้นสุดโครงการนั้นงบประมาณหรือชุดผลลัพธ์ที่ต้องการจึงสามารถเปลี่ยนแปลงได้ (หลังจากได้รับอนุมัติจากผู้มีส่วนได้เสีย)
การเปลี่ยนแปลงเป็นส่วนหนึ่งของกระบวนการ
การประมาณเป็นกระบวนการต่อเนื่องที่คุณไม่สามารถพูดได้ในตอนต้นของโครงการว่าคุณจะทำกับคุณสมบัติทั้งหมด (ส่วนใหญ่ไม่ทราบในตอนต้น) ภายใน 5 เดือน
ทีมมีอำนาจในการตัดสินใจ ทีมทำให้ความมุ่งมั่นกับจำนวนของคุณสมบัติที่ส่งมอบในระหว่างการวิ่งครั้งต่อไป สิ่งนี้ไม่สามารถเรียกร้องหรือสั่งการได้
Sprint เป็นโซนที่ปลอดภัยสำหรับทีม เมื่อทีมยอมรับเรื่องราวของผู้ใช้ที่กำหนดไว้ความมุ่งมั่นไม่สามารถแก้ไขได้นอกทีม
ส่วนหนึ่งของโครงสร้างองค์กรเก่าไม่สมเหตุสมผลเมื่อย้ายไปยังสrum Scrum กำหนดบทบาทที่สาม: การต่อสู้หลักเจ้าของผลิตภัณฑ์ทีม มีบทบาทอื่น ๆ แต่ทั้งสามตัวนี้มักจะเพียงพอสำหรับการนำเสนอแอปพลิเคชัน ความรู้สึกไม่ธรรมดาคือการมีต้นแบบการต่อสู้หัวหน้าทีมเจ้าของผลิตภัณฑ์และผู้จัดการโครงการหนึ่งคนขึ้นไป ผู้จัดการโครงการและหัวหน้าทีมมีบทบาทซ้ำซ้อนในการต่อสู้
บทบาท Guy ที่ได้รับมอบหมายจาก Guy นั้นไม่ได้เป็นอาจารย์ Scrum การต่อสู้ต้นแบบแก้ปัญหาอุปสรรค สิ่งที่รบกวนทีมคือสิ่งกีดขวางซึ่งจะต้องได้รับการแก้ไขโดยเร็ว ความล้มเหลวที่พบบ่อยที่สุดคือการกำหนดบทบาทนี้ให้กับนักพัฒนาโดยไม่มีประสบการณ์การใช้งาน Scrum มาก่อน บทบาทนี้แทนที่ผู้จัดการโครงการทั่วไปบางส่วน แต่ Scrum master ไม่มีอำนาจเหนือทีมและ Scrum master ไม่ต้องการคุณสมบัติใด ๆ Scrum master ปกป้องทีมแม้กับเจ้าของผลิตภัณฑ์ที่มีข้อกำหนดที่ไม่สามารถจัดการได้
แก้ไข:
ฉันกำลังเพิ่มบันทึกย่อที่สำคัญ เมื่อใช้วิธีการแบบเปรียวประเด็นหลักคือการมอบมูลค่าทางธุรกิจสูงสุดให้กับลูกค้าโดยเร็วที่สุด แต่ลูกค้า (แสดงโดยเจ้าของผลิตภัณฑ์) อธิบายถึงมูลค่าทางธุรกิจ ดังนั้นจึงไม่เป็นความจริงที่คุณไม่มีการวิเคราะห์หรือเอกสารประกอบเมื่อใช้ Scrum หากลูกค้าร้องขอการวิเคราะห์หรือทำเอกสารและทำเครื่องหมายว่าเป็นมูลค่าทางธุรกิจ (เช่นเนื่องจากโครงการขนาดใหญ่หรือระยะยาวซึ่งควรปรับปรุงในอีกไม่กี่ปีข้างหน้า) คุณจะสร้างมันขึ้นมาเช่นกัน วิธีการพื้นฐานที่สุดคือการวิเคราะห์และเอกสารประกอบในเกณฑ์การยอมรับเรื่องราวของผู้ใช้ การวิเคราะห์ในกรณีดังกล่าวเป็นการสื่อสารเอกสารกับเจ้าของผลิตภัณฑ์ด้วยวิธีมาตรฐาน
The most basic approach is including analysis and documentation in acceptance criteria for user stories.นั่นคือปฏิกิริยาเริ่มต้นของฉันเช่นกัน หากเรื่องราวมีเกณฑ์การยอมรับนั่นเป็นเอกสารที่ดีที่สุดที่คุณสามารถมีได้ แต่ถ้าทีมตัดสินใจที่จะสร้างเอกสารเพิ่มเติม (คิดถึง READMEs ใน trunk หรือ wiki ที่มีข้อมูลที่เป็นประโยชน์) ฉันก็เลยไม่เห็นปัญหา ฉันคิดว่าคนกลัวว่า SCRUM = ไม่มีอะไรถูกเขียนลงไปเลย
ปัญหาที่ใหญ่ที่สุดที่ฉันสังเกตเห็นในกว่า 10 ปีของ xp และการต่อสู้คือเมื่อทีมที่ยังไม่ "รับ" เปรียวเลยตัดสินใจที่จะ "ยืดหยุ่นเกี่ยวกับความคล่องตัว" และเริ่มปรับแต่งลดลงบางส่วน ฯลฯ โดยไม่ต้อง ความเข้าใจที่ชัดเจนว่าแต่ละส่วนทำอะไรและทำไมจึงอยู่ที่นั่น
ฉันเคยเห็นทีมประสบความสำเร็จมากกว่าในการต่อสู้เมื่อพวกเขาทำสิ่งต่าง ๆ ตามหนังสือเล่มแรกมากกว่าทีมที่เปลี่ยนสิ่งที่พวกเขาไม่ได้ "รับ"
นั่นคือเมื่อคุณได้รับสิ่งต่าง ๆ เช่น "การวิ่งครั้งแรกเราจะทำตามความต้องการทั้งหมด" การวิ่งครั้งที่สองการออกแบบทั้งหมด ฯลฯ ฯลฯ การทดสอบการวิ่งทั้งหมดครั้งสุดท้าย " หรือที่เรียกว่าน้ำตก หรือแม้แต่เรื่องง่าย ๆ เช่น "มานั่งต่อไปธุรกิจแบบนี้คืออะไร"
สิ่งที่ต้องทำกับ Shuhari ( http://c2.com/cgi/wiki?ShuHaRi )
ปัญหาที่ใหญ่ที่สุดคือการซื้อเสมอ หากทีมใด ๆ หรือบุคคลสำคัญไม่ได้ซื้อ (การจัดการโครงการ, QA, การพัฒนาและอื่น ๆ ) ความผิดพลาดนั้นเกือบจะมั่นใจได้
ปัญหาที่เกี่ยวข้องอีกประการหนึ่งคือการทำให้ทุกคนที่เกี่ยวข้องตระหนักถึงสิ่งที่เป็นการต่อสู้ที่แท้จริงและสิ่งที่ไม่
ฉันได้เห็นสภาพแวดล้อมที่การจัดการโครงการได้นำสิ่งนี้มาเป็นตั๋วเพื่อนำไปสู่การเปลี่ยนแปลงโดยตรงและคาดว่าจะเสร็จในวันพรุ่งนี้เนื่องจากเราใช้กระบวนการใหม่ที่ยอดเยี่ยม ทุกคนที่อยู่ในสถานการณ์นี้หรือในความพยายามที่ล้มเหลวอื่น ๆ ในการดำเนินการต่อสู้และมีรสขมในปากของพวกเขา คนเหล่านี้บางครั้งจะพยายามแยกโครงการออกไปเช่นกัน
ปัญหาอื่นที่ฉันเห็นคือการประชุม คุณจะได้คนที่อยากนั่งลงระหว่างการประชุมยืนอยู่เสมอ ... "ฉันมีอาการแย่" หรืออะไรก็ตาม ดูเหมือนว่าจะเป็นผู้ชายคนเดียวกันที่ไม่มีความคิดว่าวัตถุประสงค์อยู่เบื้องหลังความโดดเด่นและจะไม่ปิดเรื่องการเมืองหรือสิ่งที่เขาทำในสุดสัปดาห์นั้น ฉันพบการประชุมที่โดดเด่นเป็นกุญแจสำคัญในการสื่อสารที่มีประสิทธิภาพ เป็นสิ่งสำคัญที่จะไม่ปล่อยให้ใครเป็นพิษกับการประชุมเหล่านี้
management has actually taken this as a ticket to come directly to developersนั่นเป็นตัวอย่างที่ดีของสถานการณ์ที่ไม่เข้าใจกระบวนการ SCRUM ใช่ไหม ที่ทีมไม่สามารถรับเรื่องใหม่ในช่วงกลางของการวิ่ง
พยายามทำการวิเคราะห์ทั้งหมดสำหรับโค้ดที่เราพัฒนาใน sprint เดียวกันกับที่เรากำลังเขียนโค้ดจริงๆ
เราย้ายไปที่การต่อสู้เมื่อไม่นานมานี้และการจัดการที่ดำเนินการโดยสุจริตถือว่าแต่ละการต่อสู้เป็นกระบวนการน้ำตก 2 สัปดาห์ มีการยึดมั่นในกฎของการต่อสู้ที่กลายเป็นกระบวนการในตัวเอง!
นี่คือปัญหาที่ฉันพบวิธีการที่คล่องตัวควรมีความยืดหยุ่นในการทำงานอย่างมีประสิทธิภาพในแบบที่คุณต้องการ ไม่ใช่วิธีที่ถูกดำเนินการโดยกระบวนการ ตัวอย่างเช่นเรามีการทะเลาะกัน 2 สัปดาห์และทีมบอกว่าพวกเขารู้สึกว่า 2 สัปดาห์นั้นไม่เพียงพอที่จะทำงานได้ดี (ไม่ใช่จากการหยุดทำงานที่เกิดจากการสิ้นสุดการสาธิตการต่อสู้และการทบทวนข้อกำหนดเบื้องต้น) ดังนั้นพวกเขาจึงต้องการ 3 สัปดาห์. ตกใจสยองขวัญ! การจัดการปฏิเสธเพราะพวกเขาตัดสินใจ 2 สัปดาห์ต่อการต่อสู้เป็นสิ่งที่ดีที่สุดและตอนนี้บันทึกไว้ในขั้นตอนคุณภาพแล้ว
การแย่งชิงกันเป็นวิธีการที่ว่องไวน้อยที่สุดซึ่งอาจเป็นสาเหตุว่าทำไมมันถึงได้รับความนิยม คุณควรจะลบสิ่งที่คุณไม่ชอบ แต่ฉันไม่คิดว่าจะเกิดอะไรขึ้น คำแนะนำของฉันคือการใช้กฎที่ยืดหยุ่นและมีกฎน้อยลงและเพิ่มกฎที่คุณต้องการแทน ฉันชอบคริสตัลเพราะเหตุนี้
ในท้ายที่สุดเพียงแค่จำครึ่ง arsed แถลงการณ์เปรียว
ปัญหาที่ใหญ่ที่สุดคือลูกค้าของคุณต้องยอมรับกระบวนการ SCRUM และมีความคล่องตัวเช่นกัน ลูกค้าส่วนใหญ่ต้องการได้ยินสิ่งนี้ในตอนต้นของโครงการ:
ฟังดูสมเหตุสมผล แต่เข้ากันไม่ได้กับความคล่องตัวอย่างแน่นอน คุณต้องอธิบายให้กับลูกค้าของคุณว่าทำไมความคล่องแคล่วของเขาแทนน้ำตก
how much will it cost?และพวกเขาคาดหวังคำตอบอย่างละเอียดแล้ว คำตอบของฉันเกี่ยวกับข้อกังวลนี้อยู่เสมอ "ถ้าคุณรู้ว่าสิ่งที่คุณต้องการในท้ายที่สุดคุณไม่จำเป็นต้องคล่องตัวเพียงแค่เขียนมันลงไป" แต่เราทุกคนรู้ว่าจะไม่เกิดขึ้น ;-)
เรามีปัญหาใหญ่สองเรื่องในครั้งแรกที่ฉันมาที่ SCRUM:
1) เราไม่มีเจ้าของผลิตภัณฑ์จริงๆ เจ้านายของเราต้องมีบทบาทเพราะไม่มีใครควรเป็นเจ้าของผลิตภัณฑ์จะเห็นด้วยที่จะทำเช่นนั้น สิ่งนี้ทำให้เกิดจีบในสิ่งต่าง ๆ เพราะเขาไม่รู้คำตอบจริง ๆ
2) เราทำบัญชีไม่ดีสำหรับส่วนประกอบภายนอก การวิ่งสองสามครั้งแรกของเรานั้นเกี่ยวข้องกับการทดสอบอัตโนมัติเต็มรูปแบบและทำงานและเราพบปัญหาซ้ำ ๆ ในการจำลองเครื่องที่เราใช้อยู่ ยังไงก็เถอะเราไม่เคยรู้เลยว่าจะเกิดอะไรขึ้น
ปัญหาที่สำคัญที่ฉันเผชิญในโครงการของฉันคือการรวบรวมความต้องการเกิดขึ้นหลังจากที่เราประเมินการวิ่งครั้งต่อไปแล้ว เราประเมินตามเกณฑ์การยอมรับ ในระหว่างการรวบรวมความต้องการเราพบว่า AC ที่ปรับจูนนั้นใหญ่กว่ามากดังนั้นงาน initaly ที่ประเมินเป็นเวลา 8 ชั่วโมงในขณะนี้ก็จริง ๆ 24 ชั่วโมง! ดังนั้นฉันสามารถเปลี่ยนการค้างของฉันและแก้ไขประมาณการและลดเรื่องราวของฉันได้หรือไม่ ไม่ครับท่าน! เปรียวเปรอะเปื้อนที่คุณไม่สามารถเปลี่ยนค้างค้าง! นั่นคือสิ่งที่ TL ของฉันพูด ดังนั้นฉันไม่ควรเข้ารหัสตามเกณฑ์การยอมรับดั้งเดิมซึ่งฉันใช้เวลาประมาณ 8 ชั่วโมง! พระเจ้า! No! คุณทำอย่างนั้นไม่ได้! นั่นคงไม่ใช่ Agile ใช่ไหม!