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