『编程题全队』Alpha阶段事后诸葛亮分析

一、设想和目标

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

Answer：
（1）我们软件主要解决个人和团队的事务管理问题
（2）我们软件的定义明确和清楚，具体的功能都能体现相关的需求
（3）对典型用户和典型场景有清晰描述：典型用户包括学生、教师、职员；典型的场景为个人事务和团队事务

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

Answer：
我们达到目标了。原计划的功能包括个人模块部分基础功能和团队模块部分基础功能全部按计划完成，同时也按原计划交付时间交付，原计划的用户量还没有达到，不过基本满足最低预测。

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

Answer：
我们处于Alpha冲刺阶段，上一个阶段的话就是需求分析阶段。我们的软件工程质量得到了提高，主要是在任务分配和任务安排上面以及完成任务的效率上。至于具体提高了多少，我们可以知道现在花一样的时间能够完成之前两到三倍的工作量，我们是通过时间来衡量的。

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

Answer：
现在的用户量主要是我们年级的同学，跟我们之前预想的Alpha阶段的用户量差不多一致。我们队使用过的用户进行了采访，用户对于我们的完整产品表示了期待，也对我们的产品提出了建议和批评，我们也认真接受有效的看法。我们离我们的目标更近了。

5.有什么经验教训? 如果历史重来一遍, 我们会做什么改进?

Answer：
这次的目标设计和任务安排我们都完成的非常好，我们也得到了很多经验，包括对任务分配的工作更加细分，增加软件测试人员来减轻个人工作量和提高效率。如果历史重来一次，我们还是会按照之前的方法进行工作，然后对上面提到的两点进行改进。

二、计划

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

Answer：
我们Alpha阶段的PM是个非常优秀的大佬，虽然我们没有充足的时间来做计划，但是大佬充分利用课余时间对工作进行计划安排。经过Alpha阶段的验证，安排合理有效。

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

Answer：
团队计划阶段，有出现对于任务安排的不同意见，我们在PM的主持下，听取每位成员的不同意见和考虑实际情况，最后由负责人员记录，最后PM提出建议，尽量满足计划要求又符合实际需求。

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

Answer：
我们原计划的工作基本完成，但是部分团队模块功能（同步功能）没有完成，因为这是我们自己添加的任务，但是时间来不及，所以没有完成。

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

Answer：
基本没有，我们觉得每做的一项任务都是对我们产品有作用的，也许后来可能会觉得有更好地做法，但是我们认为这个做法扩大我们的视野，发散了我们的思维。

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

Answer：
对，这个可以从我们的issue中看出来。

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

Answer：
项目的计划整体按照计划进行。但项目进行中间，出现部分成员需要复习考试，这是没有估计到的风险，因为之前老师没有通知要考试。

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

Answer：
有缓冲区，为了解决部分未完成的任务和修复BUG。

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

Answer：
我们会更加合理设计缓冲区，会设计时间点来检查任务完成度。

9.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

Answer：
我觉得计划这部分做得很好，只要继续保持就好了。

三、资源

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

Answer：
由于在开始冲刺前的合理分工与安排，大家在alpha冲刺阶段可以合理的调度各种资源，所以还是有足够的资源完成任务的

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

Answer：
由于燃尽图的存在，大家每天要完成自己计划内的任务，所以在项目所需时间和其他资源的估计上还是比较精确的

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

Answer：
还是前面提到的在冲刺开始前的安排问题，我们有专门的人员进行测试和美工设计，所以对于我们的团队来说资源是足够的

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

Answer：
我不认为我做的事情让别人来做会更有效率。因为，在分工时的安排就是最好的安排，虽然我们队中一些大佬做我的事情肯定会比我做更有效率，但是可能会拉低整体的进程进度和完成效率

5.有什么经验教训? 如果历史重来一遍, 我们会做什么改进?

Answer：
在这次alpha阶段的冲刺过程中，得到的一个重要的教训就是前端与后端的交流不及时，导致在冲刺过程中做了一些无用功。如果历史重来一遍，后端开发与前端开发应同步开发，及时交流，根据前端的需要，进行后端的开发

四、变更管理

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

Answer：
当有变更消息时，PM会及时在团队交流群内发布消息

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

Answer：
团队“立会”集体表决的方法决定“推迟”和“必须实现”的功能

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

Answer：
只要是符合大家的预期以及通过了测试，我认为就算是符合出口条件

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

Answer：
如果有重大的变更发生，那么PM会召集大家在线上或线下进行讨论并制定应急计划

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

Answer：
如果在力所能及的情况下就可以接受并处理意料之外的工作请求

6.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

Answer：
我们还是会坚持这个阶段的变更管理，能够做到最好地处理紧急事件，处理意料之外的工作请求。

五、设计/实现

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

