Posts Tagged ‘scrum’
[笔记]敏捷估计与规划
敏捷估计与规划笔记
敏捷宣言推崇:1.个人与交互重于开发过程和工具–敏捷开发小组认为: 一个由使用普通工具的优秀人员组成的/运行良好的小组,总是会比由使用优秀工具和过程的普通人组成的,紊乱的小组做的更好.–我们花了太多的时间试图定义一个开发过程,以便把人当作机器上可被替换的齿轮,却没有取得成功2.可用的软件重于复杂的文档–每次迭代结束时获得一个稳定的,逐渐增强的版本,比便更频繁的收集对产品和开发过程的反馈–将反馈回馈到开发过程,以保证开发小组始终在处理最有价值的功能3.寻求客户的合作重于对合同的谈判–这是一个希望,也许不是开发小组可以控制的 –我认为4.对变化的响应重于始终遵循固定的计划–最终的目标!!是向项目客户和用户交付更多的价值(或者更多的必要特性,更合理的时间,更小的成本)–而切记计划是为目标服务的 –我认为
基于活动而不是基于功能进行规划 (是不好的!)基于活动的规划分散了我们对功能的注意力,而功能才是衡量客户价值的担忧忽视关于用户最终需要什么的不确定性,会导致虽然然按时完成了项目,却没有包含在制定计划以后发现的那些重要功能.
敏捷开发小组的主要工作方式:1.作为一个整体工作2.按短迭代周期工作3.每次迭代交付一些成果4.关注业务优先级5.检查与调整
如何分割用户故事1.按照数据边界分割按照用户故事所支持数据的边界分割大型用户故事2.按照操作边界分割把大型用户故事分割成独立的建立/读取/更新/删除操作3.去除横切考虑为用户故事建立两个版本:一个具备对横切考虑的支持,另一个不具备这种支持.4.不用满足性能限制5.分割具有混合优先级的用户故事6.不要把故事分割成任务而是寻找一个方法来让曳光弹穿过整个故事7.避免相关变化的诱惑在一个适当规模的功能中增加相关变化会把事情弄糟,除非这些变化具有同样的优先级8.组合用户故事对按照2周一次的迭代周期工作的开发小组来说,合适的做法是3~5天做完
速度驱动的迭代规划步骤调整优先级/确定目标速度->确定迭代目标->选择用户故事->分解任务->对任务估计
承诺驱动的迭代规划调整优先级->确定迭代目标->选择要增加的用户故事/把故事扩展成任务/对任务估计->要求小组作出承诺<->移除一个用户故事(如果无法承诺)->迭代规划完成(可以承诺)
Scrum status
Powered by MoFire
scrum读书笔记
Scrum的运作基础是个人和团队的承诺,而非严密的规划和控制.相对于强行控制和规划,其忠诚度.自组织和员工责任感是更为有效的机制.
阅读和谈论scrum,与具体实施它是两码事.scrum必须先就位,才有机会被充分理解.-scrum敏捷项目管理 c4
人们倾向于在现有项目管理方法的背景下诠释scrum
人们倾向于在现有项目管理方法的背景下诠释scrum，他们还没有充分理解自管理，涌现机制，可视性和检查／适应循环的根本原则，便开始使用scrum规则和实践方法。他们忽视了scrum从控制到授权，从契约到合作，从文档到代码的工作模式转变。
-《scrum敏捷项目管理》c3
–也许这样翻译好一点，＂自我管理，自发机制，任务进度透明情况和自检＂
Powered by MoFire
