l

2014年12月3日 星期三

一個人的End-To-End

Dec. 02 14:51~16:03

螢幕截圖 2014-12-02 15.58.43

武功祕笈…目錄…的第一頁XD。

 

經常有朋友問Teddy:「如何衡量Scrum團隊成員的表現?」衡量員工的表現一直以來都不是一個簡單的問題,尤其是採用敏捷開發方法的團隊,傳統上很多評量、打考績的作法並不適用。這個問題可以在《Management 3.0: Leading Agile Developers, Developing Agile Leaders》這本書找到ㄧ些方向(〈Scrum團隊如何打考績:有所本篇〉)。Teddy自己偏好另一種比較「抽象」的衡量標準:

  • Kent Beck提到,所謂「厲害的人」不是自己很強然後獨善其身不管別人死活,而是幫助別人,使別人原本認為很難的事情,在他的幫助之下變得很簡單
  • Clayton M. Christensen教授所提倡的人生目標之一:「這世界上有多少人因為你的幫助而變得更好?(請參考〈賺多少才快樂〉)

這種標準雖然只是一句話,但卻是很不容易達到的目標。

***

敏捷開發強調end-to-end的觀念,需求要寫成end-to-end story以便突顯其價值。在實作面,一位開發人員如果能具備end-to-end能力,從需求、分析、設計、開發、測試、佈署到維護,每一個工作流程階段都有辦法讓別人「因為你的幫助而變得更好」,讓別人「因為你的幫助使得原本覺得困難的事情變得簡單」,可以做為敏捷開發人員努力的目標。

「一個人的end-to-end」不是容易修練的境界,但至少可以先努力做到「一個團隊的end-to-end」。從個人修練的角度來看,可以幫自己的能力定一個「DoD(Definition of Done)」標準,如果是程式設計師,就先在開發與測試階段做到最好,有機會則可以藉由擴充DoD,慢慢往「上游」與「下游」拓展自己的能力與影響力。

最後提醒一點,在拓展DoD的過程中,不要求快導致淪為「收括流行名詞」(請參考〈學習不是為了收括流行名詞〉),那就違反「一個人的end-to-end」的本意了。

***

友藏內心獨白:一張嘴的end-to-end,不行嗎?!

沒有留言:

張貼留言