軟體過程與專案管理（第五周作業）

標籤：

淺談我們團隊敏捷開發過程中的問題

　　一開始，我們團隊選擇敏捷開發，是覺得我們的項目也不是特別龐大複雜，我們同學之間相互溝通瞭解比較多，不想讓寫文檔佔用太多時間，最後又覺的它是新型軟體開發方法，想嘗試一下，於是最終選擇了敏捷開發作為我們團隊此次的軟體開發方法。但是兩周下來，我發現可能是因為我職責上的一些疏忽，使得大家並沒有進入到敏捷開發的狀態。現總結反思如下：

　　首先，敏捷開發中強調個體和互動勝過過程和工具，在開發小組中最有效率也最有效果的資訊傳達方式是面對面的交談。起初，我認為大家都是同學，平時就有溝通交流，每天上課會見面，肯定少不了面對面的交談。但實際情況並非如此，上課的時候大家坐的都很分散，平時即使見面聊天也很少聊到進行中的項目。我在群裡說有問題就提出來大家一起討論，也極少有人回應，結果，最後大家對於我們的項目並沒有太多的溝通交流，反而都只是把自己的想法寫到了所分配的相應的文檔中，雖然寫文檔的時候是采結對完成的，但也只是兩三個人的交流。我的計劃是後面會盡量找時間邀大家一起開個會什麼的，如果大家不想走路的話，可以群內語音解決，讓大家提前想好自己有什麼問題需要解決，然後集體討論解決，讓大家真正融入這個大團隊中，而不是像一盤一吹就散的散沙。

　　其次，敏捷開發提到過度自信是編程的職業病，反饋則是其處方，每隔一定時間，團隊都要總結如何更有效率，然後相應地調整自己的行為。我感覺我們團隊內部沒有形成良好的及時反饋的風氣，下面每個小組都獨自的默默的做自己負責的模組，我不太清楚他們分別進展到哪一步了，也可能是因為前期主要是學習與設計，編碼工作的進展還比較緩慢所以沒有太多可以反饋的內容。我的想法是後面建立反饋機制，每周定個時間讓每組派一名代表向我進行進度彙報以及階段總結，然後再相應調整後面的計劃，使得一個團隊的所有小組能夠協同工作，不會拉開太大的時間差距，致使最後項目的整合延期。

　　最後，敏捷開發主張簡單，儘可能減少工作量的藝術至關重要。我們在對第一版產品的設計過程中也考慮到了這一問題，暫時不需要的第二版中需要實現的一些功能我們都沒有設計。輕裝上陣，模型盡量簡單一些，這樣也更方便日後的改進與完善。

　　我相信，隨著項目繼續深入的進行，以及不斷的摸索與學習，我會漸漸瞭解到敏捷開發的真正內涵，並且帶領大家逐漸步入正軌，感受敏捷開發的風格與特色。

軟體過程與專案管理（第五周作業）