Agile MVP (ผู้เล่น / โปรแกรมเมอร์ที่ให้คุณค่าสูงสุด)

เมื่อเร็ว ๆ นี้ฉันได้มีส่วนร่วมในโครงการเปรียว (โดยใช้การทะเลาะกัน) ซึ่งฝ่ายบริหารคิดว่าทีมจะเสนอชื่อผู้พัฒนา 'MVP' รวมถึง QA 'MVP' ในตอนท้ายของการวิ่งแต่ละครั้งโหวตโดย ทีม. จากนั้น MVP จะได้รับเงินจำนวนเล็กน้อยและอาหารกลางวันฟรีรวมถึงถ้วยรางวัลสำหรับแสดงบนโต๊ะทำงานของเขา เรามีการวิ่งสองครั้งด้วยระบบรางวัลนี้

สิ่งที่ฉันเห็นจากสิ่งนี้คือ:

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

ฉันสังเกตเห็นบางสิ่งที่ฉันจะพิจารณาด้านที่ไม่ดีในการทำสิ่งนี้ (อย่างน้อยจากมุมมองนักพัฒนา):

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

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

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

Agile เน้นความพยายามของทีมไม่ใช่ความพยายามของแต่ละคน ดังนั้นไม่วิธีนี้ชัดเจนไม่คล่องตัว

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

ฉันขอแนะนำให้ให้รางวัลแก่ทีมโดยรวมถ้าพวกเขาทำได้ดี

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

ตอนนี้อย่างน้อยสำหรับบางคนแรงจูงใจภายในหรือส่วนหนึ่งของมันถูกแทนที่ด้วยแรงจูงใจภายนอกที่ประกอบด้วยชื่อ ("MVP ประจำสัปดาห์") และรางวัล (จำนวนเงินและอาหารกลางวันฟรี) ซึ่งเป็นกลไกของเกมมักเป็นส่วนหนึ่ง ของกระบวนการ gamified

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

สิ่งที่คุณสามารถทำได้เพื่อแก้ไขปัญหานี้คือขอให้ฝ่ายจัดการเปลี่ยนกฎเล็กน้อย:

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

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

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

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

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

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

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

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

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

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

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

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

ฉันทำงานหลายอย่าง ประชุมเชิงปฏิบัติการในหัวข้อนี้และปัญหานี้เกิดขึ้นเป็นตัวอย่างในกลุ่มเป็นครั้งคราว การใช้ทฤษฎีความสามารถในการจ่ายกับกรณีที่คุณแบ่งปันในคำถามของคุณอาจมีลักษณะเช่นนี้ .....

สมมติว่าทีมของคุณเห็นคุณค่าของความสอดคล้องการคาดการณ์และรหัสคุณภาพสูง

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

แทนที่จะมี MVP เดียวโดยอิงจากการวัดข้อบกพร่องเราจะพยายามเปลี่ยนพฤติกรรมของทีมโดยทำการเปลี่ยนแปลงเล็กน้อย แต่มีความสำคัญ

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

และนี่เป็นเพียงตัวอย่างเพื่อแสดงให้เห็นถึงวิธีการและเริ่มต้น ...

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

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

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

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