[笔记]敏捷估计与规划

敏捷估计与规划笔记

敏捷宣言推崇:
1.个人与交互重于开发过程和工具
–敏捷开发小组认为: 一个由使用普通工具的优秀人员组成的/运行良好的小组,总是会比由使用优秀工具和过程的普通人组成的,紊乱的小组做的更好.
–我们花了太多的时间试图定义一个开发过程,以便把人当作机器上可被替换的齿轮,却没有取得成功
2.可用的软件重于复杂的文档
–每次迭代结束时获得一个稳定的,逐渐增强的版本,比便更频繁的收集对产品和开发过程的反馈
–将反馈回馈到开发过程,以保证开发小组始终在处理最有价值的功能
3.寻求客户的合作重于对合同的谈判
–这是一个希望,也许不是开发小组可以控制的 –我认为
4.对变化的响应重于始终遵循固定的计划
–最终的目标!!是向项目客户和用户交付更多的价值(或者更多的必要特性,更合理的时间,更小的成本)
–而切记计划是为目标服务的 –我认为

基于活动而不是基于功能进行规划 (是不好的!)
基于活动的规划分散了我们对功能的注意力,而功能才是衡量客户价值的担忧
忽视关于用户最终需要什么的不确定性,会导致虽然然按时完成了项目,却没有包含在制定计划以后发现的那些重要功能.

敏捷开发小组的主要工作方式:
1.作为一个整体工作
2.按短迭代周期工作
3.每次迭代交付一些成果
4.关注业务优先级
5.检查与调整

如何分割用户故事
1.按照数据边界分割
按照用户故事所支持数据的边界分割大型用户故事
2.按照操作边界分割
把大型用户故事分割成独立的建立/读取/更新/删除操作
3.去除横切考虑
为用户故事建立两个版本:一个具备对横切考虑的支持,另一个不具备这种支持.
4.不用满足性能限制
5.分割具有混合优先级的用户故事
6.不要把故事分割成任务
而是寻找一个方法来让曳光弹穿过整个故事
7.避免相关变化的诱惑
在一个适当规模的功能中增加相关变化会把事情弄糟,除非这些变化具有同样的优先级
8.组合用户故事
对按照2周一次的迭代周期工作的开发小组来说,合适的做法是3~5天做完

速度驱动的迭代规划步骤
调整优先级/确定目标速度->确定迭代目标->选择用户故事->分解任务->对任务估计

承诺驱动的迭代规划
调整优先级->确定迭代目标->选择要增加的用户故事/把故事扩展成任务/对任务估计->要求小组作出承诺<->移除一个用户故事(如果无法承诺)->迭代规划完成(可以承诺)

人们倾向于在现有项目管理方法的背景下诠释scrum

人们倾向于在现有项目管理方法的背景下诠释scrum,他们还没有充分理解自管理,涌现机制,可视性和检查/适应循环的根本原则,便开始使用scrum规则和实践方法。他们忽视了scrum从控制到授权,从契约到合作,从文档到代码的工作模式转变。
-《scrum敏捷项目管理》c3

–也许这样翻译好一点,"自我管理,自发机制,任务进度透明情况和自检"
Powered by MoFire