Answer：
设计工作在需求分析之后，由志威和慧君完成界面设计与排版。在需求分析阶段，我们发布了一份问卷包含了调查用户对于软件设计的一些想法，之后才进行的设计工作，可是说是适合的时间；慧君和志威同学在设计方面也完成得非常好，是适合的人！

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

Answer：
在上题中提及，设计工作紧接在需求分析阶段之后，经过了认真的分析和设计，并不存在模棱两可的情况。

3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？

Answer：
运用了单元测试、TDD、UML，工具有效。

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

Answer：
在团队看板模块存在的BUG较多，因为这块功能实现难度较高。
几个重要的BUG：
（1）BUG1：看板任务消失：点击一个任务，在出现特定情况时（任务大小超过看板宽度，并再次点击其他），任务消失。不可重现
（2）BUG2：看板排序：点击一个任务，任务自动排序到本栏中最下方。可重现
（3）BUG3：看板任务停留：拖拽看板任务，任务可停留在任意位置。可重现
（4）设计时候没考虑到这些情况是因为，这些BUG是不可预知或根本不是设计的问

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

Answer：
在进行各自功能模块时便伴随着代码复审，查看是否有冗余代码；制定了代码规范并严格执行代码规范。

6.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

Answer：
学到了任务的合理分配，完善的设计和完善流程，代码复审的要求。我们会在代码开发的时候做更多的测试，尽量消灭BUG。

六、测试/发布

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

Answer：
团队有测试计划，由测试人员编写。

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

Answer：
进行了正式验收测试，认证对代码、功能性、性能以及安全性进行测试。

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

Answer：
团队有测试工具，LoadRunner和IBM SecurityAppScanStandard。

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

Answer：
一方面测试人员使用工具进行场景测试、功能、性能、安全性等方面的测试并做好测试文档，另一方面全体队员共同使用软件寻找BUG。这些测试工作有用，而且非常有必要。因为现阶段软件还未完善，从这些测试工作中，我们可以找到并记录现阶段的不足，供之后修正。
改进：这个问题不明确，不知道是软件的改进还是测试工作的改进。（需要修改）

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

Answer：
目前软件还未完善，只发布了最基本的功能的版本。

6.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

Answer：
我们学到了测试的准备工作和具体流程还有发布的细节，我们重来会制定更完善的测试计划。

七、团队的角色，管理，合作

1. 团队的每个角色是如何确定的，是不是人尽其才？

Answer：
我们主要是以每个人擅长的技术为基准来确定角色，总体上来说是比较合理的。

2. 团队成员之间有互相帮助么？

Answer：
我们的项目相对比较复杂，在alpha阶段，遇到了一些架构、编程上的问题，大部分都通过查询资料，组员之间的问答解决了。

3. 当出现项目管理、合作方面的问题时，团队成员如何解决问题？

Answer：
因为前后端的负责人是舍友，所以一般遇到软件上问题的时候，都会在晚上的时候进行沟通。涉及到博客的编写等其他问题的时候，一般就在群内发布公告通知。

4.每个成员明确公开地表示对成员帮助的感谢（并且写在各自的博客里）：

Answer：
通过本次冲刺，我们团队的每个成员都有各自的体会。总体上来说，我们都对自己负责的模块有了更进一步的了解与掌握，学会了如何更好地与队友沟通交流，深刻体会到了“众人拾柴火焰高”的道理。再回首，依然存在一些不足，如果历史可以重来，我们会在刚开始规划架构与任务的时候花更多的时间详细地定制。

5.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

Answer：
我们学到了角色的合理分配，我们会增加测试人员。

八、总结:

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

Answer：
CMMI二级——管理级。我们的团队按照计划，责任到人，但还是没有一套完整的管理措施。

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

Answer：
应该可以算是度过了磨合期，到达了规范阶段。

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

Answer：
我觉得通过alpha阶段的冲刺，我们才到达了第一个里程碑阶段。

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

Answer：
针对软件来说，目前需要改进的就是简化客户端与服务端之间的数据交互。对于我们团队，希望能够进一步地加强队员之间的沟通交流。

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

Answer：
对照敏捷开发的原则，其中做地最好的是第一原则尽早并持续地交付有价值的软件以满足顾客需求——我们在alpha阶段结束之前就在码云上发布了我们的一个可用版本；第六原则无论团队内外，面对面的交流始终是最有效的沟通方式——冲刺期间，我们每天都有展开立会，面对面交流沟通。

九、团队照片:

十、贡献排行：

姓名	角色	团队贡献排序	可验证的排序
孙志威	PM&客户端开发	1	客户端设计源码和相关文档
孙慧君	客户端开发	2	客户端设计源码
王威	服务器开发	3	服务器设计源码
黄华林	发布工作	4	博客及发布内容
倪兢飞	数据库开发	5	数据库设计源码
连燕波	测试任务	6	测试内容和测试报告