标签：还需 原则 适应 需求分析 简单 分析 验证 联系 最佳实践
《构建之法》第四次随笔
这半个月我阅读了《构建之法》第六章，第七章，第八章。
第六章主要讲的是敏捷流程。敏捷流程是一系列价值观和方法论的集合。敏捷对团队的要求很简单：自主管理，自我组织，多功能型。但是这很困难，如果团队要变成敏捷流程，要做这些改变。多次总结改进才能使团队走上正轨。
敏捷实质是一股思潮，或者说是一种价值观，它涵盖了好几种软件开发的方法论，这些方法论又是建立在许多行之有效的最佳实践方法之上的。、
第七章讲的是MSF——微软解决方案框架，也就是微软推荐的软件开发方法。MSF有一套思想框架——9条基本原则。
1．推动信息共享与沟通
2．为共同的远景而工作
3．充分授权和信任
4．各司其职，对项目共同负责
5．交付增量的价值
6．保持敏捷，预期和适应变化
7．投资质量
8．学习所有的经验
9．与客户合作
MSF团队模型中的角色都被认为是同等重要的，重要的决定都要共同做出。MSF团队模型推动了不同利益代表在追求共同利益过程中的融合。
在练习与讨论中，小飞的问题我的答案是这样的：在如今的大学生活里，还是要靠团队成员的个人自觉。因为我们还么有迈进社会，还是无法特别有责任心的完成团队的任务，通常就是应付了事，我们成长，还需要一段时间。这次的团队合作，就是一个很好的契机，让我们能够改变自己。
第八章讲的是需求分析。软件团队如何才能准确而全面的找到这些需求主要有以下几个步骤：
1.获取和引导需求
2.分析和定义需求
3.验证需求
4.在软件产品的生命周期中管理需求
对软件的需求也可以从不同角度做划分：
软件开发的过程就是用户最需要的东西，获取用户需求为用户调研。有常用的几种：
在联系与讨论的8.8.4练习题中，在一个软件项目中，软件团队预计每天的进度为 30 小时（即，完成了30小时的工作量）。当项目完成了一半的总工作量的时候，大家发现实际的进度为15小时/天，问：在余下的时间中, 团队的进度要到多少，才能在项目结束时让整个项目的平均进度恢复到每天30小时工作量？
我认为是60小时/每天。
标签：还需 原则 适应 需求分析 简单 分析 验证 联系 最佳实践
原文地址：http://www.cnblogs.com/dearforsaken/p/6833426.html
