ทำไมและด้วยเหตุผลอะไรนักพัฒนาอาจไม่ชอบ“ การต่อสู้รายวัน”? [ปิด]

มีข้อดีในการทะเลาะกันทุกวันเช่น:

1. ทีมได้ประสานงานกัน
2. ทุกคนรู้ว่างานที่ได้ทำไปมีจำนวนเท่าใด
3. แผนภูมิเบิร์นดาวน์เสร็จสมบูรณ์มากขึ้นเรื่อย ๆ
4. อัปเดตบอร์ดงานแล้ว
5. ไม่นานเท่าไหร่ 15 นาทีจะไม่ฆ่าใคร

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

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

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

การประชุม 15 นาทีอย่างรวดเร็วกลายเป็นการประชุม 45 นาทีการอัปเดตไม่ได้ผลเพราะผู้คนจะยุ่งกับการหาวและคิดว่า "เมื่อเราไปแล้ว" แทนที่จะฟังคนอื่นและมันก็จะทำลายกิจวัตรของผู้คนด้วยเช่นกัน คนที่เป็นนกฮูกและทำงานที่ 9AM สำหรับการประชุมที่โง่นี้ทุกวันเป็นเหตุผลที่ดีพอที่ฉันจะออกจากงาน)

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

ฉันแน่ใจว่าจะมีผู้ที่ชื่นชอบ SCRUM มากมายที่จะพูดว่า "แต่มันยอดเยี่ยมมาก" - เอาล่ะฉันได้ยินมาทั้งหมด

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

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

นี่เป็นเพียงส่วนหัวของฉัน แต่มีเหตุผลที่เป็นไปได้มากกว่าเสมอ

บางทีคุณควรถามนักพัฒนาตรงๆว่าทำไมพวกเขาถึงไม่สนใจ? หากคุณต้องการการสื่อสารที่มากขึ้น / ดีขึ้นควรเริ่มต้นด้วยตัวคุณเอง

ปัญหาที่พบในการประชุม SCRUM รายวัน:

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

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

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

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

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

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

ตรวจสอบให้แน่ใจว่าไม่มีใครผูกขาดการประชุม

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

ยืนสักครู่แล้วคิดเกี่ยวกับทีมของคุณ:

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

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

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

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

หากคุณต้องการอัพเดทบอร์ดและแผนภูมิบ่อยๆให้ใส่ร่างแบบร่างไว้บนวิกิ

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

ประสบการณ์ส่วนตัวของฉัน:

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

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

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

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

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

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

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

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

ฉันคิดว่าถ้าคุณมีการประชุมมากกว่าสี่ครั้งในระยะเวลา 8 ชั่วโมงโครงการจะไม่ได้รับการจัดการที่ดี

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

• โฟกัส - ซอฟต์แวร์กับการประชุม
• การจัดการ - ผู้จัดการต้องมีการวัด
• บุคลิกภาพ - Introverts กับ Extroverts
• เวลา - เวลาขัดจังหวะ, Maker และเวลาจัดการ
• เป้าหมายลำดับความสำคัญ

แต่ละปัจจัยเหล่านี้อธิบายไว้ด้านล่าง

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

นักพัฒนาจำเป็นต้องหลีกเลี่ยงการรบกวนและหลายคนพบว่ามีข้อได้เปรียบในการเขียนโค้ดในช่วงดึก (พวกเขาหลีกเลี่ยงเสียงโทรศัพท์การทำงานไม่ว่างและเพื่อนร่วมงานที่ไม่ใช่นักพัฒนาจะขัดขวางการทำงานของพวกเขา) และเมื่อคุณทำงานจนถึง 10, 11, หรือ 12.00 น. คุณไม่ควรมาทำงานในภายหลัง (10, 11, เที่ยง?) มีเหตุผลหรือไม่ที่จะคาดว่านักพัฒนาซอฟต์แวร์จะทำงานตั้งแต่ 9.00 น. จนถึงเที่ยงคืน?

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

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

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

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

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

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

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

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

ปรับเปลี่ยนการประชุมเพื่อให้แน่ใจว่าได้รับประโยชน์:

1. กำหนดเวลาที่สะดวก ทำไมไม่เป็นเวลา 30 นาทีหลังจากเริ่มทำงานเพื่อให้ทุกคนสามารถตรวจสอบอีเมลและจัดระเบียบความคิดสำหรับการพบปะ ความกะทัดรัดใช้เวลาวางแผน ผู้ที่ไม่เตรียมตัวสามารถเดินเล่นได้ตลอดไป
2. ระบุปัญหาที่สามารถหลีกเลี่ยงได้มีการสื่อสารปัญหาระหว่างการประชุม ทุกคนต้องเข้าใจว่าอะไรคือประเด็น
3. ทำทุกอย่างเพื่อให้ข้อมูลของทุกคนมีค่าน้อยที่สุด มันไม่ใช่สถานที่สำหรับการถกเถียง กระตุ้นให้คนกำหนดเวลาการประชุมส่วนตัวนอกการประชุมรายวันโดยเน้นหัวข้อที่ต้องมีการสนทนา กฎ: เพียงคนเดียวที่พูดในเวลา

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