企业竞争力的双引擎:数字化与敏捷

[摘要]

企业的成功既需要数字化也需要敏捷化。数字化提供更好的用户体验,敏捷激发热情与创新。数字化和敏捷化是天生一对,不能只选其中一个。数字化、敏捷化如何评估?如何才能更加数字化、敏捷化?

人类的进化进入了一个新阶段。科技已成为我们日常生活中不可缺少的一部分, 大部分人离开科技就无法生活。不仅如此,我们对科技的需求还在日渐增长。你能想象一整天不用Wi-Fi、Facebook、Instagram、谷歌或智能手机吗? 对大多数人来说,这肯定难以忍受吧。 我们需要来自各种网站、应用的即时回应。亚马逊、京东等公司已用“翌日送货”乃至“一小时内送货”(只要送货地址在范围之内)这样的服务宠坏了我们。我们需要吸引眼球、容易使用的界面,想我们所想、专为我们而创造的服务。

现在每一个公司都在寻求数字化转型。图1显示了2017年1月至本文写成期间,谷歌搜索“数字化转型”的趋势。很明显,大家对这个话题的兴趣在上涨。

图 1 谷歌搜索“数字化转型”(英文)的趋势

虽然技术是数字化中必不可少的一部分,但它并不是全部。数字化也需要转换商业模式、流程、文化和思维。非技术的部分可以用一个词来总结:敏捷。要适应客户不断变化的需求,就要保持敏捷。

图2显示了2017年1月至本文写成期间,谷歌搜索“敏捷转型”的趋势。可见,“敏捷转型”和“数字化转型”的搜索趋势都是在2014年开始上升的。

图2 谷歌搜索“敏捷转型”的趋势

数字化转型和敏捷转型有很强的关联。举例来说,亚马逊是数字化企业的领头羊,它本来只是一个电子商务网站,但现已成为市值两倍于沃尔玛的巨头。亚马逊没有把利润回报给股东,而是不断投资于创新,创造更好的客户服务。它是为客户而存在的。同时,亚马逊也是敏捷方面的领头羊。杰夫·贝佐斯提出的控制团队人数,以及他著名的“两个披萨”高效团队原则,都是在谈敏捷。

企业的成功既需要数字化也需要敏捷。数字化提供更好的用户体验,敏捷激发热情与创新。数字化和敏捷是天生一对。坦白来说,根本不能只选其中一个。

“数字化”和“敏捷”是动态的、没有终点的比赛

想要数字化转型的企业往往一开始就问什么是“数字化”。虽然对它的定义众说纷纭,但在一些方面存在共识——比如,“数字化是关乎客户的”。数字化的目的是改进客户体验,让他们在达成自己的目标时投入更少。你对客户的服务越好,来找你的客户就越多,这就是真理。

但是,数字化没有一个黄金准则。有一个手机应用,不一定就是数字化公司。其他公司也有他们的数字应用,但并没有因此领先。不过如果你的数字应用很烂,那你就不能算是数字化公司。“数字化”的最低标准是有的,但没有最高标准。

企业和科技都在不断进步,数字化企业的最低标准也在不断提升。不断会有公司打破常规,抬高标准。今日的巨头很可能明日就辉煌不再,如博德斯、柯达等等。企业也是有半衰期的,平均寿命是18年。如果五年来你的公司还在同一个行业,做同样的事情,方法完全不变,就要特别小心了——你需要“颠覆自己”,不然就会被他人颠覆。

沃伦·巴菲特在2015年警告大家小心企业衰退的三要素,告诫波克夏下一任CEO必须与傲慢、官僚主义和自满作战。即使是波克夏这样一家收入超过了新西兰GDP的公司,也要小心谨慎,更不用说其他公司了。对付这致命的“三要素”的方法是公开、透明、激情,这也都是敏捷的基础价值观。

“数字化”(Digital)是个形容词,不是名词。你不能指望数字化有个标准,静态不变。这是一场动态变化的、没有终点的比赛,赛道上有很多竞争者。你需要以竞争对手为基准,来自我衡量。你能做的,只是比他们“更加数字化”。

同理,敏捷也不是个名词,没有最敏捷,只有更敏捷。在这个数字化时代,更数字化、更敏捷的企业才是赢家,也只有赢家才可以生存。

那么,到底是什么需要更数字化、更敏捷?

如果数字化和敏捷的都是形容词,它们形容的名词是什么?这个问题很重要,因为它定义了数字化转型的大框架。在这个框架下,需要找到数字化最少、最不敏捷的地方,让它们更加数字化,更敏捷。名词是你希望数字化、敏捷化的个体或组织。这个组织可以是企业也可以是政府。

图3 数字化、敏捷化的领域

那么,是什么构成了组织?组织运作的部分都是什么?它们是渠道、职能部门、外部合作伙伴、雇员、技术和领导力(见图3)。

渠道——渠道是组织与客户互动的渠道。渠道可以完全是数字化的,也可以物理与数字并存。好的渠道应该做到有用、有意义、知识丰富、无缝、统一、迅速。作为一个客户,我想与企业中那些了解组织也了解我,同时可以提供优质、迅速服务的人互动;我不想跟不同的人,还有讨厌的聊天机器人不断花时间去解释我的需求;我希望立即得到我想要的服务;我费的力气越少,我的感受就越好;不要让我费劲去想、花时间去等。

职能部门——组织中的各个职能部门齐心协力满足顾客的需要。有些可能在一线接待客户,有些可能在后台做不同的工作,有些可能负责管理与合规等等。不管怎样,他们的工作可以更加数字化、更加敏捷。他们的流程如何?采用什么步骤?可不可以省略或者自动化?有没有其他更简洁的方法达到同样效果?职能部门之间的合作能不能改进?职能部门能不能合并或重组,以精简流向客户的价值流?能不能给职能部门更大的权力去更好地服务客户?

合作伙伴——在全球化的今天,没有企业能独立生存。企业需要与伙伴或供应商合作。企业拥有的是哪种关系?是一方需要不断与另一方协商、再协商才能达成合作的关系,还是互利共赢的关系?合作伙伴能否很容易地纳入其中?信息可以顺畅地跨组织分享,还是有很多交流摩擦?沟通不畅、合作不佳,相关的职能部门就需要花时间等待,最终损害的是客户体验。

员工——有满意的员工才有满意的顾客。工作环境如何?工作环境是促进学习和分享,还是加剧孤立?员工需要每时每刻坐在桌前,还是可以在任何地方工作?举例来说,工作现在越来越移动化,员工可能不在桌前,而是用电子设备完成工作。出差和请假申请可以用电子软件批准。不过还不止于此。考虑一下能不能倾听员工的声音,提高员工参与度吧!考虑提供一个能为不同工作需要,提供不同合作空间的数字化职场吧!

技术——这点可能让人惊讶,不过技术管理及操作自身就需要数字化和敏捷。很多时候,信息技术被认为是要花钱的,我们会抱怨为什么一个系统要投入那么多人力,一个改动要花那么长时间。但是,如果我们相信科技是业务成长之源,那就在源头多投资吧:投资工具,也投资相应的人才,使用最新的技术。让你的IT系统成为“持续成长”的系统,而不是“老旧”的、衰退不能用的系统。顺便一提,英语里“老旧”一词是个多义词,它只有在形容IT系统时才作贬义词用。如果你的系统确实很“老旧”,那么,制定更新换代的计划——考虑一下DevOps(开发与运营一体化)模型,或者云端,或者微服务,或者敏捷与持续交付吧。

