ทีมล้มเหลวในการบรรลุเป้าหมายการวิ่งอย่างต่อเนื่อง

เราเป็น บริษัท ซอฟต์แวร์ขนาดเล็กที่มีหนึ่งผลิตภัณฑ์

เราใช้การต่อสู้และนักพัฒนาของเราเลือกคุณลักษณะที่ต้องการรวมไว้ในการวิ่งแต่ละครั้ง น่าเสียดายในช่วง 18 เดือนที่ผ่านมาทีมไม่เคยส่งมอบฟีเจอร์ที่พวกเขามุ่งมั่นในการวิ่งครั้งเดียว

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

คำถามของฉันเป็นพื้น:

เมื่อใดที่ควรพิจารณาปัญหาเกี่ยวกับคุณภาพของนักพัฒนา

ฉันเริ่มคิดว่าถ้าคุณเลือกงาน / คุณสมบัติของคุณเองและยังคงล้มเหลวในการวิ่งแต่ละครั้ง: - คุณไม่สามารถดูแลความซับซ้อนของรหัสของคุณเอง - หรือรหัสนั้นซับซ้อนจนไม่มีใครควบคุมความซับซ้อนได้

ฉันพลาดอะไรไปรึเปล่า?

ก่อนอื่นคุณควรถามว่า 'ใครสนใจ'

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

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

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

ฉันพลาดอะไรไปรึเปล่า?

ใช่!

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

คุณจะหายไปที่ บริษัท ของคุณไร้ความสามารถอย่างแพร่หลาย

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

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

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

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

สรุป Kanban คืออะไร

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

SCRUM และ Kanban เหมือนกันอย่างไร

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

ดูรายละเอียดที่เหลือจากลิงค์นี้

คำถามของฉันเป็นพื้น: เมื่อมันยุติธรรมที่จะมองปัญหาในคุณภาพของนักพัฒนา

โพสต์ของคุณมีข้อมูลไม่เพียงพอที่จะตอบคำถามนี้ ไม่มีทางที่จะรู้ว่าพวกเขาล้มเหลวเพราะพวกเขาไร้ความสามารถหรือล้มเหลวเพราะพวกเขามุ่งมั่นที่จะทำงานมากกว่าที่สมเหตุสมผล

ถ้าฉันเป็นนักพัฒนาที่มีพรสวรรค์อย่างไม่น่าเชื่อในทีมนักพัฒนาที่มีพรสวรรค์อย่างไม่น่าเชื่อและเราล้มเหลวในการจบเรื่อง X ในการวิ่งสองครั้ง (หรือ 36!) เราจะไร้ความสามารถหรือไม่? หรือเราแค่ประมาณค่าดูด? ขึ้นอยู่กับว่าเรื่องราวนั้นเป็น "สร้างหน้าจอเข้าสู่ระบบ" หรือ "ส่งคนไปยังดาวอังคารอย่างปลอดภัย"

ปัญหาเริ่มต้นด้วยเรื่องราวที่ไม่ดีและ / หรือการประมาณการที่ไม่ดี

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

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

ปัญหานี้เกิดจากการปรับย้อนหลังที่ไม่ดี

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

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

การแก้ปัญหาไม่ได้เป็นการตำหนิ แต่เป็นการเรียนรู้

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

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

การปรับปรุงอย่างต่อเนื่องเป็นวิธีแก้ปัญหา

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

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

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

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

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

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

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

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

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

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

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

"ซอฟต์แวร์ทำเมื่อเสร็จแล้วไม่ช้าก็เร็ว"

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

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

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

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

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

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

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

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

บางครั้งโครงการล้มเหลวก่อนที่นักพัฒนาซอฟต์แวร์จะเขียนรหัสเพราะบางคนทำงานไม่ถูกต้อง

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

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

ดังนั้นหากนักพัฒนามีส่วนร่วมในการจับความต้องการ:

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

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

