Agile MVP (Trình phát / Lập trình viên có giá trị nhất)

Gần đây tôi đã tham gia vào một dự án nhanh nhẹn (sử dụng scrum) nơi ban lãnh đạo đưa ra ý tưởng rằng nhóm sẽ đề cử một nhà phát triển 'MVP' cũng như QA 'MVP' vào cuối mỗi lần chạy nước rút, được bình chọn bởi đội. MVP sau đó nhận được một phần thưởng tiền nhỏ và bữa trưa miễn phí cũng như một chiếc cúp để trưng bày trên bàn của anh ấy. Chúng tôi đã có hai lần chạy nước rút cho đến nay với hệ thống phần thưởng này được đưa ra.

Cái tốt tôi thấy từ đây là:

• Nhiều lỗi đã được sửa (đó là những gì quản lý cấp trên muốn thấy, một số thay đổi theo hướng họ muốn)
• MVP từ mỗi 'đội' được công nhận và được tăng cường lòng tự trọng (hay đó là một sự tăng cường bản ngã?)

Tôi đã nhận thấy một vài điều mà tôi sẽ xem xét các mặt xấu để làm một việc như vậy (ít nhất là từ quan điểm của nhà phát triển):

• Có một vài nhà phát triển rất quan tâm đến con số mà chất lượng sửa lỗi đã giảm. Sửa lỗi trong một khu vực đang gây ra hồi quy trong một khu vực khác.
• Có một vài nhà phát triển đang chọn những lỗi "dễ dàng hơn / nhanh hơn" để tăng số lượng lỗi của họ. Có thể là tốt xấu ở đây tôi đoán.
• Ưu tiên cao hơn (mà rất nhiều thời gian tương quan với 'khó hơn / lâu hơn để sửa chữa') thực sự trở thành ưu tiên thấp hơn.
• Các khuyết tật chặn không được xử lý kịp thời, vì thông thường chúng sẽ mất nhiều thời gian hơn và đòi hỏi sự phối hợp nhiều hơn với QA.
• Các khía cạnh nhóm trong nhóm Dev đã bị mất. Khía cạnh nhóm của Dev và QA làm việc cùng nhau khi một người không được cải thiện, nhưng thực sự không thay đổi quá nhiều so với trước đây.
• Làm việc ngoài các sửa lỗi, hoặc làm việc theo số THAT, không dễ nhận biết / theo dõi.

Tôi tin rằng mỗi "cái xấu" ở trên có thể được giải quyết ở một mức độ nào đó, tùy thuộc vào cách nhóm xử lý từng cái.

Câu hỏi của tôi là, sau đó, có ai đã loại bỏ thành công bất cứ thứ gì như thế này không, nơi bạn nhận ra MVP mỗi lần chạy nước rút? Nếu vậy, bạn nghĩ gì đã đóng góp cho thành công đó?

Agile nhấn mạnh nỗ lực của nhóm , không phải nỗ lực của các cá nhân. Vì vậy, không, cách tiếp cận này rõ ràng là không nhanh nhẹn.

Thay vì khuyến khích sự hợp tác của nhóm, điều này khuyến khích mỗi thành viên trong nhóm tập trung vào kết quả của chính mình. Nó thậm chí có thể dẫn đến các thành viên tránh giúp đỡ lẫn nhau (hoặc tệ hơn), về lâu dài sẽ ngăn đội trở nên tốt hơn.

Tôi đề nghị thưởng cho toàn đội nếu họ làm tốt công việc.

Tôi nghĩ rằng đó là một ví dụ tốt về -bad- trò chơi điện tử ứng dụng hóa được áp dụng. Vấn đề là các lập trình viên của bạn có khả năng có động lực nội tại trong việc giải quyết vấn đề và chiến thắng mặc dù thử thách (tìm và sửa các lỗi khó) VÀ, vì bạn đã triển khai Scrum, khi làm TEAM. Nói cách khác, họ có khả năng muốn làm một công việc tốt.

Bây giờ, ít nhất là đối với một số người trong số họ, động lực nội tại này hoặc một phần của nó đã được thay thế bằng động lực bên ngoài bao gồm các tiêu đề ("MVP của tuần") và phần thưởng (số tiền và bữa trưa miễn phí), là cơ chế trò chơi thường là một phần của một quá trình được ứng dụng.