领导力——或许领导力改变的时候才能发生最深层次的改变。我并不仅仅指领导者,而是说人们领导组织的总体方式。它包括战略、计划、决策、预算、治理和绩效管理。领导者获得了准确的信息吗?雇员愿意提供信息吗?各层领导都愿意倾听吗?不论个人还是组织本身,都在持续学习吗?牢记沃伦·巴菲特的告诫,时刻警惕:傲慢、官僚主义和自满。

你有多数字化,多敏捷?

如上所述,数字化和敏捷是形容词。它们没有静态的定义,而是相对的概念。没有人能说一家公司满足了一组固定的条件,就是一家数字化公司。因此,不要问“我们是不是数字化”,而要问“跟竞争对手或以前相比,我们的企业数字化程度更高了吗?”。另外,数字化包含很多层面,你的企业可能在一个领域非常数字化,但另一个领域却做得不够。这种情况也不能长久。比如说,渠道十分数字化,但员工和技术的数字化成都非常低,就不明智。对于敏捷,道理也是相似的。敏捷也是一个相对的、包含多个层面的形容词。

在这里,我提出了一些衡量数字化和敏捷程度的评估方法,因为这是与时间、与对手赛跑,所以是相对评估。你可以有一些绝对的评估方法,不过即便如此,它们也是在相对场景下才合理。图4展示了这套评估方法。

图4 衡量数字化和敏捷的程度

我想强调这些评估方法只是为引出讨论而提出。当然没有适用于所有组织、所有领域(也就是前面讨论过的渠道、组织单位、合作伙伴等等)的一套标准评估方法。不同的组织和领域,侧重会有不同。因此,我提供的只供参考。

制定一套评估方法的时候,弄清楚你的目标对象非常重要。对渠道,评估对象是客户。一个企业更加数字化(或更加无缝等等),它的转化率就会更高。对职能部门,可以用订单、交货单等等作为评估对象。对员工,评估对象就是员工自己,人才招聘、员工发展才是最重要的。

另外,我的评估没有考虑“方法”,也就是说我并不关心你在使用什么技术。你如何做好顾客工作,达成效果才是最重要的。

这个数字化评估框架,原型是基于电商平台制定的。如果你有一家电商平台,而它比其他电商平台更数字化,我会期望你有更高的客户转化率,更低的客户投入,更高的交付履行速度,更高的推荐精准率,以及更高的客户推荐率。

评估敏捷化程度,我用的是同样的准则。评估的对象主要是变化:对变化的反应有多灵敏,变化后质量有多好,发货速度有多快,团队结构应对变化的速度和效率如何,以及学习速度有多快。

重申一下,我要强调这些评估方法只是为了引出讨论。你需要根据你的组织和领域进行调整。

如何更数字化、更敏捷

渠道,职能部门,外部合作伙伴,员工,科技,还有领导力等领域都可以变得更加数字化、更加敏捷化。虽然每个领域都有细微的差别和独特之处,数字化和敏捷化的方法是相似的,思维也是相似的。我总结了这些不同的方法帮助你变得更加数字化、更加敏捷化(见图五)。这是数字化者和敏捷者的职业工具。

图5 变得更加数字化、更敏捷的方法

先谈谈更加数字化的方法。当然这仅仅是个简介。

首先,利用数据。不要猜测,猜测会带来不必要的风险。你的设计和决策都必须基于相关的、无偏见的数据。设计在线或离线系统时,思考可以获取或收集数据的方法,当然不能侵犯客户隐私。思考在渠道、产品和服务中可以嵌入哪种智能来减少客户投入。

第二,设计思维是研发新产品和新功能时常用的。设计思维是与客户共情,了解需求以及反复改进可行的解决方案,永远追求客户认可。这与传统意义上“我什么都知道”的象牙塔思维的设计是不同的。不断收集数据、信息反馈,设计也持续迭代、改进。

第三,思考你怎样能利用科技民主化。不要限制顾客的操作,相反,向顾客和合作伙伴开放技术,让技术成为顾客的工具箱,顾客可以自行组合工具自助服务,满足需求。这包括开放应用程序接口,公开成果或提供其他自助服务的功能。这就是赋权,给客户赋权。

第四,反思你的价值主张。你还能向客户提供什么?你能更好地在客户和合作伙伴之间建立连接吗?你能重新包装你的产品,或者和合作伙伴的产品重新组合?这就是改变商业模式,它常常需要组织结构的变革。

最后,寻找将你的产品变成平台的机会。利用效应帮助客户放大商业生态系圈。这当然并不容易,需要清晰的价值主张、投资和市场,才能跨越引爆点。需要精心策划,才能保证生态系圈中有一个健康的网络平衡。

踏上数字化之旅,首先你需要变得更敏捷。没有敏捷就不能开始,这就是为什么我们经常看到新企业在做老企业想做却做不到的事情。老企业被官僚主义和自满绊住了。数字化在于改进商业科技的硬件和软件,但是敏捷在于改变员工和领导的心性。

敏捷之路开始于谦虚和勇气,在于承认我们不是什么都知道,而且我们愿意不断学习和适应。学习需要如饥似渴,对现有的所有智慧进行消化。学习也在于不断验证假设和猜想,不断调整,寻找可行的方法。

与敏捷很相似的是精益系统思维。分析整个价值流,去除浪费和瓶颈,或许还要重新设计价值流。精益系统思维常常和设计思维一起使用,但是前者更着重于后台合作,后者更着重于客户触点。

有了科技民主化,权力就会被下放。权力不再集中,相反,决策权会交给前线——创新最多的组织边缘。这对于很多组织来说,需要进行引导和赋权。过去,决策是由几个大人物掌握的,但是现在由很多小人物做决定,为顾客提供更好的服务。

引入颠覆性商业模式,需要改变组织和团队结构。这合乎情理,因为每一个商业模式都有相关联的组织结构。这是现实生活中的康威定律。不过商业模式在变,组织结构也在变。在企业结构方面没有万用灵药。组织结构是动态的,让自治的团队发挥才智满足客户需求,比让你的员工在循规蹈矩恪守工作流程要好得多。

如果数字化平台可以利用客户及其社交群体的网络效应,利用员工的网络效应也是一种创新。提供让不同职位的人合作的机会,这会让你的员工更好地了解公司,也能发掘更好的工作方法。这也能创造更强的归属感,而归属感正是传统企业中缺乏的。

为什么你不够数字化?

最后说一句,苹果公司推出iPhone的时候,诺基亚在研发上花的钱是苹果的九倍。钱和资源并不是关键。除了科技方面投资不善,我怀疑(并无证据)诺基亚当时有潜藏的傲慢、官僚主义和自满。如同每个个人一样,其实就是那句再普通不过的俗语:“骄傲使人落后。”

如果组织中存在某种显而易见的问题,鼓足勇气提出来吧。这个世界不需要假的数字化、纯粹的口舌之劳、或用来装饰门面的数字化。你需要有勇气,坚持,看到问题的核心。问题经常出在人心,也就是为什么敏捷需要先行于数字化,而勇气需要先行于敏捷。

