事后诸葛亮分析
我们
一、设想和目标
1.1我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们想要做一个集记账、日记和备忘录于一体的app，让用户使用更少的软件实现更多的功能。定义很清楚。对典型用户和典型场景有清晰的描述，如上所述，我们是为了减轻用户使用多种app的压力。
1.2是否有充足的时间来做计划?
在实现简单的功能上，我们有充足的时间，但所具备的问题就是，想要优化用户体验，可能需要的不仅仅是代码的问题，更需要沟通，沟通最消耗时间去做计划的一个环节。
1.3团队在计划阶段是如何解决同学们对于计划的不同意见的？
我们是综合了每个同学的能力去做的一个计划，因为学习新技术所需要的时间成本难以估计且学业上的压力也很大。从而我们更需要提出一个适合每个同学的计划，多次沟通后选择做一个app并且制定详细的项目流程。
1.4你们的目标会不会设定的太高而导致设想失败？
刚开始是有的，所以我们针对自身的能力，合理制定了目标去适配我们的设想。
二、计划
2.1你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
按照严格制定的计划，我们的工作是做完的了，如果有问题，那就是需要我们去进一步优化程序带给用户的体验。
2.2在做的过程中对于计划是否有过疑问？
一个好项目的最大魅力就在于计划永远不是所有人都会最终认同的，所以也提出过很多疑问，需求留还是砍，这个点有没有必要有没有价值，我们都讨论过很多。
2.3 是否项目的整个过程都按照计划进行?
因为团队大佬宇峰热情地鼓动和团队美丽女生委婉地劝谏，我们严格按照计划完成了项目。
2.4 在计划中有没有留下缓冲区，缓冲区有作用么?
有留下缓冲区，它的作用就是让我们更好地完善项目。
2.5我们在这次项目中学习到了什么？如果历史重演，我们会做什么改进？
对软件开发的流程有更多的了解，队员间的合作能力明显提高，也更好地认识了大家。我们希望我们能更有效地分配时间吧，比如说计划上有些事其实1-2个小时就可以搞定，而我们却分配了一天，就允许成员懈怠了。
三、资源
3.1我们有足够的资源来完成各项任务么?
后台我们有服务器，团队成员中有成员熟悉确切的技术。
3.2你有没有感到你做的事情可以让别人来做（更有效率）?
有的，比如说界面设计可以让UI来做，而不用ios开发去调大概的框架，需求分析让PM来做，测试报告让测试人员去负责，都能很好地完成任务。
3.3 各项任务所需的时间和其他资源是如何估计的，精度如何?
主要是根据任务的难度和量来估计的，也考虑到成员其他事务的压力。但有些任务的估计时间偏低了，因为我们低估了未知技术的难度。
3.4有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
分配任务的时候可能就没太考虑到某些成员的感受吧，可能其他人去做会比较好。改进自己的视野问题，从其他人的视角出发。
四、变更管理
4.1 每个相关的员工都及时知道了变更的消息?
由于我们建了个群，有什么信息我们都会在上面沟通，所以传播较快。
4.2我们采用了什么办法决定“推迟”和“必须实现”的功能?
推迟的功能，站在用户和开发人员的角度去预想，前者：用户会不会觉得这个功能鸡肋？后者：开发人员在实现这个功能的过程中会不会没有足够的能力从而需要更多的时间去研究如何实现？
必须实现的功能，就如我们预期所想的那样，让app集成三体于一体，不忘初衷，方得始终。
4.3 项目的出口条件（Exit Criteria）是否得到清晰的定义?
写作业的时候，大家对于出口条件不是很了解，但通过多方资料了解后，大家发现它也没有很难，但在项目中很少运用这个概念。
4.4对于可能的变更是否能制定应急计划?
基本没有变更，但是我们的人员分配方式能解决那些不存在的可能而导致的问题。
4.5成员是否能够有效地处理意料之外的工作请求？
可以。根据项目的展示情况来看，珮琳同学是基于兴趣去研究了app的logo样式，它的设计寓意也是很棒的，一些好的设计寓意，能提高用户对这个产品的幸福感，比如说云粉中的网易云音乐。
五、设计/实现
5.1设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
有些界面的设计过早，一些界面可有可无，大家都来讨论，事实上这些事情应该由制定需求的PM和开发者在后续的开发中确定是否需要。
5.2设计工作有没有碰到模棱两可的情况，团队是如何解决的？
有一点，关于备忘录和待办事项，这两个功能存在一定的相似，是否存在一定的必要性让我们做下去。最终是多方讨论决定把备忘录的功能完善强大，砍掉了待办事项的需求。
5.3 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
单元测试是用到的，如postman。postman是一个强大API测试工具，通过他，可以完成单元测试，并且能输出正确的请求API给IOS端。
5.4代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
Code Review这个过程其实没有很具体地去执行，因为我们写的代码都挺规范，有合理的注释。
六、测试/发布
6.1团队是否有一个测试计划？为什么没有？
我们有测试计划，测试人员不再像无头苍蝇胡乱测试，同时开发人员在完成每个单元的时候也有进行良好测试，保证了数据的正确性。
6.2是否进行了正式的验收测试？
因为开发人员的另外一个身份也是测试哈哈，就算不是，也会说测试是成功的，似乎是迫于某些开发人员的淫威。
6.3 团队是否有测试工具来帮助测试？
有，上面说到的postman就是，然后还有ios的模拟工具。
6.4团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
TFS 还是很有用的，至于改进，有这样一些建议：
（a）生成可能会产生bug的字段要花费测试人员比较大的心力。
（b）不是所有的Bug 或 task 都记录在TFS中。
6.5在发布的过程中发现了哪些意外问题？
ios的appleStore搞我们心态，发布审核是一个很大的问题，最终我们在github仓库上发布了我们的软件并提供了良好的安装和使用说明。
七、团队的角色 、管理、合作
7.1 团队的每个角色是如何确定的，是不是人尽其才？
按照我们各自的兴趣先主动选择，后面根据实际开发需求找出开发人员并且分出UI人员和PM爸爸，人尽其才。
7.2团队成员之间有互相帮助么？
有。互爱互助，鸽子来的时候，没有任何一个成员是无辜的!!!
7.3当出现项目管理、合作方面的问题时，团队成员如何解决问题？
因为计划中分工明确，PM爸爸说话语气也比较严肃，所以在合作这一块还是比较和谐，没有出现大问题。
八、总结
8.1你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
达到了CMMI二级——管理级的程度。我们团队遵守了既定的计划和流程，合理分配，各有任务。
8.2你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
规范阶段。
8.3你觉得目前最需要改进的一个方面是什么?
测试的覆盖度、开发效率的提高。
8.4对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
- 我们做到了可以尽早持续的交付有价值的软件。三个阶段中，我们都可以做到交付一个很贴切的APP供大家使用。
- 项目开发期间，业务人员和开发人员都在一起工作（网络一线通）。
8.5代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？
- 开发者必须严格按照流程进行代码编写和提交
- 复审过程由测试人员经手再通过管理人员发布。
- 严格按照代码规范文档，严谨地进行变量名的书写和格式等等。
8.6其它软件工具的应用，应该如何提高？
我们在测试方面，需要使用软件工具。对线程压力的测试，我们认定是不需要测试的，因为软件使用频率不会很频繁，后台服务器不会承受很大的压力。提高学习软件工具那种可以团队合作的功能的能力（但事实上穷人不配使用团队合作，因为都要钱）
8.7项目跟踪用户数据方面，计划要提高什么地方？例如你们是如何知道每日/周活跃用户等数据的？
我们可以通过后台日志分析看到用户的数据。活跃数据比较容易知道，因为用户在真正需要到这款产品的时候会添加一些记录，我们可以根据用户添加记录的数据去得出每日/每周活跃用户等数据
8.8项目文档的质量如何提高？
对于文档来说，最好的方式在一开始就设定好模板。这样大家在开发或者工作的过程中能很好地交流，并且文档是需要不断更新的，与代码同步。
九、团队成员在Alpha阶段的角色和具体贡献
| 名字 | 角色 | 团队贡献分 | 可验证的贡献 |
|---|---|---|---|
| 陈起廷 | 开发、测试 | 21 | 独立后台开发、调度团队工作 |
| 魏宇峰 | 开发、测试 | 20.5 | 独立IOS开发、提供合理的测试方案 |
| 刘珮琳 | PM、UI | 20 | 撰写博客、设计界面、设计LOGO |
| 高明莹 | UI、PM | 19.5 | 撰写博客、设计界面、整理博客 |
| 古梓欣 | 测试 | 19 | 撰写博客 |