對軟體工程Alpha迭代的反思與總結

標籤：

對軟體工程Alpha迭代的反思與總結

　　本次軟體工程的A輪迭代，我們組出了不小的問題。作為一個團隊來說，我們的隊伍出現了很嚴重的狀況，嚴重到讓老師覺得我們一度失控。於是我撰寫此文，藉以反思、總結和提高。本文分三部分，在第一部分我將闡述我們在開發期間的一些過程，第二部分我將分析事情造成的原因，第三部分我將敘述一下我們下一步的解決方案。最後還有一點小小的反思。

 

一、事情的發生

　　當時我們組隊比較晚，本來想拆散了分去各個隊伍，後來正好還有同學沒有組上，老師就把我們剩餘的這些人成立了一個新組。所以我們在團隊初期就缺乏團體性。

　　然後我們這一個組就算正式組成了。在開始的時候，組內還可以保持一段時間的交流，真正開始做的時候，學院的實驗室有很急的項目，需要我們的主力開發人員去完成，並幫他請掉了所有科目的上課時間。這讓他在第一輪的迭代中異常狼狽。白天去實驗室，夜晚回來還要考慮軟體工程的團隊開發，略微拖慢了整個團隊的進度。而其他的同學沒有事情，卻也沒有補上他的位置。大家對於項目的積極性也不是很高，偶有做不完任務就去休閑娛樂的事情發生。

　　最大的問題在於我們的Scrum Meeting沒有寫好，這讓我們在第一輪迭代中每個人失去了幾十分。

　　對於這些問題，我將逐個分析。不逃避問題，要找出真正的解決辦法。

二．問題與原因

團隊模式：

       鄒老師在《構建之法》中曾經把團隊合作模式分為一窩蜂模式、主治醫師模式、明星模式、社區模式、秘密團隊模式等等，我們的團隊屬於主治醫師模式，有一個首席程式員，其餘人都是為他服務：

 

              這樣的團隊中，有首席程式員(Chief Programmer)，他/她負責處理主要模組的設計和編碼，其他成員從各種角度支援他/她的工作（後備程式員、系統管理員、工具開發、程式設計語言專家、業務專家）。

 

這個模型很好地概括了我們的問題。在我們團隊中，只有一個人明白當前代碼的所有架構。這充分導致了其他輔助程式員的效率低下。

       在項目開始，我們設計的模式是功能團隊模式。就像大多數團隊一樣分為PM，後端，前端，UI等。然而最後我們卻沒能掌控住。

       在敏捷開發中，我們主要以個人交流為主，開發人員們共同工作。這才符合敏捷開發的原則，而事實凸顯了我們交流不夠多的問題。這是敏捷開發的大忌。這部分是由於我們還違背了一條原則：

 

“以有進取心的人為團隊為項目核心，充分信任支援他們”。

 

       由於我們其中一名主力的缺席，這大大不僅托緩了我們團隊的進度（因為寫代碼的也就3個人，然而在這個時候還缺席一名主力），更為突出的問題是，加重了其餘開發人員的壓力。

敏捷開發：

       接下來該講講我們在Scrum Meeting 上的重大失誤。

              軟體開發流程有好多種，我們怎麼衡量一個開發流程是否對當前的項目/團隊合適？我覺得Scrum/Sprint能成功實施的關鍵在於Scrum Master。我聽到有些團隊也實施Scrum，但是他們隨機挑一個成員來做Scrum Master，好像Scrum Master就是招呼大家開開會，記錄每個人的進度而已，這種方法失敗的可能性很大。

       不得不說，這是我們的重大失誤。我們的Scrum Meeting 沒有按時發布，導致整個團隊的分數走低，對於這個問題，有幾名成員難辭其咎，我來逐個說一說：

1. 在分配任務的時候把PM和部落格的任務分開了，我的本心是平衡一下團隊貢獻值，能讓我們組的成員分數極差小一點。其實當時我是看了這句話：

