事後諸葛亮分析

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

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

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

設想和目標

我們的軟件要解決什麽問題？是否定義得很清楚？是否對典型用戶和典型場景有清晰的描述？

相比傳統的筆記本記賬，電腦等，人們更喜歡通過手機來記賬，這樣隨時隨地都可以記錄自己的財務明細，更加及時了解自己的財務狀況，而不是很麻煩的用筆記本或者開電腦。所以，對於智能移動的終端開發軟件類型之一的記賬微信小程序設計是非常有意義的。定義比較清楚。典型用戶為大學生，很多學生感覺記賬是一件麻煩的事兒，不願意去記錄自己的消費情況，從而無法很好的了解自己的財務情況。所以，我們小組所做的就是制作一款專門針對於大學生的記賬小軟件。通過簡要方便的記賬形式，便利的操作模式改善或者促進用戶記賬的積極性及興趣，讓大學生了解自己的消費情況，從而有效控制花費，對自己未來的消費可以制定合適的計劃。

和上一個階段相比，團隊軟件工程的質量提高了麽？ 在什麽地方有提高？具體提高了多少？如何衡量的?

上一階段即http://www.cnblogs.com/xss6666/p/8824744.html 主要解決的問題有:
1.問題的定義及規劃
軟件開發與需求放共同討論，主要確定軟件的開發目標及其可行性。
2.需求分析
在確定軟件開發可行性的情況下，對軟件需要實現的各個功能進行詳細需求分析。需求分析階段是一個很重要的階段，這一階段做的好，將為整個軟件項目的開發打下良好的基礎。“唯一不變的是變化本身”，同樣軟件需求也是在軟件愛你開發過程中不斷變化和深入的，因此，我們必須定制需求變更計劃來應付這種變化，以保護整個項目的正常進行。
3.軟件設計
此階段中偶要根據需求分析的結果，對整個小程序系統進行設計，如系統框架設計、數據庫設計等。好的設計將為軟件程序編寫打下良好的基礎。
如果說上一階段是小程序開發的理論階段 那麽和上一階段相比我們進入了實踐階段 即 將小程序設計的結果轉化為計算機可運行的程序代碼。在程序編碼中制定統一、符合標準的編寫規範。以保證程序的可讀性、易維護性。提高程序的運行效率。

我們達到目標了麽（原計劃的功能做到了幾個？ 按照原計劃交付時間交付了麽？ 原計劃達到的用戶數量達到了麽?) 3 每一問1分

原計劃本軟件有如下功能：用戶登錄，並對用戶信息進行保密；(已實現)
可隨時增加，刪除，修改消費記錄；(已實現)
可以統計查詢出某天某月等的收入支出；(已實現)
可以對各項消費作預算；(待實現)
可以發現一些好的理財方式；(待實現)
備註功能。(待實現)
原計劃達到的用戶數量並沒有達到 ,因為服務器的配置是個問題 沒法發布,所以在Alpha階段只是面對內部的測試,並沒有公測.

用戶量, 用戶對重要功能的接受程度和我們事先的預想一致麽? 我們離目標更近了麽? 1

因為服務器的配置是個問題 沒法發布,所以在Alpha階段只是面對內部的測試,並沒有公測.所以用戶體驗不得而知.

計劃

是否有充足的時間來做計劃? 1

是,團隊成員多同一宿舍,有問題有想法隨時都可以交流.

團隊在計劃階段是如何解決同事們對於計劃的不同意見的？ 2

多人合作難免產生分歧,不過有分歧是好事，說明大家都在思考問題。需要讓大家知道共同目標是為微信記賬小程序的開發，實現利益最大化。可在適當的時候組織大家聚會暢談問題，不知不覺大家就解決了問題,而且不會為這次分歧而產生距離了.

你原計劃的工作是否最後都做完了? 如果有沒做完的，為什麽? 3

原計劃本軟件有如下功能：用戶登錄，並對用戶信息進行保密；(已實現)
可隨時增加，刪除，修改消費記錄；(已實現)
可以統計查詢出某天某月等的收入支出；(已實現)
可以對各項消費作預算；(待實現)
可以發現一些好的理財方式；(待實現)
備註功能。(待實現)

原因:團隊成員能力有限+時間有限.

有沒有發現你做了一些事後看來沒必要或沒多大價值的事? 2

一開始又想界面很炫，又想結構新穎，還想使用沒有過的新技術，結果進度很慢。

