标签:width 进度 工作 机制 关注 style toc 分配 理解
今天把前段时间,给公司讲解敏捷开发流程的PPT文档发出来。由于近来比较喜欢用Markdown编写文档,发现博客园不支持Markdown编辑,有点失望。小小吐槽,O(∩_∩)O~
敏捷开发的最大特点是:积极响应用户的需求,快速高质量的交付软件; 其核心是:以人为本,发挥人的主观能动性.
每轮迭代Sprint启动前,团队共同讨论本轮迭代详细开发计划的过程
输入:产品Backlog
输出:迭代Backlog
迭代计划会议内容:
1)澄清需求、对"完成标准"达成一致
2)工作量估计、根据团队能力确定本轮迭代将会内容
3)细化、分配迭代任务和初始工作计划
关键点:
1) 充分参与:Scrum Master(项目负责人)确保PO(产品负责人)和Team(开发人员及UI美术)充分参考讨论,达成理解一致
2) PO(产品负责人)承诺在短迭代周期不增加需求(2-4周)
每日工作前,团队成员的例行沟通机制,由Scrum Master组织,Team成员全体站立参加
聚焦主题:
1)我昨天为本项目做了什么
2)我计划今天为本项目做什么
3)我需要什么帮助以便更高效的工作
每日站立会议好处:
1)增加团队凝聚力,产生积极的工作氛围
2)及时暴露风险和问题
3)促进团队内成员的沟通和协调
关键要点:准时开始,高效会议,问题跟踪
将项目状态(进度、质量等)可以通过看板实时展示,让团队所有成员直观地获取当前项目进展信息
关键点:
1)物理实体:可视化一定要做到物理上的实体化,大家在公开场所 都容易看到
2)内容精简易懂:信息展示一目了然,切实对团队有帮助
3)实时刷新:延迟的信息拖延问题暴露,降低运作效率
如果开发完成,并向项目负责人、产品负责人 SHOW CASE以后,开发人员吧故事卡移植到等待测试
关键点:
1)展示真实的产品
2)收集反馈
在每轮迭代结束后举行的会议,目的是分享好的经验和发现改进点,促进团队不断进步
关键点: 1)会议气氛:Team全员参加,头脑风暴发现问题,共同分析根因 2)关注重点:Team共同讨论优先级,将精力放在最需要的地方 3)会议结论要跟踪闭环:可以放入迭代迭代Backlog中
看板管理工具
阶段 | 瀑布模式 | 敏捷开发 |
---|---|---|
业务需求 | 强调需求文档 | 注重沟通交流 |
管理进度 | 管理文档(需求计划、进度表) | 看板(任务开发状态是否顺利进展、<br/>有没有阻塞) |
任务分配 | 开发人员被动安排 | 开发人员主动自我管理、责任心强 |
版本迭代 | 产品整体需求计划 | 小版本迭代 |
研发 | 开发人员安照需求文档要求开发<br/>较少沟通业务场景使用情况 | 开发人员站在用户需求角度对接需求 |
研发周期 | 版本周期较长 | 版本周期短(2-3周) |
标签:width 进度 工作 机制 关注 style toc 分配 理解
原文地址:http://www.cnblogs.com/leehongee/p/7291664.html