回顾+读后感

1.回顾组织

　　主题：“我们下次怎么样才能更加认真对待？”

　　时间：设定为1小时。

　　参与者：整个团队。

　　场所：宿舍走廊。

　　秘书：团队队长秘书，筹备、记录、整理。

 

2.回顾流程

   Sprint总结：对于这一次的Sprint计划，我们没有按照原本的计划去完成。一开始，我们在连接数据库阶段一直出错，原因是我们团队三个人中没有人熟悉这项操纵，在之后的登陆做账号登陆界面时候，我们又一次的碰瓷，按照jsp书上的内容去实现，又出现了很多的错误。或许是我们高估了自己，以为这项Sprint可以不用花很多的时间去完成，结果，我们却在这个关卡花费了更多的时间。我们在这一门科目花的时间很少，所以效率也理所当然的低下。经过这次的失败，我觉得态度是真的很重要，热爱一门科目需要好的态度，即使你在实践过程中出现了很多问题，很多错误，你选择继续或者逃避，这就是你的态度。团队配合很重要，一个人的能力是有限的，所以才更需要去依赖一个团队。

 

3.轮流发言

练思明：我们在这次的Sprint中花费的时间很少，所以拖慢了进度，我们承认这个问题。在下一次的Sprint中我会更努力的去完成好自己应该要完成的事情。

卓嘉炜：尽管这次的Sprint进度拖得慢了，但是，我们会吸取前一次的经验，对于不熟悉的操作，我们更应该去提前做好准备。

何宇明：即使结果是差强人意，可是，我们也对这个项目付出了努力，后面的事情我们进一步去完善就好了。

 

生产分析：

第一个Sprint的结果跟我们预期的相差太远，有很多任务都没有完成。

原因是：1.在连接数据库方面我们出了差错，建立好数据库，我们不知道怎么样连接；

           2.在利用jsp做账号登陆界面时，我们按照书上的内容并没有实现这项操作，出现了很多的错误；

改进之处：提高积极性

              对于数据库方面的基础内容要去巩固（上学期学的内容基本我们都忘记了），拓展我们的知识面

              重新调整我们的Sprint计划；

4.回顾辅助

　　Good：我们通过看板来跟进项目进程，记录每一次的任务点和完成点。因为我们宿舍离得近，所以我们的交流很方便，有任何的想法都可以及时的去告诉对方。

　　Could better：我们要利用更多的时间去完成这项目，提高我们的积极性很重要。

5.回顾结论

　　即时贴上。

　　圆点投票来决定下一个sprint会着重进行哪些改进。

　　每个sprint只关注几个改进就够了。

 

练思明：  20

卓嘉炜：  21     http://www.cnblogs.com/luoliuxi/

何宇明：  19     http://www.cnblogs.com/40heyuming/ 

《构建之法》第8章：

第8章主要介绍了软件需求的类型、利益相关者，获取用户需求分析的常用方法与步骤、竞争性需求分析的框架NABCD,四象限方法以及项目计划和估计的技术。

作为一个软件团队要准确而全面地获取这些需求主要有以下四个步骤：

1. 获取和引导需求。这一步骤也被叫做“需求捕捉”。软件团队需要为用户着想，设身处地，为用户引导出需求。
2. 分析和定义需求。从各个方面获取的需求进行规整，定义需求的内涵从各个角度将需求量化。
3. 验证需求。软件团队要跟利益相关者沟通，通过分析报告、技术原型、用户调查或演示等形式向他们验证软件团队对于这些需求的认知。
4. 在软件产品的生命周期中管理需求。

《构建之法》第9章：

第9章主要介绍了团队角色分工、项目经理的由来和要求、项目经理和其他经理的区别、软件项目中的风险和风险管理、PM的专业能力。

PM是指项目经理

Product Manager:产品经理——正确地做产品。

Project Manager：项目经理——正确地做流程。

Program Manager：微软职位名称。

PM做开发和测试之外的所有事情

PM最大、最独特的贡献是带领团队达成最重要的目标，并保持团队的平衡。

PM的能力要求和任务：1.观察、理解和快速学习的能力;

                             2.分析管理能力;

                             3.一定的专业能力;

                             4.自省的能力。

《构建之法》第10章：

 第10章主要介绍了典型用户(Persona)和场景(Scenario)、软件功能说明书(Functional Spec)和技术说明书(Design Doc)、功能驱动的设计(FDD)、用例(Use Case)。

典型用户可包括以下内容：

1. 名字（越自然越好）
2. 年龄（不同年龄和收入的用户有不同的需求）
3. 收入
4. 代表的用户在市场上的比例和重要性（比例大不等同于重要性高，如付费的用户比例较少，但是影响大，所以更重要）
5. 使用这个软件的典型场景
6. 使用本软件/服务的环境
7. 生活/工作情况
8. 知识层次和能力
9. 用户的动机、目的和困难
10. 用户的偏好

功能驱动的设计：1.构造总体模型(Develop an Overall Model);

                      2.构造功能列表(Build a Feature List);

                      3.制定开发计划(Plan by Feature);

                      4.功能设计阶段(Design by Feature);

                      5.实现具体功能(Build by Feature)