ฉันจะจัดการกับทีมการต่อสู้แบบต่อต้านได้อย่างไร?

Backstory:
ฉันทำงานเป็นส่วนหนึ่งของทีมนี้เป็นเวลาสามปีที่ผ่านมาและในเวลานี้เรามี Scrum Master สามคนที่แตกต่างกันไป

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

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

ปัจจุบัน:
สองเดือนที่ผ่านมา บริษัท ได้แต่งตั้งฉัน Scrum Master ให้กับทีมของฉันเนื่องจากความทุ่มเทของฉันต่อการทำงานที่คล่องตัวและหลักการของ บริษัท

ฉันกำลังทุกข์ทรมานอย่างมากภายใต้ความกดดันบรรยากาศของสมาชิกในทีมของฉันที่ไม่เต็มใจที่จะทำการต่อสู้

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

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

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

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

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

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

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

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

ฉันจะทำให้พวกเขาเห็นว่าการล้อเล่นและเสียเวลาในระหว่างการประชุมเหล่านี้ทำให้ บริษัท ต้องเสียเงินเป็นจำนวนมาก?

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

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

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

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

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

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

เมื่อสมาชิกในทีมเห็นว่าพวกเขามีอำนาจที่จะทำให้เกิดการเปลี่ยนแปลงจริงในกระบวนการของพวกเขาพวกเขาก็จะมีส่วนร่วมมากขึ้น

กระบวนการย้อนหลังคือเหตุผลว่าทำไมหากคุณเยี่ยมชมทีมทั้งหมดใน บริษัท ที่มีความคล่องตัวดีพวกเขาทั้งหมดทำแตกต่างกันบ้าง เรามีบางทีมที่ทำ Kanban, บางอย่างที่ทำ XP, บางอย่างที่ทำ standup วันจันทร์พุธศุกร์

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

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

การวางแผน

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

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

• นักพัฒนารู้สึกว่าพวกเขาถูกกดดันอย่างต่อเนื่อง
• "ฉันไม่สามารถทำอะไรให้ทันเวลา"
• เนื่องจากกระบวนการไม่ทำงานพวกเขาเห็นอย่างถูกต้องว่าเป็นการเสียเวลา

โซลูชัน : แก้ไขการประมาณของคุณโดยใช้การรวมกันของ:

• คะแนนเรื่องราว (เป็นการรวมกันของเวลาและความเสี่ยง)
• ไม่อนุญาตให้ทำงานในการวิ่งที่> 55 SP
• การเปรียบเทียบเชิงเปรียบเทียบ
• การจัดตารางตามหลักฐาน

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

เมื่อคุณมีเวลาทั้งหมดสำหรับงานที่กำหนดคุณสามารถกำหนดเวลาที่คาดหวังให้กับงานก่อนหน้านั้น

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

หากคุณไม่เคยใช้ SP มาก่อนคำแนะนำของฉันคือเริ่มต้นด้วย 1 ชั่วโมงที่ซื่อสัตย์ต่องานพระเจ้า = 5SP เป็นแนวทาง เก็บไว้ในใจว่าในการพัฒนาสภาพแวดล้อมปกติคุณจะได้รับอาจจะ 6 ของคนต่อวันดังนั้น 30SP / วันสูงสุด ไม่เคยอนุญาตให้มีงานที่ต้องใช้เวลามากกว่า 2 วันขึ้นไปบนกระดาน ตามประสบการณ์ของฉันคุณควรมี 2 งานต่อวัน

หากคุณไม่ได้วางแผนอย่างถูกต้องกิจกรรมการต่อสู้ที่เหลือของคุณจะดูเหมือนเสียเวลา (รวมถึงการวางแผน)

มีผลย้อนหลัง

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

เตือนฉันDaily beatings will continue until morale improves!ถึงงานที่ผ่านมาสองงาน หากคุณไม่ลบอุปสรรคสิ่งเหล่านี้จะถูกต้องว่านี่เป็นการเสียเวลา

อีกครั้งฟังสิ่งที่ผู้คนกำลังพูดจริง หากข้อร้องเรียนที่เกิดขึ้นในระหว่างการหวนกลับไม่ได้รับการจัดการทำไมต้องทำอย่างนั้น?

ดังนั้น:

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

SCRUM รายวัน

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

ดูเหมือนว่าคุณมีปัญหาสองประการที่นี่: การประชุม SCRUM ยาวเกินไปและการวางแผนและการสร้างงานของคุณแย่มาก

ทั้งสองสามารถทำให้เสียงเหมือนการประชุมการต่อสู้เป็นเรื่องเสียเวลา

