下一篇：項目實戰(2): Beta案例
個人開發
通過一個小命令行程序的需求分析，設計實現，交付給2-3人使用，收集反饋，增量改進，優化。解決明顯的開發痛點，再推廣。這個過程是體驗很好的，為什么呢？
- 開始之前，起草並發布接口設計文檔，並郵件征求意見。
- 程序的測試成本低，速度快，幾乎任何改動都可以立刻測試看結果，由此可知那些體驗不好的一定有相反的理由:測試成本高，反饋速度慢。所以構建快速測試反饋的機制是好處非常大的。
- 一開始是模糊的，但是有大致的設計，實現過程中諸多不確定，但是方向對，就先一路實現不跑，直到codecomplete,然后開始逐接口測試，直到第一遍跑通，第一遍自反饋改進。這個過程中，明確的codecomplete節點是有意識的，通過設置這個節點，目標清晰，在cm的時候雖然代碼一行都沒跑過，但你知道最重要的腳手架搭建好了，這是本質不一樣的。
- 一旦自測通過，即可更新文檔，並發布郵件周知，然后下一步。
- step by step交付第一個人試用！在試用過程中，會遇到對方覺的不對不合理的地方，肯定不高興，但是耐心和對方談，談到合適的設計方案，達成一致后，第一波改進。這才真正是需求進階的地方。更新接口后，同步更新文檔並郵件。
- step by step交付第二個人試用…第二波改進，同步更新文檔並郵件。
- 經過幾輪，可以交付內部試用啦，alpha.
團隊開發
團隊A有一個項目外包給某公司B，由於前期溝通/了解/管理上的不足，以及對風險的誤判，導致在離截止日期只有20天的時候，才發現公司B在開發上存在嚴重問題：
- 該團隊不使用版本管理軟件協作開發，代碼靠拷貝協作，很難想象他們是如何活下來的。
- 該項目使用JavaScript作為主要語言，但是該團隊web端開發人員連
Content-Type是啥都不熟，據稱之前是開發PHP的。 - 該項目的數據庫毫無設計，完全根據前端界面需要什么就加什么字段。
- 該項目未完成基本的界面功能，以及未做任何錯誤處理
- ...
團隊A啟動緊急預案，接手項目開發。
- 創建git倉庫，將舊代碼/文檔提交到倉庫，建立需求分析/模塊設計/編碼規范文檔子目錄。
- 團隊確定人員和指責：平台+1/服務端+2/客戶端+3，客戶端有2個是做兩個獨立App，一個做Web。App開發方面使用ReactNative。
- 快速重新建立工程，讓舊代碼可以運行起來，文檔里添加「快速上手.md」，使得任何一個新加入的人可以快速搭建環境並測試運行。
- 全體現場分析舊數據庫設計，逐個表逐個字段復審，並做第一次漸進式重新設計，確認數據庫分層設計，並做一致性方面考慮。
- 3個客戶端全部優先根據需求設計好需要的后端接口，並添加到模塊設計文檔。
- 3個客戶端全部使用靜態假數據並行開發界面。
- 與此同時，后端根據新設計的數據庫，重新設計模型層接口並實現，后端所有接口同時有測試代碼。
- 1個新的人員加入，參與客戶端設計的后端接口與后端模型層接口的對接，每個實現同時有測試代碼。
- 在開發中隨時根據對平台功能的需求，快速迭代平台sdk。
- 第1個客戶端界面開發完成，開始與后端對接，做集成。
- 第1個客戶端需要模擬數據支持，后端添加模擬數據生成腳本，批量生產模擬數據，用以測試，並隨時根據需求添加。
- 第1個客戶端集成完畢，該開發人員支援第2個客戶端。
- 第2，3個客戶端相繼完成並開始集成。
- ...
- 全部集成完畢，正式alpha，同時2期開發接手的團隊找到。