异地金融研发团队的敏捷实施策略-Top100Summit

通过重构提高组织灵活性-百度技术沙龙

重构到管道式函数-软件匠艺小组

全球敏捷之旅2015天津站花絮

全球敏捷之旅2017北京站《禅与复杂》演讲(2:59-3:56)

敏捷绩效考核与OKR

敏捷的目标是增强组织响应变化的能力,主要通过目标对齐、信息透明一致、尽早反馈和调整、基本功提升、去中心化控制等来达到,因此绩效考核的原则要顺应这些敏捷思想,激发员工动力。我认为敏捷组织转型下,绩效考核(无论是KPI还是OKR)都应关注以下原则:

  1. 更多关注团队表现而非个体表现
  2. 从被动指标分解到自组织的目标管理
  3. 配合短迭代研发周期,缩短考核周期
  4. 从奖金和排名转移到学习与成长

一个可参考的敏捷团队绩效模型:

根据《Scrum Primer》 v0.5,作者根据Yahoo在2008年前后使用Scrum后调研(以1-5打分的方式进行),当时发现主要绩效提升表现在以下方面: 生产效率,团队精神,适应性,责任性,协作能力。那么敏捷转型的整体绩效也应该从以上方面进行考虑作为文化导向,结合我从2007年开始在诺基亚西门子通信的敏捷经历,建议做法如下

  • 减少个人绩效的权重,增加组织或团队层面的权重
  • 绩效打分与奖金分配不完全挂钩
  • 依据360度收集的信息、评价和数据
  • 考虑团队工作内容、需求变化和复杂程度,可结合OKR与KPI的使用
  • 敏捷Scrum中的短迭代计划——由PO指出迭代目标,团队共创出要达成的任务——实际就是一个执行层面的短期OKR。而产品、项目级别的大目标,可认为是战略层面的长期OKR。
  • 设定团队之间互相支持的指标,作为团队绩效评分(Team Performance Evaluation),例如帮助其他团队修Bug,为其他团队做分享都可以互相送分数。

大型敏捷,请和你的大老师远离敏捷

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

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

本文分为以下三个部分:

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

一、从敏捷到”大型敏捷”

1.1 回顾敏捷Agile这个词

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

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

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

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

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

继续阅读 More

subway-map-of-agile-development-practices

什么是敏捷

敏捷是一种建立和响应变化的组织能力。用于应对不确定和动荡环境,并取得成功。

