团队作业7——Alpha冲刺之事后诸葛亮

事后诸葛亮分析

1.总结的提纲内容

1. 我们的软件要解决什么问题？是否定义得很清楚？
   1）软件主要用来提供用户项目的统计信息的情况，统计的信息包括项目的代码量，项目的Method,Class数量。还有项目的一些附加的功能，如"一键修改Method的名字"。

   2）对于项目的一键修改功能在软件开发中存在着争议。考虑到用户提交到我们系统上的项目，一定是一个成型的项目，对于"一键修改Method的名字"这个功能对用户来说到底有没有用呢？我们调查了一些项目开发的编辑器，编辑器都是可以一键修项目中所有的Method和Class的名字。项目开始阶段对于功能的实用性没有考虑清楚导致后期的开发中浪费了很多的时间去做这个最终废弃的功能。

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

   1）原计划对于"日代码量的统计"的功能没有实现，其他的基本功能都实现了，也按照原定计划的时间交付了。一周的开发时间相对来说是非常紧张的。1-开发过程中遇到的问题解决就用掉差不多一半的时间 2-前期的项目的具体实现的流程没有定义清楚，所以在商讨确定项目的实现流程也花一些时间。

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

   教训：

   1：在真正代码的开发阶段，软件的前期的一些文档和项目的实现的具体流程一定要制定好，不然后期开发中对于代码书写有点无从下手。
   
   2：在软件开发过程中，发现的问题一定要及时的更改，不要一直拖到最后在改。因为随着软件开发的过程中，代码量越来越大，修改的难度也会很大。比如数据库的设计。当我们在开发过过程中需要更改数据库的表的定义以支持后期的一些功能时，要及时的更改。因为我们的这个项目涉及到的数据库的操作非常之多，所以beta阶段我们对于ALpha项目的更改的幅度有点大。
   

   改进：

   对于团队项目来时，不可避免的就要提到团队成员之间的相互合作。团队成员之间的一定要多交流，遇到问题自己解决不了要向团队成员进行请教。而不是浪费时间在一些起不到作用的事情上。首先要端正大家的态度，然后再去为我们的系统服务。
   

计划

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

   是的，我们花了一定的时间来制定整个计划，包括人员安排分配、各个阶段所花的时间、以及几次团队会议分别要完成哪些内容。

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

   既然是团队作业，出现分歧在所难免。但是每当出现分歧时，我们都尽量避免争执，采用少数服从多数的原则，在大家分别阐述完自己的理由之后，去商定最终的方案。我们毕竟是一个团队，凝聚力是非常重要的，所以大家一定要团结一心，共同前进。

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

   原计划的工作已经基本完成，只有一个"日代码量的统计"的功能没有实现，由于一周的时间比较赶，所以这个功能还没来得及去实现。

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

   项目中实现的一个功能"一键修改Method的名字"，在后来的调查分析中发现是没有必要的。

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

   是的，每个任务都是经过大家协商讨论，特别是负责代码的同学，在开发初期就有花时间去明确的定义和衡量我们的交付件。

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

   项目开发过程中，调试BUG花去的很多的时间，导致项目原定计划的一个功能没有实现。所以在开发初期我们并没有想到会有这些那些的BUG存在，这时才发现要做好这件事是没有那么容易的。

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

   有，缓冲区实际上是很有必要的。一个项目的建立的时候不一定都会按照计划一步步走。肯定会遇到不同阶段的瓶颈，而这时缓冲区就能起一个很好的协调作用，在时间和人员上做一个调整，让大家以更好的心态去应对这些棘手的问题。

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

   将来的计划我们会在大家时间的分配、人员每天的任务量安排以及留给缓冲区的时间做一个调整，争取做出更合理的方案计划。

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

1）对于项目开发过程中可能遇到的风险问题，要考虑的全面。
2）要合理的利用时间，把一些碎片时间充分利用起来。
3）好好调整队员的心态，要给大家充分的信心。

资源

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

   1）时间是我们最需要的资源。一周的冲刺阶段，项目取得了很大的进步。但是时间资源的缺少，给团队成员间带来了不小的压力。

   2）技术上的资源。项目功能的具体实现都是团队成员间商量和索寻资料来学习到的，探索的过程中也耗费了一段时间。

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

   是小组成员通过会议去预估的，精度计算到小时。

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

   测试的时间资源还不是特别充足，因为一周的时间要完成很多任务，所以到了测试这一块就显得时间较赶。对于不需要编程的资源，我们小组给出了一定的时间安排，所以完成的还算从容。

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

   每一个成员都是不可替代的，效率跟很多因素有关，但是大家都很认真在付出。

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

1）测试的时间安排还不够合理，也是因为前期遇到了一些突发状况，导致花的时间多于原本计划在这块的时间，我们还是要多留一些时间给测试这一部分。
2）在协商的过程中，大家寻找资源都多少有一点困难，我们下次要更合理的落实到每一个人，每个人有序的完成各自的任务，整个小组才会完整。

