18 | 小步快跑，小而美的敏捷
雷蓓蓓
该思维导图由 AI 生成，仅供参考
你好，我是雷蓓蓓。今天，我们来聊一聊敏捷。
很多人会认为，每天开站会，有固定时长的迭代，有自己的“Scrum Master”，就是在开展敏捷实践了，其实不然。
具备敏捷之形的团队有很多，但是，真正掌握敏捷精髓的，却并不多见。这是因为，敏捷方法属于 simple but not easy（简单但并不好做）。结合我这么多年的体会来看，与其说敏捷是一场研发方式的变革，不如说是一场思维方式的变革。
今天，我就结合我在某试点团队中深度实践敏捷的经历，来跟你分享一下，我对敏捷精神的理解，以及在敏捷应用过程中的实施建议。
为什么引入敏捷？
敏捷的特点，就是小即是美（Small is beautiful）。这个小而美，体现在人、事、时间这三个方面：
人：拆分成小规模（5～7 人）、跨职能的小团队；
事：拆分成一系列小而具体的交付物，按优先级排序，增量交付；
时间：拆分成固定大小的短迭代（1～4 周），在每个迭代结束后，对可工作的产出进行演示。
总体来说，就是用小团队在小块时间，做出小块的东西来，周期性地集成组装。为什么我们当时会考虑引入敏捷呢？这要从第一个版本的发布讲起。
这个新业务的第一个版本，原本预计在春节前发布。我们基于 WBS 做了完整的项目计划，用两个月时间进行模块开发，然后用一个月的时间来做发布前的联调、功能及性能测试。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
敏捷方法的实践并非简单应用特定做法，而是体现敏捷精神。文章分享了在应用敏捷方法的过程中对敏捷思想的体会和运用。敏捷的特点在于小即是美，体现在团队拆分成小规模、跨职能的小团队，拆分成一系列小而具体的交付物，按优先级排序，增量交付，拆分成固定大小的短迭代。文章强调了敏捷方法的应用带来的好处，包括提升客户体验、提升管理者体验和提升团队体验。最重要的敏捷精神是快速可靠交付、用户价值驱动和持续自发改进。文章鼓励读者在团队中实践应用敏捷时，遵循小而美的原则，每次一小步，挑一个痛点去集中解决，小步快跑，不断尝试和优化。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《雷蓓蓓的项目管理实战课》，新⼈⾸单¥59
《雷蓓蓓的项目管理实战课》，新⼈⾸单¥59
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(35)
- 最新
- 精选
Jason我，一枚程序员，偷偷看到现在，没敢说话。但实在忍不住了，说一句:讲的真不错！作者回复: 哈哈哈，千万别憋着…… 谢谢你的赞美，我会继续努力哒！
2019-12-0110- maks使用小步快跑的理念,结合上一讲中的"地利",参考下蓓格格的最佳实践. 可以得出适用于当前环境的敏捷方法. (0_0) 说来惭愧,刚听完这一讲中的橄榄球式为比分全局思考, 不要局限与个人任务的责任理念 结果工作的时候,就犯了这一点,事情是这样的: 上午 业务人员跟我说出了问题,然后我一看 是手机App端的 由于我目前只负责 PC端,所以对于App端看见有人在处理我就继续做其他事情了 至于后续我也没有在主动跟进 直到后面我被我上司叫过去,问我手机App端的问题为什么还没有处理掉 我一脸懵逼o((⊙﹏⊙))o,但还是唯唯诺诺的应付了几句. 之后我迅速跟进并处理掉了这个问题,然后归档再编写详细事件bug总述.. 对于这种问题还是只能说吃一堑长一智. 蓓格格,你有什么好的闭坑指南么....
作者回复: 这是一种惯性的自我保护思维，角色间自然形成的边界，也很正常。项目管理做久了，就会生出一种无边界感，最好的锻炼，就是留意自己考虑问题的视角，要一直放在整体目标上。你可以在每一次特别事情的处理上，像今天这样就很棒，建立自检的习惯，多给自己复盘。
2019-11-2937 
K战神最近我们部门甚至说公司层面在试点敏捷。 我也从中一直探索好的方式，领悟其精髓。上周六我还写了一篇总结。https://www.cnblogs.com/sunchong/p/11917766.html 其实蓓蓓大大的这个专栏，我仔细全部听了下来。总体感觉有一种清新的感觉，话语和案例都很贴地气。应该是蓓蓓大大平时的项目积累沟通积累心里积累。能够抓住读者的心，所以我读起来有种轻松全面的感觉。 我觉得现在项目管理能力是一项通往更高层级的必修课和必要技能了。很多项目做砸了或者做得很挣扎，不仅压制了组员的能力，还让项目组整天都是提心吊胆。这种感觉如果时间很长让人是非常奔溃的。都想项目快点结束吧。 我觉得项目管理好，有人带，主动学，敢实践，勤总结。 组织架构和技术框架是否对项目管理也有一定的影响呢？作者回复: 谢谢！赞一下从头听到尾的好同学👨🎓 组织架构的影响要更大些，我了解到的互联网公司，多是弱矩阵式架构，产品和用户探索的不确定性显著增加，这跟传统型项目有很大不同，很少是单个PM就能完全负责实施交付的。整体来看，方法还是万变不离其宗，但是对项目经理的软实力要求更高了，挑战更大！
2019-11-2837
like_jun交付是团队的事情。而不是个人的事情。技能不同负责的工作会不同。但这不能影响团队交付，要齐心协力。才能把交付做好。作者回复: 感谢总结～
2019-12-013
许童童快速可靠交付，用户价值驱动，持续自发改进。理解了这三点，也就领会了敏捷开发的精髓。作者回复: 👍
2019-11-283
大智若宇“如果估算值差距明显，代表大家对该条目的工作量没有获得共识，团队需要对该条目的评估结果进行讨论，由最大值和最小值的牌主，分别说明自己的估算理由，并重新讨论，确定最终的评估结果。” 想请教下老师，这儿讲的估算是估的工作量？ 我们现在实行的是估用户故事的难度。估完点数之后还要估工时。您讲的的这个估工作量的点数，应该是跟工时成正比，工作量大，对应工时也高。而我们估难度，就比较难去很好的定义，而且这个难度跟工时不成比例，有些任务难度不高，但是耗时会很久。上级对于我们每个迭代估算的点数，要么是期望我们每期稳定，要么就是希望稳步上升，又想拿这个来侧面反应我们团队的产出，另一方面又告诉我们不必太在意这个点数，真心不知道这是要干什么。 我的问题是，这个估算到底是应该估算什么呢？估算什么比较好呢？作者回复: 相对估算的点数，估的是用户故事的规模。难度是规模的一个考虑要素，但并不能直接代指规模。 建议跟你的上级沟通好事情的背景，是否存在其他你所不了解的背景或诉求，如果只是想要侧面反映团队的产出，那对规模做估算会更合适。
2020-04-181
quietwater敏捷就是船小好调头，加速反馈，只有团队强弱，没有个人高低，团队合作程度的高低决定了生产率的高低。作者回复: 对的
2019-12-171
穷查理想借用孙子的一句话赞颂一下敏捷：“兵无常势,水无常形,因敌变化而取胜者,谓之神。” 方法都在那里，关键还是要看因时因地的运用~作者回复: 没错
2019-12-021
陈宇明后续会有使用敏捷的小团队的项目案例吗？作者回复: 这个就是啊！具体是指哪方面？
2019-11-2821
Raymond吕敏捷概念已经泛滥了，人敏捷，组织敏捷，企业也要敏捷。仿佛加上了敏捷，问题就已经解决了一半。 刚开始接触敏捷的时候，感觉捷宣言都是意识层面的，认为连美国人也玩虚的了。慢慢带团队，实践摸索，感悟，才逐渐懂了一些敏捷宣言和原则背后的意义。 17年考ACP一脸懵，竟然都没有一套标准教材，要去看一堆书：看板，精益，用户故事....连PMI这么能抽象标准方法论的组织都没搞定，足以说明敏捷的标准不是谁说了算的，它应该是一门实践学问，最终找到适合自己的才是最好的。我经常跟团队讲，去试吧，反正死不了人。2019-12-24143
收起评论