团队作业7——alpha阶段之事后诸葛亮分析

事后诸葛亮分析

Alpha冲刺，很多同学经历了“Learning by doing”的学一门新的编程语言、学Git、学做一个完整的项目。但是，各组对于软件工程的“Learning by doing”的内涵了解的还不深刻，遇到的问题也不少。停一停，开个总结会，来次事后诸葛亮，为了下一步走的更好。请各小组在Deadline之前，召开事后诸葛亮会议，发布一篇事后分析报告。

一、设想和目标

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

• 我们软件的需求针对的群体是家长和老师，可以用来考察和加强孩子对四则运算的掌握。
• 定义清楚：小程序中有基本的生成题目和批改功能，还有选择难度、排行榜和错题集功能。
• 典型用户是家长和老师；典型场景：有些时候家人想要考考孩子的计算能力，就可以打开这个四则运算小程序;老师想在上课前出一些计算题在课上考考学生，也可以用这个程序生成题目。

2.和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高？具体提高了多少，如何衡量的？

• 和结对编程相比，团队软件工程的质量提高了。经过团队合作，合理有序分配任务，我们团队在界面设计、编码规范有提高。

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

• 我们alpha阶段的原计划是完成界面设计、难度选择、生成题目、批改和发布小程序。现在已经完成了大部分，小程序的发布审核出现问题，批改功能目前只能查看正确答案。原计划达到的用户数量未达到。

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

• 用户对这个小程序的重要功能的接受程度和我们预想的一致，生成题目功能、难度选择功能与查看正确答案都正常。我们离目标更近了。

二、计划

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

• 时间有些不足，因为每个人都有自己的事情，还有其他的实验报告和作业，所以有些时候做计划的时间会错开。

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

• 开会讨论，每个人把自己的想法说出来，每个人在对这个想法说出自己的意见，所以我们团队还是挺融洽的。

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

• 原计划的工作还剩一个小程序的发布。因为第一次接触微信小程序，所以还需要花更多的时间学习。

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

• 没有，因为每个人的任务都是开会分配的，每次做的事对我们来说都是有价值的。

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

• 并没有每一项任务都有，不过大部分都可以在燃尽图中体现。

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

• 项目的整个过程并没有都按照计划进行，小程序的发布我们没完成。

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

• 没有留下缓冲区，缓冲区的作用是可以用来查找项目的bug、修复项目的不过和测试代码等。

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

• 之后会增加缓冲区，将每个人的空余时间利用起来，团队一起做项目，有问题的话可以相互讨论，会提高效率。

三、资源

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

• 在人员方面，我们团队都不擅长写代码，要花更多的时间在项目上才不会拖后腿；在时间上，我们每个人都有自己的事情，还有其他的实验报告和作业，所以有些时候做计划的时间会错开，做项目的时间也不是很足够；学习资源的话，由于最近小程序挺火的，所以挺容易在网上找到关于微信小程序的课程。

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

• 各项任务的分配我们都是经过讨论后确定的，所需时间也在learngo中的燃尽图中体现，而且在冲刺博客中也能看到。但是精度的话不高。

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

• 测试的时间挺充足的，虽然我们的小程序还没有发布。至于人力资源和软硬件资源前面有提到。
• 对于界面设计，做出来的界面有点丑，说到难度的话还是挺难的，没有想象的那样的美观。

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

• 没有，每个人都有自己比较擅长的方面，我们分配任务的时候很多都是让队员自己先选，然后再将任务分配完，所以我们觉得每个人做的任务应该是最有效率的。

四、变更管理

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

• 每个人都及时知道了变更消息。

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

• 也算不上什么办法。一个能供用户使用的上线产品，核心功能能够实现，比如我们软件的生成题目和计算，答案比对功能；可推迟的就是不影响用户使用功能，比如界面优化，精简，附加功能例如排行榜。

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

• 目前，我们的产品能生成题目给用户答题，并通过计算后给用户统计分数，存入后台数据库，并可以调出数据查看，就是我们项目的出口条件。

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

• 我们的程序核心功能就入上述描述一般，可能的变更在除去出现使用bug以外，变更只会增加用户体验功能，并不会对程序造成下线处理的情况。
• 所以应急计划就是由我们储存每一个可运行的版本，如果出现问题，替换。

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

• 可以。除非用户提出更难以实现的功能，涉及到更繁复的前后台与用户的交互，更难以实现的算法。

五、设计/实现

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

• 设计工作由组长邹其元在正式开始项目之前与项目进行中完成。是，是。

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

• 有。题目生成是以何种形式规则定义难度划分。
• 听一个人的。一种是以计算的数据位数决定难度，一种是以计算的次数，限定在100以内的计算划分难度。听一个人的，能有效解决这种难以定义的问题。最终我们选择后者。

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

• 还没有上线，暂时没有测试。

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

• 生成题目。这是因为算法实现问题。暂时还没发布。设计之时有想到我们会因为算法问题遭遇bug。

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

• 暂时还没有。

六、测试/发布

1.团队是否有一个测试计划？为什么没有？

• 没有。因为前期主要在题目生成功能上花费了不少时间，来不及制定一个测试计划。

2.是否进行了正式的验收测试？

• 没有，在Alpha阶段只完成了小程序的生成题目基本功能，还未完成后端与前端的数据交互。

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

• 使用的是微信自带的测试工具。

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

• 根据小程序生成题目时间来踪软件的效能。测试工作应该还是有用的，能发现小程序的不足之处。

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

• 暂未发布。

七、总结

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

• CMM/CMMI一共分为五个等级，(1)初始级(initial)；(2)可重复级(Repeatable)；(3)已定义级(Defined)；(4)已管理级(Managed)；(5)优化级(Optimizing)。
• 我觉得我们处于第二等级。

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

• 目前团队属于规范阶段。

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

• 首先明确了问题并得到了解决，比如题目难度划分规范
• 团队对于发现的问题存在矛盾时有了解决的优先选择

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

• 后台上线

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

• 简洁。对用户使用过程友好，并没有不合理的交互，呈现出简约的风格
• 过程每日汇总。每日都有过程汇总，每个人每天都有做出贡献，并且对整个项目都有信息的上传和更新了解。

6.照片

7.根据展示博客中给出的团队成员在Alpha阶段的角色和具体贡献排序：

组员	角色	团队贡献排序	可验证贡献	个人贡献分
邹其元	PM	1	题目生成功能的实现	35
吴剑通	开发	2	查看正确答案功能的实现	20
江鹭涛	测试	3	wxml界面的实现、测试	15
杨钧宇	开发	4	题目生成功能的实现，博客撰写	10