Gamification có thể được áp dụng thành công trong công việc nhưng bạn phải rất cẩn thận trong việc tận dụng động lực bên trong / bên ngoài. Động lực bên ngoài phải tạo sức mạnh để thúc đẩy sự tự quyết để động lực trở thành nội tại. Tuy nhiên, điều xảy ra ở đây là điều ngược lại, các lập trình viên đang "chơi trò chơi" để giành chiến thắng .

Những gì bạn có thể làm để khắc phục điều này là yêu cầu ban quản lý thay đổi các quy tắc một chút:

• cho điểm phù hợp với độ khó và mức độ ưu tiên của vé. Làm cho nó trở nên thú vị hơn, thông minh hơn, để sửa một lỗi khó tìm / tái tạo.
• cho điểm để giải quyết vấn đề hợp tác (một lần nữa, NHÓM). Đây là nơi bạn có thể khiến nhiều lập trình viên tương tác với QA hơn. Cho điểm cho một vấn đề đang được giải quyết hợp tác bởi một lập trình viên và QA chẳng hạn.
• đưa ra các tiêu đề khác nhau, một cho nhiều điểm nhất và một cho nhiều vé nhất. Điều này sẽ đáp ứng bản năng cạnh tranh của các lập trình viên.
• thiết lập một cuộc cạnh tranh thân thiện giữa Dev và QA bằng cách tổng hợp điểm của mỗi thành viên trong đội

Tuy nhiên, việc giảm khả năng lỗi hồi quy xuất hiện là một vấn đề khác. Ví dụ, bạn có thể áp dụng các điểm tiêu cực, nhưng tôi chắc chắn đó không phải là một ý tưởng hay vì đây sẽ là một hình thức trừng phạt. Điều tốt hơn có lẽ là tự động bắt đầu chạy nước rút với một vài điểm nếu không phát hiện thấy lỗi hồi quy trong tuần qua. Nếu lỗi hồi quy đã được phát hiện, lập trình viên bắt đầu bằng 0.

Ngoài ra, trong "gamification" còn có "game". Và khía cạnh cơ bản của một trò chơi là bạn chơi / tham gia một cách tự nguyện. Trong bối cảnh công việc, nó có thể được áp dụng bởi ban quản lý là trường hợp ở đây, nhưng thông thường không ai bị ép buộc vào việc này.

Để kết luận, điều MVP này không nhất thiết là một ý tưởng tồi, nhưng cách tiếp cận có thể được thay đổi một chút để làm cho doanh nghiệp (giải quyết các lỗi quan trọng) đến trước, và nhấn mạnh làm việc theo nhóm hơn là cá nhân.

Một số loại công nhận nhóm về những nỗ lực của một thành viên trong nhóm có thể là một động lực có giá trị, nhưng trong trường hợp này có vẻ như nó bị áp dụng sai. Bạn nói rằng MVP được chọn bằng cách bỏ phiếu, nhưng có rất nhiều đề cập đến số lượng lỗi được sửa trong mỗi lần chạy nước rút. Có vẻ như thời gian của bạn có một định nghĩa hài hước về MVP - Tôi sẽ cho rằng người xứng đáng với danh hiệu "có giá trị nhất" là người đã thêm giá trị nhất cho phần mềm trong lần chạy nước rút đó. Nếu một thành viên trong nhóm chọn ra các lỗi có thể khắc phục nhanh chóng, nổ tung chúng nhanh nhất có thể và gây ra lỗi hồi quy và các vấn đề khác theo cách thức của họ, thì họ sẽ không thêm giá trị, họ sẽ tạo ra nhiều công việc hơn cho bất cứ ai có để theo dõi họ xung quanh việc xác định và khắc phục những vấn đề đó.

Đề nghị của tôi sẽ là cố gắng bắt đầu một cuộc thảo luận thích hợp vào lần tới khi nhóm của bạn có một trong những phiếu bầu này. Đừng chỉ biến nó thành một bàn tay; nói chuyện qua trước Nếu ai đó dường như đạt được số phiếu dựa trên số "bản sửa lỗi" mà họ đã thực hiện, hãy chỉ ra (một cách khéo léo) trong đó các bản sửa lỗi đó gây ra hồi quy và đề nghị rằng có lẽ người sửa lỗi hồi quy đó nên được đề cử để làm sạch người khác lộn xộn. Nếu ai đó dành toàn bộ nước rút cho một vấn đề khó chịu, hãy chỉ ra cho nhóm, nhấn mạnh thực tế là mặc dù số lượng sửa lỗi của người này là một, nhưng họ đã giải quyết một vấn đề lớn với phần mềm của bạn - một vấn đề là khó chịu đến nỗi không ai muốn chạm vào nó

