ฉันคิดว่าคนอื่นให้คำตอบที่ดี แต่ฉันจะเพิ่มของฉันเท่านั้นเพราะฉันคิดว่าทีมของคุณเพิ่งจะเปลี่ยนเป็น Scrum และตอนนี้พวกคุณอยู่ในตำแหน่งที่คล้ายกันมากเมื่อเราเริ่ม
ก่อนอื่นการแนะนำของเราเกี่ยวกับ Agile และการแย่งชิงกันโดยเฉพาะนั้นไม่ราบรื่นนัก โดยทั่วไปการจัดการลงมาและกล่าวว่าตั้งแต่วันนี้ไปคุณจะต้องต่อสู้และนี่คือกระบวนการที่คุณจะทำตาม มากสำหรับผู้ที่มีอายุมากกว่ากระบวนการ
กระบวนการที่เราติดตามมาในตอนแรก (สุ่มสี่สุ่มห้าฉันอาจเพิ่ม) สิ้นสุดลงคล้ายกับวิธีที่คุณอธิบาย ผู้คนได้รับมอบหมายงานทุกคนได้รับการจองและเราทุกคนกลับไปที่โต๊ะทำงานและเสียบปลั๊ก จากนั้นเรามีการประชุมที่น่าเบื่อทุกวัน
กุญแจสำคัญในการตระหนักคือ Agile และ Scrum ที่รวมอยู่นั้นเป็นเรื่องเกี่ยวกับผู้คน เมื่อทีมเข้าสู่การวางแผนการทำซ้ำอย่าให้นายการต่อสู้ของคุณ (ซึ่งอาจเป็นผู้จัดการของคุณ) มอบหมายชั่วโมงการเล่าเรื่องและงานให้คุณ มันขึ้นอยู่กับทีมอย่างสมบูรณ์ ฉันคิดว่าสำหรับผู้คนจำนวนมากนี่เป็นแนวคิดที่ยากมากที่จะผ่านเพราะหลายปีก่อนที่พวกเขาจะมาทำงานและพวกเขาจะมีหัวหน้า (ผู้จัดการฝ่ายนำด้านเทคนิค ... ) ที่จะมอบหมายงาน พวกเขาดำดิ่งเข้าสู่ Scrum แต่ทุกคน (รวมถึงอาจารย์ต่อสู้ด้วยตัวเอง) ยังคงทำงานในโหมดเดียวกัน
อยู่มาวันหนึ่งคุณจะเบื่อกับสิ่งนี้ดังนั้นคุณจะเริ่มอ่านหนังสือบล็อกและถามคำถามเช่นนี้ในการแลกเปลี่ยนกองซ้อน การตระหนักว่าคุณจะได้รับคือคุณในฐานะนักพัฒนาและเพื่อนร่วมทีมของคุณควรเป็นแรงผลักดันที่อยู่เบื้องหลังการยอมรับเรื่องราวและการมอบหมายงาน หากพวกคุณรู้สึกว่าคุณจะได้รับประโยชน์จากการเขียนโปรแกรมคู่โดยทั้งหมดสร้างงาน 2 อย่างสำหรับวิศวกรแต่ละคนและกำหนดเวลาทำงานให้ทั้งคู่ สิ่งเดียวที่ควรทำเช่นนี้คือการวัดความเร็วกับเรื่องราวที่เสร็จสมบูรณ์ที่คุณได้มอบให้กับทีมในการทำซ้ำครั้งก่อน
อีกสิ่งหนึ่งที่ดักอึออกจากฉันก็คือคนบอกว่ากำลังการผลิตของพวกเขาอยู่เสมอ 75% ของเวลาทั้งหมดดังนั้นนั่นคือสิ่งที่พวกเขากระทำและตลอดระยะเวลาการทำซ้ำพวกเขาบ่นว่า a) พวกเขาไม่สามารถ ช่วยคุณหรือข) พวกเขาทำสิ่งที่ไม่ถูกต้องเพราะพวกเขาได้รับมอบหมายหลายชั่วโมงเกินไป ผู้คนไม่ควรได้รับการบอกกล่าวว่าต้องใช้เวลากี่ชั่วโมงและแน่นอนว่าพวกเขาควรจะถอยกลับหากอาจารย์ต่อสู้พยายามดึงอะไรทำนองนี้! ทุกคนควรทำตามสิ่งที่พวกเขาพอใจ ตัวอย่างเช่นฉันเป็นหัวหน้าทีมและบ่อยครั้งที่ฉันต้องลงเอยด้วยการพูดคุยเกี่ยวกับการออกแบบแบบสุ่มโดยไม่ได้วางแผนหรือช่วยเหลือใครบางคนเกี่ยวกับรหัสหรือแก้ไขปัญหาแปลก ๆ ดังนั้นความสามารถของฉันจึงไม่เกิน 50%
ทีมของเราใช้เวลา 4 รอบในการเรียนรู้ที่จะไม่ทำในสิ่งที่ฉันเพิ่งพูดถึงและแม้ว่าเราจะพัฒนาขึ้นอย่างแน่นอนถ้าคุณถามผู้เชี่ยวชาญว่าเราไม่ว่องไวแม้แต่น้อย ยังคงมีการเรียนรู้ให้ทำมากมาย
อัปเดต 1: ตอบกลับความคิดเห็นของคลิฟ
ดีคุณเสนอหูของคุณดังนั้นที่นี่มันเป็น ...
คุณพูดถูกวัฒนธรรมเป็นกุญแจสำคัญ แต่การเปลี่ยนแปลงนี้ไม่จำเป็นต้องเกิดขึ้นในระดับผู้บริหาร ผู้จัดการกลุ่มของคุณเองสามารถเปลี่ยนวัฒนธรรมภายในทีมของคุณและแยกพวกคุณออกจาก บริษัท BS ที่เขาต้องรับมือด้วย สิ่งที่คุณกำลังอธิบายคือเราเกี่ยวกับจาก 2007 ถึง 2010 ทีมของเรา (และทีมอื่น ๆ เช่นกัน) flopped release หลังจากปล่อย ในหนึ่งในการเผยแพร่โดยใช้ "กระบวนการของการเป็นว่องไว" ของผู้บริหารเราจัดการให้มี 9 คนที่ผลิตงานที่มักจะทำโดยคนเดียวและใช้เวลาเป็นสองเท่า ฉันมีเวลาว่างมากจนฉันได้อัปเดตประวัติการทำงานของฉัน
จากนั้นฉันได้พูดคุยกับหัวหน้าของฉันและอธิบายสิ่งเหล่านี้ให้เขาฟังว่าผู้คนมีความคล่องตัวอย่างไรและถ้าคุณต้องการให้เราใส่ใจเกี่ยวกับผลิตภัณฑ์ให้เราตัดสินใจที่ส่งผลต่อวิธีการที่เราทำงานและส่งมอบผลิตภัณฑ์ ฉันคิดว่าเขาตัดสินใจที่จะทำการทดลองจากมันเขาทำการเปลี่ยนแปลงทุกอย่างที่เรา ... ดีส่วนใหญ่ตัวเอง แต่ฉันพูดคุยกับทีมที่เหลือเป็นจำนวนมากดังนั้นความจุ 50% :) ... เสนอ เป็นไปได้ว่าเขาคิดว่าถ้าเขาทำการเปลี่ยนแปลงทั้งหมดที่เราร้องขอและเรายังล้มเหลวเขาจะกลับมาพร้อมกับชัยชนะ "ฉันบอกคุณแล้ว"
ดังนั้นในช่วง 12 เดือนที่ผ่านมาเราได้กำจัด "โง่" มากมันไม่ตลกเลย ตอนนี้การประชุมสแตนด์อัพของเราสมเหตุสมผลแล้วเพราะเราทำงานร่วมกันไม่ใช่แยกออกจากกัน เรายังมีความเป็นเจ้าของ (อย่างน้อยตอนนี้) ของส่วนที่เฉพาะเจาะจงของผลิตภัณฑ์ แต่เราก็ยังข้ามบ่อยมากในรหัสของกันและกัน เราทำการทบทวนโค้ดอย่างต่อเนื่องเพื่อไม่เพียง แต่สมาชิกในทีมจะได้เรียนรู้รหัสอื่น ๆ แต่พวกเขายังเรียนรู้เทคนิคการเขียนโค้ดและการออกแบบที่ดีขึ้น เราแบ่งทีม "agile" เสาหินยักษ์ออกเป็น 3 ทีมเพื่อให้การวางแผนและการประชุมอื่น ๆ สั้นลงมากและผู้คนสนใจพวกเขาจริง ๆ เพราะพวกเขาไม่ได้นั่งฟังสิ่งที่พวกเขาไม่สนใจ ผม' เคยเห็นเมื่อ 4 ใน 5 ของพวกเรา (หนึ่งในทีม) จะออนไลน์เวลา 23.00 น. ในตอนกลางคืนและไม่มีใครบอกเราว่าเราต้องทำงานหนักหรือกดดันให้เราทำงานมากกว่า 40 ชั่วโมง ผู้ที่ไม่สามารถดูแลน้อยกว่าครึ่งปีที่แล้วทันใดนั้นทั้งหมดก็มีส่วนร่วมและตื่นเต้นเกี่ยวกับงานที่พวกเขาทำ และสิ่งที่ต้องทำก็แค่ให้ผู้จัดการของเราทำก็คือพูดว่า "พวกคุณตัดสินใจในสิ่งที่ถูกต้องและทำสิ่งที่คุณต้องทำและฉันจะทำให้ บริษัท BS ออกจากทีมให้มากที่สุดเท่าที่จะทำได้"
มันเริ่มต้นจากการทดลอง (ความสงสัยของฉันเขาไม่เคยบอกฉันว่า) แต่ตอนนี้กลุ่มของเราเตะก้นเมื่อเปรียบเทียบกับกลุ่มพัฒนาอื่น ๆ ในแผนกและเรายังมีนักพัฒนาคนอื่น ๆ ที่พยายามเข้ามาร่วม
อุปสรรค์ที่ยิ่งใหญ่ที่สุดสำหรับเรานับตั้งแต่การเปลี่ยนแปลงนี้เกิดขึ้น (และยังคงเป็นปัญหาในปัจจุบัน) คือความจริงที่ว่าวิศวกรในสภาพแวดล้อมขององค์กรปกติเป็นเหมือนหนูทดลองในกรง แม้ว่าผู้จัดการของคุณตัดสินใจที่จะ "คล่องแคล่ว" อย่างแท้จริงและกำจัดกรง แต่ทุกคนอยู่ในกรงนานมากพวกเขาไม่ได้ตระหนักว่าพวกเขาเป็นอิสระ ดังนั้นแม้จะมีอิสรภาพทั้งหมดพวกเขายังคงทำตัวราวกับว่าพวกเขายังถูก จำกัด ฉันคิดว่าสิ่งที่จะช่วยได้คือมีอย่างน้อยคนในทีม (เช่นตัวคุณเอง) ที่ออกไปนอกขอบเขตของกลุ่มและค้นหาวิธีที่ดีกว่าในการทำสิ่งต่าง ๆ จากนั้นกลับเข้ามาในกลุ่มนั้นและคนให้เข้ากัน
ในกรณีของคุณการเขียนโปรแกรมแบบจับคู่อาจไม่ใช่วิธีแก้ปัญหาหากคุณกำลังมองหาแรงภายนอกที่จะมาลงทีมและบอกพวกเขาถึงวิธีการทำงาน ให้โยนกฎออกไปนั่งกับพวกเขาโดยไม่มีการจัดการและถามพวกเขาว่าพวกเขาต้องการทำอะไร? อะไรจะทำให้พวกเขามีความสุข ผลผลิต? ระบุปัญหาที่ใหญ่ที่สุดแล้วถามทีมว่าพวกเขาคิดว่าวิธีแก้ปัญหาควรเป็นอย่างไร