สำหรับความยาวของ SCRUM:

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

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

• แบ่งงานออกเป็นจุดย่อย
• ตรวจสอบให้แน่ใจว่างานมีขนาดเล็กพอที่จะใช้เวลาน้อยกว่าหนึ่งวัน ตามหลักการแล้ว IMO งานควรมีอายุประมาณ 3 ชั่วโมงและมีค่าประมาณ 13 SP ดังนั้นคุณสามารถทำได้ 2 ต่อวันในสภาพส่วนใหญ่

การจัดการกับทีม

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

เขาพูดถูก. คุณผิด. คุณกำลังทำ SCRUM ที่ถูกกลั่นแกล้งและ / หรือการเปลี่ยนแปลงใน Kanban ไม่ใช่ความผิดของพวกเขาเลย

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

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

พวกเขาแค่ทำงานแทนที่จะจัดการกับอุปสรรค

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

นี่อาจเป็นเหตุผลว่าทำไมคุณถึงมีปัญหามากมายในการหวนรำลึก

ฉันจะทำให้พวกเขาเห็นว่าการล้อเล่นและวนเวียนในระหว่างการประชุมเหล่านี้ทำให้ บริษัท ต้องเสียเงินเป็นจำนวนมาก?

หยุดการประชุมที่ไร้ประโยชน์แล้วพวกเขาจะพูดเล่นตลกรอบ ๆ watercooler แทน ดูวรรคที่เกี่ยวกับการเฆี่ยนตีการปรับปรุงขวัญกำลังใจ หากพวกเขาใช้อารมณ์ขันเป็นกลไกในการป้องกันคุณมีปัญหาร้ายแรงกับคุณ!

เข้าเรื่องตลก - ในการทำงานกับทีมของคุณ (ใคร fuuuuuu ใส่ใจเกี่ยวกับเงินของ บริษัท คุณเป็นผู้ถือหุ้นตอนนี้หรือไม่)

เพื่อสรุป

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

ปรับปรุงการวางแผนของคุณและคุณจะปรับปรุงขั้นตอนและขวัญกำลังใจ

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

สำคัญที่สุด: ฟังคนของคุณ พวกเขาบอกคุณแล้ว (และฉัน) ว่ามีปัญหาอะไร

โชคดี!

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

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

นอกจากนี้คุณกำลังทำลายหนึ่งในหลักการในการประกาศ : "บุคคลและการมีปฏิสัมพันธ์กับกระบวนการและเครื่องมือ"

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

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

หากคุณต้องการดูวิดีโอที่ดีเกี่ยวกับการต่อสู้ดู " Robert C. Martin - ดินแดนแห่งการต่อสู้ที่ลืม "

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

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

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

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

การให้ทีมของคุณปิดการวิ่งของคุณอย่างมีประสิทธิภาพ (อย่างน้อย 80% ของเรื่องราว) การวิ่งผ่าน sprint เป็นสิ่งที่สำคัญที่สุดที่คุณสามารถทำได้ หากทีมของคุณขาดหายไปอย่างสม่ำเสมอนั่นเป็นข้อบ่งชี้ที่ชัดเจนว่าคุณต้องปรับการประมาณของคุณ

ทีมควรเปิดกว้างสำหรับเรื่องนี้แม้ว่ามันจะยากมากที่จะทำให้นักพัฒนามีความเป็นจริงมากขึ้นเกี่ยวกับการประมาณการ - ฉันทำงานกับทีมที่ไม่ได้ปิดการวิ่งเป็นเวลาหนึ่งปี (ปิดน้อยกว่า 50% ของการวิ่ง) ภายใต้การคาดการณ์เสมอและในทุกการวางแผน / การหวนคิดถึงฉันเป็นคนเดียวที่บอกพวกเขาว่าคุณกำลังดูดคุณกำลังมีความมั่นใจเกินเหตุหยุดการแก้ตัวสำหรับสิ่งที่ป้องกันไม่ให้คุณประเมินและปรับประมาณการแทนความจริง อาจมากกว่าทางการทูต แต่นั่นเป็นความเชื่อมั่นขั้นพื้นฐาน) - เมื่อคุณอยู่ในตำแหน่งนั้นฉันจะเห็นด้วยอย่างเต็มที่กับ curmudgeon ในทีมของคุณที่กล่าวว่ากระบวนการนี้เป็นการเสียเวลาเพราะคุณกำลังทำ KonBon โดยไม่คำนึงถึง สิ่งที่คุณเรียกว่า ณ จุดหนึ่งความเห็นของเขาจะถูกตรวจสอบโดยสถานการณ์ มัน'

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

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

