927
《程序員度量：改善軟件團隊的分析學》一案例分享：度量和懷疑論者
案例分享：度量和懷疑論者
我們團隊裏一位滿頭華發、經驗豐富的程序員給了我一個臉色，僅僅揚了揚眉，給了一個假笑。是的，這個臉色是在告訴我，把度量告訴那些年輕的家夥吧，看他們打算怎樣幫助提升我們的團隊，你們做你們的，我不會搞砸什麼，他的沉默表明了他的觀點。我不想說什麼，但是他仰起的下巴讓我知道他並不買賬。他是一個懷疑論者。
一個月過去了。我們召開了團隊會議，我給每一位同事展示了一組公司和產品的度量。它展示了我們的產品目前情況怎麼樣，我們怎樣與競爭產品（就我們知道的而言）相比較，已完成的單個特性如何。我們關注那些在過去6個月裏實現的產品特性。每個人都非常投入。這是我們整年中開過的最活躍的一個會議。即使我們滿頭華發的程序員也提出了很多看法。
又一個月過去了。我們召開了另一個團隊會議。在這次會議中我們著眼於公司和產品度量的更新，但是我們同樣著眼於從我們近幾個sprint（我們使用敏捷方法，因此我們工作的增量是“sprint”）提取的團隊度量。我們剛剛發布了一個新的特性。我們思索團隊度量如何才能夠關聯到新特性的接受度、哪些度量是重要的及其原因。那位滿頭華發的程序員說實現最後一個sprint中特性的工作的複雜度太高，他預計我們的測試或許有些一些問題沒有發現，並且我們可能預見有不少的問題會在最終產品中發現。盡管我們的QA經理指出所有計劃的測試及完整的回歸測試都完成了，但我們都認為有些事值得關注。
又過去了幾個月。現在我們擁有關於新特性客戶接受度的良好數據，雖然不是十分壯觀驚人，但很確鑿，並且在產品中發現了一些問題。我們的程序員是對的。相對其他我們跟蹤過的特性來說，這個特性的問題的比率和複雜度明顯比較高。大多數的問題已經在那個點上修改掉了，但是團隊依舊做了記錄以便於未來考慮。第一次，我們同樣開始考慮個體程序員的度量。我們考慮了在sprint中工作的複雜度，包括產品特性開發和產品bug的修複。我們考慮了每個程序員處理的打斷事件，並且我們也考慮了每個人負責多少部分的代碼。我們考慮了程序員花了多少時間幫助他人，這稱為“助攻”。我們也考慮了基於團隊收集的度量。我們討論這些度量怎樣可以關聯到團隊目標、團隊的成功、產品的成功和公司目標。我們同意在接下來的月份繼續關注這些度量，看我們可以從中學到什麼。
有些有趣的度量顯現了出來，一些團隊成員對它們提出了自己的看法。例如，有一部分程序員有非常高的工作負荷，但是他們負責的事項的平均複雜度又不高。其他程序員又剛好相反，負責高複雜度但是更小工作負荷的事件。我們沒有從中得出什麼結論，隻是發現這非常有趣，並且說出心中的疑惑：這看起來分布不均的任務複雜度對於團隊來說是否是件好事。另一個顯著的事實是，當其他程序員沒有提供任何協助時，一些程序員擁有非常多的“助攻”。我們討論了怎樣度量這個，請主管來扮演觀測員。在這一點上，看起來大家都沒有問題。那位經驗豐富的程序員什麼也沒有說。
然而，在兩天後他走進了我的辦公室。“Dang，”這位程序員說道，“一群夥計對那些年輕人幫助了很多。我沒有任何“助攻”—— 我沒有做這些。我隻是想讓你知道我明白了。我肯定會去做我的那一部分。”就是那樣。
又一個懷疑論者被同化了。
最後更新：2017-08-17 12:02:37