[Beta]M2事后分析

计划

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

答：没有，全部的功能没有实现。其中，界面还差两个，逻辑还差闹钟逻辑和群组逻辑，可以说这些东西是我们的核心功能之一，缺失了他们对我们整个团队的影响非常大。原因错综复杂，然而最主要的原因还是因为繁重的课业压力和“不作为”的心态。

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

答：重新检测后端，重新分配任务。事实证明我们就应该先办个培训。技术断层出现了，让成员们跟的很辛苦。安卓平台多种多样的语句再次给程序的编写带来了麻烦。另外大家在心中普遍认为编译比较重要，有一种逃避心态。

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

答：是的。每一件任务都有清楚的定义和交付，然而交接困难，在交接时还会出现各种各样的问题。文档和学习方式、地址没有定义，这也是我们做东西难度很大的原因之一。【绝对要先找到合适的学习方式，规范整个工程细节】如果说收获的话，这是我在本次迭代中收获最大的内容之一了。

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

答：整个项目的过程完全没有按照计划进行，按照原计划，我们在12月28号就可以完成大部分工作，然而事实上，我们在12月28号之前的工作很少量，而且还是无关紧要的一些。在Beta迭代中，我们遇到了很多考试或者大作业的突然拦截，更加减慢了我们整体的进度。

在计划中有没有留下缓冲区，缓冲区有作用么？

答：我们的缓冲时间在1.1日到1.7日，然而事实证明这个缓冲区没有起到缓冲区的作用。在12月中旬后所有科目都迎来了大作业阶段，1.4号的编译考试也使这一段时间作为缓冲区的想法彻底废弃。事实上，我们在12月20日之后先后迎来了编译课程设计，数学建模论文，数据库课程设计，缓冲区没有起作用。

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

答：暂时没有下一次迭代开发的计划，假设还有第三轮迭代，一定会先整理思路，集合人马。写出文档和学习资料。否则进展将十分艰难。

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

答：学到的主要是团队管理的东西。比如如何调动团队成员的积极性，对于项目本身该怎么估计，如何处理成员自身的事情和发派任务之间的关系，等等。如果再来一次，我会改善整个团队的人员配比，多产生几个业务熟练的代码工程师来实现功能。然后把整个团队项目的设计文档、声明写好。还要为所有团队成员写一份学习的文档，用于成员们提升自己。

资源

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

答：对我们组而言，最宝贵的资源是时间。时间是不够用的。而其余无论是硬件还是软件，我们的资源应该都比较充裕，也可能是我们整个团队项目需要的资源太少了吧。

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

答：Beta阶段有很多课程的大作业临近截止，时间紧迫，大家也很慌张，沉不下心去开发软工。所以我们布置的时间很宽裕，然而我们遇到了一个问题：有时间没积极性，鼓动到有积极性就没有时间了。这真是一个死结。

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

答：人力资源足够。刚才上一问没注意到，没发现人力资源也是资源。我们需要4名能够进行快速开发的熟练安卓开发者，然而我们小组的成员没有做到这一点。对于UI和文案，我们没有低估难度，也没有高估难度。在这方面我们还是充满信心的。

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

答：是这样的。我本人对于安卓开发的兴趣不太高，在寻找API和测试API中也是吃了不少苦头，所以效率特别低。而事实上，我们能做系统开发的程序猿的人数极少。然而我的工作也是需要完成的。所以只能硬着头上。

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

答：不要有英雄主义，不要盲目自信。你要明白，别人5天能做完的东西你不可能一天做完，要学会利用团队的力量，学会调动整体积极性，这对一个团队而言十分重要。

总而言之就一句话，在团队里，要利用团队的力量。

变更管理

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

答：是的。我们会在群中进行通知，不过偶然也会出现沟通不及的事情。不过那个比较少见啦。

我们采用了什么办法决定"推迟"和"必须实现"的功能？

答：主要是看自己程序的杀手优势，能不能实现我们的杀手优势对我们而言意义重大。所以当一个杀手优势遇到困难时，我们会推迟其余的事情去做他。

项目的出口条件有清晰的定义么？

答：当压力测试和兼容性测试完成并且这两个测试基本没有问题，我们就认为可以发布了。

对于可能的变更是否能制定应急计划？

答：一般而言，如果这个问题十分大，我们会放下手中的其余工作去做他。如果这个问题并不重要，我们应该会直接放弃。

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

答：并不能，大家对于自己的时间管理都非常看重，所以一般不会同意计划之外的工作请求。不过讲道理的说，这一个学期大家真的太累了，累到天天通宵没有力气，谁也不想再去做点什么。对于这个事情吗，我是可以理解的。

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

答：积极了解组员的生活状态，然后试着把一切都往好的地方去引导，虽然有时候可能做不到，但是也得尽力去尝试。

设计/实现

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

第二阶段开始之前，所有人开会讨论了一下我们第二阶段的功能、进度以及可能出现的问题，然后指定了一个计划，主要由所有人讨论呢完成，时间也恰好合适。

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

没有，我们的任务写的都十分面向问题，告诉你要解决一个什么样子的问题。

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

所做的测试不够充分，使用了一部分单元测试，没有太大的效果。

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

用户部分，这部分有很多的BUG，这是我们一直没有调出来这个的原因。因为一开始没有想好推送怎么写，浪费了大量时间而一无所得。因为你不去亲自实践是不知道可能会出现这个类型的问题的。

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

大部分代码是遵从代码规范的，没能做到所有的都严格执行代码规范。代码复审由测试的同学黄上看一下，然而还是有一部分懒得改。这也是我们做的不好的这一点。

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

设计阶段我们犯了一个大忌：想的太好，做的太少。好多东西都没法及时跟进，可能还是由于积极性确实不高。

测试/发布

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

按照我们的计划，我们写完一个功能就由测试人员进行测试。

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

未完全做完，所有验收测试没有进行。

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

主要是Android Studio和JUnit

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

这部分我们可以说的不多，因为软件整体没有完全实行，空谈效能只是纸上谈兵，没有什么意义。

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

没有发布新版本，所以回答不了这个问题。

总结

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

答：我觉得团队目前的状态属于已定义级别，有维护的标准文档，但没有严格的代码复审流程，团队协作比较协调。

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

答：我觉得我们团队目前处于磨合阶段。整个团队还是不能合到一起去，拧成一股绳。

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

答：改进是我们引入了一个代码大神，比原来的队伍更好沟通和开发了。不得不说一个有上进心，不怕付出的队友真的真的很重要。

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

还是整体的完成度。我们的完成度较低，大家学习和工作的积极性不太高，这也是比较让我们难过的地方吧。

相比于α阶段，我们改进了什么？

学会了使用Git去管理项目，发布任务，生成燃尽图。

相比于α阶段，我们保持了什么特点？

保持了对于项目的思考和实时的改进，也保持了我们的最初想法和杀手优势。