标签：
第八章主要软件团队如何准确全面的找到人们对于软件五花八门的需求，主要有以下几个步骤：
1、获取和引导需求
2、分析和定义需求
3、验证需求
4、在软件产品的生命周期中管理需求 。
接下来讲了软件产品的利益相关者，还有用以获取用户需求的九种用户调查方法。得到需求之后软件团队就要考虑功能的定位和优先级，之后还有计划和估计等更多才能进行更好的需求分析。这章教会我们如何更好的规范有序的进行软件需求分析。分而治之。把大任务分解成多个小任务，帮助你更加精确的估计它们，并且保证更加精确、细密的状态跟踪。然后让不同的人负责，还有，PM要跟进这些小任务的进度，确保项目的高速以及正常进行。
第九章介绍项目经理的，然后第二节讲了微软pm的来历，以及pm做开发和测试之外的所有事情，然后pm管理代码之外的，还有风险。总的来说，PM就是要带领团队达成最重要的目标，并保持团队的平衡。还有值得注意的一点是PM管事不管人，毕竟，我们倡导平等工作。PM不做开发和测试之类的事，毕竟PM要负责太多的事，应该没什么时间参与开发。最后详细说了pm的能力要求和任务。PM的能力要求和任务，书上列举了一些PM的能力，有，观察、理解、快速学习的能力；分析管理能力；一定的专业能力；自省的能力。这章就是向我们介绍软件团队的重要角色——项目经理。
第十章首先讲了如何定义典型用户及场景，以及典型用户的价值，模板，场景的模板等，然后有讲“用例”这个需求分析工具，接下来规格说明书介绍了功能说明书及模板和技术说明书，最后说了功能驱动的设计。典型用户和典型场景。大概就是非专业的程序员、专业的程序员、项目经理这三种人吧！典型用户很大的作用就是让程序员考虑问题时从用户的角度出发。定义完典型用户后，我们还要和典型用户的代表交流并理解他们。从典型用户到典型场景，要针对典型用户写典型场景，在从场景到任务，最后编写故事模板。用例，是需求分析工具。通过讲简单故事来传递信息。但讲故事较难，一般很难得心应手。规格说明书。有软件功能说明书和软件技术说明书。功能说明书是从用户角度描述不涉及软件内部细节。而技术说明书是设计文档，描述了开发者怎样实现功能，这对于中途加入团队的成员很有用。功能驱动的设计。就是把用户的需求变成团队的开发工作，然后不断实现这些需求。它涉及到构造总体模型、构造功能列表、制定开发计划、功能设计阶段、实现具体功能这几个步骤。这章教我们锁定典型的用户群体，利于我们寻找更好的用户。
提问：
1软件的生命周期具体指的是什么？如何判断软件的生命周期的长度？
2.软件团队中那么多角色，为什么要挑项目经理单独讲一章？
3.如果要找典型的用户，怎么找？
sprint总结：
之前我们组讨论的时候不激烈，总会冷冷清清，的确存在沟通问题，近几次的讨论每一个成员都非常激烈，说出自己的意见，sprint第一个冲刺周期顺利完成，都是在每一个成员的积极配合下完成的，而且大家有不懂的都会去请教别人或者看书，上网查资料，产品负责人一开始把产品需求会列得很清楚。
标签：
原文地址：http://www.cnblogs.com/hui1005039632/p/5534866.html