变更管理

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

   是的，组长都及时的通知了大家。

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

   大家通过会议讨论，综合大家的意见，确定出一些“加急”任务以及“可延迟”任务。

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

   有，包括整个功能的实现，完成用户的需求，以及用户使用后的评价，来定义项目是否“做好了”。

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

   是，我们敏捷开发的一周里，每一天都会针对不同的问题变更做出相应计划的改变。

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

   由于时间上存在一定的问题，所以我们还是只能完成初期制定的硬性任务，按照计划一步步实现。

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

1）对于各种部分的变更，大家应对的心态还不够积极，之后我们会通过沟通交流，调动大家的积极性，去解决遇到的变更。
2）计划总是赶不上变化，这就要求我们要有不畏困难的精神，此时不应该出现争执，而是要冷静应对，去修改原本的计划。

设计/实现

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

   系统的设计工作安排在开发初期，是团队中写代码的人一起讨论设计的。

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

   还没有遇到模棱两可的情况，都是明确的计划制定。

3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？

   是的，用IED自带的Junit4进行测试，是很有效的

4. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
   文件分析最多bug，因为统计的是很会有很多统计情况忽略，比如统计类方法的时候。因为在刚刚设计/开发时候没有想到那么多的实际情况

5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
   代码复审一般在一个功能出现问题时，由另外的同学按照流程把别人写的代码看下，看看有没有什么不规范，或者觉得有问题的，然后询问解答，共同解决问题

我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
1）在设计阶段我们就应该精确制定详细计划，搞清楚我们要做什么内容，每个人适合哪些内容。
2）代码出现了很多BUG需要不断的修复，才能完善，我们低估了这一块的时间，导致出现了意外情况，时间偏急。

测试/发布

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

   有，组长安排了一个测试计划，组员都有配合。

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

   还没，只是完成alpha版本的初步，还有很多预期的没有实现，但是暂时实现的都有测试

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

   没有专门工具，一般都是用JUnit4，以及正常的流程进行测试

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

   用实际运行时间，以及关注是否有内存泄露等等问题进行效能测试，这些功能有用，对于速度性能上还有改进空间，比如解压后的分析可以用另外的线程去处理。

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

   发布的时候还会存在一些没有预知的Bug比如统计的类少了，后面发现才改正

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

我们学到了一个好的软件想实现的完美还是很难的，想着容易做着难。然后对于功能的测试是很重要的，一定要多测试几遍，多一些案例，才能测试的更全面。

团队的角色，管理，合作

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

   是根据大家的性格、擅长方面而确定的，尽量做到人尽其才。

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

   有的，如博客撰写是大家都会互相帮忙各自的部分，写代码的同学也会提出自己的意见，来帮助大家完成各自的任务。

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

   首先开讨论会议，把问题说出来，大家一起想最好的解决方案，不要出现争执、内讧情况，不利于整个团队的发展。

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

李雯钰：我感谢朱毕川对我的帮助，因为在完成我的代码任务出现代码问题进行不下去时，她会帮我找这个编译错误的原因，并且告诉我这个方法为什么不对，这个语法有什么错误，这个代码是否规范，她会用她的代码知识帮助我进步。

华天生：感谢朱毕川同学的帮助，有时候代码出现bug的时候一个人很难找出在哪里出错了，然后她会帮我看看哪里出问题从而解决。

肖荣森：感谢天生同志的帮助，一开始的需求分析多亏了帮助才能够顺利的罗列出来，还有一些函数的应用以及页面的设计，遇到问题都能及时的帮助同学。

林乔桦：在编写压缩文件上传，有点拖累了项目的进度，不过好在有队友毕川与天生的帮助，最终集众人的智慧终于攻克难题，正印证了一句老话——众人拾柴火焰高。

魏芳：感谢天生同学的帮助，在一些函数的运用上出现错误，在查找了多方面的材料还是不能解决问题，好在他的帮助下，才能顺利完成自己的任务。

朱毕川：感谢天生同学的帮助，大家在写代码的过程会遇到困境，找不到bug解决方法，天生就会很耐心的帮我看代码，让编程顺利进行。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

1）每个人都是重要的一员，都是不可或缺的角色，大家的心态一定要这样摆正，才能让每个队员充分发挥自己的才能。
2）团队合作是一门艺术，在这次的开发过程中我们也是遇到了很多问题，出现过很多分歧，但好在都得到了解决，可见沟通是相当重要的，在下一次的任务安排上，我们会根据这次版本大家的表现，对各自角色的分配进行适当的调整。

总结:

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

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

   团队目前出于规范阶段。

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

   大家的心态更好了，也更积极了，面对问题更加从容冷静。

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

   大家的时间总是不能很好的利用，多少都会浪费在一些零散的事情上，要更合理的应用。

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

我们小组做的最好的是第一点（尽早并持续地交付有价值的软件以满足顾客需求）和第六点（无论团队内外，面对面的交流始终是最有效的沟通方式）。我们的项目每一次都有按照制定的计划交付任务，不断更新给用户项目当前的进展，后又根据用户新的需求作出分析改动。组长也经常号召大家聚在一起开讨论会议，面对面的解决遇到的困难和一些分歧，因为面对面的沟通是解决问题和增强团队凝聚力最直接有效的方式。

2.全组讨论的照片

3.团队成员在Alpha阶段的角色和具体贡献：设想和目标