从知乎摘抄的
敏捷 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,把控产品的用户体验,负责与外界的沟通和合作。