Alpha事后诸葛亮

组长博客连接：https://www.cnblogs.com/cmlei/p/11924459.html

1.设想和目标

1.我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？

解决福大校园内学生难以发布任务以解决自身需求的问题

定义清楚，多指人力需求任务，如跑腿、宿舍维修等，

对典型用户和典型场景有清晰的描述，如：A需要人帮忙从食堂带一份外卖，在同学帮平台发布任务并留下联系方式，B在同学帮看到该任务并选择接取，拿到外卖后通过联系方式联系到A完成任务，获得报酬

2.我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)?

做到了以下七个：利用数据库技术对用户发布的各种信息进行管理。用户可以发布任务，撤销任务 ，通过个人页面查看自己已发布的任务和接受的任务。并且通过任务详情内的联系方式完成交易双方的沟通，最终完成任务/交易。APP 内提供搜索功能，帮助用户快速找到自己期望的任务或者交易物品。

已按照原计划时间交付

用户数量达到

3.用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?

用户量不一致，暂时使用的只有组里几个人

接受程度一致，组员们都用的还行

更近了

4.有什么经验教训? 如果历史重来一遍, 我们会做什么改进?

预先做好详细的团队部署，精确到每日安排与备用计划，做好每个功能在开发过程中的代码分配

2.计划

1.是否有充足的时间来做计划?

有，我们很早就开始了计划，时间上较为充足

2.团队在计划阶段是如何解决同事们对于计划的不同意见的？

在开会时各抒己见，将各人的意见记录下后，主导大方向的意见通过投票决定，其余意见通过讨论合适程度拍板

3.你原计划的工作是否最后都做完了? 如果有没做完的，为什么?

4.有没有发现你做了一些事后看来没必要或没多大价值的事?

5.是否每一项任务都有清楚定义和衡量的交付件?

每一项任务都有很清楚的定义，但衡量交付标准则不一定，因为例如前端UI界面设计这一类随开发人员审美变化大的任务无法进行硬性界定

6.是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?

中间因为碰到多次考试而导致在准备阶段与冲刺阶段项目的实际建立过程出现延缓，我们因疏忽而未提前做好预先分工调配，没有为每个人安排第二任务以便突发情况下填补人手，导致项目开发进展并不顺利

7.在计划中有没有留下缓冲区，缓冲区有作用么?

没有，因为计划时不了解缓冲区的概念。

8.将来的计划会做什么修改？（例如：缓冲区的定义，加班）

将来会将任务集中在一段时间完成，而不是平摊到整个任务周期。

9.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

长痛不如短痛，远见胜过疏忽，预先安排人手分工与准备突发情况备用计划，一次性完成任务是最好的

3.资源

1. 我们有足够的资源来完成各项任务么?

   有，本组有数位优秀的同学带飞，如熔炜，润秋，洪威等巨佬，服务器也具备，但因尚未进行高压测试所以暂时无法估计服务器资源是否足够

2. 各项任务所需的时间和其他资源是如何估计的，精度如何?

   各项任务所需的时间和其他资源的估计是基于团队成员过往经验以及询问有开发经验的学长所得，十分粗糙

   精度方面，我们没有确切估计，但是相比于我们咨询的学长，我们在本项目上的耗时相对更多一些，但是质量方面却无从考究

3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?

   测试的时间，人力与软件/硬件资源足够，难度上可能略微低估了美工设计的难度

4. 你有没有感到你做的事情可以让别人来做（更有效率）?

   按大家来看的话，每个人都在自己最合适的位置上，但是若考虑到效率这一方面的话，肯定多少会存在差异性

5. 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?

   我们会更均等安排各人任务，不让大佬承担太多担子，同时也要考虑大家个人时间是否充足，让计划在制定时突出人性化

4.变更管理

1.每个相关的员工都及时知道了变更的消息?

组内成员都有及时知道变更的消息，我们有建立QQ群，随时在群内交流

2.我们采用了什么办法决定“推迟”和“必须实现”的功能?

一般是PM根据实际情况决定

3.项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?

我们计划要完成的项目功能就是我们的出口条件。

4.对于可能的变更是否能制定应急计划?

能，组长与攥写文档的同学随时沟通，备有后备计划

5.员工是否能够有效地处理意料之外的工作请求？

在与当前任务不冲突的情况下可以，大家都很厉害

6.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

计划赶不上变化，无论如何都会出现意外情况（比如考试期间无暇分心，影响了alpha版本开发的进度），在计划的时候要设置缓冲区以应对未知的变更。

5.设计/实现

1.设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？

设计在分工结束后就由各分组负责人完成，时间和人选都很合适