是否每一項任務都有清楚定義和衡量的交付件? 1

並沒有每一項任務都有清楚定義和衡量的交付件,功能能簡化就簡化，界面也簡單到極點，盡早做出能用的小程序.

是否項目的整個過程都按照計劃進行，項目出了什麽意外？有什麽風險是當時沒有估計到的，為什麽沒有估計到? 2

並沒有按照計劃進行,任何事物的發展都是前進性與曲折性的統一.主要問題是服務器的配置 ,沒人會.

在計劃中有沒有留下緩沖區，緩沖區有作用麽? 2

沒有.時間太緊迫.

將來的計劃會做什麽修改？（例如：緩沖區的定義，加班） 2

希望改進整個項目沒有指定裏程碑或規定設計評審期，什麽時間節點完成什麽任務不能如期，再去進行下一個階段的開發計劃與實施。攤子鋪得太大，人員和準備嚴重不足。

資源

我們有足夠的資源來完成各項任務麽? 1

並沒有足夠的資源.

各項任務所需的時間和其他資源是如何估計的，精度如何? 1

團隊成員根據自己擅長的方面在Alpha階段開始之前進行任務的認領以及自己進行所需時間的估計....精度還行,但是不高....經常有到時間不能進行任務的交付.

測試的時間，人力和軟件/硬件資源是否足夠? 對於那些不需要編程的資源 (美工設計/文案)是否低估難度? 2

小程序完成的並不是很好所以沒有更多的精力人力去進行小程序的測試.. 對於那些不需要編程的資源大大低估了其難度,特別啊,是這個博客ＥＭＭＭＭＭＭ．

你有沒有感到你做的事情可以讓別人來做（更有效率）? 2

有，各種文案的編輯．

變更管理

每個相關的員工都及時知道了變更的消息? 2

能及時知道變更的消息，團隊成員多同一宿舍,有問題有想法隨時都可以交流．

我們采用了什麽辦法決定“推遲”和“必須實現”的功能? 2

確定目的， 確定典型用戶群體， 準備詳細問題。先進行問卷調查，進行問題分組，整理，分析 .提取用戶的需求作為必須實現”的功能 .
團隊覺得有必要但用戶並沒有反饋的內容作為"推遲實現"的功能.(用戶答不上來的問題，錯過的信息，也可能非常重要)

項目的出口條件（Exit Criteria – 什麽叫“做好了”）有清晰的定義麽? 2

Alpha階段僅僅是滿足於“軟件可以使用”或“功能能夠實現”.

對於可能的變更是否能制定應急計劃? 1

沒有,團隊十分脆弱,隨時都可能解散了.

員工是否能夠有效地處理意料之外的工作請求？ 2

能. 工作進行過程中，難免會出現一些意外情況。為保證項目按計劃實施，不受影響，就要學會及時匯報。這樣做，一方面可以團隊一起商討進而調整策略.站立式會議均在強調不能將所有步驟都壓在完成時匯報，這個時候還是要考慮到每項任務的時間節點。能夠在對的時間，把事情提前做好.不能一些問題或者其他都“默默”承受，怕提出的問題讓他人認為自己的能力不行等各種考慮，其實完全沒有必要.

設計/實現

設計工作在什麽時候，由誰來完成的？是合適的時間，合適的人麽？ 1

在http://www.cnblogs.com/xss6666/p/8824744.html階段根據需求分析的結果，對整個小程序系統進行設計，如系統框架設計、數據庫設計等 .時間合理.

設計工作有沒有碰到模棱兩可的情況，團隊是如何解決的？ 2

設計工作有碰到模棱兩可的情況,小事可以含糊過去,比較重要的大家一起探討再確定.

團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實現？這些工具有效麽？ 1

開發時間所限，沒有做單元測試。在開發的過程中我們用到了UML圖展現各個模塊，這樣讓全體開發人員對於彼此間模塊的關聯都了解了一下，能大幅提升開發效率。

什麽功能產生的Bug最多，為什麽？在發布之後發現了什麽重要的bug? 為什麽我們在設計/開發的時候沒有想到這些情況? 4

增加，刪除，修改消費記錄功能產生的Bug最多.增加，刪除，修改消費記錄功能整體的難度是最高的.
1.備註與金額輸入為空（增加彈窗提示用戶）
2.如果你選擇支出但是金額寫的是負數，顯示出來的還是正數。
3.金額輸入字符串，導致合計為NULL,改進成輸入字符串彈框提示錯誤。
原因:沒有正規的代碼審查;沒有使用靜態分析工具;沒有好好測試

