(no title)
#《scrum敏捷产品管理》读后感
软件工程是从其他工程行业借用造出来的词，但软件同制造业是有差别的，制造业最终都能由机器人替代，软件则是一项有创造性的工作，可以说它是门工艺，优秀的软件需要的是匠人精神，但大型的项目，确实是需要一个工程管理的规范，来组织协调资源，来保证项目的成功。所谓的工程，其实就是通过规范的流程来把控成本，质量和进度，传统的瀑布模型的问题在于迭代周期长，市场情况在变，用户需求也会变。而Scrum敏捷开发强调快速开发，快速迭代，从满足特定用户需求的最小功能集的产品开始，减少上市的时间，用最小的成本，或者高的投资回报率，改善现金流，引入反馈机制到开发的过程中。并根据市场的反馈来直接调整。Think big, but start small。
scrum的重要角色和流程
大家一起做一个产品，首先就需要有个大家都认可的vision，传统的开发流程中，信息的传递很可能是这个方式: “市场研究 -> 产品经理 -> 项目经理 -> 开发团队 -> 测试团队”，市场人员有了用户的需求，然后产品经理设计产品，项目经理依据需求设定开发计划，开发团队开发软件，测试团队了解功能需求，然后测试团队验证功能实现。很有可能存在这种情况：功能都实现了，测试也过了，但最终和用户想要的有差距。可以说是信息的多次传递导致的，但这个很难避免，问题在于需要有一个全局的把控，所以本质上是缺乏一个对产品最终是否成功负责的人。一个成功的产品背后，总可以找到这么一个人，那个人也就是产品的Owner，对这个产品负责，也有权威做出决策，这个人需要具备”市场研究，产品经理，项目经理”的综合素质，对只是经验的广度和深度都有一定的要求。这个职位的职责包括:
- 构想产品的vision
- 整理产品的backlog
- 发布计划
- 帮助团队和客户用户股东建立沟通机制
- 管理成本
- 参加团队会议并和团队协作
这个人是团队的统帅，既然是统帅，那就只能是一个人，有权威（不是权力），但是很多决策还是和团队一起讨论。很多产品的Owner甚至是公司的CEO。
需要具备的特征:
- 有远见，也是实干家
- 是领袖，也能融入团队
- 善于沟通，也勇于说不
- 有权威，也有担当
大型项目可以考虑引入层级的Product Owner，需要有一个首席的Product Owner来负责全局，总的开发进度，协调用户和其他的股东，剩下的Product Owner则专注特定的功能或子系统。这里涉及到团队构成的问题，大型项目的复杂性会使得我们自然而然的倾向按模块来划分scrum团队，而不是按产品的功能来划分，这样的问题往往会出现在集成过程中，各个模块完成了自己负责的需求，但作为一个产品的功能往往是多个模块集成起来提供的，按模块来组成scrum团队，会导致与功能对应的backlog被切分，并被分别验收，结果就是导致没有人来对集成后的产品的功能来验收。所以功能性相关的backlog，都应该按功能来构成scrum团队；非功能性的backlog（性能优化，代码重构等）才可以考虑按模块划分来组建scrum团队，并且由资深的技术人员来担任Product Owner。
如果说Product Owner是球队的总经理，那么Scrum master则是球队的教练（这是只是一个职责的类比，作为scrum团队的成员，并没有这种上下级关系）。Product Owner负责要做什么样的产品，而ScrumMaster对怎么用正确的Scrum方式去做负责。这个职位的职责包括:
- 帮助Product Owner梳理backlog，调整发布计划
- 保证团队的协作顺畅高效
- 带领团队准守最佳工程实践
- 组织内不同团队的沟通(SoS)
确保团队不被其他和sprint目标不相关的事情打断
更多的细节参考“The Scrum Master Checklist”
这是两个不存在于传统开发模式的新角色，Product Owner集市场研究，产品经理，项目经理于一身，而Scrum master则类似技术经理的角色，但弱化了其权力，强调了团队协作共同决策。Scrum的产品开发模式和传统开发模式也有很多不一样的地方。
一个产品首先需要有Vision，构想产品Vision需要能回答下面的问题:
- 目标客户和目标用户分别是谁？
- 产品要解决什么问题？
- 产品提供哪些核心功能让其脱颖而出？
- 如何盈利？
- 可行性，是否有研发能力？
什么样的想法才算是Vision？
- 首先需要大家都认可，在这个阶段最好是让投资方和团队都参与。
- 宏观并且激动人心的目标。描述要做什么，而不是怎么去做，这样才能激发团队的创造力。
- 清晰简明的价值主张。用户选择一个产品，使得其有竞争力的卖点往往就是那么三四个。检验一个产品的vision是否简练，要想想是否能在电梯里面就能将产品的核心价值解释清楚。
有了vision后，就要开始计划推出最小市场化的产品(minimal marketable product)，未来很难预测，保险的做法就是从满足特定用户需求的最小功能集的产品开始，快速迭代。当产品推出市场之后，就可以开始制定未来6个月到12个月内的roadmap了，包括什么时候发布，目标客户和他们的需求，首要的3到5个功能点。
backlog替代了传统的需求文档，是一些按优先级排列的代办事项，可以是功能性和非功能性的需求，配置环境，修复bug等任何和交付产品相关的事情。这个列表由Product Owner来管理，团队其他成员和客户用户参与讨论。backlog需要满足下面的条件(DEEP):
- Detail，高优先级的backlog要比低优先级的描述更加详细，大的backlog会被拆分。
- Estimated，工作量能够评估。
- Emergent，backlog不是一成不变的，会有增删改的情况
- Prioritize，有优先级的区别。
backlog的描述一般采用user story，包含如下信息:名称, 简要描述，和验收标准。
在对优先级进行调整的时候要考虑的因素包括:
- 功能的价值，最有价值的先交付。
- 风险，对于风险不确定的事情，早尝试可以早点知道结果，避免项目晚期来不及做调整。
- 功能是否可以尽快发布。只要能提供用户有用的功能，不一定要完成所有的功能点，就可以发布出去尽快获取用户反馈并进行调整。
- 依赖关系，要么解除依赖，要么解决依赖。
backlog的整理可以在任何时候，也可以不定期的单独安排grooming的会议，但这个过程是一个团队协作的过程，而不是Product Owner单独的决策。在每次的scrum plan会议之前，要在接下来的sprint做哪些事情事先就要已经准备好了，需要对大的不明确的backlog进行拆分，拆分为清晰，可以测试的，可行的项目。工作量的评估也是一个协作的过程，团队每个成员要对工作量达成一致，如果不一致要陈诉自己的原因，这样确保大家对backlog的工作量达成共识，工作量不是一个绝对的值，而是一个相对的。工作量评估便于对项目整体进度进行把控。
有了准备好的backlog，就可以开始做计划了，计划首先需要定义一个目标，这样选出来的backlog才有一定的关联性，保证能交付满足用户需求的特定功能。在plan会议中，Product Owner要帮助团队理解需要做什么，团队需要弄清楚能做多少，怎么做，所有的目标都不能强制制定，而要又团队自己来决定能做多少，保证整个开发过程是可持续的。Plan过程中要对backlog细化为具体的任务，对每个任务进行工作量的评估，每个任务不要超过一天的时间。
计划开始执行时，每天都会有一个短会，这个短会的目的除了汇报进度（昨天做了什么，今天要做什么），也可以让其他人知道你在执行过程中碰到了什么问题，需要什么帮助。Sprint的燃尽图是不用来给领导汇报进度的，而是团队自己用来跟踪进度并调整计划的。管理层要关注的是产品发布的燃尽图。
Sprint完成后，可以有一个sprint review会议，由Product Owner主持，作为一个团队和用户股东沟通的机会，团队可以做产品展示，用户和股东可以给出反馈。这个会议要杜绝使用PPT，目的是增加开发流程的透明度，并让产品朝着正确的方向演化。Backlog的验收可以放在这个会议中，也可以在backlog完成后立即验收，提前给出反馈。
Sprint反省会是团队的一个学习机会，总结过去展望未来，学到了什么，有什么要提高。
从上面的流程来看，要保证项目的快速迭代，也需要结合Test Driven Development和Continuous Integration来提高效率。