Chọn ra các bản sửa lỗi dễ dàng và thực hiện chúng một cách vội vã hoặc khó hiểu là không có giá trị, vì vậy các nhà phát triển chỉ cần làm điều đó có thể không đủ điều kiện làm ứng cử viên MVP. Khi chọn MVP mới, hãy quên tất cả về nhóm và những người trên đó và xem phần mềm. Chọn ra thay đổi quan trọng nhất trong phần mềm đó kể từ lần trước. Ý tôi là độc thân ở đây; "Không nhiều lỗi nhỏ" không phải là một thay đổi lớn. Có một lỗi đặc biệt rõ ràng đã được sửa chữa? Có một tính năng mới tuyệt vời đã được thêm vào? Khi bạn đã xác định được một thay đổi lớn này là gì, hãy hỏi ai chịu trách nhiệm cho nó. Một trong những người đó có lẽ là MVP thực tế của bạn. Nếu "không nhiều lỗi nhỏ" là sự khác biệt duy nhất , thì và chỉsau đó, lỗi được tính là thước đo hợp lệ của MVP - và thậm chí sau đó, tôi sẽ xem xét tỷ lệ lỗi được sửa với lỗi hồi quy gây ra. Mỗi lỗi ai đó gây ra ít nhất 1 từ số lượng của họ. Trong thực tế, tôi muốn nói nhiều hơn 1, vì một sửa chữa xấu sẽ gây ra một chưa biết lỗi mà bạn sau đó phải tìm, đó là tồi tệ hơn một tiếng lỗi đó là được tìm thấy rồi. Một lỗi đã biết cần nỗ lực của nhà phát triển để sửa chữa; một lỗi không xác định cần nỗ lực của QA để tìm và nỗ lực của nhà phát triển để khắc phục, và sau đó có nguy cơ QA sẽ bỏ lỡ nó.

Về lý thuyết, nếu các nhà phát triển nhận ra rằng cách để giải thưởng là khắc phục ít vấn đề hơn, lớn hơn, họ sẽ nhắm đến những vấn đề khó khăn, những vấn đề phức tạp, những khiếm khuyết ngăn chặn. Điều này đôi khi sẽ yêu cầu họ phải liên kết với nhau, bởi vì không có đủ vấn đề khó khăn để giải quyết, hoặc bởi vì vấn đề đủ khó khăn để đòi hỏi nhiều mắt hơn . Có lẽ gợi ý rằng trong những trường hợp như thế này, giải thưởng có thể được chia sẻ nếu không rõ ngay lập tức ai trong số những người đã làm việc nhiều hơn để sửa lỗi - và hãy nhớ, công việc đã hoàn thành! = Dòng mã được viết. Các nhà phát triển có thể sẽ biết điều đó, nhưng bạn nói rằng quản lý có liên quan và quản lý không luôn hiểu điểm đó.

Và này, nếu thất bại, hãy quên chương trình MVP. Nói chuyện với các nhà phát triển đồng nghiệp của bạn bên ngoài các scrums và chỉ ra tác động tiêu cực mà giải thưởng MVP đang có trên phần mềm. Xem nếu bạn có thể làm cho họ bỏ qua nó, hoặc không làm cho nó một vấn đề lớn như vậy. Để chiếc cúp trong ngăn kéo, dành giải thưởng tiền mặt cho một vòng đồ uống cho đội sau giờ làm việc, sử dụng bữa trưa miễn phí để lấy thứ gì đó bạn có thể chia sẻ, như một bó bánh cupcake. Agile là một hệ thống nhóm; làm nổi bật các rủi ro hiệu suất cá nhân đọ sức nhóm với nhau. Đoàn kết bạn, chia cho bạn phần mềm đầy lỗi, sau thời hạn, ngân sách quá cao.

Đây là một ví dụ kinh điển về cách một thực tiễn cụ thể (công nhận là MVP) có thể có tác động đáng kể nhưng gián tiếp trong cách hành xử của nhóm bạn. Điều này vượt xa các khuyến khích, động lực, và phần thưởng và thực sự chạm đến các ý tưởng trong tâm lý học môi trường / hành vi và kiến ​​trúc quyết định. Công cụ mát mẻ.

Câu hỏi là - làm thế nào bạn có thể thiết kế một quy trình để nhóm của bạn dường như làm tất cả những điều đúng đắn một cách tự nhiên, mà không phải đưa ra các chính sách cứng nhắc hoặc buộc mọi người phải làm gì đó?

