什么是敏捷教练

国际首位CTC认证者和你聊聊什么是敏捷教练

(原文发布于http://gitbook.cn/m/mazi/article/58c36775b7cea5d11d422f19?isLogArticle=no&readArticle=yes&from=groupmessage&isappinstalled=0)

敏捷已成行业潮流,看到许多有着强烈转型意愿的组织,慢慢开始意识到敏捷教练的重要性了,但招一个也不容易,自己培养更不容易。笔者所在的敏捷教练团队,除了提供服务直接地催化客户组织的蜕变发生,另一个愿景就是:培养更多的本土敏捷教练。本文分别阐述是什么是敏捷、教练、敏捷教练,并对发展和培养给出一些建议。

(本文约5000字,阅读需要15分钟)

继续阅读 More

敏捷Scrum中蕴含第一性原理来降维打击

最近敏捷小伙伴们在讨论Scrum与Kanban的区别,还有一些伙伴趁着清明节使劲地挖坟考古。我也来谈谈看法。本文无意考古和展开某种方法论,而是试图以“第一性原理”来探讨事情的本质。

第一性原理

A first principle is a basic, foundational proposition or assumption that cannot be deduced from any other proposition or assumption.

这是来自于量子力学计算的一种说法,意思是从头算,只采用最基本的事实,然后根据事实推论。

继续阅读 More

Spotify敏捷工程文化系列视频之中文字幕版

知名音乐网站Spotify的敏捷组织设计与工程文化近两年为人称道,其敏捷教练Henrik Kniberg发布的2段视频功不可没。为了让国内同胞能更好地理解视频的内容,我们成立了一个以Scrum方式工作的字幕翻译小组,将其翻译成中文,他们是:

  • Bill Li, CST, 来自上海优普丰
  • Jacky Shen, CTC/CSD, 来自上海优普丰
  • Roger Chou, CSP/PgMP, 来自台湾长宏

点击下方按钮,可以看到视频

  1. http://video.tudou.com/v/XMjQxOTk1MDEwNA==.html
  2. http://video.tudou.com/v/XMjQxOTk1MDEwOA==.html

关于这两段视频的解说,请看之前的两篇文章:

视频原帖

  1. https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/
  2. https://labs.spotify.com/2014/09/20/spotify-engineering-culture-part-2/

如何进一步提高组织的灵活性和顺畅度?

引言

2015.5.28,携程网宕机,消耗了10几个小时才恢复,每小时的损失高达100万美元。作为随时处于变化之中的互联网公司,发生事故总是难免的,但在这次宕机中对突发事件中响应得不够灵活顺畅,就很难被接受了,据说几位高级总监已经被开掉了。

近年来,不论大型还是初创公司,纷纷引入敏捷软件开发的理念,遍地开花。敏捷在不同的组织中以不同的形态出现,Scrum、看板、甚至精益创业等等,无不围绕快速迭代和改进的研发理念展开。强调需求分拆,时间分拆,进度可视化,利用度量进行改进等实践,来提高组织协作的顺畅度,提高灵活性以满足随时变化的业务需要。老板、销售、产品经理、项目经理、过程改进人员、开发测试人员都能听得懂,然后开始导入,不亦乐乎。

一段时间后,爱思考的管理者就会冒出一些疑问,怎么开了很多会没是觉得配合不顺畅?怎么还是感觉进度不快?质量也没见提高?于是乎,很多人就都会给出分析:比如开站会的姿势不对,比如看板不够漂亮,比如度量手段不完善,比如团队缺乏正能量,等等。总之,都还是强调深化过程改革和意识培养。但现状却是仍然觉得组织协作不够顺畅,以至于对市场事件和业务需求变化不能够及时响应,业务总是觉得一点需求变更就会花很久才能完成,最终客户方的满意度提高缓慢。

刚刚买到一本《如来神掌》,就以为自己真的会功夫了?

继续阅读 More

敏捷开发中分解用户故事的几种模式

用户故事是敏捷开发中流行的需求表达手段,各种敏捷流派中都提倡将大型需求进行化整为零,减少颗粒度,提高灵活性,实现尽早交付价值和揭示风险。本文根据 @申导 多年敏捷实践经验,同时借鉴业内流行做法,整理出一套分解用户故事的模式,分享给大家。并且最后也给出了优秀的用户故事需要满足的3C特征及INVEST原则。

继续阅读 More

用户故事图谱 User Story Mapping

传统的产品待办项列表(Product Backlog)相对于传统管理办法是一个巨大的进步,但是仍然存在一些问题:

  • 只见树木不见林
  • 重要的待办项容易淹没在各种细节中
  • 看不到全貌因而难以排列优先级
  • 并未明显地聚焦于用户需求
    而故事图谱是一个可视化Product Backlog的简单工具,有助于解决上述问题,特别是当PB越来越大,越来越复杂的时候。

继续阅读 More

“设计”工作应该放在迭代中吗?

在教练敏捷团队的过程中,一些团队反映“某些用户故事不好拆分,无法在一个迭代内完成”。对于这些故事,一些团队的做法是先指定资深人员作为“设计师”,他从“需求分析师”或业务方拿到需求后,花上1个迭代的时间进行“设计”,然后由他将编码任务进一步分配给“开发人员”,并且负责验收代码。这些故事往往就会持续1~2个迭代才能完成,甚至还来不及测试。

继续阅读 More

敏捷中分布式团队的合作策略

敏捷的工作模式强调个体及团队的互动和频密交流,为了及早反馈和频密交付。但这对于分布在不同办公室甚至不同国家的团队成员带来不小的沟通和合作方面的挑战,很多人会觉得沟通的负担超重,或者浪费无谓的等待时间。基于我们的经验,如何应对其实也没有什么大秘密,只要遵循以下一些原则和策略,就能减少分布式的合作之痛,同时确保良好的敏捷交付效果。

继续阅读 More

中层管理者应该做什么?

Esther Derby发表了文章 What do middle managers do?
关于敏捷转型,存在两种现象。有时候高层管理者要求“使用敏捷”,但中层经理“抵抗”;另外有些中层经理在高层并不关心敏捷的情况下,做到了转型。

作者观察到,高级和中层管理者都看到了转向团队为基础的组织和迭代增量式开发的好处。据她的经验,中层经理往往对现有模式不愿放手。为什么?如果他们在敏捷组织中没有看到自己的位置,他们不会拥抱敏捷。而敏捷方法对中层经理的角色所言甚少。泛泛的说消除对经理的需要没有帮助。
组织向敏捷转型仍然需要管理层,而且经常需要管理角色的人,特别是在大型复杂的组织中。在传统层级中,中层经理从高层确认未来的方向,并将工作重点放在一线人员,让他们完成。当团队从队列中拉取任务并自我管理来完成目标,中层经理们真正的机遇是跨越部门边界来观察组织,以改进系统和培养人员及团队。 所以当中层经理不再指挥日常工作,他们做什么?作者认为有很多,特别是帮助同事,上司和团队:

不同读者在评论中指出以下几点:

  • 通常,中层经理起着承上启下的作用。他们不断扮演救火英雄来克服扔过来的挑战,大多数中层没有机会也没有动力去拥抱新方法。转型的能够取得的进步取决于组织成熟度,当组织和激励手段倾向于保持现有模式,新模式就难以形成。
  • 让曾在风口浪尖的中层经理们退居幕后,他们会成为从瀑布式转型的最大障碍。不幸的是,他们会对敏捷转型造成最大的伤害,并导致脱轨(也有人认为在足够成熟的组织或流程中,中层经理并无如此大的破坏力)。更糟的情况是,此时很难让高层管理者来出面解决。
  • 越要求他们承认错误,他们越会坚持己见。
  • 帮助中层经理关注于“恰当的角色”是改进团队的好办法,给他们有价值的位置,让他们来塑造更好的团队型组织,给他们更多授权使变化发生,他们将重新投入热情。
  • 另外,高级管理角色在敏捷组织中的定位也是个有意思的话题。

原文:
http://www.infoq.com/cn/news/2012/05/what-do-middle-managers-do