所以,抛弃旧方法,系统地开启数字化的工作,在走向数字化和敏捷的进程中也要运用数字化和敏捷。有了这份勇气,你会得到丰厚回报的。

了解更多关于数字平台战略的信息,可下载《数字平台战略》白皮书。


更多精彩商业洞见,请关注微信公众号:ThoughtWorks商业洞见

Share

Offshore敏捷交付团队QA生存指南

跨地域性的offshore敏捷交付一直以来都是一个充满挑战的工作,对于需要与各种角色进行交互的QA而言更是如此。我在2016年初进ThoughtWorks时就经历了这样一个项目。此间个人也经历了从忐忑不安到得心应手。现在此离岸项目已经交付完成,我也想总结一下这一年来的项目生存实践。

项目背景

客户:澳洲大型电信公司Digital部门,我所在的电商产品部门下有3个交付团队和1个Devops[1]团队,每个交付团队有3-4个开发,1-2个QA,1个IM[2],BA[3]则是按项目分配且全部都在Onshore。

系统与架构:基于AWS部署的Oracle的内容管理和电子商务系统,系统较重,且需要通过中间件从核心系统拿到数据。

QA职责

  1. 参加需求评审和技术评审会议,与BA讨论AC[4],与开发讨论实现方案。根据需求和技术方案制定测试策略。
  2. 准备测试数据,测试数据大多来自于第三方系统,可以自己手动创建,有时需要其他团队帮助。
  3. 对已开发完功能进行测试,即测试故事卡。
  4. 负责新功能上线。QA需组织系统发布启动会议,完成集成测试和回归测试,在上线后对系统进行主要功能的回归测试。

项目困难

Offshore的项目中存在的主要困难来源于三个方面:时间不同,空间不同,文化不同。

  1. 澳洲时间比国内早三个小时,算上各自午饭时间,与onshore团队的工作重合时间可能不到5小时,一旦过了澳洲的下班时间,有问题需要找onshore的团队就会很困难。
  2. 澳洲距离远,国内团队和澳洲团队只能通过视频会议、邮件、即时聊天软件等方式进行远程沟通交流。
  3. 基于国内的网络环境,在与澳洲团队工作的时候,网速、VPN都会对沟通和工作效率产生影响。
  4. 澳洲距离国内坐飞机大概要13个小时,较长的路途决定了不会有很多机会和预算让两地团队频繁的出差、相互交流。
  5. 同时由于不在一个地方工作,几乎没有比如团建活动,茶歇等能够促进团队成员互相了解、建立良好团队关系的机会,这对于敏捷团队的建立是非常不利的。
  6. 澳洲是移民国家,虽然相对于欧洲国家人们的思想更开放,更能接受不同的文化,但中西方文化的截然不同还是会在某些场合带来一些意想不到的问题。而且如果彼此双方对对方的文化完全不了解,交流起来也会缺乏共同话题,难以建立同属感。

生存指南

为了减少时差带来的工作时间重合度不高的问题,国内团队相应会提前上班时间,并且在非工作时间内也会注意澳洲团队是不是有紧急的问题需要解决,时刻保证澳洲团队能通过电话顺利联系上国内团队。

做好每天的工作计划,在有限的共同工作时间里,把需要澳洲团队帮忙解决的问题设置较高的优先级,然后预计会有阻碍或者依赖的工作点要优先提出来。而作为QA,我们应该合理利用共同的工作时间,把需要与onshore团队沟通的任务比如需求澄清, 故事启动,客户展示等工作优先完成,把可以独立完成的测卡工作优先级相对降低,这样就不会因为某些流程必须要两岸团队共同完成而阻碍。

网络环境的不同有时候会给测试工作会带来很多不便。为了最低程度降低网络环境带来的影响,首先我们要依赖于Techops团队搭建稳定可靠的VPN,再者作为QA在测试过程中如果遇到一些奇怪的问题,在分析问题原因的过程中应该考虑到网络的因素,必要的时候可以请onshore团队帮忙测试排除网络因素。

在解决两地团队相隔较远的问题上,我们制定了定期派遣项目人员去客户现场进行知识传递的计划。对于时长6周的现场出差,出差人员一定要提前做好计划,定时追踪知识传递的进度,在客户现场要尽可能的多了解项目的有关知识并和onshore团队建立良好的关系。作为QA,首先,一定要找到客户的质量经理一起安排好自己六周的知识传递计划并定时追踪进度。然后在客户现场需要找到一个onshore 的QA和他一起结对工作,在这个过程中你会很快的了解到一切关于QA的流程和工具,包括测试环境、测试数据、CI工具、Bug管理工具等等。同时,QA也需要找到一个对系统十分了解的开发工程师给你仔细讲解系统的架构和技术实现。最后,在知识传递过程中一定要学会记笔记,快速准确的把有用的信息及时分享给自己off shore团队,以个人带动团队共同成长。出差在客户现场,还有一点很重要的就是要利用面对面的机会与onshore团队建立良好的同事关系。茶歇和下班后的聚会都是很好了解对方的文化背景,兴趣爱好,建立团队认同感的机会。

虽然敏捷团队提倡“工作的软件高于详尽的文档”, 但是对于分隔两地的团队来说,有时候详尽的文档恰恰是提高沟通效率的必要手段。比如一个团队共享的wiki就能够帮助团队在不知道从谁获取知识时高效的查找到所需信息。作为QA,在离岸交付团队中,我们更需要注重测试的文档化。比如我们不仅应该详尽的对每张故事卡的测试案例和测试步骤文档化,而且还要记录测试环境的配置和测试工具使用说明,甚至有时为了使团队知道Bug如何重现,我们需要把重现步骤用截图的方式记录在Bug里。总之,在离岸交付中我们提倡并强调把自己所掌握的知识第一时间文档化分享给大家。

最后,为了提高团队的融洽度,获得彼此的信任。团队成员不仅要在技术等硬技能上体现出专业性,还要提高自己的软技能,学会怎样与有着不同语言,信仰,文化的同事进行无障碍沟通。这就需要首先努力提高自己的英语水平,适应不同的口音,再者要了解对方国家文化习俗,如果能在节日时送上祝福,或者闲时聊聊对方的文化,都能使对方感到亲切,获得认同感。同时,我们也要适时输出自己的文化,创造一个多文化的融洽的工作环境。

短短一年多的离岸交付因为限制很多,无法像在其他项目上一样积累足够多的经验,但在这个过程中,我在不断的突破限制、找到最佳实践的过程中也获得了个人能力的提升。现在我把这些经验总结出来,希望能帮助到现在或以后有相同工作场景的小伙伴们。

注:

  1. Devops: Development&Operations, 负责环境搭建,流水线配置,部署等工作。
  2. IM:Iteration Manager, 敏捷团队中负责管理迭代工作
  3. BA:Business Analyst, 业务分析师
  4. AC: Acceptance Critiaria, 故事或需求的验收标准。

更多精彩洞见,请关注微信公众号:思特沃克

Share

2017中国企业敏捷实施调查:总结与反思

在这瞬息万变的环境里,企业的生存与发展状况取决于其快速响应变化的能力,而敏捷运作是构建该能力的核心。

