【2017下集美大學軟工1412班_助教部落格】團隊作業9——事後分析（Beta版本）成績公示

作業要求

團隊作業9

團隊評分結果

編号	Total	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31	32	33	34	35	36	37	38
PHILOSOPHER		0.4	0.5	0.2											0.1		0.3											-0.5
音樂播放器	16.9	0.6	0.8					0.7																1.5
部落格管理系統	10.9
三人行	2.2

評分标準

組成部分	檢查項	分數
總分
設想和目标	我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？
和上一個階段相比，團隊軟體工程的品質提高了麼？ 在什麼地方有提高？具體提高了多少？如何衡量的？
我們達到目标了麼（原計劃的功能做到了幾個？ 按照原計劃傳遞時間傳遞了麼？ 原計劃達到的使用者數量達到了麼?)
使用者量, 使用者對重要功能的接受程度和我們事先的預想一緻麼? 我們離目标更近了麼?
計劃	是否有充足的時間來做計劃?
團隊在計劃階段是如何解決同僚們對于計劃的不同意見的？
你原計劃的工作是否最後都做完了? 如果有沒做完的，為什麼?
有沒有發現你做了一些事後看來沒必要或沒多大價值的事?
是否每一項任務都有清楚定義和衡量的傳遞件?
是否項目的整個過程都按照計劃進行，項目出了什麼意外？有什麼風險是當時沒有估計到的，為什麼沒有估計到?
在計劃中有沒有留下緩沖區，緩沖區有作用麼?
将來的計劃會做什麼修改？（例如：緩沖區的定義，加班）
資源	我們有足夠的資源來完成各項任務麼?
各項任務所需的時間和其他資源是如何估計的，精度如何?
測試的時間，人力和軟體/硬體資源是否足夠? 對于那些不需要程式設計的資源 (美工設計/文案)是否低估難度?
你有沒有感到你做的事情可以讓别人來做（更有效率）?
變更管理	每個相關的員工都及時知道了變更的消息?
我們采用了什麼辦法決定“推遲”和“必須實作”的功能?
項目的出口條件（Exit Criteria – 什麼叫“做好了”）有清晰的定義麼?
對于可能的變更是否能制定應急計劃?
員工是否能夠有效地處理意料之外的工作請求？
設計/實作	設計工作在什麼時候，由誰來完成的？是合适的時間，合适的人麼？
設計工作有沒有碰到模棱兩可的情況，團隊是如何解決的？
團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實作？這些工具有效麼？
什麼功能産生的Bug最多，為什麼？在釋出之後發現了什麼重要的bug? 為什麼我們在設計/開發的時候沒有想到這些情況?
代碼複審（Code Review）是如何進行的，是否嚴格執行了代碼規範？
測試/釋出	團隊是否有一個測試計劃？
是否進行了正式的驗收測試？
團隊是否有測試工具來幫助測試？
團隊是如何測量并跟蹤軟體的效能的？從軟體實際運作的結果來看，這些測試工作有用麼？應該有哪些改進？
在釋出的過程中發現了哪些意外問題？
總結	你覺得團隊目前的狀态屬于 CMM/CMMI 中的哪個檔次?
你覺得團隊目前處于 萌芽/磨合/規範/創造 階段的哪一個階段?
你覺得團隊在這個裡程碑相比前一個裡程碑有什麼改進?
你覺得目前最需要改進的一個方面是什麼?
對照靈活開發的原則, 你覺得你們小組做得最好的是哪幾個原則? 請列出具體的事例。
照片
成員貢獻

團隊分數變化

助教有話說

1. PHILOSOPHER 緩沖區沒利用起來，一開始的規劃并沒有做好。照片直接貼的原來部落格的，倒扣對應分數
2. 三人行的部落格博文深得一字經真傳，不過可能正如三人行組長所說，談到經驗教訓說：“　選個自己的題目，從頭做起，才好做下去。” 但是這博文寫作的态度，真的有很大的改進空間。
3. 音樂播放器做的還算不錯，博文的内容還算全面
4. 部落格管理系統博文缺失了設計與實作部分