我们的项目是自选项目，一款名为备忘录锁屏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. 在发布的过程中发现了哪些意外问题？
发现部分网站审核时间过长，失算。
四、总结