设想和目标
1.我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
- 我们的软件要解决为用户提供一个供一个可以倾吐和记录点滴的地方，无社交无广告，只有自己的平台，同类产品充斥着满屏的广告与喧闹的社交而使用户无法静心的问题。
- 定义清楚，主要功能是要能实现发一篇日记收到一篇别人的日记，有收藏、标签功能，基于市场普遍存在的日记应用的拓展。
- 对典型用户和典型场景有清晰的描述，切合问卷调查与用户场景分析来进行开发。
2.是否有充足的时间来做计划?
- 我们有充足的时间来做计划，可以说Alpha冲刺持续了一个月的时间，如果重需求分析开始算起，目前已花了两个月的时间。显然我们的计划不够具体，大部分人没有做好计划，没有好好利用这一段时间，实现的过程很多细节也要重新构想。
3.团队在计划阶段是如何解决大家对于计划的不同意见的？
- 主要通过开会或使用QQ群内讨论，对于提出的不同意见，我们采取每个人都说说自己的想法，最后择取多数人共同的部分，并听从多数人的意见，或是接受有过相关经验经历的人的想法，此外若是关于实现问题，也将在讨论时附上一个简易的模型。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
- 理想很美好，显示很骨感。刚开始我们计划要完成“多少多少”，有激情，而这份激情被时间一点一点的磨蚀掉。高估了自己，对可能遇到的困难没有一个清晰的概念，现实情况中困难重重，理想与现实的悬殊太大。
- 如果历史重来一遍，我们会先交流好每个人最擅长的部分，接着制定计划时，会根据这一点出发。执行计划的过程中也会去互相监督。
计划
1.你原计划的工作是否最后都做完了? 如果有没做完的，为什么？
- 在服务器与数据库部分，数据库已完工，而服务器已实现大部分功能。但是他关于安卓与服务器交互的部分（安卓后台）只完成了少数。原因便在于计划不够完善，在最后的冲刺时间选择把时间集中投入于界面与界面交互。
- 安卓方面很多事情都没做完。完成了大部分界面，但是时光轴的实现在多天尝试后仍失败，由于计划不周与执行计划不够自觉导致的时间问题，只能把它放到beta完善。碎片嵌套也没能实现，原因在于原本的代码结构不好，也没能及时对代码进行重构。
2.有没有发现你做了一些事后看来没必要或没多大价值的事？
- 对界面的控件进行重新命名，修改原本设定好的控件布局，为达到尽量美观。结果，重新命名没有特别大的作用，重新写布局也没有变得更好看很多。
- 对于代码规范在事前已经定好了，但是在具体实现时代码规范被几乎搁置，而且缺乏注释。导致于后面在一起解决安卓的界面和界面交互时出现了需要一人解释的情况，这无疑中又浪费了些许时间。
3.是否每一项任务都有清楚定义和衡量的交付件？
- 大部分都没有，因此一方在接收时往往不能确定是否合格，在后续的开发中可能又进行修改和完善。并且到最后我们没有完成预期目标。
4.是否项目的整个过程都按照计划进行？
- 一开始有按照计划进行，但是后来随着执行计划的自觉性降低并且难度增大，时间越花越多，出现了“滚雪球”现象，就没能及时完成任务。
5.在计划中有没有留下缓冲区，缓冲区有作用么？
- 一开始就对预测可能遇到难度的板块预留了缓冲区，而这个缓冲区由于计划的执行不够也减少了其长度。缓冲区确实有发挥作用，虽然我们并没有完成预期目标，但依旧减少了成员的不少压力。
6.将来的计划会做什么修改？
- 对任务进行更为明确的时间安排，制定每个时间点需要完成什么目标。
- 吸取本次Alpha冲刺的教训，在执行计划上，每一天都应该分享今日完成的进度，团队成员互相监督，对在执行计划中遇到的难点说出来一起解决。
- 预留更为符合实际的缓冲区长度。
- 计划很美好，实际上最后离要计划的目标相距太大。问题不完全在于制定计划上，更多的在于执行上。
- 如果历史重来，要关注每天的进度，防止停滞状态出现。
资源
1.我们有足够的资源来完成各项任务么？
- 如果排除金工实习两周，时间资源相对来说还是充裕的。
- 但是对于人力资源而言，由于大家都缺乏一定的项目开发经验，所以对于项目的进度的把控存在不足。
- 在开发过程中，有许多有经验的人士可以咨询，老师、助教、IT人士（实际上只找了助教）。网络资源上，表面上百度很丰富，实际上几乎都是有问题的资源，这一点很是头疼。
2.各项任务所需的时间和其他资源是如何估计的，精度如何？
- 在任务的时间估计方面，主要是规划好每天的任务，任务精度级算是精确到每天。在计划安排中，考虑实际执行可能出现的各类情况以及刚开始成员经验较少，因此前期的任务时间安排较长，后期缩短，这更符合实际情况。
- 对于每个成员分配的工作量以要实现的功能模块划分，精确到每个具体模块。
3.用户测试的时间，人力和软件/硬件资源是否足够？
- 由于开发项目过程中对于Android studio不够熟悉，队员中多次出现了各种问题（Android studio3.0版本发生较多改动，出现了很多不能完全说是代码问题的问题），导致花费额外的时间解决开发用的软件问题。
- 测试的时间较赶，硬件资源足够。想要用真机来测试时随便有，妥妥的~
4.你有没有感到你做的事情可以让别人来做（更有效率）？
- 在项目后期，前端的设计遇到了瓶颈，负责后端开发的队友临时投入到前端的开发中，但是由于对前端开发的经验不足，并没有很好的解决存在的所有问题。
- 每个人都有自己擅长的部分，在任务分配时对这一点不清楚，在实际进行中这一点就突出了出来。
- 要更为客观实际的分配好资源。
变更管理
1.每个相关的员工都及时知道了变更的消息?
- 有创建讨论组，在项目进度更新的时候会在组里进行通知，并进行必要的讨论，确保每个人都能能知道变更的消息。每个人收到消息时也都会进行回复。
2.我们采用了什么办法决定“推迟”和“必须实现”的功能？
- 在开始十天冲刺之前，通过小组站立式会议讨论，确定了本次冲刺要完成的部分核心功能。核心功能中容易实现的必须在 alpha 版本实现（必须实现），而核心功能中有技术难点的推迟到 beta 版本实现（推迟）。
3.项目的出口条件（Exit Criteria）是否得到清晰的定义？
- 对于项目的出口条件并不能清晰的定义，所以Alpha版本只实现了部分的核心功能。
4.对于可能的变更是否能制定应急计划？
- 项目的数据库或者重要的服务器代码在进行改动时会备份到群里保存，防止突发的数据丢失对于项目进度的影响。
- 在团队中的个别成员在冲刺期间有考试时，适当减少该成员的工作量（最后发现竟然5个人在轮流考试中，而且还挺难的），并经过讨论合理调整任务计划。
5.员工是否能够有效地处理意料之外的工作请求？
- 对于意料之外的工作请求，在进行讨论后，后端开发人员临时加入到前端的设计开发中，只能尽最大的努力完成任务（结果后端根本那前端的技术相当不得力啊，然后又想回去做后端了），这并不是有效的处理办法。
- 遇到瓶颈导致停滞出现时，团队没有一个好的解决方案，处理起来没有效率。
- 在事前要制定好应急方案。
设计/实现
1.设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
- 设计工作在我们团队第一次讨论的时候就开始了，在进行需求分析的时候完成的，是由团队所有成员一起讨论完成的，当然做需求分析的同学和做界面原型设计的同学给出的建议更多。
- 至于设计工作完成的时间我觉得是大致合适的，不过我们在实际开发中也有改动一开始的设计，所以也没有一直按照最开始的设计进行开发。完成设计是大家一起，然后做需求的同学和做页面的同学给出更多的idea也是相对比较合理的。
2.设计工作有没有碰到模棱两可的情况，团队是如何解决的？
- 有的，比如在一开始定功能和需求的时候，大家的意见就无法统一。我们一般采用少数服从多数的原则来解决。
3.团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
- 有使用UML来帮助设计和实现，这使得我们对项目有了更深刻的认识，方便了后续的开发。
4.什么功能产生的Bug最多，为什么？
- 随机收到日记功能产生的bug最多，因为动态收到日记的实现比较复杂。
5.代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
- 在写过代码后会有一个人专门看代码以及命名规范，同时在写的过程中每个人都按照代码规范来写代码。但是在实际开发过程中还是会产生没有按照规范的问题，然后写好了代码后面也很难去调整了。
- 制定的代码规范不能只停留在看的层面上，要去落实。
测试/发布
1.团队是否有一个测试计划？为什么没有？
- 有一个测试计划的雏形。由于时间上原因，没有对它进行下一步操作。
2.是否进行了正式的验收测试？
- 没有
3.团队是否有测试工具来帮助测试？
- 没有，只停留在自己写代码去测试代码的层面。
4.团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
- 使用最原始的手动代码操作测试。将遇到的BUG记录在文本中。
虽然原始，但还是有它的作用。要做出的改进，有如下：
- 对每个功能写一个代码测试很耗时间。要改进方法。
- 记录的BUG很凌乱，需要分类。
5.在发布的过程中发现了哪些意外问题？
- 有些功能在不同的机器上工作的效果不一样。有些设置操作停留在某些人的脑袋中，导致在机器上运行时出现了一堆错误。
总结
1.你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
- CMM
2.你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
- 磨合
3.你觉得目前最需要改进的一个方面是什么?
- 分工要更加细致明确，计划制定要更为考虑到实际问题。执行要保持激情。
最后附上成员本次开会照片