一. 设想与目标
1. 我们的软件要解决什么问题？是否定义的很清楚？是否对典型用户和典型场景有清晰的描述？
-
解决的问题
用户入不敷出的问题，通过账单和日历结合的方式来实现
-
是否定义的清楚
定义的比较清楚，目的也很明确
-
是否有较为清晰的描述
典型用户为学生，典型场景有较为清晰的描述，具体参见展示博客
2. 和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高？具体提高了多少？如何衡量的？
目前还属于Alpha阶段，暂无上一阶段，属于从无到有的情况。要说提高还是有很大的提高了
3. 我们达到目标了么
-
原计划的功能做到了几个？
原计划第一阶段完成13个功能，做到了11个，删除和修改没有做
-
按照原计划交付时间交付了么？
按时间交付
-
原计划达到的用户数量达到了么?
emmmmmmmmmm虽然现在只是内测阶段，但还是有将近10个用户的，勉强算是达到了？
4. 用户量
-
用户对重要功能的接收程度和我们事先的预想一致吗？
比较一致吧，主要这个功能以前没有出现过，所以反馈说不上一致好评，有好有坏吧
-
我们离目标更近了吗？
当然，我们的主要功能已经全部实现了，接下来就是一些用户体验问题了。离目标是越来越近了
二. 计划
1. 是否有充足的时间来做计划?
有，我们团队提前很久开始整个项目的，项目的大致方向是定下来很久的，然后细化具体需求又用了不少时间。不过也因为时间比较长，就不断的在调整，反而有点需求爆炸的感觉了。
2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
开会讨论，这种事情只有当面谈才说的清楚。有些看似很好的需求功能，争论不下的话，就会先放入备选方案里面，如果团队有余力就去开发，没有就搁置。这样类似的需求计划我们这其实挺多的
3. 你原计划的工作是否最后都完成的？如果有没做完的，为什么？
90%都完成了，发布上线属于超额完成的任务。没有完成的主要就是流水账单的删除和修改了。这两个属于需要的功能，但是......忘了 ......主要原因是，一开始原型设计就忘了做，后面就彻底的忘了......
4. 有没有发现你做了一些没必要或没多大价值的事？
我应该是没有，但是团队成员有。比如说后端同学和前端同学与git斗智斗勇的那几天，都非常的心酸了......码云上传量就是这么刷上去的......
大概问了一圈组里，大家的问题基本都在于和各种类型的软件做斗争，你要说价值吧，还真没什么价值。搞定之后也不觉得有什么意义，但是又必须去弄，就很费时间。以及其他团队和服务器，数据库这些东西斗争了很久吧（虽然我们没有这个问题就是了）
5. 是否每一项任务都有清楚定义和衡量的交付件？
不一定，有一些任务是要和其他任何合在一起进行交付的。比如说日历的选择要和跳转看到的流水总界面一起交付会比较好（不然就像非洲的前端同学一样，因为脸黑，根本没法调试.....）
6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险事当时没有估计到的，为什么没有估计到？
基本上是按照计划进行的。要说唯一算得上意外的，就是发布的bug了吧，本来后台调试的非常好，没什么大的问题了，就等着上线了。结果发布审核通过后，发现几乎所有的功能都不能使用（整组的内心都是崩溃的......）
这个问题在一开始我觉得也不可能预料到吧，谁能想到本地好好的，上线就连后端都连不上了......
7. 在计划中有没有留下缓冲区？缓冲区有作用吗？
有留缓冲区，我们团队整个项目开始的时间相对早一些，就是为了有充足的时间来面对各种各样的问题。事实证明这个方案挺对的，开发过程中总是会有各种突发情况出现，一共两周的冲刺，8篇博客，截止现在，我们差不多用了三周整的天数来做开发和修改以及解决突发问题。一个充足的开发时间真的很有必要，毕竟你永远不知道下一刻会发现什么事
8. 将来的计划会做什么修改？
重新修改“计划”和“图表”页面，作为我们的核心功能，还是想把这个计划部分做到最好。现在的情况是，功能可以实现，但是用户体验有点差，容错性也不高。
图表部分主要是原本找的图没法修改，就......比较难看，所以这部分在将来肯定要修改的
三. 资源
1. 我们有足够的资源来完成各项任务吗？
基本有，第一阶段的完成足以证明了。不过要是能再有个做后端的人就好了
2. 各项任务所需的时间和其他资源事如何估计的，精度如何？
依靠一点相关的其他东西的开发经验进行估计的，精度不太准，毕竟是个新接触的事物
3. 测试的时间，人力和软件/硬件资源是否足够？对于那些不需要编程的资源（美工设计/文案）是否低估了难度？
还行，简单来说就是前端兼职美工设计，PM兼职文案。并没有低估难度，脸上笑嘻嘻（微笑）
4. 你有没有感到你做的事情可以让别人来做（更有效率）？
没有吧，统一问了一圈，后端大兄弟表示前端他做不来，审美比较差，前端表示后端她做不了，代码能力没那么强。PM表示，请不要和我说代码，我头疼。
就这样，我们团队，非常的合适，各司其职（摊手）
四. 变更管理
1. 每个相关的员工都及时知道了变更的消息？
嗯，有个讨论组，有什么事情都会及时发在群里。比如说，git部分有个bug，前后端同时在调整一个页面的时候，会有问题。解决方案是谁提交谁吱一声......（网上真就这么说的...），所以有时候，虽然群里没人回应，但是大家都是知道发生了什么的
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能？
可能是PM比较强硬的决定吧......必须实现的功能这一部分。至于推迟的部分，是和开发人员商量的结果。由开发人员提出，可能这个功能在代码上会比较麻烦，想要推到下个阶段。然后PM这边核对这个阶段的其他功能，如果说这个要推迟的功能对这个阶段其他要发布的功能没有其他影响或者干扰，且这个阶段要发布的东西也不少的时候，就会选择推迟。
但是必须实现的功能是这个程序的最根本的东西，是绝对要完成的
3. 项目的出口条件（什么叫“做好了”）有清晰的定义吗？
（1）记账的记录功能没有问题
（2）计划的制定没有问题
（3）金额的计算没有问题
（4）日历正常显示，且可以正常跳转流水账单界面
（6）图表统计部分数据正常（界面问题此阶段暂不解决）
总的来说，我们的Alpha阶段，主要是实现一个记账小程序的基本使用功能以及我们的核心功能（实现每天金额的动态计算和规划）。所以在这两个主要功能完成的前提下，功能使用没有问题，我们就认定Alpha阶段足够好，可以发布。我们在功能可以正常使用，且进过测试之后没有逻辑bug，限制也都加过了。各方面测试数据显示问题应该不大，且安全方面做的还可以，所以就选择发布了。
4. 对于可能的变更是否能制定应急计划？
勉强能。其实对于应急计划的制定，从我的角度出发，并不难。很快就能想出好几种备用方案，计划的制定是比较快的。但是对于开发人员要调整的会比较多，所以他们能否做到才是重点。我们因为开发人员比较厉害，所以还挺顺利的，不管是正常开发，还是应急预案。
5. 组员是否能够有效的处理意料之外的工作请求？
跟上面那个问题差不多，成员挺厉害的，不少问题都可以完成。工作量较大的部分虽然这个阶段提出没法完成，但是设想和实现方式都以及有框架了，在时间充裕或是下个阶段都能完成。工作量小的时候，第二天就能当附加任务完成了
五. 设计/实现
1. 设计工作在上面时候，由谁来完成的？是合适的时间，合适的人吗？
设计这一部分，基本是由前端同学兼职完成的，PM主要提建议（就是那种，你这里不行啊，你这里要改啊的那种）
人选我认为是挺合适的，毕竟她做的设计，她来做UI，之间无缝对接
时间方面我倒是也还行，我们的设计阶段挺靠前的，没有跟其他工作撞在一起
2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
有，因为用来参考的其他相同软件看的太多了，导致感觉这个也觉得好，那个也觉得不错，就很迷茫，应该参考哪个来。
最后是讨论，感觉还是按照我们自己的特色来吧。本来我们的核心功能就和别人不一样，我们的核心界面也不要总是参照别人的，按照自己的风格来就好
3. 团队是否运用单元测试，测试驱动的开发，UML，或者其他工具来帮助实现？这些工具有效吗？
比较少吧，因为程序内容的限制，我们的后端代码主要的也就100多行，前端页面又基本没法做单元测试，所以一些工具用的是真的挺少的......
4. 什么功能产生的BUG最多，为什么？在发布之后发现了什么重要的BUG？为什么我们在设计/开发的时候没有想到这些情况？
图表功能的bug最多！因为图表不是我们自己写的......（毕竟图形，绘图什么的，对吧......没法啊）这个部分在改进，这几周开发人员休息的期间，他们去找可控性更高的图表代码了......
发布之后，最重要的bug就是前端没有给后端发送网络请求，导致我们的程序基本没有可以用的地方......这个是真的绝望啊。
要说为什么没能想到......谁能想到产生bug的原因是因为没看完微信的发布说明书啊？漏填了一个地方的域名地址，导致前端根本没有发送网络请求，所以什么都做不了......
5. 代码复审是如何进行的，是否严格执行了代码规范？
代码复审啊......摸着良心说，我们没做......
代码规范还是严格执行了的，毕竟开发人员少，他们之间协调起来还是很容易的。况且他们之间的代码重叠度说不上太高，所以也还好
六. 测试/发布
1. 团队是否有一个测试计划？为什么没有？
有，具体要测试哪些地方，这些地方的测试重点在哪？这些都是有事先计划的，然后哪里有问题再让开发的同学改。
2. 是否进行了正式的验收测试？
没有吧，我们在冲刺阶段是真的每天都在开会，然后每天开会的时候就一起把今天完成的部分讨论验收了。正式的那种验收应该是没有的
3. 团队是否由测试工具来帮助测试？
有些地方还是需要的，比如CPU，内存等资源消耗情况，这些东西我们肯定没法手动或者肉眼测出来的。这些都需要工具的辅助。
4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用吗？应该有哪些改进？
效能是通过微信端自己的测试功能进行的效能测试，从软件实际运行的结果上来看，测试工作感觉意义不大。可能是我们能力不够，还不懂这些参数背后的意义。
5. 在发布的过程中发现了哪些意外问题？
发布遇到的问题上面说了好几次了，基本就是因为文档没有读完，导致发布之后前端不会向后端发送网络请求。其实也就是发布的时候有些地方没有填写造成的
七. 总结
1. 你觉得团队目前的状态属于CMM/CMMI中的哪个档次？
目前处于过程改进部分
2. 你觉得团队目前处于 萌芽/磨合/规范/创造 的哪一个阶段？
创造阶段？因为磨合和规范都已经过了，就肯定处于创造阶段
3. 你觉得团队在这个里程碑相比前一个里程碑有什么改进？
应该是团队之间的合作更加默契了吧，之间的沟通也好了很多
4. 你觉得目前最需要改进的一个方面是什么？
如何让别人知道我们到底是要做什么。经过之前的展示，好像一些同学没能够感受到我们的程序的主要作用在哪，比较痛心......接下来有考虑看看能不能加个“新手指引”一样的东西上去
5. 对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
（1）可以经常性的交付工作，我们的代码更改很快，版本更新的也很快，如果有需要，是可以经常交付的
（2）能做到有效的面对面交谈，我们组天天开会，天天被吐槽
（3）团队开发人员不断的在关注新的技术和设计，后端整天想搞个大新闻
八. 团队成员贡献度
下面可验证的贡献写的比较概括，具体做的挺多，但是如果一 一列出来就太多了，所以统一用了简略的写法。虽然老师一直说PM是一个团队的灵魂，但是我还是觉得没有能做开发的人，不管有什么想法都是可能没法实现的，计划的再好的进度也不可能完成。所以还是开发的兄弟们最辛苦了！
