เป็นที่ยอมรับหรือไม่ที่จะมีการอภิปรายที่ไม่เกี่ยวข้องกับการเช็คอินในการประชุม Scrum Daily Standup?

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

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

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

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

จุดประสงค์ของ Daily Scrum คือเพื่อให้ทีมพัฒนาทำการตรวจสอบ 24 ชั่วโมงที่ผ่านมาและอัพเดตแผนของพวกเขาใน 24 ชั่วโมงข้างหน้า

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

สิ่งที่การต่อสู้ในชีวิตประจำวันไม่ได้มีไว้สำหรับหาวิธีแก้ไขปัญหา ทำอย่างนั้นหลังจาก ...

แน่นอนว่ามันเป็นที่ยอมรับ แต่ให้ความสำคัญกับสิ่งสำคัญก่อน ถ้าเรามีเวลาเหลือใน 15 นาทีซึ่งเป็นเรื่องธรรมดาสำหรับทีมพัฒนา 5 คนที่รุม (เพราะพวกเขาซิงค์บ่อยในระหว่างการพัฒนา) ฉันไม่มีปัญหากับการสื่อสารและประกาศพิเศษ ตราบใดที่เราเลื่อนพวกเขาไปจนถึงวันสิ้นสุด

ในฐานะอาจารย์การต่อสู้ฉันแน่ใจว่าทีมตอบคำถามสำคัญสามข้อ

The Daily Scrum เป็นเหตุการณ์ในกล่องเวลา 15 นาทีสำหรับทีมพัฒนาเพื่อซิงโครไนซ์กิจกรรมและสร้างแผนสำหรับ 24 ชั่วโมงข้างหน้า

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

ทีมพัฒนาหรือสมาชิกในทีมมักจะพบกันทันทีหลังจาก Daily Scrum สำหรับการสนทนาโดยละเอียดหรือเพื่อปรับหรือดัดแปลงงานส่วนที่เหลือของ Sprint

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

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

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

ขั้นตอนนี้อาจเข้มงวดหรือรวมประเด็นทางสังคมด้วยทั้งนี้ขึ้นอยู่กับวัฒนธรรม มันไม่ควรจะเป็นเหตุการณ์ที่ไม่คาดคิดซึ่งจะถูกมองว่าเป็น "ซอมบี้ต่อสู้"

บ่อยครั้งที่มีการแบ่งแยกขั้วระหว่างสิ่งที่ผู้คนมากมายยืนยันอย่างแย่งชิงกันคือ Scrum และแนวคิดของผู้คนเกี่ยวกับกระบวนการ

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

ไม่ว่าจะด้วยวิธีใดฉันจะโน้มน้าวให้ได้ในตอนท้ายหลังจากกระบวนการขั้นตอนปกติเสร็จสิ้น

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

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

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

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

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

กฎของหัวแม่มือฉันได้ติดอยู่กับและเจาะลึกในระหว่างโครงการกับเพื่อนและ honed ในการตั้งค่ามืออาชีพ:

• เมื่อวาน

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

• ในวันนี้

ดังกล่าวข้างต้น แต่วันนี้

• บล็อค

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

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

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

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

หลีกเลี่ยงสิ่งต่อไปนี้:

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

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

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