專案之路-敏捷開發菜鳥版
一晃就又是一個月過去了，到了管理端，心裡想的就是如何把亂七八糟的事情有序排列，讓團隊持續地的產出。雖說基本不用敲程式碼，但同時參與3個專案，感覺略累，這是一場馬拉松，要麼走過終點吐口氣，要麼走火入魔。
經過大概一個月的準備，8月份一個正式的創業專案終於確定下來，進入開發階段。
該專案雖然技術難度不高，屬於是垂直領域的產品，但大大的挑戰還是有的。
我們的優勢：
線下運營團隊已經實戰兩年，並且有過萬的客戶量，領頭大哥也有強悍的市場地推能力。
技術成員有2個，並且熟悉該業務；具備國際視野的設計師有1個。
我們的挑戰：
我們是學生團隊。技術不夠強悍，對外招聘又不現實。
解決方案：
我出面找有比較有能力的學生參與進來，最終專案成員有7人；一人設計，一人APP介面實現，一人APP整合，一人APP互動，一人web前端，一人java後端，而我來做架構&專案管理。
OK，簡單的前期鋪墊就到這裡，接下來進入本文主題，按敏捷開發宣言的路線走。
敏捷開發宣言：
個體和互動 勝過 過程和工具
團隊合作的最大難度不是技術，而是人。對於我們這個立馬從外部拉起，立馬開工的團隊，敏捷開發適合我們嗎？要知道，敏捷開發最重要的就是團隊默契，其次是個人綜合能力，最後就是專長。在這個點上，有一個比較成熟的套路，那就是每天幾分鐘的站立會議，大家來交心，昨天做了什麼，今天要做什麼，遇到什麼問題&解決思路。但這個套路我們用不了，因為我們工作時間太過自由（不是公司制度）。一開始是這樣的，我跟大家說，我們每天下午一起到機房工作如何？其它時間就自由安排。但只有3人說可以做到這樣。緣由就不說了，沒問題的，有時需要集結，再一起過來就行了。 敏捷開發的話，團隊協作
目前的主要個體互動點是這樣的：設計&APP介面實現；APP整合&APP互動；web前端&java後端；我&所有人；但沒有極限程式設計的元素。
可以工作的軟體 勝過 面面俱到的文件
我們只有簡陋版的文件，用word表格畫的介面，標誌其關聯的資料庫表。
我也只通過processon.com做了簡單的概念架構圖等，把每個模組說明清楚，具體設計&實現就交由相關負責人（當然不是丟過去就是了~）
事實證明，我們在開發過程中，需求還是在改動的，有時是減法，有時是改進，因為能力有限，沒辦法預先拿出最佳方案。
可以工作的軟體，不一定是整合完的，不同人不同時間做出來的模組，都是“可以工作的軟體”，軟體出來了，思考點馬上就清晰了。當然每週任務交付，也不是那麼容易實現的，我設計的第一次迭代任務，就完成不了了，所以現在的話，提早進入了大亂鬥階段，整合工作放後，增強溝通，防止戰場分散得太厲害。
客戶合作 勝過 合同談判
我們是為自己開發的，當然也有客戶，因為專案不是我們技術團隊主導的，而是市場運作人員。但即使是內部人員，也無法在一起工作，他們經常要跑動，我們不想出宿舍。開發人員一般也不喜歡開會，所以，每週我會跟客戶碰面兩次，討論進展&各種情況，回來可能會調整下載工作計劃。
響應變化 勝過 遵循計劃
雖說這一點是敏捷開發的好處，但誰願意聽到“變化”這兩個字？需要“變化”，是誰的錯？
一次完整的開發，就是一場戰爭，一鼓作氣，再而衰，三而竭！
所以響應變化，只能出現在我這個環節。開發前要把各主要系統獨立開來，在第一次迭代的過程中，就得與客戶確定第二次迭代的內容，當然客戶是不懂的設計迭代的內容的，所以由我來安排優先序，最不確定的，最可能改變的，就先不做。（一般是建議最重要，最簡單的先做，但我會加多考慮，是否是容易變化的）。