敏捷開發績效管理之十：阿米巴經營之軟件團隊經營什麼（中）

經營技術

經營技術是說，不要只是把作產品/項目的過程看成完成任務或提高本身能力的過程，而是要看成爲企業積累技術的過程。

這聽起來很容易，但作起來有難度，好比這幾個問題：

1. 團隊是否有一個可複用的技術庫？（DLL，類，函數，各類層面的）

2. 團隊是否有一個機制令得這些庫被充分利用？（一個可度量指標就是代碼行/功能點，越低越充分）

……

通常而言若不進行有效管理，20人團隊的代碼冗餘率可能在95%左右，也就是95%左右的代碼是多餘的。在2004年的一次技術改造中，一個19萬行，13人×9年的產品，被改造爲1.3萬行，1人×1.5年的相同產品（更關鍵的是缺陷少了，此次改造的直接動因就是原來產品的缺陷衆多並且隱藏很深）。

這並非個例：這家公司是納斯達克上市的上千人的電信軟件公司，其開發和管理強於通常的中小公司，後者的技術水平可能更差。但因爲廣泛而言人們使用別人代碼的比例很低（咱們經常感受到用過別人的東西，但若本身數數，又會發現不過就幾百行代碼而已），因此人數越多可壓縮的比例越高；再加上因爲多數人連本身的複用作的也很差，因此在未完善管理的狀況下，對代碼進行大規模壓縮的潛力通常都接近在2×人數倍以上。

注意這個例子中，較少的代碼不但有更高的生產率，質量也隨之提升，甚至更加明顯。

相似這種規模和週期的軟件及團隊，都應該刻意地在開始就不要只以完成當前任務爲惟一目標，而開始架構和積累整個技術架構。

「若剛開始的時候老闆不給充分的時間怎麼辦？」一則我歷來沒有見過老闆指着咱們的可複用庫說：「不要編寫這個，直接給我壘代碼」；二則及時被給予足夠的時間，多數團隊也沒有造成這樣的可複用庫；三則可複用庫的生效速度是很快的，若前三個月投入複用的時間尚未賺回來，那麼多半作錯了……考慮到這些，多數時候缺乏對技術的經營，實際上是咱們軟件人員本身的問題。

經營過程

過程就是人們作事的方法，說大一些，就是「企業文化」。

文化是很容易被談論又很容易被忽視的東西。不少底層的程序員能看到遠在天邊的企業文化，但卻看不清楚本身面前的編碼文化。

在2001年的一個團隊裏邊（就是我第一次感覺鬆結對編程與139團隊的那個團隊），剛開始只有5我的，人們不須要專業的測試人員而仰賴高手幫助新手查看代碼和本身自主測試來保障質量；一年之後，當團隊擴張到25我的的時候，這個傳統仍然存在——此時咱們的專業測試人員只有2個，並且只負責總體測試。

這是由於在團隊成立的開始，團隊嘗試創建起一種以高質量爲榮的團隊文化，全部製造大量的缺陷程序員（包括剛開始時的我本人），都會同時受到鄙視和幫助，人們能夠選擇接受二者，或者只接受前者。結果是接受幫助的人逐漸擺脫了被鄙視的局面，他們繼承了這種傳統，進而幫助後來的新人。

能夠被經營的過程有不少，有不少徹底無需領導受權便可進行，另外一些須要在進行必定程度後說服領導進行下一步的支持。這些過程包括：

1. 代碼審查

2. 開放的辦公室空間

3. 白板和常常的討論會

4. 基於白板的簡單設計（好比預想陳述）

5. 看板

6. 鬆結對編程

7. 1-3-9團隊

……

誰來經營

「若是老闆能讓我放手管理，我也能夠經營好咱們的團隊。但是……」這是經常聽到的一句話。

實際上，老闆通常都是「放手」管理的。多數團隊的領導者（尤爲項目經理）與本身團隊相處的時間，超過再上一級的100倍。若這些時間——其實應該說是精力——被充分用來經營團隊，而不是簡單地執行傳聲筒和工頭的角色，本文所說的經營徹底能夠實現。