敏捷宣言的作者们选择了“敏捷”(Agile)这个词,是因为这个词所代表的适应性和变化响应力对他们的方式方法至关重要。(参见 https://martinfowler.com/articles/agileStory.html)

这种思维是关于你如何理解当今环境所发生的一切,识别你所面对的不确定性,边前进边找出应对措施。

什么是敏捷软件开发

敏捷软件开发不只限于Scrum、极限编程XP或特性驱动开发(FDD)等框架,也不限于结对编程、测试驱动开发、站会、计划会和迭代时间盒,而是一把遵循了敏捷宣言和原则的大树,支撑着上述方法论和实践共同的价值观理念。

下面这张地铁图囊括了各种敏捷实践及名词的集合家谱。

Scrum和Sprint名词的历史和误区

Rugby(英式橄榄球)运动是1845年开始的。Scrum方法创始人们是读了1986年HBR论文《The New New Product Development Game》而受到了Rugby运动的启发,并在1995年发布论文,正式提出Scrum方法。论文链接见:http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.86.4164http://jeffsutherland.com/oopsla/schwapub.pdf

Scrum是Agile敏捷开发方法的一个流派,Sprint一词(英文原意是Rugby运动中的短距离冲刺)是1995年Scrum一词(英文原意是Rugby运动中的争球)创立者为了区别于其他增量迭代式开发(IID)方法(例如 XP极限编程方法),而从Rugby运动借来的比喻,意为一个短的时间盒,期望每个时间盒末尾能有潜在可交付的产品增量以供反馈和调整。

如今敏捷行业,Iteration和Sprint几乎混在一起使用了,甚至包括一些新兴的精益产品创新方法如谷歌的Design Sprint一词也效仿设计了5天的固定时间盒。

继续阅读 More

UCAC敏捷教练静修-4月杭州-静待花开

什么是VUCA时代,这个时代对个人有什么影响?如果是往年,还真要费一番口舌去解释,然而现在,我们刚刚过完2018,没什么能比这个年份更好的解释VUCA了。
2018 年,一些大公司干着干着突然遇到危机了,多少被公认有前途的行业,干着干着突然就遇到了拐点。有多少人设,轰然坍塌,年初的豪言壮语,到年底只剩下一地鸡毛。

如果你用吃瓜群众的心态旁观2018, 那么它无疑是一个观赏性十足的年份。一年之内,你就能见证无数起“眼看他起朱楼,眼看他宴宾客,眼看他楼塌了”。然而每一个轰塌的背后,都有无数人失去工作,辗转求职,陷入应付生活成本的焦虑中。前一天还在吃别人的瓜,今天就轮到自己成为吃瓜事件的主角。

所有那些曾经看起来坚固牢靠的东西,现在都想打一个问号,罗振宇说,「这个世界还会好吗?」

这就是VUCA时代,一个充满变数的,模糊的,复杂的时代。

继续阅读 More

一线外包公司老板告诉你如何与甲方签署敏捷外包合同


作者:王洪亮

近几年,随着社会化分工的趋势,许多领域的客户都考虑到软件外包服务,在开发新的项目中,会涉及到一些系统,设备和业务领域等进行开发,如果全部自己开展起来,承担着技术积累风险和短时间开发的风险。出于时间和成本的考虑,客户会考虑到软件外包。
与此同时,随着敏捷传入中国并发展了十五年以上,敏捷产品研发的观念逐步替代了传统的项目管理,也带来了新旧观念的现实碰撞。近期很多客户跟我们探讨过软件外包项目合同如何签署,而笔者除了在多家企业担任敏捷教练之外,也是在自己的企业中负责了多个外包服务项目,并以敏捷的理念与客户进行合作。所以这次我们根据如何在敏捷语境背景来行展开,谈谈如何签署敏捷的软件外包服务合同。

一 合同的形式

本次讨论的合同形式主要为固定价格合同和T&M合同。

继续阅读 More

优普丰十年敏捷推广的心得总结

(作者:Bill李国彪;审校:谢炜玮/Jacky申健)

上篇-从零到一的信心加持
下篇-保持归零的敏捷初心

核心看点:

关键时刻:听说并尝试Scrum;成为CSM;翻译第一本Scrum著作;成立优普丰;第一次CSM上海公开课;第一次中国Scrum Gathering大会;结识Vernon史文林;奇虎360公司内训;

关键心得:选正确的事;顺势而为;跟对人;心态开放;拥抱意外的学习;要专注;把手弄脏;快速试错;恒心;社区;善观察;多思考;找对人;

自2007年优普丰敏捷学院成立并开始专注在中国推广敏捷,光阴如梭,已有十个春秋。虽我不善词藻,回想敏捷在这十年中给我以及我身边的朋友、同事、社区的伙伴及各大客户带来的变化和成长、开阔的眼界,以及更积极和正向的思维方式和心态,我抱着感恩之心,不禁想写点什么与大家共勉。如今回顾这一历程,信心不断加持,也鼓舞我们投向未知的但也是无比广阔的未来。

继续阅读 More

Git命令扫描频繁修改代码热力图以提高代码质量

对于大型复杂架构的产品代码,如何知道哪些是被频繁修改的?哪些不稳定或蕴含了潜在的缺陷或者需要频繁的回归测试,以保证持续交付的质量?如果能根据代码痕迹画出热力图或云图。据此就能找到那些不稳定的模块和代码,调动人员review这些代码,分析导致变动的原因,解决那些不稳定因素,不管是耦合问题,还是抽象层次问题,那么代码的质量会直线上升,程序员工作量就会直线下降。

Git Log加命令行管道

git log命令的结果中包含了所有的提交信息,可以通过参数只筛选出文件名,然后先按照文件名进行排序(sort),然后用(uniq)命令来统计每个文件名出现的次数,然后再按次数排序(sort),最后是(head)命令来找出提交次数最多的10个,即是那些被频繁修改的代码文件。

git log --pretty=format: --name-only | sort | uniq -c | sort -rg | head -10

管道命令可以任意拼接,比如只想从所有C#代码里面来扫描,就再加一个grep管道来过滤即可:

git log --pretty=format: --name-only | grep .cs$ | sort | uniq -c | sort -rg | head -20

Git Effort

如果你在安装GIT命令行时安装了附加工具包git-extras,就可以用git-effort命令来扫描, 它会列出你的仓库中所有文件及提交次数。例如,你可以用下列命令来忽略少于4次提交的文件:

git-effort --above 4

新加坡一家银行的数字化创新:DBS走出石器时代的十条敏捷转型经验

作者:2017年4月4日,Paul Cobban, DBS星展银行首席数字化及转型官

中文版授权翻译团队信息(译者:刘文举;审校:赵瑜、李国彪)

原文链接:http://sina.lt/f2wY
译文链接: https://www.uperform.cn/digital-innovations-singapore-bank-10-lessons-learnt-when-dbs-came-out-of-the-stone-age/

我们在团队创新中吸取的经验

还记得我在DBS的第一天。当我告诉新加坡出租车“叔叔”我要去DBS时,他说道 “DBS-慢得要死。”(“Damn, Bloody, Slow.”)

毫无疑问,2009的DBS银行因其官僚作风盛行、想象力缺乏、反应迟钝而享有盛誉。

我们当时也有了一位新的行政长官Piyush Gupta。他下定决心要扭转这种局面。我们都知道我们该做点改变,但不知道从何入手。

银行业以外的汽车行业给我们带来了灵感,尤其是Kaizen持续改善的理念。Kaizen是由日本管理大师Masaaki Imai 今井正明提出的,它强调的是持续改进的过程,最初应用于汽车生产线。这也是今天我们所读到的精益管理的基础。

在参观日本工厂期间,我们有机会幸会了Masaak imai本人,也看到了持续改进过程在现代制造业中的影响力。但它是否适用于银行呢?我们决定一试。

继续阅读 More

敏捷项目迭代过程中测出缺陷要不要在看板加一列Bug List?

说说我对于迭代过程中测出bug这件事的看法:先不论开发测试是不是独立团队,也不争论Scrum与看板方法(两者都是遵循精益思想),测出的bug分几种情况处理:

  1. 如果产品负责人/产品经理判断立刻要改,那么就是个阻塞项,贴红色标记,留在当前列里面不回流,不修好这个item不能称为完成
  2. 如果判断说根本不是bug,那么直接丢弃
  3. ROI不高的鸡肋,狠心丢弃(断舍离),实在太纠结就重新回到Product Backlog待办列表一列,待将来重新排期(虽然很可能再也不会改了)

为什么这么做?

继续阅读 More