自從我加入TrackAbout的團(tuán)隊(duì)以來，我一直在重新思考我對流程改進(jìn)的一些想法。

我一直大力提倡測試驅(qū)動開發(fā)、靜態(tài)代碼分析和軟件開發(fā)中的其他最佳實(shí)踐。

在以前的工作中，我有很大一部分時間是在明確或隱含地改進(jìn)發(fā)展過程中度過的。這不是一個真正有趣的地方，但我一直感到有一種強(qiáng)烈的道德信念，那就是接受這份工作，把事情做好。

當(dāng)流程改進(jìn)不起作用時

我在TrackAbout工作的團(tuán)隊(duì)中有很多開發(fā)人員，他們確實(shí)是我共事過的最聰明的人之一，他們不僅有豐富的經(jīng)驗(yàn)，而且知識淵博，尤其是在最佳實(shí)踐方面。

在這里應(yīng)用相同的開發(fā)過程改進(jìn)步驟似乎沒有意義。

我說的是：

• 代碼在單元測試中必須有90%的代碼覆蓋率。

• FxCop必須沒有新的警告。

• 不能同時處理兩個積壓的代碼。

• 積壓的代碼必須分解為不超過x小時的任務(wù)。

在我工作過的大多數(shù)團(tuán)隊(duì)中，這些類型的“規(guī)則”確實(shí)有助于提高團(tuán)隊(duì)生成的代碼質(zhì)量。

這是我第一次覺得在開發(fā)團(tuán)隊(duì)中引入“規(guī)則”實(shí)際上會損害代碼的生產(chǎn)率和質(zhì)量。

非常優(yōu)秀的開發(fā)人員似乎有判斷力，能夠做出正確的決定，即他們需要多少代碼覆蓋率，以及哪種靜態(tài)分析規(guī)則是重要的。

似乎沒有一套開發(fā)過程規(guī)則能夠捕捉到這種判斷的價值。

我覺得在我工作的地方，每個人都對自己寫的每一行代碼都有自我意識，他們不必被告知對此有自我意識，這真的是我在其他地方從未經(jīng)歷過的事情。

我在那里工作過的大多數(shù)地方，可能都有一兩個與我志趣相投的人，他們是公司里所有的開發(fā)人員中的一員，但老實(shí)說，在TrackAbout，每個開發(fā)人員都有同樣的熱情。

所以我是說開發(fā)過程是不必要的嗎？

一定要說“不！“但我要說的是，有時他們的僵化程度是不需要的。

當(dāng)我在過去負(fù)責(zé)建立開發(fā)過程時，經(jīng)常有人問我“為什么單元測試90%的代碼覆蓋率？”這一問題。

在單元測試中擁有90%的代碼覆蓋率并不是什么神奇的事情。它不會突然讓你的代碼變得很好，但它通常可以確保以下幾點(diǎn)：

• 您有一種可測量的、可執(zhí)行的方法來確保單元測試是真正編寫的。

• 如果開發(fā)人員正在經(jīng)歷困難以獲得90%的代碼覆蓋率，那么他們更有可能編寫好的單元測試來實(shí)實(shí)在在地執(zhí)行代碼。（不總是這樣，但肯定更有可能。）

• 它防止了那些不應(yīng)該做出判斷的人需要做出判斷。你不能相信每個開發(fā)人員都能做出正確的判斷，所以通過強(qiáng)加一個任意的規(guī)則，你可以在沙子上劃出一條線，而這條線大部分是正確的地方。

強(qiáng)加開發(fā)過程規(guī)則還有其他好處和原因，老實(shí)說，對于大多數(shù)團(tuán)隊(duì)，我強(qiáng)烈推薦它們。

我在這篇文章中所做的是質(zhì)疑我自己的想法，即如何將它們應(yīng)用到一個成就卓越的團(tuán)隊(duì)中。

如果沒有一套嚴(yán)格的規(guī)則，那么如何改進(jìn)流程？

這是我現(xiàn)在正在努力解決的問題。老實(shí)說，我還沒有一個很好的答案。

即使在這種情況下，看起來我的看板和指南中的原則仍然適用。 

我還在思考這個問題 。

我覺得總是需要一些過程改進(jìn)，持續(xù)改進(jìn)是非常重要的，沒有一個團(tuán)隊(duì)可以從過程改進(jìn)中獲益。

關(guān)于高績效團(tuán)隊(duì)的改進(jìn)過程的另一個問題是，沒有人坐在那里談?wù)摳倪M(jìn)過程。相反，每個人都在完成事情。通常情況下，過程改進(jìn)討論是出于必要性，或者因?yàn)轱@然存在需要改進(jìn)的問題。

我相信，當(dāng)我自己找到這些問題的答案時，我會在這個話題上寫得更多。