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

 

设想和目标

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

　　（1）我们软件要解决学习提醒的功能，能让用户自主设置提醒功能

　　（2）对于功能定义的比较明确

　　（3）我们小组成员都有过此经历，对同学们的需求也做了处理，所以对于典型用户和典型场景有比较清晰的描述

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

　　可以说达到了预期的目标，原计划的功能完成了大部分，也按照原计划交付的时间交付了，用户数量也达到了。

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

　　跟预想的差不多一致，离目标越来越近了。

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

 　　开发的过程还是很痛苦的，中间因为知识储备和粗心大意耽误了不少时间。如果再重来一次，我们的进度就能更快完成，就能开发出更多的功能。

 

计划

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

　　有的，在开始开发之前就做好了计划。

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

　　遇到不同意见的话，先听取他的意见，再一起讨论是否接受意见并修改。

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

　　没有全部做完，在开发过程中，会感觉到开始的许多需求其实没有太大的作用，就删减或者修改了一些工作，再有就是时间不够了。

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

　　有，所以我们每天做完都会有一段时间的讨论，然后删除一些没必要的功能或者需求。

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

　　定义的没有那么清楚，不过大部分功能都实现了。

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

　　出了许多意外，主要还是大家的编程经验不充足，也没投入很多的精力在编写代码上，导致原计划推进的很缓慢，许多功能都是后面加班加点完成的。

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

　　有留一部分的缓冲区，但是感觉缓冲区倒是给了自己一个不想努力编程的理由。。

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

 　　把比较基础的问题时间安排的紧密一点，把核心的问题多留出一点缓冲区时间解决，这样能适当加快项目进度。

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

 　　制定计划没有想象的那么轻松和随意，需要对于项目成员的性格和软件需求有一定的了解。如果重来一遍的话，我们一定要做出更好的计划，更好的更合适的安排项目的进度。

 

资源

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

　　a.技术资源：我们组的技术资源部分相较其他组而言，并没有太大优势，我们组的组员，大部分都没有太多的独立编程的经验，大家都比较局限于理论知识，实操较少。但好在我们选择了采用大家都系统学习过的JAVA语言，完成这次作业。且有两位在这方面比较优秀的组员引导大家，我相信我们能完成这次任务，并且每个人都能在任务中有所提升有所收获。

　　b.时间资源：到达大三下学期，有几个同学报名参加校外的培训，有的同学还要考会计，可以说大家的时间都不充裕，但大家都表示一定会挤出时间，完成本次任务。

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

　　时间资源是按照每天推进项目的进度，但是总会出现许多的意外，所以也会留出一部分缓冲时间。

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

　　a.测试时间：由于各个方面的原因，项目的进度还是很缓慢的，也导致测试时间不太充裕。
　　b.人力资源：人力资源方面还是够的，虽说开始大家磨合出现问题，但后来还是都能做到齐心协力。
　　c.软件/硬件资源：资源上倒是没啥问题。在手机或者模拟器上就可以测试了。
　　d.不需要编辑的资源：确实最开始低估了它们的难度，因为当整个APP页面出来，才能感觉到，美观并不容易做好，而且美观性往往也是用户非常在意的一部分。

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

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

　　一个项目开始之前，PM最好能全面了解各个成员的长处和缺点，这样才能更好的分配任务，也能让项目开发更加有效率。重来一遍的话，我们会先做一个成员长处的小调查，用于后面的任务分配，让大家在开发过程中发挥自己的优点。

 

变更管理

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

　　敏捷冲刺的时候，每天的站立式会议都会交流进度和修改的内容。后面每天也会在群里讨论修改的需求信息。

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

　　根据开始设计时和后面开发过程中对功能优先级的区分。

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

　　预定的功能测试完成，软件也能正常运行，就“做好了”。

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

　　没有制定应急计划

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

 　　可以，因为就算出了意外，也离不开大家的工作范围，大家一起讨论，基本都能解决。

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

 　　消息变更的信息一定要及时通知，功能的需求变化也要及时告知大家。重来一次的话，可能会更加频繁的在群里交流开发的信息。

 

设计/实现

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

　　设计工作是后台程序完成之后大家一起讨论完成的，由于集合大家的意见，肯定很合适。

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