代碼復審（Code Review）是如何進行的，是否嚴格執行了代碼規範？ 1

首先每個模塊寫完，負責的同學都會進行一次自我的代碼復審。然後代碼匯總後，各同學再一次進行復審。
我們並沒有一個嚴格遵守代碼規範，但是我們簡要地說明了一些規則來保證代碼的可閱讀性，例如，變量名盡量起得比較有意義，要進行比較合適的註釋，再提交自己部分的代碼時要附上自己的測試代碼等。

測試/發布

團隊是否有一個測試計劃？ 2

沒有一個十分完整的測試計劃。Alpha階段時間緊任務重，又因為大家都是第一次進行軟件工程開發，經驗欠缺，無法一開始就制定明確的測試計劃。

是否進行了正式的驗收測試？ 1

沒有.

團隊是否有測試工具來幫助測試？ 1

基本上由手工實現。

團隊是如何測量並跟蹤軟件的效能的？從軟件實際運行的結果來看，這些測試工作有用麽？應該有哪些改進？ 2

沒有使用跟蹤軟件效能的工具，主要還是憑借人工的操作和體驗。因此，下一次叠代在這方面要做些功夫。

在發布的過程中發現了哪些意外問題？ 1

服務器配置問題導致的無法發布.

總結

你覺得團隊目前的狀態屬於 CMM/CMMI 中的哪個檔次? 1
初始級(initial)。工作無序，項目進行過程中常放棄當初的計劃。管理無章法，缺乏健全的管理制度。開發項目成效不穩定。
計劃不能按期完成，大致三種原因，1、計劃不合理；2、人員沒有抓緊；3、因其它計劃外的原因造成延誤
原系統的代碼規範但沒有較好的執行。
開發時因分工不明確，每個任務可能團隊所有的人都有參與，這其實出問題的風險是非常大。

你覺得團隊目前處於 萌芽/磨合/規範/創造 階段的哪一個階段? 1

散夥階段。
工作無序，項目進行過程中常放棄當初的計劃。管理無章法，缺乏健全的管理制度。開發項目成效不穩定。計劃不能按期完成。

你覺得團隊在這個裏程碑相比前一個裏程碑有什麽改進? 1
你覺得目前最需要改進的一個方面是什麽? 1

• 計劃不能按期完成，以後的階段會制訂更加詳細計劃，相關成員討論以決定計劃完成日期，制訂時間需要科學合理，如果明確後，相關成員需要盡量按時完成，若有特殊原因，比如技術難題，計劃外的事情耽誤等等，需要給出理由。再由成員共同商議解決時間，以保證全局的進度不受影響。
• 開發的時候，僅僅是滿足於“軟件可以使用”或“功能能夠實現”的情況，並沒有關註到每個設計、每次改動、每天的操作。

對照敏捷開發的原則, 你覺得你們小組做得最好的是哪幾個原則? 請列出具體的事例。 1
面對面的交談。沖刺階段每天都進行站立式會議，討論項目每個成員的昨天進展、存在問題、今天安排。
及時匯報。這樣做，一方面可以團隊一起商討進而調整策略.站立式會議均在強調不能將所有步驟都壓在完成時匯報，這個時候還是要考慮到每項任務的時間節點。能夠在對的時間，把事情提前做好.不能一些問題或者其他都“默默”承受，怕提出的問題讓他人認為自己的能力不行等各種考慮，其實完全沒有必要.
可用的軟件。 一致的目標都是盡早交付“可用的軟件”。

b. 博客要附上全組討論的照片。

2.根據展示博客中給出的團隊成員在Alpha階段的角色和具體貢獻排序：

• 既然同學們上這個軟件工程課，那麽就希望大家能夠認真的參與到軟件工程實踐中來。當然，同學們的投入程度會有所不同，所以我們就把大家做了哪些工作亮相給大夥看看，把這些情況量化出來，擺在大家面前。 醬油在哪裏，大腿在哪裏就一目了然。這樣我們的團隊貢獻分就很好決定了。

• **請根據每個團隊個人貢獻排序，總分為N*20，給出每個人的團隊個人貢獻分（排序無並列，因此每個人的個人貢獻分不同）。**

團隊作業7——alpha階段之事後諸葛亮分析