2.设计工作有没有碰到模棱两可的情况，团队是如何解决的？

有，比方说不确定这个任务能不能按这样的设计实现，解决方式是询问学长、查询资料与开会讨论

3.团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？

使用了Pycharm和单元测试功能与人力手动测试

4.比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？

区别极大，如某个功能一开始我们设想的极为全面，但现在的状态下该功能我们进行了一定的精简与优化，相印的内容也进行了修改，项目开始时的文档是基于我们的空想完成的，实际开发过程中不断地在调整，需要更新的

5.什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?

数据接收方面，代码上可能有一点小疏漏，比如发布任务后无法自行刷新，需要手动退出再进入才能刷新， 开发的时候有考虑到，但是这个是要通过大量的训练才能解决且疏漏时而难以避免，开发过程中只能尽力而为

6.代码复审（Code Review）是如何进行的，是否严格执行了代码规范？

时间紧任务重，未能进行代码复审，也未能严格执行代码规范。

7.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

代码编写任务分配需平均，代码复审应该随时进行，而不是等项目完结后再进行。代码规范亦是如此。

6.测试/发布

1.团队是否有一个测试计划？为什么没有？是否进行了正式的验收测试？

有，但较为粗糙，就是在完成雏形之后先使用人力测试

2.团队是否有测试工具来帮助测试？

无

3.团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？

暂无这方面的安排

4.在发布的过程中发现了哪些意外问题？

软件暂未发布

5.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

分配足够的人手进行测试，同时测试计划应该紧随开发计划之后指定，并随实际开发进度调整

7.团队的角色，管理，合作

1.团队的每个角色是如何确定的，是不是人尽其才？

角色主要是成员自荐，基本上自荐之后就完成了分工。目前看来基本上达到了人尽其才

2.团队成员之间有互相帮助么？

有，大家都很热情，也都很有耐心，开发过程中互相之间会交流合作

3.当出现项目管理、合作方面的问题时，团队成员如何解决问题？

平心静气地讨论解决

每个成员明确公开地表示对成员帮助的感谢 （并且写在各自的博客里）：

我感谢 对我的帮助， 因为某个具体的事情:

我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

沟通是解决问题的唯一途径，不急不躁方可成事

8. 总结:

1.你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?

属于CMMI一级 ， 软件组织对项目的目标与要做的努力很清晰，项目的目标可以实现。但是由于任务的完成带有很大的偶然性，软件组织无法保证在实施同类项目时仍然能够完成任务。项目实施能否成功主要取决于实施人员

2.你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?

磨合阶段，大家彼此之间交流很愉快，但尚缺少些许默契

3.你觉得团队在这个里程碑相比前一个里程碑有什么改进?

形成了合作意识，培养了制动性

4.你觉得目前最需要改进的一个方面是什么?

任务分配需要更加合理，计划也应提前制定，即预见性和大局规划还要加强

5.对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例

避免不必要的开销：我们的项目计划和文档加起来一共只有三篇，我们开发过程中计划的制定与更改多以口头讨论和网络交流为主，减少了耗费在文本纸墨上的时间

说真话：我们不说假话，不说空话，胡乱编造只会加大开发难度

本次贡献比例：

组员	贡献占比
陈明磊	9%
林镕炜	15%
韩洪威	7%
杨润秋	15%
李欣凯	8%
陈舒洋	8%
陈锦杰	8%
陈振旺	7%
胡浩楠	8%
钟伟硕	7%
陈锦鸿	7%
陈思涵	1%

1.PSP表格

PSP2.1	Personal Software Process Stages	预估耗时(分钟)	实际耗时(分钟)
Planning	计划	30	45
Estimate	估计这个任务需要多少时间	1300	1700
Development	开发	1100	1500
Analysis	需求分析 (包括学习新技术)	10	150
Design Spec	生成设计文档	60	90
Design Review	设计复审	40	60
Coding Standard	代码规范 (为目前的开发制定合适的规范)	60	60
Design	具体设计	6	60
Coding	具体编码	50	700
Code Review	代码复审	60	100
Test	测试（自我测试，修改代码，提交修改）	220	280
Reporting	报告	200	200
Test Report	测试报告	12	130
Size Measurement	计算工作量	40	10
Postmortem & Process Improvement Plan	事后总结, 并提出过程改进计划	40	60
	合计	1330	1845

2.学习进度条

第N周	新增代码（行）	累计代码（行）	本周学习耗时(小时)	累计学习耗时（小时）	重要成长
1	100	100	12	12	对应学的框架有一个初步的了解
2	100	100	12	24	对应学的框架有一个初步的应用