事后分析报告（M2阶段）

我们的项目是自选项目，一款名为备忘录锁屏MemoryDebris的软件。

在第二轮的迭代中，由于各科的大作业都集中在这一段时间，所以这段时间各个组员间的负担都比较大，但是在大家共同努力，最终我们还是交上一份满意的答卷。

一、小组成员在M2阶段的贡献

在M2阶段，我们小组成员并不像在M1阶段那样分工明显，大部分情况下都是谁有时间就编写软件的某个模块，或者是修复某个BUG。如果非要明显地区分出来的话，大致如下：

顾育豪：负责锁屏模块的连接工作和锁屏界面的设计。

刘强：调整了备忘录，读书笔记的数据库结构，修正了数据库存在的BUG。

王洛书：负责使用说明和备忘录界面的设计、实现；市场宣传。

黄明源：软件主界面的设计者；其他工作如修改小bug，软件图标，各部分连接时候提供帮助；……。

陈睿翊：负责软件设置界面的设计实现，对软件进行测试并提出改进意见。

张梦达：审美一流的设计者，负责团队美工方面；市场宣传；写博客。

二、小组成员M1阶段的分数分配

王洛书 21.5分

顾育豪21分

刘强20.5分

黄明源：19.5分

张梦达：19分

陈睿翊：18.5分

 三、总结

3.1设想和目标

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

我们要做一个能够帮助人们利用解锁屏幕时间的软件。便捷地将每天需要记忆地内容呈现在锁屏界面，让用户根据自己的需求设置、记忆。

定义的很明确。

典型用户：学生、商人、学者等

典型场景：

　　 “解锁屏幕的时候，是不是可以提醒一下自己今天的任务清单是什么？

是不是可以再背一遍今天在书上看到的巧妙算法？

是不是可以再看一看presentation的提纲？

是不是可以再温习一下某个朝代重大事件？

是不是可以再记一下今天要背的生词？

是不是可以再记忆一下等会儿谈判的要点？”

 

2、是否有充足的时间来做计划?

有，我们在第一轮迭代开发时花了1-2周的时间来做计划。

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

开会讨论不同意见，大家评价哪种想法更好。事实证明，我们的方法很有效，大家对产品设计产生过很多分歧，但是最后都通过讨论达到共识。

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

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

一致，我们对现在2000+的下载量表示满意。

我们的经验是前期分工太乱了，让大家一起做一个项目，如果重来一遍，我们会更明确分工内容。

3.2计划

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

完成了。

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

没有。

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

是。

4、是否项目的整个过程都按照计划进行?

是。

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

有缓冲期，缓冲期让我们有充足的时间应对计划之外出现的情况。

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

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

增加缓冲期的长度，更注重界面的设计和风格的统一。

3.3资源

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

资源较少，因为我们的选题是一块市场相对空白的领域，网上几乎没有公开的可供参考的代码。

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

大家坐在一起讨论分析，在大体时间把握上不错，但细节精度不太准确。

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

是。我们低估了美工设计的难度。刚开始写会议总结时分工也有点乱，下一轮会改进。

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

暂时没有团队成员提出。

3.4变更管理

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

是，我们建立了QQ群，每天都会在群里沟通，每周也会在现实里组织开会。

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

通过去掉这个功能，用户体验会降低的程度和程序是否还能正常运行来判断。

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

有。

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

能。

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

能够，我们完善地应对了很多次突发状况。 比如说团队成员生病、发现实现难度有些大、部分Bug修复困难等，最后都很好的解决了。

3.5设计/实现

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

设计工作是第一轮迭代时，大家一起讨论设计，再分工完成每个人自己的部分的。很合适。

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

有，投票决定。

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

有，有效。

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

把设置的内容显示在锁屏上，需要考虑屏蔽安卓自带的锁屏功能，有时一不小心会出bug。

发布之后发现v1.0只能支持4.0以上版本，我们在编码时由于缺乏开发经验，并没有想的这么全面。

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

我们在初期采取的是把6个人分成3组，进行两两结对编程，一边编程一边复审。

3.6测试/发布

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

有测试计划，很有用。

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

进行了。

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

有。

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

大多是人工检测，通过判断是否和预期一致检查性能。这些测试工作挺有用的，后期应多借助一些工具。

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

发现部分网站审核时间过长，失算。