ในที่สุดทีมของเราก็มีแรงฉุดและสิ่งต่าง ๆ เริ่มราบรื่นขึ้นและต่ำลงและดูว่าเราเริ่มมีผลผลิตสูงขึ้นเมื่อกระบวนการเริ่มทำงานจริง ดังนั้น tl; dr - ทำทุกอย่างที่จำเป็นเพื่อเริ่มการวิ่งแข่งด้วยความสำเร็จระดับสูง หากคุณไม่ได้ทำสิ่งที่ curmudgeon ในทีมของคุณจะยังคงมีความต้านทานต่อ Scrum ตรวจสอบโดยผลและในที่สุดจะถูกต้องว่ากระบวนการของคุณในความเป็นจริงเพียงเสแสร้งและเสียเวลาทุกคน

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

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

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

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

ระหว่าง Retrospective [... ] คนอื่น ๆ เงียบและฉันต้องจัดการกับมันทุกครั้ง

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

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

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

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

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

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

คุณทำอะไรได้บ้าง

1. ฟังความกังวลของพวกเขา อีกครั้งคุณกำลังมีความสุขในการที่คุณจะได้มีคนฉลาด

2. ช่วยให้พวกเขาแก้ไขอุปสรรค

และนั่นคือมันจริงๆ คุณจะต้องทดสอบด้วยการเปลี่ยน Sprint Planning, Daily Scrum และ Retrospectives เพื่อให้มีค่าต่อทีม - แม้ว่าคุณต้องการที่จะทิ้ง Scrum label คุณยังมีการประชุม 3 ครั้งที่มีความถี่และวัตถุประสงค์ที่คล้ายคลึงกัน วิธีการจัดการโครงการออกมี สำหรับวิธีที่คุณจะทำการทดสอบ (ความถี่เนื้อหาที่เป็นเจ้าภาพการประชุมเวลาระยะเวลา ฯลฯ ) นั่นเป็นเรื่องง่ายอย่างน่าประหลาดใจ: ถามทีม อย่าบังคับความคิดของคุณให้กับพวกเขาหากมีสิ่งใดที่คุณควรปล่อยให้พวกเขาบังคับความคิดของพวกเขาให้กับคุณ

หากคุณกลัวว่าจะสูญเสียการควบคุมให้กำหนดขอบเขตไว้ล่วงหน้าเช่น:

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

ผมคิดว่าทุกคนจะอ้างบรรทัดเดียวกันจากเปรียว ฉันจะทำเช่นเดียวกัน: "บุคคลและการมีปฏิสัมพันธ์กับกระบวนการและเครื่องมือ"

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

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

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

หรือผสมและจับคู่พวกเขา ฉันทำงานในโปรแกรมที่ต่อต้านการทะเลาะกัน ลูกค้าต้องการเพิ่มงานใหม่ได้ทุกเมื่อในระหว่างกระบวนการและให้เราดำเนินการทันที (นี่เป็นคำขอที่มีเหตุผล: งานของพวกเขานั้นมีความผันผวนสูงและพวกเขาต้องการการสนับสนุนอย่างรวดเร็วบ่อยครั้ง ... เป็นสิ่งที่เราจ่ายให้) แน่นอนว่าเราต้องหาวิธีจัดการกับปัญหา "ทำไม X ถึงไม่ทำเมื่อคุณสัญญากับปัญหาในการวิ่ง" ทางออกของเราคือการสร้างกระบวนการสองขั้นตอน งานระยะยาวถูกนำไปไว้ใน SCRUM เพื่อจัดลำดับความสำคัญที่เหมาะสม งานระยะสั้นถูกวางไว้ในกระบวนการโฮมบรูว์ซึ่งมุ่งเน้นไปที่การโต้ตอบอย่างแน่นหนาระหว่างลูกค้าและนักพัฒนา เป็นที่เข้าใจว่าลูกค้าสามารถผลักดันเราโดยใช้กระบวนการระยะสั้นนี้ แต่พวกเขาเข้าใจว่าการทำเช่นนั้นผลักดันให้ Sprint ' ไทม์ไลน์ของพวกเขาและพวกเขาถูกห้ามจากการเพิ่มการร้องขอโดยไม่ต้องรับฟังพร้อมกันและจัดการกับปัญหาการตั้งเวลาที่เกิดขึ้น ผลลัพธ์? มันได้ผล งานส่วนใหญ่ถูกนำไปใช้ในกระบวนการ SCRUM อย่างที่ควรจะเป็นและเหตุฉุกเฉินก็มีปฏิสัมพันธ์กับพวกเขาอย่างราบรื่น ทัศนคติคือ "ถ้าคุณต้องการเป็นลูกค้าให้ยืนต่อเรื่องราว SCRUM ถ้าคุณต้องการเป็นหุ้นส่วนอย่าลังเลที่จะลงมาและทำงานร่วมกับเราในระดับต่อวันและทำให้ผลิตภัณฑ์นี้ทำงานได้ !"

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

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

