項目之路-敏捷開發菜鳥版

    一晃就又是一個月過去了，到了管理端，心里想的就是如何把亂七八糟的事情有序排列，讓團隊持續地的產出。雖說基本不用敲代碼，但同時參與3個項目，感覺略累，這是一場馬拉松，要么走過終點吐口氣，要么走火入魔。

    經過大概一個月的準備，8月份一個正式的創業項目終于確定下來，進入開發階段。

    該項目雖然技術難度不高，屬于是垂直領域的產品，但大大的挑戰還是有的。

    我們的優勢：

    線下運營團隊已經實戰兩年，并且有過萬的客戶量，領頭大哥也有強悍的市場地推能力。

    技術成員有2個，并且熟悉該業務；具備國際視野的設計師有1個。

    我們的挑戰：

    我們是學生團隊。技術不夠強悍，對外招聘又不現實。

    解決方案：

    我出面找有比較有能力的學生參與進來，最終項目成員有7人；一人設計，一人APP界面實現，一人APP整合，一人APP交互，一人web前端，一人java后端，而我來做架構&項目管理。

    OK，簡單的前期鋪墊就到這里，接下來進入本文主題，按敏捷開發宣言的路線走。

    敏捷開發宣言：

個體和交互 勝過   過程和工具

可以工作的軟件 勝過   面面俱到的文檔

我們只有簡陋版的文檔，用word表格畫的界面，標志其關聯的數據庫表。

我也只通過processon.com做了簡單的概念架構圖等，把每個模塊說明清楚，具體設計&實現就交由相關負責人（當然不是丟過去就是了~）

事實證明，我們在開發過程中，需求還是在改動的，有時是減法，有時是改進，因為能力有限，沒辦法預先拿出最佳方案。

可以工作的軟件，不一定是整合完的，不同人不同時間做出來的模塊，都是“可以工作的軟件”，軟件出來了，思考點馬上就清晰了。當然每周任務交付，也不是那么容易實現的，我設計的第一次迭代任務，就完成不了了，所以現在的話，提早進入了大亂斗階段，整合工作放后，增強溝通，防止戰場分散得太厲害。

客戶合作 勝過   合同談判

我們是為自己開發的，當然也有客戶，因為項目不是我們技術團隊主導的，而是市場運作人員。但即使是內部人員，也無法在一起工作，他們經常要跑動，我們不想出宿舍。開發人員一般也不喜歡開會，所以，每周我會跟客戶碰面兩次，討論進展&各種情況，回來可能會調整下載工作計劃。

響應變化 勝過   遵循計劃

雖說這一點是敏捷開發的好處，但誰愿意聽到“變化”這兩個字？需要“變化”，是誰的錯？

一次完整的開發，就是一場戰爭，一鼓作氣，再而衰，三而竭！

所以響應變化，只能出現在我這個環節。開發前要把各主要系統獨立開來，在第一次迭代的過程中，就得與客戶確定第二次迭代的內容，當然客戶是不懂的設計迭代的內容的，所以由我來安排優先序，最不確定的，最可能改變的，就先不做。（一般是建議最重要，最簡單的先做，但我會加多考慮，是否是容易變化的）。

結論

生活不易，碼農辛苦
如果您覺得本網站對您的學習有所幫助,可以手機掃描二維碼進行捐贈