第八章：成长：规划与迭代
8.1 敏捷十二条原则
一、对于我们而言，最重要的是通过尽早和不断交付有价值的软件满足客户需要。
二、拥抱变化，欢迎需求的变化，即使在开发后期。
三、敏捷过程能够驾驭变化，保持客户的竞争优势。
四、经常交付可以工作的软件，从几个星期到几个月，时间尺度越短越好。
五、业务人员和开发者应该在整个项目过程中始终朝夕在一起工作。
六、围绕斗志高昂的人进行软件开发，给开发者提供适宜的环境，满足他们的需要，并相信他们能够完成任务。
七、在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈。
八、可以工作的软件是进度的主要度量标准。
九、敏捷过程提倡可持续开发。
十、对卓越技术与良好设计的不断追求将有助于提高敏捷性。
十一、简单——尽可能减少工作量的艺术至关重要，最好的架构、需求和设计都源自自我组织的团队。
十二、每隔一定时间，团队都要总结如何更有效率，然后相应地调整自己的行为。
Scrum方法
►团队角色
PO（Product Owner）通常是产品经理，要对各种利益相关方负责。
SM（Scrum Master）充当教练的角色，一般由对流程、方法论比较熟悉的人来担任，不建议这个角色和PO重叠。
Team由核心成员组成，其中的某一个人是可以担任SM的。
►关键产出物
Product Backlog指比较长期的产品任务表，即第06章提到的功能列表。
Sprint Backlog在Scrum里指当前这个迭代里面的任务点。
Burndown Chart是燃尽图，用来监控任务是不是在按期推进。
►重要的会议
首先是每个迭代的计划会 ，经常和需求评审会 合并，主要目的是明确任务，以及评审这个迭代里需要做的功能。
每天的站立会议 ，是重要的信息同步手段。
功能评审会 用来评估做出来的东西是不是想要的。
回顾会 的目的是为了过程改进，因为Scrum和敏捷最核心的思想就是不断优化，以优化出一个最适合当前团队的方法论。
►日常管理工具
看板 是一个非常重要的实用工具，很多公司的办公区里都会有，在硅谷创新公司里也被广泛应用。
流程的简化
►立项会议： 确定项目目的——为什么、做什么（时间控制在半小时以内）。
►需求评审： 确定项目怎么做（对相对较小的项目，可以和立项会议合并，总体时间控制在2小时以内）。
►功能评审： 简单地讲，就是在测试环境下演示一下产品，以确定做出来的是不是团队要的（1小时左右搞定）。
►发布上线： 确定产品是不是用户想要的，以及用户还要什么。通过获取用户反馈来让产品的优化形成一个螺旋上升的闭环。以上说的是主流程，还有两个常见的分支流程也简单提一下。
►需求变更 ：这在项目过程中不可避免，一开始可以简化成某个人拍板，决定是否接受变更。
►日常需求： 即零散、随机出现的小需求。开始只掌握一点，即所有需求必须经过产品经理，运营等角色不能直接找开发，确保产品经理知道所有的需求信息，以便统筹安排。
广义的公关之法，其本质就是先不做，却告诉受众我已经做了，从而收集反馈，其优势在于成本非常低，验证非常高效。