Scrum Master 不是一個官，而是一個沒有權利的溝通者，就像微軟的PM那樣，他/她同時還要在團隊中做具體的工作。直接把原來的“經理”變成Scrum Master的方法大多行不通。

       現在事實告訴我們：PM和部落格不能徹底分開。否則一定會出問題。

我們還有一個問題是在迭代結束四天前，曾和老師通郵件說明我們部落格的缺失，表示要及時補上，然而當天晚上我們的組員一直在開發，不一會兒就把這件事忘掉了。導致最後的一次Scrum Meeting也沒能補上。

1. 第二是負責部落格的同學的大失誤。當時分配任務的時候，她的任務是負責部落格，我們要求她及時關注羅老師的動態，不全的資料找開發的同學要，要把組內的部落格寫好。可是她沒有及時更新團隊的部落格，比如功能說明和會議記錄，這導致了我們整體部落格的持久未更新。我想，如果能夠及時的看老師的部落格或者是及時的上課，就能知道老師的提醒，就不會出這麼大的問題了。
2. 第三是PM的問題。其實我們在本輪迭代的前半段，是基本處於無PM的狀態。我們發現了這個問題後，才任命一人為PM。按說PM一定要提醒所有人員的進度，但PM身兼數職，實在無法在兼顧所有任務。這個問題有更為致命的原因，我將在之後進行分析。

簡單地總結一下，我們的團隊有成員沒有達到敏捷開發的要求：自主管理，自我組織。

       自主管理：以前領導布置了任務，我們實現就可以了，現在要自己挑任務；每次Sprint結束之後，還要總結不足，提出改進，並且要自己實施這些改進。“自主管理”不等於“沒有管理”。

       自我組織：以前做好自己的事情就好了，安心下班。現在每個人要聯合起來對項目負責，有人工作落後了還有協助他改進，項目缺少某類資源自己還要頂上去。

       這件事情發生在團隊身上，就是“積極度不高”。大家沒有積極地把這件事情做出激情，對於團隊交代給的任務也沒有積極完成。比如說，如果留學生同學能夠主動的來要代碼，把我們分享的知識學習完全，寫部落格的同學能主動找開發人員要今天的進度。負責輔助首席程式員寫代碼的同學能夠主動的去要任務來減輕首席程式員的負擔，這些都是“自主”掌控的地方，而在這些地方我們掌控的都不好。

開發流程：

　　我們的團隊的開發流程是：

　　確定軟體需求<->分析<->程式設計<->編碼<->測試<->發布。基本是瀑布模型(Waterfall)的變種，又沒有像統一流程(Rational Unified Process)那麼繁瑣，敏捷開發嘛，文檔寫的不是很全。在整體的流程中大體還不錯，只不過出現了一些技術的斷檔，也就是說能懂整體架構的人只有一個，其他人都是去輔助他，實現具體的模組。現在反思，原因就在於：

　　　　產品模組之間的介面、輸入和輸出能很好的用形式化的方法定義和驗證。

　　　　使用的技術非常成熟，團隊成員都很熟悉這些技術。

　　在這兩點上，我們做的不夠。我們的開發是一個人負責一個模組，架構師總統這些模組。所以只有一個人熟悉所有的東西。

　　現在就得提到我們團隊另一個大問題：人手不夠。我們的留學生同學態度非常好，有些什麼任務安排給他會答應，只是——由於知識積累的不夠或者其他的原因，他們產出實在有限。絕大部分的事情都是另外五個組員在做。在這五個人中，一人負責所有的測試工作，一人負責部落格。所有的開發代碼都是由余下三任完成的。這也就是說，我們的開發人員只有三個人。比起其他的組，我們無疑有很大的劣勢，因為這會給予開發人員非常大的壓力，使其3個人能應付5個人的工作量。即使其他的隊員沒有什麼事情，也不會來主動做一些東西來分擔壓力。這是我們不團結的表現，足以讓我們引以為戒。這也刺激了我們去解決這些問題，改善組內的開發狀況，使整個項目可以達到我們的預期。

　　然而我們也有很多做的很好的地方，值得繼續發揚：

