随着敏捷开发的流行，近年来各种大型、规模化敏捷框架、敏捷组织设计、业务敏捷也称为大老师们口中的热词，也带来了很多讨论甚至质疑。本文根据笔者Jacky Shen在2019上海和北京敏捷之旅发表演讲所整理。

笔者认为，敏捷的核心是“小而美”，追求“大而全”非常危险而且也达不到敏捷的目标，即“早+准”，在不确定环境中快速反馈来命中商业愿景，提升竞争力。

本文分为以下三个部分：

• 从敏捷到”大型敏捷”
• 骨感现实中的复杂性
• 变革管理及一些原则

一、从敏捷到规模化”大型敏捷”

1.1 回顾敏捷Agile这个词

2001年17位软件行业先驱在美国雪鸟镇聚会，石破天惊地提出了《敏捷开发宣言》，当时的主要关注点包括：

• 追求响应力与灵活性，即适应性over预测性 （不是单纯地求快，也不是要压榨产能）
• 以人为本（一群“艺术”家），而非用流程来管控（流水线工人）
• 提升客户和团队满意度

然而现实中，人们对”敏捷”还有其他期望：

• “抄竞品抄得快” — （敏捷不见得能帮你少花时间，只让你知道该干嘛）
• “明年少招点人” — （敏捷不见得提高产能，只是增加了可管理性）
• “按时上线” — （敏捷不见得确保时间，只是摧毁不切实际的幻想）

笔者认为，我们平时书本和课程谈的各种敏捷方法论、框架实践集，都在描述一种“理想的未来状态”，但是很难说如何在特定组织中能够达到那种状态，所以与敏捷转型（变革管理）是两码事。

继续阅读 More

飞机上读完了来自著名敏捷产品开发小公司–37signals的两本书，Getting Real《达成现实》和 Rework 《重塑工作》，后一本是前一半的升级版。作者是大名鼎鼎的Jason Fried / David Heinemeier Hansson / Matthew Linderman。讲述在VUCA(乌卡)互联网时代，用聪明、快速、容易的方式构建一个成功的产品。

最能够引起共鸣的，第一个是专注，专注于问题的关键，专注于客户价值，专注于要事，分清轻重缓急，敢于说“不”。第二个是“动手，别吵吵”，把手弄脏同时拥抱变化，迅速决定下一个小目标，然后完成它，从成功的成就感和经验中迭代前行。第三个是高效的适量工作远好于过量的低效工作，轻松优雅地平衡好生活与工作，在路上要不时地抬头望望天。

继续阅读 More

如何分拆硬件研发中的产品增量?

这个例子来自德国纽伦堡的某个硬件产品团队，他们在5年前开始导入LeSS（大规模敏捷）。

产品领域是电信硬件和软件，其中关键是cross connect board(某种PCB电路板)，包含电源、FPGA–现场可编程门阵列(其中一些最终融入到ASIC–专用集成电路中)、设备驱动等。

一个架构要点是，容错是非常重要的；一块PCB电路板经常具备另一块“B计划即故障切换(failover)板子（想象该cross connect board”方案具有A板和B板），即使在单块板子上也会有容错处理（例如:从外接电源切换到电池）

继续阅读 More

Henrik Kniberg & Eik Thyrsted Brandsgård

2016年12月

原文授权链接: http://blog.crisp.se/2016/12/30/henrikkniberg/agile-lego

翻译&审校：
李洁(Jerry Li) 何强 龚正 姚宇宏(Ella Yao) 陈婧(Elina Chen) 申健(Jacky Shen)

统筹&出品：申健(Jacky Shen)

2017年1月

中译文链接：http://www.jackyshen.com/2017/01/31/planning-as-a-social-event-scaling-agile-at-lego/

— “什么？一个150人的团队会议只要（2天）1天？”

— “对啊！每两个月一次。运行得非常好。”

— “但是为什么这样？怎么做到的？”

背景

乐高数字解决方案部门（DS）由20个左右的团队组成，负责处理孩子和家长手中各种设备- 普通电脑，平板电脑，各种app应用，可穿戴设备，虚拟现实设备等等进行通讯。我们同时也在展望未来的产品开发，如何去拥抱新的技术，如何将传统的玩法与酷炫技术，例如增强现实结合起来，或者找一种能够将一个物理模型“扫描”进游戏的方法。绝大部分的团队在丹麦的比隆，但是我们在印度也有一部分团队。

继续阅读 More

Spotify是继Pandora之后，国外第二大音乐媒体网站。上一篇
Spotify的新型敏捷矩阵组织：部落、分队、分会和协会出了以后，很多人对Spotify的敏捷组织形式非常感兴趣。这里@申导 抢鲜给大家带来第二部分，关于Spotify的敏捷工程文化。

第一部分主要提到基于敏捷原则，将人按照小分队Squad的方式来组织，松耦合但紧密联盟(Align)。通过内部代码开源，鼓励“异花传粉”。通过架构解耦、特性开关等手段来做到频密的小规模发布。借助自助的发布和部署服务，减少人们之间的任务交接。所有一切都关于“人”，因此组织更加要关注激励、信任与社区文化，而非等级结构或控制。

第二部分讲的是关于失败，用Spotify的创始人Daniel的话说就是，“我们要比其它人更快地犯错误”。因为失败意味着学习，因此更快地失败就意味着更快地学习，更快地改进。

继续阅读 More

顶尖金融服务企业中的大型组织是如何采用大规模Scrum框架(LeSS)的？

背景

J.P.摩根的全球核心处理技术集团由Simon Cooper领导，是一个遍布全球的3000多人的组织。2013年集团决定要改变为(真正的)Scrum，并采用Large-Scale Scrum(LeSS)框架，这意味着在组织设计要做出相应改变。

之前他们曾零散地采用了”Scrum-But”及各种敏捷工程技术，主要是在开发团队中，但现有的权力和组织结构并无显著改变，与业务的交互也是一样——仍然是“合同谈判”而非“客户协作”。仍然存在负责交付“合同”的研发项目经理、团队主管、单一职能的专家角色，以及单独的组件团队和职能团队（比如测试团队）。

年初Craig与Simon Cooper及其直接下属的经理做了一次有力的对话，随后他们就决定将组织设计转变为基于LeSS的Scrum框架。

这次领导力对话认清了组织中目前“合同游戏”的动态，它阻碍了组织提高敏捷性和改善以客户为中心的特性交付。

这次领导力对话也针对真正的特性团队进行了探讨——跨组件和跨职能团队，它可以端到端地交付客户特性，不存在移交、依赖或延迟。这需要消除组织内的藩篱，比如职能部门和组件团队，以及相应的经理角色。

继续阅读 More

组织导入敏捷往往更加关注形式和标准化，然后却发现不同团队的接受程度不同。 这里介绍了Spotify 的大规模敏捷之路。Spotify是继Pandora之后，国外第二大音乐媒体网站，在从6个人扩张到1200人的过程中，它使用一种了新型的矩阵组织来扩展：部落、分队、分会和协会。

继续阅读 More