• ข้อกำหนดที่ไม่สมบูรณ์และคลุมเครือ
• ความต้องการ / งานที่ใหญ่เกินไปในตอนแรก
• การสื่อสารที่ไม่ดีระหว่างทีมพัฒนาและผู้บริหารระดับสูง
• การขาดเกณฑ์การยอมรับที่กำหนดไว้อย่างชัดเจนก่อนส่งงานให้ทีม
• สเปคที่ไม่สมบูรณ์หรือคลุมเครือของการทดสอบการยอมรับ (เช่นนิยามของเสร็จสิ้น)
• เวลาไม่เพียงพอที่จัดสรรให้กับการกำหนด / ยอมรับเกณฑ์การยอมรับ
• นักพัฒนาไม่ได้พิจารณาเวลาในการทดสอบรหัสพื้นฐานที่มีอยู่หรือแก้ไขข้อบกพร่องที่มีอยู่
• นักพัฒนาทำการทดสอบรหัสพื้นฐานที่มีอยู่ แต่ไม่ได้เพิ่มข้อผิดพลาดเป็นปัญหาการบล็อกก่อนที่จะให้ประมาณการเกี่ยวกับข้อกำหนด
• ฝ่ายบริหารเห็นปัญหา / ข้อบกพร่องและตัดสินใจว่าไม่จำเป็นต้องแก้ไขข้อบกพร่องก่อนที่จะเขียนรหัสใหม่
• นักพัฒนาอยู่ภายใต้ความกดดันที่จะคิดเป็น 100% ของเวลาแม้ว่าอาจจะ 20% (หรือบางหมายเลขที่คล้ายกัน) ของเวลาของพวกเขาอาจจะเกิดขึ้นจากการประชุมการรบกวนอีเมล ฯลฯ
• การประมาณการจะได้รับการเห็นด้วยกับมูลค่าและไม่มีใครปรับพื้นที่สำหรับข้อผิดพลาดหรือความไม่แน่นอน (เช่น "เราตัดสินใจว่าจะใช้เวลา 5 วันดังนั้นเราจึงคาดว่าจะเสร็จใน 8")
• การประมาณการจะได้รับการปฏิบัติโดยทุกคน (นักพัฒนาและการจัดการ) เป็นตัวเลขเดียวแทนที่จะเป็นตัวเลข "ช่วง" ที่เหมือนจริง - เช่น
  • ประมาณการกรณีที่ดีที่สุด
  • การประเมินที่สมจริง
  • การประเมินกรณีที่แย่ที่สุด

... รายการอาจยาวกว่านั้นอีกมาก

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

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

ฉันเห็นด้วยกับโปสเตอร์อื่น ๆ ทั้งทีมไร้ความสามารถหรือพวกเขากำลังพยายามทำสิ่งต่างๆมากเกินไป

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

คุณควรรวบรวมข้อมูลและสร้างระดับความมั่นใจโดยอ้างอิงจากประสิทธิภาพที่ผ่านมา

http://www.leadingagile.com/2013/07/agile-health-metrics-for-predictability/

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

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

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

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

4. แก้ไขปัญหา (วิเคราะห์ข้อเสนอแนะและปรับ)

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

5. กลับไปที่ขั้นตอนที่หนึ่งและทำซ้ำจนกว่าจะปล่อย ...

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

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

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

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

การประมาณความพยายามและเวลาที่ใช้ในการทำงานที่ซับซ้อนเช่นรหัสการเขียนโปรแกรมทำได้ยาก ดังที่Joel Spolskyกล่าวไว้:

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

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

การต่อสู้ทำบางสิ่งบางอย่าง

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

ประการที่สองมันสร้างผลิตภัณฑ์ที่ใช้งานได้ค่อนข้างแม้ว่าจะไม่ใช่ทุกอย่างเสร็จสิ้น นั่นคือจุดที่มี "ผลิตภัณฑ์ที่สามารถจัดส่งได้" ในตอนท้ายของการทำซ้ำแต่ละครั้ง

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

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

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

นี่เป็นวิธีที่มีประโยชน์ในการใช้รูปแบบการต่อสู้แบบ มันทำงานต่อเนื่องและวางแผนอย่างใกล้ชิดกับการผลิตให้ข้อเสนอแนะบางลูป ฯลฯ มันยังมีข้อได้เปรียบที่ไม่ได้พัฒนาวิปริตและการทดสอบเพื่อให้ตรงกับระบบ (ถ้าการทดสอบทำได้ดีที่สุดกับงานเสร็จแล้วโดยทั่วไป พยายามทำให้เสร็จและทดสอบภายใน sprint เดียวกันบังคับให้ back-end ของ sprint ไม่เกี่ยวข้องกับการพัฒนาใหม่!)

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

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

กระบวนการนี้มีอยู่ภายใต้เป้าหมายของสิ่งที่ทำสำเร็จ

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

"ซอฟต์แวร์ทำเมื่อเสร็จแล้วไม่ช้าไม่ช้า" เป็นสูตรสำหรับความล้มเหลวหากคุณไม่ได้กำหนดว่า "เสร็จแล้ว" จะเป็นอย่างไร

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

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

อ้อและใช่เราใช้การหวนกลับ

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

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

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

เมื่อใดที่ควรพิจารณาปัญหาเกี่ยวกับคุณภาพของนักพัฒนา

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

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

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

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

"เมื่อไหร่ที่จะต้องพิจารณาคุณภาพของนักพัฒนา"

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

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

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

มันอาจจะทำให้พวกดัดเพิ่มขึ้นเล็กน้อย

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

ถ้ามันเป็นสิ่งระยะยาวมันจะบังคับให้คุณหาปริมาณและวางมันลงในการวิ่งเป็นข้อกำหนด!

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

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

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

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

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