　　1.責任感和使命感。當開發時間緊、任務繁多的時候，我們還是完成了任務。其中做出了很大貢獻的是PM，他在開發主力不在的時候寫了很多代碼，使得我們在衝刺階段的時候少了一名開發隊員的情況下，仍然完成了初期的介面任務。記得那天晚上，淩晨2點他給缺席的開發主力發QQ，說我們有了一些成果，我看到成果的時候，還是為他的效率而驚訝，因為我們都是從零開始學安卓，而他只用了6個小時就寫完了好多結構和介面。在接下來的時間裡，我再接手時也得到了他的很多協助。這次我們隊伍在軟體工程的A輪迭代能夠達到預定目標，和他有非常大的關係。在我回來後我們仍加班加點的工作，直到完成我們A輪的計劃目標。

　　2.通攬全域的大局觀。當問題出來之後，隊伍第一時間想的是怎麼解決當前的問題，而不是先去追究誰的責任。當然，由於我們是績效分配，所有一定會考慮到每位同學的團隊貢獻，不讓付出的同學失望。對於工作少的同學，一定得在第二輪迭代裡面多做一些工作，否則怕是難以得到自己想要的分數。當然，我們責任制強調的也不夠多，讓一些同學想要水水就過。而事實上我們的任務很大，需要大家齊心協力。

　　最後我們想對老師說，我們不是放棄了，不是失控了，我們一直沒有中斷過對於軟體的開發。或許隊內確實發生了問題，但是絕不是放棄了希望。現在的結果我們很痛苦，也很難接受，所以我會再多做點工作，以提高整體的團隊成績。我們一直以能夠學到真正的軟體工程為豪。

 

三．做什麼改進

       剛才我們對於團隊發生的問題做了深度的透析，在我看來基本把所有潛在的矛盾都激化了出來。使得在分析我們的病因時能夠分析的更透徹。那下面就應該是我們治病的過程了。

       我們應對現在的棘手情況做出以下改進：

1. 我們認識到了具備一位統攬全域的PM之重要，在第二輪我們將任命一名專職的PM，以掌控全域。
2. 改善整體的團隊成員分配，我們需要在第二輪迭代中引進一位能夠編寫代碼的同學，這樣我們就有了4位主力進行開發。此舉能夠大大加快我們的進度。解決我們碼力不足的尷尬境地。
3. 提高全體成員的積極性。這對我們而言是不簡單的工作，因為我們還同時有編譯原理和資料庫作業，所以一定要拿出成果，及時播報成果，讓隊伍有了成就感，就自然有了團隊的向心力。這個任務交給黃上，由他來帶動整體的氣氛。
4. 完善E-R圖，清楚地寫明代碼的邏輯，方便後來的同學進行快速上手。這件事主要交給崔強去做，因為現在只有他熟悉整個架構。
5. 嚴格執行績效制度，想要得分就一定要對團隊有正貢獻。用以防止我們出現人手不足的這種情況，讓所有的同學能夠加入到開發過程中來。每次的任務都有任務點(Mission Point)來標記，最後將按照任務的權重來分配分數。

四．最後再多說一點，對於軟體工程的建議。

　　鄒老師的原意是把公司的軟體工程引進來，這給我們提供了很不一樣的視角，讓我們認識到在大公司中的開發是什麼樣子的。但是公司和學校是不一樣的。我們沒有辦法建立起一套能夠激勵隊員的制度，也無法真正對隊員的一些行為做出實質性的處罰或規約。更要考慮人際關係以及它所帶來的影響。所有的這些差別都會影響團隊的運作。

　　所以在明年的實驗中，對這些問題提出一些相對的方法可能會使整個課程的運作更加完善。感謝羅傑老師對我們的關懷、理解、提醒和支援，也感謝鄒老師帶給我們接近真實工作的體驗，我們在這一輪的過程中學到了很多東西。希望我們團隊能夠積極面對接下來的挑戰，攻克難關，笑傲風雨。

                                                                                                          

 

對軟體工程Alpha迭代的反思與總結