Author: 多人运动会
Project: Listen聆听
会议照片
设想和目标
- 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰得描述？
我们的软件要解决部分忙碌的人或不善于社交的人，提供给他们一个社交环境，可以让他们抛开现有的环境去进行交流沟通
2. 我们达到目标了么（原计划的功能做到了几个？按照原计划交付时间交付了么？原计划达到的用户数量达到了么？）
实现了原计划的匹配聊天，但没有完全实现原计划功能，由于无法经过微信小程序审核，无法上线，暂时获取不到用户量
- 团队在计划阶段是如何解决同学们对于计划的不同意见的？
在制定计划之前，会和各队员协商好，尽量匹配各个队员的技术栈，制定合理的目标
计划
- 是否有充足的时间来做计划？
有充足时间
2. 团队在计划阶段时如何解决同事们对于计划的不同意见的？
开会协商，并由队长决定方案
3. 你原计划的工作是否最后都做完了？如果有没做完的，为什么？
原计划主流程工作均做完，但是由于选题失误，无法上线微信小程序，附加功能没有继续实现
- 是否每一项任务都有清楚定义和衡量交付条件？
任务有清楚定义，但没有衡量交付条件
- 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险时当时没有估计到的，为什么没有估计到？
项目前期均按照计划进行，后期出现无法上线的意外，没有仔细阅读微信小程序的规范
- 在计划中有没有留下缓冲区，缓冲区有作用么？
没有
7. 我们学到了什么？如果历史重来一遍，我们会做什么改进？
在开发流程中，团队合作能力得到提升，学会如何配合团队进行开发
资源
- 我们有足够的资源来完成各项任务么？
对于UI设计方面则人手不够，对于开发方面，由于软件需要用到的技术过于单一，导致部分队友不能大展身手
- 各项任务所需的时间和其他资源时如何估计的，精度如何？
根据预测的代码量和测试量估计，精度有所偏差，部分功能实现比想象容易，也有部分功能遇到了难关
- 测试的时间，人力和软件/硬件是否足够？对于那些不需要变成的资源（美工设计/文案）是否低估难度？
测试时间足够，低估了对美工设计和文案的需求
- 你有没有感到你做的事情可以让别人来做（更有效率）？
有，我个人的组织能力不够，队伍在配合时较为松散，需要，偏向于开发
5. 有什么经验教训？如果历史重来一遍，我们会做什么改进？
选题探讨会更加细致一些，并尽量符合队员的技术栈
变更管理
- 每个相关的员工都及时知道了变更的消息？
每当出现新功能时，都会通知队员
- 我们采用了什么办法决定“推迟”和“必需实现”的功能？
在项目必经流程内的功能必需实现，附加功能或不影响软件正常使用的功能可以推迟
- 项目的出口条件（Exit Criteria - 什么叫“做好了”）有清晰的定义么？
软件没有重大Bug
能够承担一定的并发量
设计/实现
- 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计是由团队共同提出建议一起设计，最后由队长归纳完成
- 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
没有
- 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML，或者其他工具来帮助设计和实现？这些工具有效么？
团队没有运用单元测试工具进行测试
- 代码复审（Code Review）是如何进行的，是否严格执行了代码规范
当功能开发完毕并debug一段时间后回头复审，未能完全严格执行代码规范
测试/发布
- 团队是否有一个测试计划？为什么没有？
有测试计划，每次新功能出现时都会集中测试
- 是否进行了正式的验收测试？
无，由于一开始没有好好了解到微信小程序的开发限制，本项目功能并不允许在微信小程序上正式使用，导致无法发布，难以让用户参与测试
- 团队是否有用测试工具来帮助测试？
Postman以及微信公众平台
- 团队时如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有那些改进？
功能开发后交由队员进行用例测试，并能检查出bug，是有用的，应该多使用专门的测试工具来进行测试提高效率
5. 在发布过程中发现了哪些意外问题？
未提前了解微信小程序的申请发布限制，导致最终项目无法发布
团队的角色、管理、合作
- 团队的每个角色是如何确定的，是不是人尽其才？
团队角色都是由个人主动选择的，不过由于团队成员技术栈与方向均有一定差别，没有做到人尽其才
- 团队成员之间有互相帮助吗？
有的，开发总有遇到困难，会咨询队友，并且测试的时候大家都有帮忙
- 当出现项目管理、合作方面的问题时，团队成员如何解决问题
由队长和PM听取队员意见后开会议共同协商处理
总结
- 你觉得团队目前状态属于CMM/CMMI中的哪个档次？
达到了CMMI一级——执行级。我们的团队目标清晰且目标可以实现，但在任务完成度上取决与实施人员
- 你觉得团队目前处于 萌芽/磨合/规范/创造？ 的哪一个阶段
磨合阶段
- 你觉得目前最需要改进的一个方面是什么
小组开会讨论的流程
- 对照敏捷开发的原则，你觉得你们小组做的最好的是哪几个原则?请举例
主张简单，尽可能保证模型的简单，不过分构建软件，项目设计流程简明扼要
快速反馈，每当出现一个新功能，测试总可以很快的提出修改意见和bug反馈
- 代码管理的质量具体应该如何提高？代码复审和代码规范的质量应该如何提高？
代码的每次commit都需要规范化
代码每次提交后都应该由测试人员复审
代码复审应有专门的文档来规范复审流程
- 其他软件工具的应用，应该如何提高？
在测试方面，应该多了解一些有用的测试工具，方便开发
- 项目跟踪用户数据方面，计划要提高什么地方？例如你们是如何知道每日/周活跃用户数据的？
通过小程序的后台工具查看
- 项目文档的质量如何提高？
规范化，应建立一套模板，并每次开发结束后需要对文档进行回顾和补充
团队成员在Alpha节点的角色和具体贡献
| 名字 | 角色 | 团队贡献分 | 可验证的贡献 |
|---|---|---|---|
| 潘俊渊 | 队长 | 21 | 带领团队，撰写博客，开发 |
| 倪佳建 | 开发，测试 | 20.5 | 撰写博客，测试出多项bug |
| 张焜 | 开发，测试 | 20 | 撰写博客，完成后台开发 |
| 魏甫 | 开发，PM | 19.5 | 设计开发流程，组织团队开发 |
| 张鹏 | 开发，UI | 19.5 | 提供UI设计 |
| 马桂佳 | 开发 | 19.5 | 完成后台环境搭建 |