敏捷和其他创新思想一样,需要时间传播。全世界不少企业都已迈向敏捷的运作模式,也有很多传统企业,还没有尝试敏捷,处于观望评估的阶段。从2001年公布敏捷宣言至今,经过十来年的时间,敏捷在中国可以算是已经跨越了鸿沟,逐渐成为主流。作为世界范围内敏捷运作的领袖,ThoughtWorks很自然地就会接触到实施敏捷的这些早期使用者企业。这些企业在实施敏捷的过程中获得了明显的改进,也遇到不少困难。

与其独自探索,不如向行业的先行者学习。在敏捷逐渐成为主流的这十几年间,行业也一定为后来者积累了可参考的经验,这对于还在观望评估的企业来说,无疑会是宝贵的财富。ThoughtWorks在2017年6月至7月期间进行了一项针对中国企业的敏捷实施调查,了解这些早期采纳敏捷的企业:

  • 为什么要实施敏捷?
  • 面临哪些挑战,经历了哪些困难?
  • 采用了哪些敏捷实践?
  • 采取了哪些实施措施应对那些挑战和困难?

希望通过这个调查的结果,能为后来者提供有价值的参考。

当前实施敏捷企业的特征

本次调查的范围主要是ThoughtWorks中国所接触的行业人士,多是敏捷在中国的早期实施者。调查参与者总共229名。调查参与者来自全国各地,40%北京、9%上海、17%深圳广州、19%成都杭州武汉西安。调查不可避免有局限性,但我们仍相信结果具有一定代表性。

 

受访者来自不同行业,其中来自互联网企业的26%、信息科技21%、通信16%、金融17%。这些行业面临激烈的市场竞争和技术变革,必须走向更敏捷的运作方式,很自然地就会实施敏捷。

调查的参与者主要是敏捷教练(25%)和项目经理(17.6%)。这些角色都有提升开发团队交付能力的职责。调查参与者也包括开发(15%)、测试(14%)、产品经理(7%)、需求分析师(4%)。也有不少中层与高管参与调查,其中部门经理占10%,高管占4%。非研发人士也逐渐认识到敏捷的意义,参与了我们的调查。

敏捷实施规模大部分在100人以内

企业敏捷实施的团队规模大部分(79%)在100人以内。其实,这是一个趋势,随着技术和工具的发达,一个人能做的事越来越多,所以团队规模也自然变小。更重要的是,自主小团队和网络式组织结构,更灵活、更能够产出成绩。这也符合敏捷理念。只有特别复杂的系统,才需要大规模100人以上的团队。我们仔细分析了500人以上的敏捷实施团队,他们大部分实际上是多个独立产品线并行交付。单产品的交付,大部分还是100人以内。

敏捷实施的主要目的: 缩短周期、提高质量和满意度

企业实施敏捷不是为了敏捷,而是要达到效果。

有69%的受访者表示他们企业实施敏捷最主要的目的是缩短开发周期。这是通过更快的迭代节奏来达成的。贯彻和运作精益思想、减少浪费、解除瓶颈也是重要手段。所以,很多企业会同时实施敏捷和精益。有些人误以为敏捷会导致质量下降。其实,敏捷是有保障质量的理念和实践,有60%的受访者认为“提升质量”也是实施敏捷的目的,49%的受访者把“客户满意度”也设为重要改进目标。

其他实施敏捷的目的如下:

  • 缩短开发周期(69%)
  • 提高质量(60%)
  • 提升用户满意度(49%)
  • 提高人员的能力(30%)
  • 增强协作(43%)
  • 减少工作量,提高产能(32%)
  • 产品创新(17%)
  • 改变管理方式,让成员更有参与感(34%)
  • 其他(4%)

敏捷实施周期与效果:坚持6个月,必有效果

大部分(56%)受访者回复他们企业实施敏捷不到一年。这可能是受访者范围的局限性——敏捷在中国的推广已经有10年了,那些前几年实施敏捷的企业应该是早期领先者,敏捷已经逐渐受到认可,这是再次崛起的一波新浪潮。实施敏捷的企业,不管是刚起步还是实施多年,43%表示有所改进,18%表示获得了显著的改进。敏捷实施就是持续改进、系统性地解决问题,如果能够坚持半年以上,效果必然大增。

敏捷实施要解决的问题

实施敏捷是一个富有挑战的变革。敏捷本身要解决的也是个复杂问题。我们向受访者询问了这些挑战的影响程度:

  • 不涉及
  • 没有遇到这个问题
  • 偶尔遇到这个问题,没有影响
  • 偶尔遇到这个问题,影响不大
  • 遇到这个问题,对我们有影响
  • 经常遇到,影响很大
  • 就是它搞得我们特别累

我们按照挑战的影响程度分为三大组。每个企业的成长旅途都不同,所以它们面临的挑战也不同。然而这其中存在着规律,它们所面临的挑战的影响程度或许能够被粗略的归纳为“需求与架构、流程治理、以及企业文化”三大组。

第一组挑战:需求与架构不良

第一组挑战对企业影响最大。这些基本都是和需求、产品相关的问题,也包括架构和团队能力的问题。具体包括:

  • 需求变化多、工作量过载、需求工作拆分不够细
  • 需求不合理、定位不稳定、架构不良、团队能力不足

敏捷体系当中有不少实践都是为了解决这些问题。需求流程前端的实践,如设计思维、产品画布、用户故事等都是为了让开发团队更聚焦在有价值的需求上,以最少的投入快速产生价值。然而,敏捷虽然可以提供快速验证产品的机制,但是并不能指定产品方向。这还是依赖于有智慧、有眼光的产品负责人。有能力的产品经理,加上一个有效的敏捷运作机制是一个完美的组合。

关于架构问题,组织需要有策略地进行优化或改造遗留系统,清除过去的技术债务。这不是一夜之间能够解决的事,不是喊着敏捷的口号就能解决的,解决是需要规划和投入的。敏捷设计方法,例如领域设计、持续重构、结对编程、自动化测试,能够防止后续的腐化。不管是需求还是架构,这都是软件工程师本身该有的专业能力。系统快速增量的演进,暴露了这些能力的缺失。企业必须有系统性的能力培养和人才的引入。

第二组挑战:笨重的流程治理

第二组挑战对企业有不少影响。这些大部分是流程治理的问题。具体包括:

  • 治理不敏捷、团队之间协作、流程笨重
  • 涉众意见不合、绩效考核不敏捷、第三方合作

这些问题不是纯软件工程的问题。任何行业的企业在敏捷实施的过程中都可能遇到。实施敏捷的企业应该投入时间来分析已有的流程并进行简化。在这方面,精益思想非常重要。通过对精益价值流的分析,重新梳理团队职责、其贡献的价值和绩效导向的关系,就能够很快识别问题的根因。但是如果要彻底解决问题,还是需要上下的合作,制定新的流程。

第三组挑战:企业文化

第三组挑战的影响程度在不同企业中的表现并不集中,因为我们的问题是通过印象程度组合的,而不是它们所属的领域。然而,我们发现这大部分都是与人相关的问题。敏捷实施的持续性,最终必须要考虑人性。

  • 团队不愿意学习新东西、公司文化不敏捷
  • 开发测试和开发运维协作不好、需求实现复杂、团队分散

