如何理解敏捷开发
2014-08-30 13:17
190 查看
从知乎摘抄的
敏捷 Short Cycles that are test-driven and feedback-driven, yielding constant improvement 的核心就是短周期迭代交付,可视化,自适应调整,开放式及时沟通,所有的敏捷实践基本都围绕这些核心展开,如果要再对敏捷的核心进行抽象就是迭代+自适应。
首先,敏捷开发是一种过程控制论,通俗地说,就是一种做事情的方法
1. 它适用于软件,可以改。如果是硬件,改起来就没那么方便了。
2. 它适用于客户不知道自己要什么的情况,其实这样的客户占大多数。因为客户不知道要什么,所以我们需要不断帮客户弄明白他到底要什么。
也就是说,需要和客户沟通,合作,倾听,反馈,持续改进等等。
3. 它适用于竞争激烈的市场,这样的情况下,赶在竞争对手前交付一个不完美但至少能用的产品非常重要。
4. 它适用于快速变化的市场,你在埋头造一辆汽车的时候,客户已经想开飞机满天飞了,这就需要你能一步步地把汽车改成飞机,还能保证按时交付。
5. 它适用于在一个地方办公的小团队,一般7到9个人。这样使得敏捷中主要的沟通方式F2F是可行的。
其次,敏捷开发是一套工具集,里面有形形色色的工具,你可以不搞敏捷,但可以用那么一两个工作来提高效率。
比如:
1. stand meeting: 我昨天干了啥, 今天准备干啥,中间碰到什么问题,三个问题,简洁有效的小团队沟通方式。
2. KANBAN:直观地反映工作进度,反映流程遵守情况,反映流程缺陷。
3. plan meeting,retrospective meeting:适合小团队的写作和优化反馈方式。
4. user story: 站在用户的角度讲需求
5. 持续集成:随时高质量交付的基础,有利于应对剧烈变化的市场。
再次,敏捷开发是一种企业管理方式
比如:
1. 一线员工可以同时是架构师,ScM, 开发工程师,测试工程师。这样可以发挥他的主观能动性,有利于提高效率和创新。
2. 敏捷不专注于团队中个人的绩效考核,而更多侧重于整个团队的绩效。
3. 把大项目拆分成小项目去做,每个sprint都是一个迭代,需要输出一个高质量的版本,相当于完成一个小项目。
bug的生存周期也被控制在一个迭代以内,降低了风险,也减少了后期改bug的工作量。
4. 把数十人的大team分成几个敏捷团队,这几个敏捷团队的ScM、OPO再组成一个更高一级的敏捷团队,利用stand meeting,retrospective meeting
Knaban等敏捷元素,可以避免数十份邮件也不能解决一个小问题,互相踢皮球,沟通不畅等大企业病。
5. 老板可以是最大的opo, 他给下面的高管将idea(user story),定期检查Demo,把控产品的用户体验,负责与外界的沟通和合作。
敏捷 Short Cycles that are test-driven and feedback-driven, yielding constant improvement 的核心就是短周期迭代交付,可视化,自适应调整,开放式及时沟通,所有的敏捷实践基本都围绕这些核心展开,如果要再对敏捷的核心进行抽象就是迭代+自适应。
首先,敏捷开发是一种过程控制论,通俗地说,就是一种做事情的方法
1. 它适用于软件,可以改。如果是硬件,改起来就没那么方便了。
2. 它适用于客户不知道自己要什么的情况,其实这样的客户占大多数。因为客户不知道要什么,所以我们需要不断帮客户弄明白他到底要什么。
也就是说,需要和客户沟通,合作,倾听,反馈,持续改进等等。
3. 它适用于竞争激烈的市场,这样的情况下,赶在竞争对手前交付一个不完美但至少能用的产品非常重要。
4. 它适用于快速变化的市场,你在埋头造一辆汽车的时候,客户已经想开飞机满天飞了,这就需要你能一步步地把汽车改成飞机,还能保证按时交付。
5. 它适用于在一个地方办公的小团队,一般7到9个人。这样使得敏捷中主要的沟通方式F2F是可行的。
其次,敏捷开发是一套工具集,里面有形形色色的工具,你可以不搞敏捷,但可以用那么一两个工作来提高效率。
比如:
1. stand meeting: 我昨天干了啥, 今天准备干啥,中间碰到什么问题,三个问题,简洁有效的小团队沟通方式。
2. KANBAN:直观地反映工作进度,反映流程遵守情况,反映流程缺陷。
3. plan meeting,retrospective meeting:适合小团队的写作和优化反馈方式。
4. user story: 站在用户的角度讲需求
5. 持续集成:随时高质量交付的基础,有利于应对剧烈变化的市场。
再次,敏捷开发是一种企业管理方式
比如:
1. 一线员工可以同时是架构师,ScM, 开发工程师,测试工程师。这样可以发挥他的主观能动性,有利于提高效率和创新。
2. 敏捷不专注于团队中个人的绩效考核,而更多侧重于整个团队的绩效。
3. 把大项目拆分成小项目去做,每个sprint都是一个迭代,需要输出一个高质量的版本,相当于完成一个小项目。
bug的生存周期也被控制在一个迭代以内,降低了风险,也减少了后期改bug的工作量。
4. 把数十人的大team分成几个敏捷团队,这几个敏捷团队的ScM、OPO再组成一个更高一级的敏捷团队,利用stand meeting,retrospective meeting
Knaban等敏捷元素,可以避免数十份邮件也不能解决一个小问题,互相踢皮球,沟通不畅等大企业病。
5. 老板可以是最大的opo, 他给下面的高管将idea(user story),定期检查Demo,把控产品的用户体验,负责与外界的沟通和合作。
相关文章推荐
- 项目经理的商务指南系列之三:认识客户(敏捷开发,被动而弱小的客户,理解客户的古怪行为,如何喜欢上客户)
- 【敏捷开发每日一贴】:如何理解敏捷开发?
- 项目经理的商务指南系列之三:认识客户(敏捷开发,被动而弱小的客户,理解客户的古怪行为,如何喜欢上客户)
- 项目经理的商务指南系列之三:认识客户(敏捷开发,被动而弱小的客户,理解客户的古怪行为,如何喜欢上客户) .
- 项目经理的商务指南系列之三:认识客户(敏捷开发,被动而弱小的客户,理解客户的古怪行为,如何喜欢上客户)
- 如何理解敏捷开发?
- 如何理解敏捷开发?
- 项目经理的商务指南系列之三:认识客户(敏捷开发,被动而弱小的客户,理解客户的古怪行为,如何喜欢上客户)
- 项目经理的商务指南系列之三:认识客户(敏捷开发,被动而弱小的客户,理解客户的古怪行为,如何喜欢上客户)
- 项目经理的商务指南系列之三:认识客户(敏捷开发,被动而弱小的客户,理解客户的古怪行为,如何喜欢上客户)
- 敏捷开发(名字起得很帅,很忽悠人)原则 括号里面加了自己的理解笔记
- SOA技术架构如何支持敏捷开发方法
- 深入理解敏捷开发的常见九大误区
- 敏捷开发(名字起得很帅,很忽悠人)原则 括号里面加了自己的理解笔记
- 对敏捷开发中常用的几个"敏捷概念"的理解
- 敏捷开发(名字起得很帅,很忽悠人)原则 括号里面加了自己的理解笔记
- Agile Development 敏捷开发艺术-遗留项目如何处理-20090331
- 如何在敏捷开发中做好数据迁移
- 敏捷开发(初学者理解最合适)
- 我对各敏捷开发方法的大致理解