ข้อดีของการแย่งชิงกันสำหรับนักพัฒนาเอง? [ปิด]

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

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

แต่นักพัฒนาจะมั่นใจได้อย่างไรว่าจะยอมรับ Scrum? การแย่งชิงกันจะทำให้ชีวิตง่ายขึ้นได้อย่างไร

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

อย่างไรก็ตามมันจะนำมาซึ่งการมองเห็นมากมายเกี่ยวกับ procrastinators, นักพัฒนาที่ไม่ดี, นักปัจเจกชน, ... ในคำอื่น ๆ , นักพัฒนาที่ไม่ดี

การต่อสู้เป็นดาบสองคม

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

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

Stack Ranks / Backlog ป้องกันไม่ให้เหตุการณ์สำคัญเกิดขึ้น

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

การต่อสู้เพราะมันมี 'คุณสมบัติที่สำคัญ' สูงในรายการที่ค้างช่วยให้นักพัฒนาจัดการความตึงเครียดนี้ในเชิงรุกได้สองวิธี ก่อนอื่นคุณสามารถจัดอันดับ 'คุณสมบัติที่ชื่นชอบ' ไว้ใน backlog เพื่อให้เขา / เธอมีความสุขมากที่สุด ประการที่สองมันให้คำตอบที่ชัดเจนและเป็นรูปธรรมกับ "เนื่องจากเราย้าย 'วิดเจ็ตกะพริบ' ให้อยู่ในอันดับที่ 1 เป็นไปได้มากว่าเราจะไม่ได้ 'กระเด้งกระต่าย' ในการวิ่งนี้เนื่องจากตอนนี้อยู่ในอันดับที่ 7 คุณพอใจกับการแลกเปลี่ยนนี้ไหม? "

ฉันยังพบว่าด้วยการวิ่งสั้น ๆ 'ผู้ควบคุมภายนอก' จะไม่ค่อยพอใจกับการเลื่อนเวลาทำงาน หาก 'กระพริบวิดเจ็ต' ไม่ทำให้กลายเป็น 'เหตุการณ์สำคัญ 1' และ 'เหตุการณ์สำคัญ 2' ไม่สิ้นสุดจนถึง 9 เดือนนับจากนี้ผู้สนับสนุนของ 'วิดเจ็ตกะพริบ' จะไม่พอใจ แต่ถ้า 'กระพริบวิดเจ็ต' เป็นสแต็กอันดับ 7 แทน 1 เพราะมีสิ่งสำคัญมากกว่า 6 อย่างที่ต้องทำก่อนนั่นหมายความว่าเราน่าจะได้มันในการวิ่ง + 1 หรือที่วิ่งเร็ว + 2 ซึ่งหมายความว่า มันจะปรากฏขึ้น 12 หรือ 18 สัปดาห์นับจากนี้ (ใช้ sprints 6 สัปดาห์) จากประสบการณ์ของฉันการรอ 3 เดือนนั้น 'ยอมรับได้' สำหรับคนที่ใจร้อน - นอกจากนั้นกลับมาในรูปแบบ 'น้ำตก' ซึ่งเป็นเหตุการณ์สำคัญ 3 เดือนขึ้นไป

ในที่สุดถ้าเรามาถึงจุดสิ้นสุดของการวิ่งและสิ่งต่าง ๆ ใช้เวลานานกว่าที่คาดไว้มันเป็นเรื่องดีมากที่สามารถผลักดันสิ่งที่ค้าง 5-6-7 ไปยังการวิ่งครั้งต่อไปและตรวจสอบให้แน่ใจว่าเราได้ทำ 1-2-3 เสร็จแล้ว -4 ที่มีคุณภาพสูงและไม่ใช้เวลา 70 ชั่วโมงต่อสัปดาห์ ท้ายที่สุดเราจะต้องวิ่งไปอีก 5-6-7 ครั้ง อีกครั้งเนื่องจากกรอบเวลาสั้นลงที่เกี่ยวข้องในการเลื่อนเวลา 'ตัวควบคุมภายนอก' โดยทั่วไปจะรู้สึกสะดวกสบายมากขึ้นและไม่ยืนยันว่าเราส่งเหตุการณ์สำคัญออกมาสองสัปดาห์และสั่งอาหารเย็นในแต่ละคืน

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

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

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

สองสิ่ง:

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

• คะแนนเรื่องราว! นักพัฒนาซอฟต์แวร์คนใดไม่ชอบรับคะแนนสำหรับทำสิ่ง !! อย่างจริงจังจะดีกว่าการรับตราใน SC2 หรือ Stack Overflow

มีหลายสิ่งที่ฉันในฐานะนักพัฒนาชอบเกี่ยวกับการต่อสู้

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

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

มันเป็นการดีที่จะถอยกลับทุกๆสามถึงสี่สัปดาห์และสูดลมหายใจและอย่างน้อยก็เปลี่ยนจังหวะ

ทีมจัดระเบียบตนเองดูเหมือนจะให้ความหลากหลายในการทำงานมากขึ้น

ในทางทฤษฎีอย่างน้อยในระหว่างการวิ่งมีการขัดจังหวะน้อยลงและ 'กรณีฉุกเฉิน'

การประชุมประจำวันลุกขึ้นบังคับให้โปรแกรมเมอร์พูดหลาย ๆ คำทุกวัน

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

แผนภูมิที่ถูกเบิร์นลงเป็นวิธีที่มีประสิทธิภาพในการติดตามความคืบหน้า

ข้อได้เปรียบสำหรับนักพัฒนาคือข้อเสนอแนะก่อนหน้า (จากลูกค้าผู้ทดสอบเจ้าของผลิตภัณฑ์ ฯลฯ )

นอกจากนี้ในฐานะนักพัฒนาฉันสนใจที่จะทำสิ่งต่าง ๆ เป็นขั้นเป็นตอนโดยไม่รบกวน การต่อสู้ให้สิ่งนี้

PS: scrum ไม่ได้เป็นวิธีการที่เป็นกรอบ