就像第二组问题一样,大部分问题不是跟软件工程有关,而在于文化和协作。有效协作的动力来自两方面:首先是成员本身的态度,有些成员本来就热爱学习,愿意为企业的长期利益着想。有些成员更多的考虑个体的利益,很难跳出舒适区。要改变企业文化是不简单的。所以,实施敏捷的时候,首先要先从一批意愿比较强的成员入手,同时也要考虑当前的绩效管理体系是否会促进或阻碍协作。领导的积极参与、以身作则,也是非常重要的。如前所述,敏捷实施是一项长期的变革,是需要坚持的。

敏捷实践落地步伐:团队、端到端、企业

企业要实施敏捷时,需要考虑实施的范围和要引入的敏捷实践。以及如何把这些改变有效的落地和生根。在我们的经验中,企业通常会先从小范围做起,有了一些成果之后再逐渐铺开到整个交付流程,从需求到交付上线,然后再考虑如何将敏捷精神扩散到整个组织。此次调查结果确认了我们的观点。我们向受调查者询问他们敏捷实践的落地情况:

  1. 已决定不会尝试
  2. 不知道这是什么
  3. 还没开始尝试
  4. 刚开始尝试(3个月以内)
  5. 已实施一段时间,有挑战但是会坚持
  6. 实施成功了,已经是习惯性的做法

我们按照他们有意愿尝试的实践进行了排序,并将其划分为三个组合。所谓“有意愿”就是包括他们认为自己还没开始尝试、刚开始尝试、已实施一段时间、以及实施成功的实践。

我们发现,这些实践组合正好和我们之前建议的开发测试敏捷、端到端需求交付敏捷、以及企业级敏捷,这三个实践组合一致。

第一组实践组合:开发测试敏捷

第一组实践组合包含最普遍的基础敏捷实践,包括Scrum和看板,也包含一系列的自动化实践,如自动化测试、持续集成、持续发布、以及敏捷管理工具(例如JIRA)。 团队如果不实施这些实践,就不能说他们是敏捷的。如果一个团队说他们很敏捷,但是没有站会,没有工作跟踪,没有自动化测试,更没有持续集成,你觉得他们能够敏捷起来吗?这些都是必备因素。然而,即使有了这些实践也可能只是流于形式。更重要的是团队有敏捷的学习心态。

第二组实践组合:端到端敏捷

第二组实践组合包含的都是开发团队以外和周边的协作,包括开发运维、业务人员、团队各角色的协作。它们存在于需求从概念形成到完成交付的各个环节,包括:设计思维、前期需求管理、微服务、特性团队、测试驱动开发、验收测试驱动开发、DevOps。有效协作的前提是开发测试的实践已经有效落地。如果稍微一动代码就崩溃,开发测试不能够迭代交付,那么就谈不上什么端到端的敏捷。

第二组实践组合本身不是特别难,但是一旦牵扯到不同职能,就难免有利益冲突。教练可以采用逻辑一个个地说服各职能的成员。一个行之有效的办法就是在各职责成员中共享产品愿景和目标。产品一旦能够有明确的发展发向,并且能有效的传达到每个成员,每个成员理解他对产品成功的贡献,那么各职能成员的参与度就更有可能提高。敏捷是一个很好的工具,但它的有效落地还是需要方向的。

第三组实践组合:企业敏捷

第三组实践组合包括:项目组合管理、预算与绩效管理、其他职能的敏捷、大规模敏捷、精益创业。

这些实践大部份都是软件交付以外的实践,是一系列很不同的专业。这里有财务人员、有人力资源、有企业战略、有业务负责人等。要有效的开展敏捷协作,首先必须理解他们的观点以及他们面临的挑战和矛盾。他们大部分都不是IT出身,不理解IT的术语。传统敏捷实践和术语不能够解决他们的问题。

企业治理需要另一套崭新的实践。其中,超越预算是一个开始受人关注的体系。它提供了一套财务办公室、人力资源办公室、以及战略办公室的协作理念和机制。有不少企业开始在这方面进行尝试。企业治理的敏捷事关重大。领导层,以及这层职能的敏捷,完全决定了企业上下的敏捷。企业级的敏捷实践还是在演化中。我们期待这方面的发展。

不要忘记代码质量

我们也发现,受调查的企业对代码设计方面的关注比较缺失,这包括领域设计、UML、结对编程。其中最有争议的实践就是测试驱动开发(TDD)以及结对编程。有不少企业决定不尝试这些实践,对它们的效果有所怀疑。这或许是由于受访者对这些实践的理解不足,或者是他们的落地比较困难。我们的观点是这些实践都是非常重要的。代码质量决定系统的质量。即使实施有所困难,企业应该在这方面更加专注。

敏捷实施措施:流程、自动化、领导力、组织文化

企业敏捷实施基本上是一个组织的变革,所以必须按照变革项目来对待。变革项目必须要有全面的考虑。如果不够全面的话,实施会受到一些阻碍。我们将敏捷实施措施按照它们的必要性和投入排序。

第一组措施:流程变更,自动化投入

这些措施都是企业觉得有必要并进行了合适的投入、是大家默认最基本的事实策略。首先,必须要建立一个敏捷实施工作组、调整运作流程。另外,自动化这方面是需要有额外的人力投入的,否则会对研发团队的交付速度有所冲击。

  • 调整运作流程、敏捷实施工作组
  • 建立内部自动化测试、持续集成、持续交付能力

第二组措施:领导参与,建立改进目标

敏捷变革基本上是一个组织发展工作。必须有领导以及外部顾问的积极参与。顾问会带来他们的经验,避免团队走冤枉路。另外,企业必须例行跟进和分享,确保实施敏捷的团队受到关注。敏捷的实施也必须敏捷。

  • 领导积极参与、雇佣外部教练
  • 把敏捷改进作为团队目标
  • 例行敏捷实施会议、组织敏捷相关的分享

第三组措施:组织文化、绩效管理

这些措施是受访者觉得必要、但是没足够投入的。如果要有效可持续的敏捷落地,不仅仅要考虑团队的辅导,也要考虑其他方面。这或许会涉及到系统架构、组织结构的演进。一般来说,遗留系统是妨碍企业敏捷的原因。除此之外,也要建立内部教练机制、实践社区,要让员工持续的学习。最重要的,也要考虑企业的绩效管理。已有的绩效考核是否正在阻碍敏捷文化的推进,还是能够促进敏捷文化的建立。

  • 系统架构改造
  • 实践社区、内部教练
  • 改造绩效管理制度

敏捷实施有套路

敏捷已经拥有将近20年的历史。对于软件开发这样一个迅速发展的领域来说,这是一个很长的时期,在这个时期中,敏捷有了很大的进步。事实上,企业可能面临的任何问题似乎都与敏捷相关。问题不在于解决方案不存在,而在于企业采用这样的解决方案的态度过于谨慎和保守。企业害怕实施敏捷时所带来的变化对组织的冲击太大。企业需要系统地将敏捷整合到他们的工作方式中,并转向敏捷的思维方式。

企业在这敏捷实施旅程中并不孤单。有很多企业的经验可以参考,而我们这次的调查就系统地收集了许多企业的经验,总结了一些通用可借鉴的实施措施。首先,企业必须克服以下几个方面的挑战:需求和架构、笨重的流程、以及企业文化。我们发现企业采用的步伐通常都是先实施团队级的敏捷,然后端到端交付敏捷,最终实现企业级敏捷 。这与我之前在《企业敏捷转型道路》所描述的完全一致。