Tôi đã viết về việc sử dụng các khoản chi trả (theo truyền thống của Thiết kế mọi thứ hàng ngày của Donald Norman ) cho các quy trình như một cơ chế để thiết kế một quy trình phù hợp với nhóm của bạn. Ý tưởng cơ bản là các thực tiễn trong một quy trình ảnh hưởng trực tiếp đến hành vi của một người. Do đó, các vấn đề phát sinh khi chi phí trong quy trình của bạn không hoàn toàn phù hợp với giá trị của nhóm bạn.

Tôi đã từng tổ chức một số hội thảo về chủ đề này và vấn đề đặc biệt này xuất hiện như một ví dụ trong các nhóm theo thời gian. Áp dụng lý thuyết về chi phí cho trường hợp bạn chia sẻ trong câu hỏi của bạn có thể trông giống như thế này .....

Giả sử giá trị nhóm của bạn nhất quán, dự đoán và mã chất lượng cao.

Bạn đã có một danh sách các hành vi tiêu cực mà bạn đã quan sát và tất cả chúng dường như xuất phát từ việc sử dụng các số liệu khiếm khuyết để chọn MVP của nhóm. Ví dụ, đồng đội dường như tự nhiên muốn chọn và sửa lỗi một cách ngớ ngẩn, ảnh hưởng tiêu cực đến cả ba giá trị của bạn. (Tôi cho rằng trước đây cũng có vấn đề và đây là điều dẫn đến ý tưởng MVP).

Thay vì có một MVP duy nhất dựa trên số liệu khiếm khuyết, chúng tôi sẽ cố gắng thay đổi hành vi của nhóm bằng cách thực hiện một số thay đổi nhỏ nhưng quan trọng.

• Hãy để bất cứ ai đưa ra một "đội kudo" cho bất kỳ (và tất cả, không chỉ một) cá nhân nào mạnh mẽ nắm lấy giá trị đội của bạn. Điều này sẽ thúc đẩy khả năng dự đoán là dân chủ hóa hệ thống giá trị đội thông qua các ví dụ. (Chúng tôi thực sự làm điều này trong nhóm của chúng tôi ..)
• Bắt đầu lập trình cặp (hoặc gán "bạn bè lỗi") cho tất cả các sửa lỗi. Điều này sẽ thúc đẩy chất lượng bằng cách không khuyến khích các quyết định lập trình vội vàng hoặc nửa khẳng định và khuyến khích tính nhất quán vì bạn bè sẽ tiết chế hành vi thất thường. (Ý tưởng này thường được đề xuất trong các hội thảo, có vẻ trực quan ..)

Và đây chỉ là một số ví dụ để thể hiện cách tiếp cận và giúp bạn bắt đầu ...

Điều tuyệt vời về phương pháp này là bạn đang tích cực thiết kế các thay đổi quy trình của mình và có lý do chính đáng cho các thay đổi quy trình bạn thực hiện. Giống như trong thiết kế đối tượng hoặc giao diện người dùng, bạn thậm chí có thể đo lường kết quả để hiểu liệu mọi thứ có hoạt động hay không.

Một trong những điều chỉnh dễ thực hiện nhất để đảm bảo một cái gì đó giống như chương trình MVP hoạt động là thưởng cho các thành viên trong nhóm vì là người có giá trị nhất đối với thành công của đội, chứ không phải là người làm việc chăm chỉ nhất.

Chúng tôi đã thực hiện điều này thành công bằng cách nhận ra những người thậm chí không làm việc với các lỗi hoặc tính năng, nhưng đã làm điều gì đó tuyệt vời khiến mọi người trong nhóm thành công tốt hơn. Ví dụ: chúng tôi có một nhà phát triển đảm nhận nhiệm vụ cố vấn một nhóm thành viên mới cho nhóm để họ có thể tìm hiểu kiến ​​trúc và cách chúng tôi làm việc. Vận tốc của chúng tôi tăng vọt vì chúng tôi có những tân binh này có thể cung cấp kết quả nhanh chóng và hiệu quả, mặc dù cá nhân rằng vận tốc của một nhà phát triển đã giảm vì anh ta dành nhiều thời gian hơn để giúp đỡ các thành viên còn lại trong đội.

Khen thưởng tinh thần đồng đội và nhóm sẽ nhận thấy rằng đó là NHÓM quan trọng, không phải thành công của riêng họ.