เมื่อผู้จัดการของฉันบอกกับทีมว่า " ตอนนี้เป็นต้นไปเรื่องราวของผู้ใช้ที่ประสบความสำเร็จจะได้รับการพิจารณาเพื่อการประเมิน! "
เรานั่งที่นั่นในขณะที่ตกใจและนั่นเป็นหนึ่งในหลาย ๆ ช่วงเวลาที่ขากรรไกรหล่นเขา :-)
เรารู้สึกว่าเป็นความคิดที่โง่เพราะจะทำลายแนวคิดและเป้าหมายทั้งหมดของวิธีการพัฒนาแบบว่องไว
บอกให้ฉันรู้ว่าคุณคิดอย่างไร และเราจะโน้มน้าวเขาได้อย่างไร?
คำตอบ:
แซนดี้ขออภัยคำสั่งผู้จัดการของคุณเป็นความเข้าใจผิดคลาสสิกของการต่อสู้โดยเฉพาะอย่างยิ่งและคล่องตัวโดยทั่วไป
วิธีการเสนอฆ่าการทำงานร่วมกันและเคาน์เตอร์หลักการของความเป็นเจ้าของรหัสส่วนรวม เรื่องราวของผู้ใช้ในแบบเปรียว (ถ้าเป็นแบบเปรียวจริง) ไม่ค่อยจะเสร็จสมบูรณ์ก่อนที่จะถูกคนหลายคนแตะต้อง นอกจากนี้คุณจะมีเรื่องราวของผู้ใช้เป็นครั้งคราวที่ต้องการการปีนป่ายเพื่อที่จะเสร็จสิ้นภายในการทำซ้ำ คุณจะได้รับอย่างไรเมื่อแรงจูงใจของแต่ละคนอยู่ในแนวตรง 180 องศาในทิศทางตรงกันข้าม
สัญชาตญาณของทีมคุณถูกต้อง ฉันจะแนะนำแหล่งข้อมูลใดในระยะสั้นเพื่อให้คุณอ่านในขณะที่คุณระดมสมองการตอบสนองต่อผู้จัดการของคุณ ดูบล็อกของผู้เชี่ยวชาญที่มีชื่อเสียงเปรียวเช่นMike Cohn , Martin Fowler , Elizabeth Hendrickson , Jurgen Appelo , Esther Derbyและคนอื่น ๆ อีกหลายคนและมองหาบทความเกี่ยวกับการจัดทีมองค์กรแบบคล่องตัว
ข้อโต้แย้งหลักของฉันต่อวิธีการประเมินนี้คือมันอาจเป็นอุปสรรคต่อความร่วมมือระหว่างผู้พัฒนา ฉันคิดว่าส่วนสำคัญของผลผลิตของทีมพัฒนาคือความเต็มใจของสมาชิกในทีมที่จะช่วยเหลือซึ่งกันและกัน เมื่อฉันเข้าใจรูปแบบที่แนะนำมันอาจนำไปสู่การพัฒนาที่ยึดติดกับงานที่ได้รับมอบหมายของพวกเขาและไม่สนใจสมาชิกในทีมคนอื่น ๆ ที่ติดอยู่และอาจจะติดขัดได้ง่ายๆด้วยความช่วยเหลือเล็กน้อย
เรามักจะมองหาผลงานที่โปรแกรมเมอร์ทำกับทีมและธุรกิจ
สิ่งนี้อยู่ในระดับที่เทียบเท่ากับการวัดเส้นโค้ดหรือจำนวนข้อบกพร่อง - แต่มีความซับซ้อนกว่าเล็กน้อย
เมื่อดูอย่างรวดเร็วไม่มีอะไรผิดปกติกับการวัด แต่เมื่อคุณคิดถึงมันคุณจะเริ่มคัดค้าน:
เป็นสิ่งที่ชัดเจนที่สุดที่เกิดขึ้นในใจ - ฉันแน่ใจว่ามีคนอื่น
ผู้จัดการของคุณคิดว่านี่เป็นความคิดที่ดีอย่างเห็นได้ชัดดังนั้นคุณต้องระวังว่าเมื่อคุณคัดค้านคุณยังสามารถนำเสนอโซลูชั่น วิธีนี้อาจจะต้องมีการปรับเปลี่ยนรูปแบบของเขามากกว่ารูปแบบใหม่
ตัวอย่างเช่นคุณอาจต้องการชี้ให้เห็นว่าคนที่ทำงานในเรื่อง "ง่าย" จะเสร็จสมบูรณ์มากกว่าคนที่ทำงานใน "ยาก" มากกว่าและสิ่งนี้อาจนำไปสู่การมุ่งเน้นในด้านที่สำคัญน้อยกว่าของการพัฒนา ดังนั้นทางออกหนึ่งอาจจะพิจารณาจากจำนวนเรื่องราวมากกว่าแค่จำนวนเรื่อง
ฉันเห็นด้วยกับ ChrisF ว่าสิ่งนี้กลับไปเป็นปัญหาเดียวกันกับการวัดใด ๆ สิ่งที่คุณสรรเสริญคือสิ่งที่คุณได้รับ จะมีคนที่เล่นเกมเป็นระบบเสมอไม่ว่าระบบนั้นจะเป็นอะไร
วิธีการที่มีประสิทธิภาพจริงอย่างเดียวที่ฉันพบสำหรับการให้รางวัลแก่โปรแกรมเมอร์นั้นมาด้วยสามขั้นตอน
คีย์ทั้งหมดคือโปรแกรมเมอร์ไม่ได้ฟันเฟืองในเครื่องที่สามารถ 'ปรับ' โดยดูที่สถิติ คนที่แท้จริงต้องได้รับการตรวจสอบและปรับปรุงโดยรวมและทีมจะต้องสามารถพึ่งพาซึ่งกันและกันในความร่วมมือไม่ใช่การแข่งขัน
นักแสดงที่ไม่ดีในทีมจะได้รับโอกาสในการพัฒนาและเพิ่มพูนทุกครั้งก่อนที่พวกเขาจะถูกปล่อยตัว ในที่สุดโปรแกรมเมอร์ที่ดีจะเจริญเติบโตในสภาพแวดล้อมนี้และโปรแกรมเมอร์ที่ยากจนซึ่งปฏิเสธที่จะปรับปรุงจะถูกปล่อยให้ไป
ส่วนใหญ่เรื่องราวของผู้ใช้จะเสร็จสิ้นในความพยายามร่วมกัน สิ่งนี้ทำให้แทบเป็นไปไม่ได้เลยที่จะประเมินการประเมินของแต่ละคนในเมตริกนี้
ตัวชี้วัดนั้นสามารถจัดการได้ง่ายเนื่องจากกระบวนการวางแผนเป็นความพยายามของทีมและยิ่งเร็วกว่านั้นระบบทั้งหมดก็จะถูกควบคุม นั่นคือสิ่งที่คุณไม่ต้องการในกระบวนการที่คนให้ความสนใจ
ฉันคิดว่าผลงานที่ดีต้องได้รับการยอมรับจากระบบโบนัสบางอย่างจากความสำเร็จของทีม แต่เรื่องราวของผู้ใช้ไม่ใช่ตัวบ่งชี้ความสำเร็จที่ดี