最后,敏捷企业应考虑采取以下措施:

  • 简化流程
  • 投入自动化
  • 确保领导参与
  • 建立改进目标
  • 让组织文化和绩效管理更符合敏捷理念

在当今的商业环境中,不敏捷的工作方式已经不再是企业的选择。实施敏捷不是为了时尚,不是为了跟上“最新和最伟大”的潮流。“企业不实施敏捷是等死,错误实施敏捷是找死。” 实施敏捷是一个生存的根本动作。没有敏捷,就难以执行任何其他战略举措,例如数字化转型。

希望我们的这些总结和反思,能给正在实施敏捷或将要实施敏捷的企业,提供有价值的参考和指导,让大家少走一些弯路,早日实现企业级敏捷。也期待大家留言分享各自的观察和思考。

附:《中国企业敏捷实施情况调查-2017》(请用手机打开链接)

Share

项目管理中的敏捷实践

作为项目经理,我们经历了不同的项目,却总是受限于相似的困局。比如以下三个典型难题:

  • 团队目标不一致
  • 团队成员不熟悉
  • 信息发布不流畅

倘若我们任由问题存在,而不在每次项目中进行总结和提炼,就会反复的徘徊于丰满理想与骨感现实当中。

敏捷思想和实践能够为我们提供一种可能性,帮助我们解决在项目交付过程中遇到的具体难题。

敏捷的项目管理——追求最大价值的成功

当我们提到敏捷的项目管理,就得先说说瀑布式开发和迭代式开发的区别。

