敏捷实践,你可以绕开一些弯路——BB-Talk #002回顾

前言
BB-Talk 是什么?
BB-Talk 是由Worktile 特别推出的线上分享活动,聚焦互联网时代更高效的工作流,横跨TMT、电商、律师、教育等各行业,覆盖研发、产品、设计、市场、运营、HR、行政等各职业。
每期邀请一位相关领域的大牛嘉宾,通过微信群内的语音、文字、图片等形式,分享干货、自在交流。
本文为7月5日BB-Talk 第二期嘉宾分享与互动提问的总结。

本期嘉宾

特里斯谭,时代光华大数据团队负责人。
企业内部分享达人,连续三年优秀员工。
CSPO认证,3年时间从0到1完成团队敏捷转化,打造了两个不同的敏捷团队。

内容概要

BB-Talk 第一期之后,大家了解了Scrum 的框架,清楚了敏捷开发的主旨。这些听上去都很有道理,But 实践起来却未必轻松。老板和高层,PO 和 SCM 对敏捷成功到底有重要的影响?你真的需要拆分并估算出每个任务的工作量嘛?在向敏捷转型的过程中,工具应该扮演什么角色?Worktile 在实施敏捷的过程中发挥了怎样的作用?

本次分享嘉宾特里斯谭经过几年和团队的打磨,希望通过若干个大大小小的项目实践经验和你分享敏捷实践的点点滴滴,给你一些启发,帮助你走上正确的实践敏捷之路!

分享内容

大家好,我是上海时代光华的特里斯谭,也是Worktile 的深度用户。最近Worktile 针对研发行业打造了从 研发流程管理到 工作效率评估 的 一站式研发解决方案 ,其中就包含了敏捷开发管理。我作为一个敏捷的信仰者,今天就想跟大家聊聊自己的敏捷实践经验。

我的观点

实践敏捷,实际上真的是需要大家重视、并真正去身体力行的一件事情。有意义的敏捷实践一定是围绕人这个因素展开的、是以提高用户价值为目的的迭代式的活动。人、用户价值、迭代,这三个词几乎可以代表着敏捷的核心的理念和观点。

我的经历

我大概是13年底开始接触敏捷,到现在为止近3年的时间。
初次尝试敏捷,公司想要把整个研发中心转型到敏捷的过程当中,主要是为了解决加班、团队人员不稳定、团队质量不好等一系列问题。这一次的尝试最终以失败告终。
第二次尝试是2014年5月至2015年2月,我带着一个七、八个人的团队实践敏捷,初期我们有一定成果,但最终结果仍然是失败的。
经历了这个前两次的失败和教训也好,然后就迎来一次机会。在15年3月份,我带领一个15人左右的团队,开始使用一些敏捷的方式,形成一些团队规则。我们大概用了两个月的时间,完成了公司战略级移动端版本的迭代。
15年11月,我们再次做了内部转型。我们开始用电子看板,尝试按角色拆分小团队,团队成员渐变成自组织,这些事情贯穿起来,就是我的敏捷实践之路。

我眼里的敏捷

其实敏捷实践就如谈恋爱一样,你和你的团队关系,或者你的团队在实践中的关系,就像是两个人的恋爱关系,我把它分为三个阶段。

第一阶段,初恋期(将敏捷导入团队)

在从0到1实践敏捷的前提下,大家会发现成员对敏捷的认知是不一的。敏捷千万不要自己玩,不要觉得我是开发,我把开发带进来就能玩好了,我建议大家把更多角色都带进来。不管是研发、测试、产品或者是设计师,所有的相干者都需要达成一致之后再开始做。否则的话,这件事情最终达到的结果就会与预期相距甚远。

敏捷,就像是一场改革,需要一个推动者来推行改革的环节。而且这个推动者的职位越高越好办事。我看到很多公司CTO或者是老板,直接就说我们把敏捷实践的非常好。如果从开始就有一个非常好的环境的话,往下推行这件事情相对来讲会变得顺利。

第二阶段,热恋期(磨合、并且逐渐走向成熟的阶段)

如果你挺过了第一个阶段,会发现在这个时候你的团队会对敏捷有一定的认识、开始尝到甜头,并逐渐形成固定模式。

其实大多数的成员已经对敏捷的框架方法有了一定的了解,并且开始执行起来。进展顺利的团队可能几个月就会进入到这样一个阶段,这取决于团队的规模,理论上人数越少推行的会相对顺利。敏捷实施的效果和团队成员默契度有非常大的关系,若团队关系非常好,就越快趋于成熟。

另外,在新人加入的时候,是对这个团队的一个考验。如果新人加入你的团队后,能够非常迅速的过渡到成为这个团队的成员,这证明你的团队是一个良性的团队。而且敏捷在这个阶段会开始有一定的影响力,你会渐渐的发现,大家的抵触情绪慢慢消失,并且团队成员的敏捷精神开始相互传染。

第三阶段 —— 稳定期(形成团队默契):

进入这个阶段可以说是一个成熟的标志,也是大家都很向往的一个理想的状态。在这里其实要注意的是,如果你一直管或者一直来维护这个团队的话,在我看来这并不是什么好事。应该要不断的给团队成员更多的自主权。如果团队磨合得好,尽量去适当放权,让他们自主去做决策、做优化。