เนื่องจากการเปลี่ยนแปลงใน Scrum Masters และวิธีการแสดงของพวกเขา

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

ฉันสงสัยว่าทีมจะมาจากไหน เป็นไปได้ไหมที่พวกเขาจะเป็นอิสระมากขึ้นหรือน้อยลงก่อนที่จะมีการแย่งชิงกัน ทำไมจึงมีการแนะนำ Scrum ตั้งแต่แรก? มันควรจะแก้ปัญหาอะไร?

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

นี่เป็นปัญหาที่ไม่ จำกัด เฉพาะซอฟต์แวร์

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

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

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

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

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

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

ฉันจะทำให้พวกเขาเห็นว่าการล้อเล่นและวนเวียนในระหว่างการประชุมเหล่านี้ทำให้ บริษัท ต้องเสียเงินเป็นจำนวนมาก?

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

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

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

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

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

คุณได้รับคำตอบที่ยอดเยี่ยมมากมาย นี่คืออีกไม่กี่จุดที่อาจเป็นประโยชน์:

วิธีการเปลี่ยนเป็นเรื่องยาก

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

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

ฉันขอแนะนำ Roy Osherove ในหัวข้อนี้ เขาได้บทสรุปโดยย่อเกี่ยวกับวิธีการวางแผนและการเปลี่ยนแปลงผลกระทบที่ บริษัท ของคุณและเขาเข้าสู่หัวข้อที่มีความลึกมากกว่าในวิดีโอนี้

การสังเกตขั้นพื้นฐานของ Osherove คือต้องพบกับความท้าทายต่อไปนี้ทั้งหมด:

แรงจูงใจส่วนตัว: ทำไมบางคนควรใส่ใจในพฤติกรรมที่เฉพาะเจาะจง?
ความสามารถส่วนบุคคล: พวกเขาสามารถทำมันได้อย่างแท้จริง?
แรงจูงใจทางสังคม: มีแรงกดดันจากเพื่อนสำหรับพฤติกรรมนี้หรือไม่?
ความสามารถทางสังคม: คนรอบตัวฉันสนับสนุนพฤติกรรมของฉันและช่วยเหลือฉันเมื่อฉันต้องการความช่วยเหลือหรือไม่?
แรงจูงใจโครงสร้าง:มีรางวัล \ ลงโทษสำหรับพฤติกรรมที่ดี \ ไม่ดี?
ความสามารถทางโครงสร้าง: สภาพแวดล้อมทางกายภาพรองรับพฤติกรรมนี้หรือไม่

คุณต้องเรียนรู้ที่จะทำลายงานลง

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

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

บางคำตอบอาจเป็น:

• ฉันกำลังเรียนรหัสคลาสนี้อยู่
• ฉันกำลังแก้ไขข้อบกพร่องซึ่งมีอาการ (อาการ)
  • หากนี่เป็นข้อผิดพลาดบางอย่างที่กำลังดำเนินอยู่: "วันนี้สิ่งที่ฉันจะลองคือ ... (PLAN)"
• ฉันต้องการเปลี่ยนอินเทอร์เฟซนี้
• ฉันกำลังเขียนข้อสอบ
• ฉันกำลังรวมรหัสที่ยังไม่ผ่านการทดสอบ

... และอื่น ๆ และอื่น ๆ. ความสามารถในการสังเกตสิ่งที่คุณทำได้จริง ๆ ในหนึ่งวันหรือในหนึ่งสัปดาห์นั้นเป็นประโยชน์อย่างมากของ Agile แต่นั่นหมายความว่าคุณต้องดูความละเอียดของแต่ละวันไม่ใช่ Task X ขนาดใหญ่ที่จะพร้อมเมื่อใดก็ตามที่พร้อม

เสร็จสิ้นพร้อมส่งแล้ว

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

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

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

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

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

นี่อาจเป็นความคิดเห็นที่ไม่เป็นที่นิยม แต่คุณอาจไม่สามารถทำอะไรกับมันได้

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

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