(图片来自:http://t.cn/R9IjtIs)

大家都知道瀑布式开发的特点是大批次、缓慢流动、在每一阶段追求工作完整,但因其缺乏并行迭代的概念,对变化的响应必然很慢。而迭代式开发则恰恰弥补了这个弱点。在迭代式开发过程中,整个开发工作被组织为一系列短小的、固定长度(在ThoughtWorks通常是2周)的小项目,我们将其称为一系列的“迭代”。每一次迭代都包括了需求定义、需求分析、设计、代码实现与测试。

采用这种方法,开发工作可以在需求被完整地确定前启动,并在每次迭代中完成系统的一部分功能开发工作,再通过客户的反馈来细化需求,并开始新一轮的迭代。

ThoughtWorks的敏捷开发通过逐步细化、迭代前进的方式,分阶段地将需求予以实现。比如说,我们先从整体功能规划中定位出一小部分核心功能,打造能基本运转、对用户有价值的最小可用产品(Minimum Viable Product,MVP),然后迅速迭代开发,听取用户反馈,及时调整功能规划。

我曾在一次培训中听到同事谈到敏捷团队与西游团队的相似性,他认为唐僧师徒可以被看作敏捷中的全功能团队:团队有共同的目标——取到真经;他们历经了九九八十一难,好比九九八十一个迭代,每次打怪成功都是完成了一次交付;在不断迭代的过程中,这个团队不断地收集反馈、持续改进,一步步地完成了最后的目标。取到了真经,意味着完成了项目的交付,同时使得团队能力得到质的提升。这是一个美妙的结果。

项目成果的交付和团队能力的提升,这是项目经理在项目管理中最希望达成的目标。 传统项目管理的定义是:“在有限资源限定的条件下,实现或超过设定的需求和期望”。一句话概括了传统项目管理的铁三角:需求是范围,资源包括时间和成本。

那么这个定义是正确的吗?

大家都看过电影《泰坦尼克号》,如果我们套用上面这个“范围、时间和成本”定义的框架,《泰坦尼克号》会被判断为一个失败的项目。为什么呢?这部电影在拍摄过程中多次延期,预算也超出很多,无论从成本还是时间来看,这都是一个失败的项目。可是我们都知道,《泰坦尼克号》直到现在仍然是一个难以超越的票房神话。

由此可知,左图的“传统项目管理铁三角”概念忽略了“价值”这一重要因素。右图的“敏捷项目管理铁三角”强调,团队应得到来自市场的真实反馈,以此来帮助敏捷团队持续不断地、尽早地交付有价值的软件。

在追求价值交付过程中,我们越来越多地发现敏捷项目管理中有着至关重要的一环——人,也就是我们的团队。价值是人创造的,是为人服务的,很多敏捷实践都围绕人展开。我们试图找到一种通用的方法来最大限度地发挥人的能量。未来社会最有价值的人,是以创造力、洞察力、对客户的感知力为核心特征的,我们相信这样的团队能创造最大的价值。

下文将以我在ThoughtWorks的项目经历为例,讲述ThoughtWorks日常交付项目中主要使用的敏捷实践是如何帮助团队实现最大价值的。

用户故事

用户故事(User Story)是敏捷开发的基础,它从用户的角度来对需求进行描述。软件开发是为了实现产品的商业价值,满足用户需求。只要需求足够明确,所有人都了解其具体内容,团队就能简单有效地把需求转化成可实现、可测试、能够发布的代码。为了实现这个目标, 需要找到一种方法来描述需求,让所有人都能对任务的范围有一个共同的认知。这样团队对任务完成会有一个共同的定义,不会出现“你做的不是我所要求的”、 “我忘了告诉你这个需求”等类似的问题。

用户故事体现了用户需求以及产品的商业价值,同时定义了一系列Acceptance Criteria(AC)。只有团队完成的工作符合这一系列的AC时, 才算真正完成了这个用户故事。一个用户故事通常包括三个要素:

  • 角色:谁要使用这个功能;
  • 活动:需要完成什么样的功能;
  • 商业价值:为什么需要这个功能,这个功能带来什么价值。

用户故事可以有不同的展现形式,以下是其中一种:作为一个<某种类型的用户角色>,我要<达成某些目的>,只有这样我才能够获取<商业价值>。

所以用户故事一旦被确定,那么它所要实现的功能、需求范围、所需工作量也就随之确认了。之后开发人员所要做的就是根据这个用户故事的内容进行开发,只有当所有AC被覆盖到,测试人员完成测试,发现所有功能是可测试的、可运行的,这个用户故事才算完成了。

估算和迭代计划

估算(Estimation):团队在动手开发一个用户故事功能之前,应当对实现这个用户故事所需要的工作量有清晰的认识。如Martin Fowler所说,”Estimation is valuable when helps you make a significant decision”。只有当团队对达成一个目标的工作量以及完成它之后的“收益”有明确的认知, 才能做出明智的决定。

当团队在为工作排定优先级、制定迭代计划时,业务分析师需要知道每个用户故事的成本,团队成员需要知道每个用户故事的价值。有很多种估算用户故事工作量的方法,其中一种就是把完成这个用户故事所需要的点数(根据用户故事的复杂度估算)写到对应的故事卡上。估算可以帮助团队以不同的方式,对实现即将开始的用户故事、未来的架构方向和代码库的设计,有更好的理解。一个迭代能完成多少个点数是能估算出来的。也可以使用一些工具统计出过去每个迭代所完成的点数,比如燃尽图。

只要整个团队共同协作,估算本身也可以变成一种很有意义的活动。它有助于团队增进理解,并保证团队每个人都对要交付的需求范围和价值达成共识。让评估变得更有趣的是,通常不采用简单连续的数列,比如1,2,3,4,5等——而是采用一种近似菲波拉契数列的形式,像1,2,3,5,8,13等(正如《达芬奇密码》里面看到的),这样当数字越大、相邻数之间的间隔就越大,使得团队更容易区分哪个故事更小、哪个更大。

在做迭代计划(Iteration Planning)时,团队需要从客户价值维度和技术风险的角度来排定优先级。下图中是常用的工具之一——需求优先级矩阵。

迭代会议和功能演示

敏捷宣言里面有一条:客户协作优于合同谈判。在敏捷团队中有一个角色叫做业务分析师(BA),其核心职责是确保业务需求的清晰和透明,保证开发团队对业务有足够的理解,并将这些待完成的用户故事按照优先级排列出来,以任务卡的形式来驱动团队的开发。

迭代会议(IPM)通常发生在每个迭代的第一天,团队成员一起制定迭代计划。这个会议由BA主持,大家一起同步几个方面的内容:

  • 下一个迭代的用户故事;
  • 对下一个迭代的期望和计划;
  • 风险的评估和总结。

不同的人对需求有着不同的理解,所有团队成员都要对用户故事所有相关内容、所要实现的功能、满足哪些条件用户故事才算完成达成一致。迭代会议的主要产出是下一个迭代中需要完成的用户故事,这些用户故事即为下一个迭代所要完成的主要目标。

功能演示(Showcase)是敏捷开发流程中的又一个实践,通常发生在每个迭代的最后一天,目的是演示可工作的软件。团队把一个迭代中开发好的功能给相关人员演示,并收集反馈,以便在下一个迭代中可以对变化作出快速响应。

站会和用户故事开卡

简单地说,站会(Standup)是团队在一起快速地开一个会(通常在物理墙前),成员逐个更新自己的状态。更新包含以下几个方面:

  • 昨天完成的工作;
  • 今天计划做的工作;
  • 面临什么阻碍,需要什么帮助;
  • 自己手头用户故事的进展,是否存在技术风险。

既然是快速的会议,站会的时间就不宜过长,10分钟左右为佳。建议团队成员站着开会,因为研究表明,当人们坐着开会的时候,会议的时间会被无形中拉长。

这里有一些实践原则:

  • 团队成员都要参加站会,轮流主持,谁迟到了都不等——仪式感很重要。
  • 站会的时候,每位团队成员围绕故事卡进行更新。介绍一种有意思的实践——使用Token(也就是使用一个实物作为”令牌”,准备发言的人首先取得”令牌”,发言完成后将“令牌”传给下一个人。令牌要醒目,可以是毛绒玩具,也可以是一顶帽子)。

用户故事开卡(Story kick-off):在每个用户故事开发之前,要确保BA、DEV和QA对用户故事理解一致。这个沟通活动通常表现为由DEV讲解这个用户故事要完成的功能及AC,一旦发现任何疏漏,BA及时补充。DEV有任何疑惑也需及时提出来,当场确认,使这些功能得以正确实现。在后续开发中如果碰到任何疑惑,也应及时找BA了解清楚。QA会严格按照AC来验收用户故事。

代码审查和回顾

代码审查(Code Review) 开发团队在完成每天代码之后,会聚在一起评审当天的代码,这样做有几个好处:

  • 团队经过一天高强度的思考与编码,适当地停下来,看看其他人写的代码,同时将自己的代码讲解出来,往往能获得一些意外的灵感,或许能解决自己面临的阻碍;
  • 互相了解设计思路,获得更好的建议和进行思路重构,提高代码质量;
  • 及早发现潜在缺陷,降低事故成本:如果这个时候发现代码的坏味道和一些需要改进的地方,代码审查结束后可以花少量时间作出更改;
  • 促进团队内部的知识共享。

回顾(Retrospective):回顾会议的目的是通过新的沟通形式唤起大家对团队的集体意识,指出团队或个人在一段时间内的不足并列出对应行动。持续而有效的回顾和反馈,可以保证团队关心生产力和效率,了解自身的不足,这将成为团队持续改进的起点。

回顾的关注点也多种多样,除了“项目开发”之外,还可以关注“敏捷成熟度”、“团队角色和职责”、“人员技能提升”等。在坚持回顾的同时,需要做的还有保证回顾的有效性。应根据团队建设目标的发展变化,不断调整回顾的关注点和形式,确保回顾能够有针对性地发现团队的缺陷并转化为实践。长期有效的回顾和正确的回顾产出,还能够不断提升团队内部的安全感和信任度。

回顾的形式和方法非常多,最常见的是“Well & Less Well”。

最大程度的可视化

看板源于精益生产实践,敏捷将其背后的可视化管理理念借鉴过来,形成了具有自己独特风格的可视化管理工具。

在敏捷项目里,挂在墙上的“人人可见的大图表”是一种普遍的实践,它被用来共享项目的状态并将之可视化。比如表示项目状态的物理墙,这样的物理墙通常包括三个元素:时间、任务和团队。

除了表示项目状态,项目团队还会可视化其他的元素,比如团队应坚持的规则、项目上的经验分享以及项目的里程碑。

一般来说,通过有关联的团队和个人之间相互协商,可以识别出未来一段时间里各自的活动,以及相应的、对成功的衡量方式,然后将其可视化出来,每段时间再回顾和调整一次。有了这样的可视化,团队会更加容易对齐目标,并不断培养和加深责任感。

可视化带来的好处是:

  • 日常工作透明,将迭代过程中所有的故事卡可视化出来,团队成员可以随时知道当前需要完成的工作以及将要完成的工作。由于人对视觉反应更灵敏,可视化的故事墙能立刻聚焦团队的注意力。
  • 将迭代过程中遇到的问题暴露出来,可以促进团队成员在工作中一起积极讨论解决方案。
  • 团队也可以根据现在的进度以及遇到的问题,了解需要哪些帮助,更好的分配资源,减少开发进度被滞后的风险。

沟通计划

敏捷里面的自组织团队其实是敏捷的结果,而不是先决条件。实施敏捷的过程也是打造自组织团队的过程。每个团队成员在面对“做什么、怎么做”的问题时,也会以自组织的方式去解决。每一天,团队中的每一个人都要其他成员保持协调。为了保持同步,我们会创造基于敏捷实践的沟通机会,这个也是实施敏捷的过程之一。

在ThoughtWorks有一个非常有名的活动叫Inception。Inception是启动软件设计和交付项目的方法,通过集中式、互动式的设计工作坊,帮助客户在最短时间内对项目范围达成一致,快速进入项目交付。而Inception的一个产出就是沟通计划(Communication Plan)。比如在这个沟通计划中会讨论:以什么频率、什么形式作项目的更新,比如说每周五以周报的形式作一些主要信息的更新;站会和迭代会议什么时候召开,需要邀请哪些人,比如说业务负责人,技术负责人等等。

以下内容都会在沟通计划中定义清楚:

写在最后

回到文章开头的部分,我认为可以将敏捷实践和解决方案做如下对应:

团队目标不一致

  • 用电子墙和物理墙展示用户故事、需求全景图、项目进度燃尽图;
  • 通过迭代会议和功能演示会议对齐迭代计划,项目进度、识别项目风险。

团队成员不熟悉

  • 基于敏捷实践,创造更多的沟通机会,比如回顾会议、代码审查和站立会议。通过不断地创造这样的沟通机会让团队成员更加默契。

信息发布不顺畅

  • 共享信息,制定沟通计划;
  • 最大程度的可视化。

文中提到了很多类型的敏捷实践,这些实践需要贯穿到团队的日常活动中去,持续的实施和改进。行为心理学研究认为:21天以上的重复就会形成习惯。任何一个动作,重复21天就会变成习惯性的动作;任何一种想法,重复21天、或者重复验证21次,就会变成习惯性的思维方式;任何一种信念或者有益的实践,经过团队持续验证,它一定会成为团队的信念和实践。

剑道中有这样一个心诀:守、破、离。

  • 守:最初阶段须遵从老师教诲,认真练习基础,达到熟练的境界
  • 破:基础熟练后,试着突破原有规范让自己得到更高层次的进化
  • 离:在更高层次得到新的认识并总结,自创新招数、另辟新境界

项目管理者中的大多数人都处于“守”的阶段:他们学习、吸收了前人的项目管理经验,带领自己的团队有序地开展项目交付工作;但是他们经常困惑于某些在管理中反复出现的问题,苦于找不到有效的解决方法,不得不在新的项目中重复之前的困惑;

有的项目管理者已经达到了“破”的层次:他们能够以全局优化的角度去总结自身项目管理的经验,并通过学习、分享及各种交流平台去开阔眼界、拓宽思路,借鉴或改良项目管理的方式方法,使之更适用于团队;

而所有项目管理者的最高目标则是“离”:随着项目经验的不断积累、对管理的思考日渐加深,对项目管理有了新的、更高层次的、属于自己的独特认知,并将其应用在实践中,独辟蹊径,使整个项目管理思路焕然一新。

希望越来越多的项目管理者能够达到更高的阶段。这是我们在项目管理中不变的追求。


更多精彩洞见,请关注微信公众号:思特沃克

Share

Bahmni,公开的敏捷项目

Bahmni是什么

在ThoughtWorks,我们有三个重要的使命,其中第三个支柱“推进社会和经济公正”让我们有机会去改变这个世界,让更多的需要帮助的人得到信息化技术的帮助以改善生活。Bahmni(读作“巴姆尼”)正是在这个使命下孕育的一个项目,其目标是让Jan Swasthya Sahyog(人民健康扶助团,简称“JSS”)、以及其它成千上万类似的医院实现信息化。

ThoughtWorks印度公司从2013年开始做这个产品,其核心是一个开源的电子病历(Electronic Medical Record)系统OpenMRS。这个软件内建了一套标准的医疗信息记录数据体系,在北美和南美的一些医院里应用并收到了很好的反馈,并且有一个活跃的社区(包括医学专家、公共卫生专家和IT专家)在不断完善它。我们组建了70余人的团队,分布在印度的4个城市和中国的成都以便支持整个项目的开发。(部分摘自《印度儿童诗雅拉尔之死》)

Bahmni产品目前在印度、不丹、孟加拉国等国家均有实施,最为耀眼的是在孟加拉国,Bahmni会作为整个国家的HIE(Health Information System 医疗信息化系统)。

更多的介绍请见:

我们的敏捷实践

Bahmni是一个开放的敏捷项目,世界上任何一个人都可以对该项目做贡献,而不仅仅局限于ThoughtWorks内部。为了能够让更多的人参与,ThoughtWorks选择了开源的工具、开放的敏捷管理方式,这些管理、实践、工具和ThougtWorks的其他内部项目和客户项目均类似,参与者参能够用到最佳的敏捷开发方法。

公开的知识管理

一款开源的产品如果无法很方便的使用,则失去了它大部分的价值。在Bahmni项目中,团队很重视文档,采用AtlassianWiki进行知识管理。Wiki涵盖了产品的特性、社区、实施指南、开发指南、项目管理等方方面面。ThougtWorks内部对文档进行了持续的更新,保证文档的健全,为项目的参与人员提供了最大程度的便利。

公开的需求管理

在Bahmni项目中,客户是医院的工作人员,他们会提出各种各样的比较模糊的需求。同样在技术上Bahmni也会有自身的一些需求。Bahmni在管理这些需求的时候,采用了Trello将所有的需求管理起来,所有人都有权利看到并对需求提出自己的看法。每过一段时间,产品经理将会对所有的需求进行Review,包括对需求澄清、进行进行优先级的划分。

每一年,Bahmni团队会召开一系列的会议对Trello内的需求进行梳理,制定出一年的Roadmap。所有的人包括来自于OpenMRS的开发者、自由开发人员都可以参加Roadmap的制定过程,提出自己的意见和建议。但这个Roadmap并不是一成不变,敏捷总是拥抱变化,所以在变化产生的时候,Roadmap也会做及时的调整。

公开的迭代管理

迭代计划会根据Roadmap进行制定,我们使用mingle对项目进行迭代管理。

使用这套系统,任何人都可以看到卡的状态及内容,持续跟踪整个项目的进度。开发的人员提交的代码会和卡根据提交记录中的编号进行关联,方便事后对卡片的内容进行追踪。每个迭代都会有一系列的会议,对于ThoughtWorks之外的团队、个人,我们提供了Events Calendar以便他们参加会议。

技术实践

Bahmni项目使用了多种技术实践来保证产品的质量。

我们使用TDD,为每一个业务价值书写单元测试,测试覆盖率高于80%。我们用Gauge对页面进行端到端的测试,每天进行产品的回归测试。我们用GoCD对产品进行持续集成及版本发布,保证发布管理的自动化,减少人工干预导致的各种问题。产品发布并部署到到测试使用的云环境以及Demo环境,全程只需要很少的界面点击即可完成。

活跃的社区

Bahmni是基于OpenMRS的一套医疗管理系统。基于OpenMRS的客户群,我们在OpenMRS Talk中专门开辟了Bahmni的版块,对Bahmni相关问题进行解答。我们深知活跃的社区对于一款开源产品的重要性,所以团队内部有专职的人员对社区进行追踪,尽最大可能及时的回答用户的问题。为了更好的帮助用户快速入门,我们还准备了Youtube的频道进行了大量的讲解。

同时,我们还有IRC Channel对用户进行实时的帮助。Bahmni团队所有的开发人员都被鼓励去回答用户的问题,只有开发人员和用户有最近的距离的时候,开发人员才能理解用户的需求以及诉求,从而设计更好的系统。

我们也积极参与OpenMRS的开发和讨论,每周OpenMRS都会有开发人员的会议,基于OpenMRS的产品团队、开发人员都可以参与到会上进行交流。每年OpenMRS都会举行OpenMRS Summit,Bahmni作为其发布版也参与到其中贡献数个话题并寻求积极的反馈。

总结

Bahmni项目的公开运作方式从产品的设计到需求的获取到最后的开发得到了大量的社区用户的积极参与,线上线下的结合拉近了和用户的距离。ThoughtWorks一项以技术实践为骄傲的敏捷开发方式在产品的生命周期内展现的淋漓尽致,可以说是敏捷项目的一个标杆。


更多精彩洞见,请关注微信公众号:思特沃克

Share