每个人都是渴望成长,每个团队成员都是渴望挑战的,他们不喜欢做一个重复的执行者。而你需要更宏观的站在团队的组织者,甚至一个领导者的心态去看整个团队的发展。达到这个阶段,你是需要为团队争取一些更好的利益,这是走向下一步的基础,比如选择一款合适的工具来帮助团队更好地实施敏捷。

这里给大家分享一下我们团队Worktile 看板。我们在敏捷实践中逐渐由实体看板转到电子化的看板,Worktile 给到我们团队一个非常好的辅助作用。

依据Worktile 本身看板管理的特性和任务驱动的方式,可以很好的将一些进度和概要信息展示出来。通过这个看板大家可以看见我们团队的工作流程,大致分为“待开发”、“进行中”、“已演示”以及“待发布”。整个流程对我们团队的所有成员而言都是清晰可见的。项目看板上的列表直接就能展示我们团队的进度和阶段,也能很好地实现整体进度和个人进度的统计。
同时,Worktile是一个非常灵活化的工具,它的自定义设置留给我们很多实现团队个性化特色的空间。在敏捷实践当中,选择合适的工具能有效提升整个团队的工作效率。

我的敏捷实践心得:

很多人可能会问到底什么才是敏捷?我们是否敏捷了?其实敏捷就是从最小的事情开始。比如说你一开始没有每日站会的时候,突然开始做站会了,大家一起每天来探讨自己的工作,而且在固定的时间里,给大家互相交流的一个机会。这就是敏捷的一个开端。

敏捷的成功实践一定是基于人这个因素的,在这个过程中你要考虑你的团队文化,你的老板的敏捷意识和决策能力,要勤奋而有耐心的为你的敏捷实践先铺好路,才能保证后面的事半功倍。

另外,我的经验告诉我,其实敏捷一开始真的是不需要扁平的。很多时候我们会疑问公司职能化太严重了是不是不能做敏捷?其实不一定。当敏捷开始做起来、并且让团队成员享受一些甜头之后,你会慢慢的发现,你的团队自然就扁平了。你的部门、你所管辖的这个领域也就扁平了。

小团队需要注意的是,不管多小,每个人都需要有跨职能的能力,每个人都应该具备多种技能。最后一点是团队成员必须要保持学习心态,有奉献精神和责任心。

Q&A

Q1:寄快递的问题有些像福特创造的流水线模式,虽然模块之前是相关的,但是尽量分拆然后降低模块之间的耦合,每个人专心做一个小模块。敏捷就是小而快,是这样吗?  @REVEES

A:寄快递的故事就是告诉大家,每个人分工做不同的事情会增加沟通成本,反而阻碍整体效率的提升。如果我们每个人独立负责,信息透明,那在工作执行的过程中会更加清楚地知道工作进展以及问题所在,这样反而能快速解决问题,完成工作任务。

小蜗提示:Worktile 企业版所具备的任务看板、日历、网盘等功能,可以确保公司每个人在需要信息的时候都知道去哪里查找,都知道可以向谁咨询。它能帮助公司成员消除一切在交流和获取信息中可能存在的障碍,让团队更加开放透明。

Q2:请问敏捷实践中,您认为搞定人是第一关键因素,那么仅次于它的因素是什么?可否简要谈谈? @邵智康

A:搞定了“人”这个最重要的因素之后,就需要合理使用工具和方法来更好地实现团队的敏捷,从细节问题着手,保证整个团队的有效沟通。

Q3:敏捷团队的考核方法是怎么样的,如何避免考核对团队成员的“伤害”?  @zwtforward

A:每个团队定好目标之后,一定会有燃尽的,每天更新迭代燃尽图就是一个很好的考核标准。想要避免伤害,我认为最好的方法就是把丑话说在前头,尽早提出执行规则和惩罚措施。

小蜗提示:以往我们需要通过Excel 的记录生成燃尽图,或者是在一张白板上手工绘制燃尽图。但是在Worktile 中,系统会根据项目中任务的新增和完成状态,自动生成燃尽图。Worktile 所具备的强大的项目可视化统计功能就是在“不伤害”团队成员的前提下把目标过程进度展示给所有人。
想要详细了解,可以点击 一站式研发解决方案

Q4:驱动敏捷团队前进的动力是什么,仅仅是画饼是不够的?  @zwtforward

A:画饼是没有用的,高效的协作和实现个人成长才是驱动敏捷团队前进的动力。

Q5::我发现对于每日站会而言,用实际的白板大家关注度和默契会高些,电子白板的使用过程中感觉有些流程化了。不知道您对这个怎么看的,能都分享下你的团队如何使用电子白板来默契地开站会的?  @刘易鑫-知康-产品

A:看板是非常有用的,从短期来讲能增加团队的仪式感,这个仪式感对于敏捷实践来讲是非常重要的,从实体看板转为电子看板实际上是让这项流程更加高效。

Q6:对于定制项目,可以谈谈敏捷团队里如何在项目签合同前评估成本和报价,执行中如何控制成本?

A:关于评估成本和报价,其实它真的不是敏捷解决来的,而更多的是依赖于整个的环境。 @养猫的-铲屎官

Q7:敏捷开发过程,如何做详细设计呢?  @戴小冬

A:详细设计和概要设计一般都是PM 或者项目管理里的概念。敏捷跟设计详细流程实际上是没有关系的,它更多强调的是让大家互相形成一个高效沟通的模式,它并不依赖于详细的文档。用户想要的东西更多是在迭代过程当中慢慢形成的,这个过程一直是变化的。