　　有碰到，基本都是能顾全两边就顾全两边。

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

　　有运用单元测试，基本都是每个人测试自己的模块，在遇到实在不懂得问题，大家一起讨论，在测试结果符合后再合并到一起。测试过程没有采用工具，基本是手工测试，遇到问题就修改。

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

　　APP后台运行的功能产生的BUG比较多，因为大家经验都不充足，编写时总出现各种各样的问题。发布之后没有出现太大的问题。设计和开发的时候比较乐观，没有想到这么多

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

 　　为了便于识别和修改，我们严格执行了代码规范

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

　　 代码一定要规范，合理规划时间和安排分工，项目经理及时督促，团队之间多沟通，共同解决成员遇到的问题。

 

测试/发布

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

　　有，但是没有依照计划进行 原因：alpha版本的时候团队进度比较小，以至于deathline还有在修改代码，完善功能，留给我们的测试时间就大大减少了，导致测试计划没有如期进行。

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

　　没有进行正式的验收测试，只是每个人对于自己的部分做了测试，还有就是对源代码打成的APP包安装之后的测试。

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

　　Eclipse里面有一个安卓虚拟机，可以用于测试。

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

　　对于软件进行了预定功能的测试，从结果来看，测试工作还是有用的。不过还是有一些问题手动测试不出来。

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

 　　没有出现太大的意外吧。

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

 　　对于软件的测试要重视，要善于发现问题并且解决问题。再来一遍的话。我们可能会组织一个更加全面的软件测试，能把软件编写的尽善尽美。

 

团队的角色，管理，合作

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

　　　　每个角色基本属于毛遂自荐。一部分人自告奋勇选择分工，剩下的大家再分配，基本是做到了人尽其才。

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

　　　　各个分工也都有很多交叉的部分，大家在交流的工程中基本做到了互帮互助，氛围还是很好的。

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

 　　　　都是大家在一起讨论解决方案，谁能说服大家，我们就听取他的意见。

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

 　　在一个团队里面，角色很重要，交流和互帮互助也很重要。如果再来一遍的话，我们应该会更加注重团队沟通，互帮互助，提高编程的效率。

 

附件：

CMM/CMMI将软件过程的成熟度分为5个等级,以下是5个等级的基本特征：
1． 初始级
软件过程是无序的，有时甚至是混乱的，对过程几乎没有定义，成功取决于个人努力。管理是反应式的。

2． 已管理级
建立了基本的项目管理过程来跟踪费用、进度和功能特性。制定了必要的过程纪律，能重复早先类似应用项目取得的成功经验。

3． 已定义级
已将软件管理和工程两方面的过程文档化、标准化，并综合成该组织的标准软件过程。所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件，软件产品的生产在整个软件过程是可见的。 目前，公司需要申请的就是已定义级别，通常称为CMMI3。由此，我们可知CMMI3是CMMI其中的一个等级。

4． 量化管理级
分析对软件过程和产品质量的详细度量数据，对软件过程和产品都有定量的理解与控制。管理有一个作出结论的客观依据，管理能够在定量的范围内预测性能。

5． 优化管理级
可集中精力改进过程，采用新技术、新方法。拥有防止出现缺陷、识别薄弱环节以及加以改进的手段。可取得过程有效性的统计数据，并可据进行分析，从而得出最佳方法。 每个等级都被分解为过程域，特殊目标和特殊实践，通用目标、通用实践和共同特性。

总结:

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

　　我觉得我们目前的状态属于第二个档次

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

　　我们暂时属于磨合期，相信后面能很快达到规范期　

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

　　大家编程经验更加丰富了，而且彼此之间的交流也更加频繁，契合度也更高了。

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

　　大家对于新功能的开发和美工的完善不是太积极，可能需要在这个方面改进。

 

博客要附上全组讨论的照片。

小组成员	角色	团队贡献分	可验证的贡献
林清清	PM	20	代码撰写，分配任务
郑莹	Dev	19	部分代码、博客
陈惠	Dev	21	部分代码、博客
林晓芳	Test	19	测试、博客
栗海辉	Test	18	新成员
张中结	Dev	21	代码、博客