事后諸葛亮分析

---

Alpha沖刺，很多同學經(jīng)歷了“Learning by doing”的學一門新的編程語言、學Git、學做一個完整的項目。但是，各組對于軟件工程的“Learning by doing”的內涵了解的還不深刻，遇到的問題也不少。停一停，開個總結會，來次事后諸葛亮，為了下一步走的更好。請各小組在Deadline之前，召開事后諸葛亮會議，發(fā)布一篇事后分析報告。

1.總結的提綱內容，請參照課本15章內容或鄒欣老師的博客：

a. 項目管理之事后諸葛亮會議：http://www.cnblogs.com/xinz/archive/2011/11/20/2256310.html

設想和目標 1. 我們的軟件要解決什么問題？是否定義得很清楚？是否對典型用戶和典型場景有清晰的描述？我們要解決的問題是一個能夠導入課程表的個人學習計劃提醒系統(tǒng)。在之前的需求規(guī)格說明書有隊典型用戶和典型場景有清晰的描述。 2. 我們達到目標了么（原計劃的功能做到了幾個？ 按照原計劃交付時間交付了么？ 原計劃達到的用戶數(shù)量達到了么?)?功能都有做，就是交互方面實現(xiàn)的不是太好，目標還沒達到，幾個功能不足的地方將在beta版本進行改進。 3. 用戶量, 用戶對重要功能的接受程度和我們事先的預想一致么?我們離目標更近了么?因為只完成了alpha版本所以用戶量是微小的，只有幾個好朋友。且功能目前不是實現(xiàn)的非常好，所以現(xiàn)在的用戶體驗是暫時的。還要看最終的成品。- 有什么經(jīng)驗教訓? 如果歷史重來一遍, 我們會做什么改進?設想很豐滿，現(xiàn)實很骨感。。目標定得不夠細致，應該將目標分的更加細致。計劃 1. 是否有充足的時間來做計劃? 時間不是非常充足，且大家都不太知道如何更好地利用時間來做計劃。 2. 團隊在計劃階段是如何解決同事們對于計劃的不同意見的？主要通過會議解決，畢竟隔壁宿舍，有問題面對面交流，加上隊長大人發(fā)言一般不同的聲音很快就會變成統(tǒng)一意見的。 3. 你原計劃的工作是否最后都做完了? 如果有沒做完的，為什么?是有沒做完的，一是時間問題，二是考慮欠缺，會在beta版本好好完善的。 4. 有沒有發(fā)現(xiàn)你做了一些事后看來沒必要或沒多大價值的事?有！！大部分的團隊成員對于這一點答案還是相當統(tǒng)一的。但是做了也沒什么壞處，把糾結做這件事有沒有意義的時間還不如就做了呢。 5. 是否每一項任務都有清楚定義和衡量的交付件?只能說是模糊的。說清楚好像有點太自信的感覺了。。 6. 是否項目的整個過程都按照計劃進行，項目出了什么意外？有什么風險是當時沒有估計到的，為什么沒有估計到?幾乎是按照計劃進行的，在隊長的有效領導下，進行的也蠻順利的。但是到最后發(fā)現(xiàn)還是有出現(xiàn)差錯的地方，會在接下來的beta版本進行完善。至于風險還是有的，比如說項目alpha版本演示的時候，隊長請假了，主心骨沒了，大家還是很著急的~ 7. 在計劃中有沒有留下緩沖區(qū)，緩沖區(qū)有作用么?有，因為團隊成員的能力還是有差距的，進度就不太一樣，所以還是需要緩沖區(qū)的。 8. 將來的計劃會做什么修改？（例如：緩沖區(qū)的定義，加班）更加明確緩沖區(qū)的長度。- 我們學到了什么? 如果歷史重來一遍, 我們會做什么改進?計劃還是得根據(jù)個人能力定制，緩沖區(qū)還是要有的，要適當考慮可能的風險因素，要做好風險應對策略。資源 1. 我們有足夠的資源來完成各項任務么?我們做的是web開發(fā)，所以資源不是什么大問題。 2. 各項任務所需的時間和其他資源是如何估計的，精度如何?估計的時間和實際的時間相差還是比較大的，進度差比較大，精度小。 3. 測試的時間，人力和軟件/硬件資源是否足夠? 對于那些不需要編程的資源 (美工設計/文案)是否低估難度? 還是處于簡單的測試階段，各方面的資源還是足夠的。不算低估難度。況且對美工方面，每個成員都會提一點小小的建議。 4. 你有沒有感到你做的事情可以讓別人來做（更有效率）?如果都給會的人做肯定會更有效率，但是分工合作一起查資料，可以幫助基礎不好的人提升項目代碼編寫的能力，也不失為另一種意義上的有效率。- 有什么經(jīng)驗教訓? 如果歷史重來一遍, 我們會做什么改進?對于資源方面，主要還是人員的分配方面，適當?shù)娜俗鲞m當?shù)氖隆Ｗ兏芾?1. 每個相關的員工都及時知道了變更的消息?那是肯定的，除了qq群之外，隔壁宿舍這個優(yōu)秀的條件，有啥消息在適當?shù)臅r間敲敲門面對面聊一聊就都知道了。 2. 我們采用了什么辦法決定“推遲”和“必須實現(xiàn)”的功能?一是看用戶的需求哪些是必須的，哪些是用戶沒有考慮而我們自己想做的；二是看項目要求的基礎功能，基礎功能要是沒了還說什么進階功能呢；三就是看自身的能力啦，如果有余力，功能越完善越好，主要是看時間的長短。 3. 項目的出口條件（Exit Criteria – 什么叫“做好了”）有清晰的定義么?我們的出口條件是能夠對每日任務進行操作，能夠導入課程表，能夠對每日任務進行評價，且可以進行用戶郵箱提醒。沒有明顯的bug，能夠正常運行基本的功能。--》這樣就是初步的做好了。 4. 對于可能的變更是否能制定應急計劃?并沒有，所以遇到緊急事件只能熬夜補救。 5. 員工是否能夠有效地處理意料之外的工作請求？我們工作外的請求就是別的學業(yè)啦，由于其他課的作業(yè)也比較多，有時候真的會面臨時間不夠的情況。但是大家還是兩邊抓緊，都沒有落下。- 我們學到了什么? 如果歷史重來一遍, 我們會做什么改進?變更管理的消息要及時散發(fā)給各個成員，務必讓大家及時接收到消息，對于可能的變更，要有預備的緊急應對策略。設計/實現(xiàn) 1. 設計工作在什么時候，由誰來完成的？是合適的時間，合適的人么？原型設計是項目的開頭，由翁珊和謝曉萍完成，合適的時間，由于她們也是前端代碼編寫的人員，也是合適的人員。 2. 設計工作有沒有碰到模棱兩可的情況，團隊是如何解決的？有。比如說有考慮過做網(wǎng)頁的字體格式，后來在實現(xiàn)的時候，也沒時間，也覺得不是非常的必要，大家綜合考慮就決定放棄了。 3. 團隊是否運用單元測試（unittest），測試驅動的開發(fā)（TDD）、UML,或者其他工具來幫助設計和實現(xiàn)？這些工具有效么？尚未運用。 4. 什么功能產(chǎn)生的Bug最多，為什么？在發(fā)布之后發(fā)現(xiàn)了什么重要的bug?為什么我們在設計/開發(fā)的時候沒有想到這些情況?數(shù)據(jù)庫交互功能產(chǎn)生的bug最多，數(shù)據(jù)庫的數(shù)據(jù)無法在HTML頁面中展示并困惑了許久，花費了大量時間進行了修整。因為低估了Python語言和MySQL的相適應性。（換句話說，用Python和MySQL搭配有點坑，應該轉用SQLite） 5. 代碼復審（Code Review）是如何進行的，是否嚴格執(zhí)行了代碼規(guī)范？不算嚴格執(zhí)行。 - 我們學到了什么? 如果歷史重來一遍, 我們會做什么改進?提前把MySQL的程序模塊寫好。測試/發(fā)布 1. 團隊是否有一個測試計劃？為什么沒有？有。 2. 是否進行了正式的驗收測試？暫時還沒有，只是各成員自己對自己負責的模塊進行很初步的測試。 3. 團隊是否有測試工具來幫助測試？coverage插件進行測試。 4. 團隊是如何測量并跟蹤軟件的效能的？從軟件實際運行的結果來看，這些測試工作有用么？應該有哪些改進？使用了多種瀏覽器進行測試，并無太多問題，同時在郵箱驗證過程中采用了多種SMTP供應商的服務來進行測試，比如，Sina，Gmail，Tencent，Yahoo等，來確保郵件服務的穩(wěn)定性。 5. 在發(fā)布的過程中發(fā)現(xiàn)了哪些意外問題？服務器部署出現(xiàn)意外。 - 我們學到了什么? 如果歷史重來一遍, 我們會做什么改進?提前學習服務器部署知識。Apache+Mysql+PHP的部署比Python Flask+MYSQL要容易的多。團隊的角色，管理，合作1. 團隊的每個角色是如何確定的，是不是人盡其才？結合自身的能力，再通過自薦，權衡進行確定的。算是人盡其才了。 2. 團隊成員之間有互相幫助么？ 當然有，幫助是相當相當?shù)拇蟆Ｈ绻麤]有成員之間互相的幫助，肯定是沒有現(xiàn)在的成果的。 3. 當出現(xiàn)項目管理、合作方面的問題時，團隊成員如何解決問題？通過會議，大家提出意見看法，一起討論最后的解決方案。每個成員明確公開地表示對成員幫助的感謝 （并且寫在各自的博客里）：我感謝 _______<姓名>______對我的幫助， 因為某個具體的事情: _____________________。成員博客：詳見下方團隊成員的角色表格。- 我們學到了什么? 如果歷史重來一遍, 我們會做什么改進?每個角色要用適合的人選擔任，成員之間要互相幫助，大家互相幫助，共同進步。總結:你覺得團隊目前的狀態(tài)屬于 CMM/CMMI 中的哪個檔次?二級，管理級。 你覺得團隊目前處于 萌芽/磨合/規(guī)范/創(chuàng)造 階段的哪一個階段?目前我們的團隊已經(jīng)完成了alpha階段的沖刺，沖刺階段中的分工合作進行的有條理，可以算是正在磨合走向規(guī)范的階段。 你覺得團隊在這個里程碑相比前一個里程碑有什么改進? 1.成員都有了一定的或多或少的經(jīng)驗；2.成員的感情一步步變得更加緊密，合作起來更加的順利。 你覺得目前最需要改進的一個方面是什么?加強訪問頁面的穩(wěn)定性，做好一些小bug的完善。 對照敏捷開發(fā)的原則, 你覺得你們小組做得最好的是哪幾個原則? 請列出具體的事例。 1.業(yè)務人員和開發(fā)人員在項目開發(fā)過程中應該每天共同工作。--雖然沒有共同工作，但是做到群內討論。2.以有進取心的人為項目核心，充分支持信任他們。--組員相互信任，尤其信任組長。3.時時總結如何提高團隊效率，并付諸行動。

b. 全組討論的照片。

2.團隊成員在Alpha階段的角色和具體貢獻：

名字角色團隊貢獻分可驗證的貢獻

翁珊	前端	18.5	前端頁面代碼編寫
謝曉萍	前端	17.3	前端頁面代碼編寫
黃月梅	后端	17.5	后端功能代碼編寫
徐曉珊	數(shù)據(jù)庫	18.7	數(shù)據(jù)庫設計
龐伊凡	后端	30	后端功能代碼編寫
趙婭汀	測試	18	最后的測試功能

且每個人都積極參與團隊博客的撰寫工作，除組長以外大家的工作量都差不多，所以采用了以上的團隊貢獻分分配。

轉載于:https://www.cnblogs.com/KKlist/p/6837768.html

總結

以上是生活随笔為你收集整理的团队作业7——Alpha冲刺之事后诸葛亮的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內容還不錯，歡迎將生活随笔推薦給好友。