軟件項目成功之要素

本文轉載自查看原文 2016-10-02 11:42 2309 Management

我們在不斷探尋更好的軟件開發方法，希望能找到適合自己和團隊的好辦法。不過，基於既有的教條，關於各種開發方法孰優孰劣的討論最終總會演變成激烈的爭吵。字典中教條的定義是“一種權威性觀點，但並沒有充分的依據”。我們經常會看到，各種方法的擁護者們都堅持認為自己的方法才是開發軟件唯一正確的方法。我們不斷聽到一些從業人員這么講，他們執着地采用某種方式開發軟件，即使這種方法明顯危害到團隊的其他人甚至整個組織，卻仍然固執己見。事實上，開發軟件根本沒有所謂“絕對正確的方法”。倒是有很多錯誤的方法，不過沒有哪一種方法、觀點、哲學或工具能“以不變應萬變”，在所有時間、所有場合對所有項目和所有人都適用。軟件是人創建的，不會有兩個人完全一樣。

如何構建優秀的產品

在人生中，我們應該選擇優秀的一些習慣，我們要刻意去培養它，使得其成為自己的習慣。讓自己習慣性優秀，那么就會獲得成功。“我們每一天怎樣度過，一生就會怎樣度過”

習慣性優秀，如果我們堅持不懈，那么優秀就不再是一種行為，而成為一個習慣。

采石工人信條：

盡管我們只是采石頭，但腦海中必須想象着最終建造出的宏偉教堂。

腦圖

一流的產品只不過是好習慣的副產品

工具和基礎設施

1. 在沙箱中開發，只需記住一個基本原則，在你准備好之前，要與其他人隔離，使他們不會受到你的工作的影響。把這個原則描述為“隔離原代碼”。

2. 管理資產，需要一個源代碼管理（SCM）系統，也稱為版本控制（VC）系統，跟蹤存儲庫（或數據庫）中的所有資產，並協調對這些文件的安全訪問。

3. 建立構建腳本，構建會把源代碼轉換為一個可運行的程序，根據需要打包圖像和其它資源。自動完成構建過程不僅可以更准確地完成各個步驟（更不容易出錯），還能讓我們按時收工。

4. 跟蹤問題，一個好的問題跟蹤系統會為給定的產品生成活動報告，遇到多少個問題，多少個問題得到解決，花費了多長時間等，從而用來找出項目中的問題地帶。

5. 跟蹤特性，跟蹤特性的方法與跟蹤問題列表相同，需要維護一個統一的特性請求列表，為特性指定優先級，並對研究或增加這個特性可能需要的時間做一個基本估算，並在白板上保留最高優先級的特性列表，
讓大家一目了然。如果一個任務不在指定優先級的列表中，就不要做任何處理。

6. 使用自動化測試框架來創建和運行自動化測試，也可以手工編寫獨立的測試。
包括單元測試、功能測試、性能測試、負載測試、煙霧測試、集成測試、模擬客戶測試。

   單元測試：驗證一個代碼單元中邏輯操作的正確性
   功能測試：測試整個產品的操作或功能是否正確
   性能測試：運行速度
   負載測試：在很大負載情況下的表現
   煙霧測試：冒煙測試

7. 選擇工具，工欲善其事、必先利其器，使用的每一個工具都應當最勝任相關工作，
要在每個領域中尋求“最出類拔萃”的工具。

任務清單

使用任務清單相當容易，不過，任務清單要真正做到有效，必須遵循一些原則。包括以下所有特點：
1. 可以公開獲得    
   團隊的任務清單必須可以公開獲取，一個秘密的任務清單對協作沒有任何幫助。要把任務清單放在你的白板上或者放在網站上為它建立一個RSS提要，不然至少要讓人們很容易很明了的讀到。把任務清單一直放在面前，有助於保證工作重點。
2. 已指定優先級    
   任務清單必須已經指定優先級，要區分產品中不同類型的特性 --- 必要特性、可取特性和無用特性。在對任務清單指定優先級時必須有所區別，否則不分輕重緩急最后只會浪費時間。通常會有一組核心任務必須在產品交付前完成，這些就是優先級最高的特性。絕對不要忽視你設置的優先級，在處理較低優先級任務之前，一定要先完成所有高優先級的任務，除非確實有充分的理由暫緩某個任務。
3. 有時間表    
   任務清單總有一個關聯的時間表，這個時間表並非一成不變。但應該包括估計時間，指出任務清單中的各項任務大致需要多長時間完成。然后，當你完成一個任務時，要記錄實際所花的時間，並注意二者之差。
4. 活躍    
   任務清單必須是活的，不能一成不變。你的團隊必須能夠適應變化。技術領導人會隨着項目進展調整特性的優先級；一些新的特性會出現，而有些特性會退出。任務清單有變化通常意味着客戶或干系人在關注這個項目，而且確實提出了想法和有價值的反饋。
