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

 

　　因为我们组成员在此之前都没有接触过安卓开发，于是在第一阶段花了很大的时间和精力学习安卓。又花费了较长一段时间设计软件与研究安卓锁屏机制。

 

　　基于我们的基础，我们对第一次迭代开发的结果相对满意，并深深认同每一位团队成员对我们团队的付出，在此做一些总结，希望第二轮迭代可以走的更远。

 

 

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

 

顾育豪：很尽责的PM，组织能力优秀；与王洛书组队，完成锁屏模型设计与实现；后期负责锁屏模块的连接工作；……。

刘强：实现对手机短信数据库的访问，调用；设计了备忘录，读书笔记的数据库结构，编写了数据库的控制接口；添加了前台界面的事件监听；……。

王洛书：与顾育豪组队，完成锁屏模型的设计与实现；负责编写用户选择是否锁屏部分的代码；编写图片导入模块；市场宣传；……。

黄明源：很好的dev与designer，主要针对软件UI进行设计与制作，编写xml文件。其他工作如修改小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. 在发布的过程中发现了哪些意外问题？

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

 

 

 

四、总结