5. 可測量    
   為了保證有效，任務清單上的每一項必須是可測量的。畢竟，如果你想從任務清單中去除某項任務，就必須能確定這項任務已經完成。基於這個原則，要避免一些模糊不清的任務，如“提高性能”，而傾向於一些具體的任務，如”保證登錄在5秒內完成“或者”在10秒內生成報告X“。通過創建一個只有“是”和“否”兩種狀態的目標，你就能明確這個目標是否已完成。如果你的任務清單上有一些任務是不可測量的，那么要花些時間查看真正的需求是什么。把這個任務分解為明確的只有兩種狀態的任務，然后讓原先提出要求的人檢查這些任務。如果一項任務無法轉換為可測量的目標，就把它設置為優先級最低，先處理更高優先級的任務。
6. 有針對性    
   有兩類任務清單：團隊任務清單和個人任務清單，都非常重要，必須針對適當的對象。團隊任務清單包含整個項目的所有重要工作，個人任務清單包含的任務較少，一旦完成，就要從團隊的任務清單中復制一項任務，把它加到個人任務清單中

曳光彈開發(Tracer Bullet Development)

集體參與架構設計：
1.一個會議主持人，任何人說話之前必須經他“許可”
2.整個會議中應在白板上記錄要點
3.可以用LEGO或積木表示系統中的對象
4.記錄接口並發布。
5.保證會議不被中斷。要盡量減少轉移話題和回答問題的次數。

增加總線數：
總線數是指當損失的開發人員達到這個數，則極有可能導致項目失敗。如果你的團隊有一個“超級明星”，項目大部分信息都在他手里，那么你的團隊總線數就是1。

曳光彈開發流程：
提出系統目標->提出接口->連接接口->增加功能->重構、求精、重復->提出系統目標（新目標）->...如此重復

工作流程：
1.定義系統對象。
2.定義系統對象間的接口。
3.編寫接口樁stub。

簡言之:

address fundamental problems as soon as possible
give the client a useful result as soon as possible

千萬不要工作兩天以上而不做一次代碼審查

維護遺留代碼：

構建自動化構建模擬用戶功能測試單元測試
測試之前不要修改遺留代碼

盡早而且經常發布真實演示系統。

另類開發人員：與團隊步調不一致，經常造成破壞但堅信自己是正確的。
使用每日站會修正另類開發人員的航向
保證另類開發人員只能完成任務清單上的任務
使用代碼審查和自動代碼變更通知來追蹤另類開發人員的工作
使用CI來作為最后一道防線監視另類開發人員的工作

如何有效的與你的經理溝通：

制定團隊任務清單和個人任務清單，定期（例如每2周）讓經理審查
讓經理（例如每周）掌握團隊和你的最新進展（例如郵件）
如果遇到每天檢查你好幾遍的老板，則給他看任務清單，讓他能夠在特定的時間得到定期的狀態更新。

每日例會可能已經偏離正軌的信號：

每個團隊成員需要十分鍾或者更多時間。
某個團隊成員總是占用太多時間，幾乎是其他成員時間的總和。
人們以一種不友善的方式相互責問。
會議總是很晚才開始（或結束）
會議變得空洞無物，開發人員僅僅只是宣稱“我完成了90%”，或者“我在做關於***的工作”
團隊成員在漫無目的地聊天，忘記要報告他們做了些什么，你要私下里要求這些團隊成員把他們的工作寫下來，這樣在開會時他們就能保證目標集中，報告簡潔，他們還可以建立自己的任務清單從而更有條理。

技術領導人要完成的工作：

確保團隊的工作優先級與客戶的需求一致；
確保將團隊的工作適當地展示給管理層；
將團隊與不懂技術的管理層隔離；
為不懂技術的干系人解釋技術問題；
讓開發團隊了解非技術問題。

技術領導人的職責：

為團隊成員設定方向；
管理項目的特性列表；
為項目的特性確定優先級；
隔離你的團隊，使他們不受外部干擾。

技術領導人應該能夠順利回答的問題：

你知道團隊的每一個成員都在做什么嗎？
你能不能在5分鍾內生成一個關於項目狀態的總結？
產品接下來要事先的5到10個特性是什么？
你能不能很容易地列出產品中優先級最高的缺陷？
你為團隊成員解決的最近的問題時什么？
如果一個團隊成員需要解決一個重要問題，他會來向你求助嗎？

警告信號：
缺乏對每一個團隊成員工作方向的全局認識。
他一來，工作就要停下來。
團隊工作出色，但只要他得到好評。
不能解決問題，或者更糟糕地，反而會帶來問題。
不能准確地預測工作時間表。
不清楚團隊成員的技術能力，也不知道團隊成員希望了解什么。
對團隊中的沖突視而不見。