基于GitHub的敏捷学习方法之道与术

首先,让我们从需求出发,从市面上来寻找一款符合敏捷的学习软件,别想了,当然是没有的。对于一名程序猿来说,最理想的答案其实就是 GitHub,作为全球最大的程序猿(交友)网站,GitHub 本身以及围绕 GitHub 的各种插件使得其项目管理能力远比你所能想象的厉害得多。

持续行动,持续反思,持续进步。—— via. 敏捷学习宣言

前言

对时间的敬畏

需要好多年才能懂得,最好不是去震惊世界,而是要像易卜生所说的,生活在世界上。

我们都一样,渴望着建树功勋、改变世界。可是伴随着年岁的增长,却发现梦想仍旧遥远,而时间却依然残酷的流逝着,不会仅仅因为「你」而发生丝毫的改变。如《奇特的一生》当中所言,我对时间始终充满着敬畏之心,最好的方式也不过是奢求时间能够跟自己做朋友,伴随着我这也许注定朴实无华的一生,共同成长。

在我们一生所能做的事情里,睡眠占去 1/3,此生只剩 2/3,除去非做不可的基本生活维护成本之外,剩下的时间要么选择浪费而荒度此生,要么瞄准目标而奋力向前,让这一生不留遗憾。Follow your heart,你需要找到一些愿意为其付诸终身的「目标」,以这样的姿态「生活在这世界上」。

敏捷与个人成长

就像软件开发一样,一个人的成长也应该有自己的方法论。人的一生若是顺风顺水、一成不变,那未免太无趣了,正是由于世界的未知在等着我们去探索,不一样的经历才会让人感到惊喜和有趣。想做的事情永远都不会嫌多,就像柳比歇夫最开始是研究生物学的,却在科学的道路上越走越远,进而研究起了数学、物理、哲学,甚至于美学,而更关键的是,他在每一方面都做出了很大贡献并且留下了诸多著作。

时间充当着 Product Owner 的角色在不断向你提出各种各样的需求,敏捷当中最重要的一大前提就是「拥抱变化」,而在「记录时间这件小事儿」里面我提到的GTD流程便可以用于处理这源源不断的需求,即收集、整理、执行、回顾,对应到敏捷当中的几大会议,显然也可以由个人完成,自己就是自己的 IM & PM,当然也是 BA & Dev & QA(当然不用担心人格分裂)。

实践之术

我都没想到怎么写着写着就把开头写成了鸡汤文。但是咧,如果前面讲的是「道」,那么接下来就会具体到基于 GitHub 的「术」,即各种实践。

首先,让我们从需求出发,从市面上来寻找一款符合敏捷的学习软件,别想了,当然是没有的。对于一名程序猿来说,最理想的答案其实就是 GitHub,作为全球最大的程序猿(交友)网站,GitHub 本身以及围绕 GitHub 的各种插件使得其项目管理能力远比你所能想象的厉害得多。

  • 收集:需求无时无刻,无处不在,anywhere anytime
  • 整理:as BA,即分析,Elaboration & Estimation & IPM => 确定 MVP & Efforts
  • 执行:as Dev & QA,Developing & Testing & Review/Sign-Off
  • 回顾:Retrospection,Introspection,持续反思,持续进步…

通过 GitHub Issues 收集需求

首先你可以给自己建一个 GitHub 仓库作为主页,比如我的 JimmyLv/jimmylv.github.io: Agile Learning based on GitHub issues ,最开始就是从个人博客的主仓库发展而来。那么,如何快速收纳自己的想法呢?以解决问题为导向,就是有什么需求就直接给自己的 repo 建一个 issue 作为 Story Card,了却这个需求的最终形态就是 close 掉这个 Issue,比如我要写这篇文章就始于这个 issue:基于 GitHub 的敏捷学习方法总结 · Issue #36

GitHub issues 的进阶用法

与此同时,新建 issue 还有更高级的用法,也就是通过 ISSUE_TEMPLATE 这样一个模板来新建某个 issue,从而更快地定位问题所在和解析自己的想法,最主要的是能够输出更具体的 TODOs,即下一步行动的具体内容,这个还会在后面详细解释。

  • issue 和 issue 之间是可以通过 # 相互连接,甚至可以跨仓库,被 reference 的 issue 也会出现在另外一边的 issue 里面;
  • 而通过 #! 符号是可以在 comments 里面直接新建一个 issue ,这在思维爆炸的时候来得特别爽快;
  • 你还可以随意艾特你的小伙伴们,互相监督、互相学习或者给出 Constructive Feedback 之类的,😂;
  • 更甚至于,若是在 Intellij 里面关联了 GitHub,就可以在 git commit 信息里面直接看到你所要关联的 issues 列表了。

这种方式仿佛学习中的大脑,神经网络被连通了的感觉。

移动端的解决方案

而在移动端则可以通过 GitDo 这个 App 来轻松新建和管理自己的 Issues,没错,就是有人把 GitHub issues 做成了一个 Todos 类 App,还做得很漂亮功能很完善。只是不知为何这软件最近被下架了,伤感,我就又重新把滴答清单(TickTick)作为自己的万能收集箱了,之后再把比较重要的、需要进一步追踪的事项添加到 GitHub issues 里面来。

整理你的 GitHub Issues

大胆地把 issues 作为你的个人需求列表吧,需要解决的问题可以大到做一个开源项目,或者小到读一本书、写一篇文章。对于比较大的需求,你还可以将其转化为 Epic 然后把拆分过后的小 issues 们加入到这个列表里面来。

而 GitHub (with ZenHub) 强大的 issues 管理能力绝对会让你的迭代工作变得井井有条,使用 GitHub 新出的 Projects 特性或者使用 ZenHub 的 Boards 就可以让你瞬间拥有日常敏捷工作的感觉了吧!

计划与执行具体任务

制定迭代计划

首先,让我们新建一个 Milestone 来制定计划,也就是决定在一个 Iteration 里面你需要完成哪些 issues。在这里我所制定的阶段性计划周期为一个月,当然你也可以勤快一点,以2周作为一个 Iteration,享受一下自己的计划要完成不了、这个 Milestone 就要废了,没法向「时间」这个一生的朋友交付所有需求的快感吧 :)

当然咯,一般我会在月初做计划的时候给自己准备专门的时间来做 Elaboration,把 Backlog 里面的卡拖到 Rethink/Plan 这一列,经过分析和详细输出 TODOs 以及所对应的估点 points 之后便可以将其拖到 Ready For Todo 了,一般我给自己估的点数就是完成这件事情所需要的时间,一小时即对应一个 point。

这样你就可以愉快的选择 Filter Issues by Milestone 专注于当前 Iteration,专注于 In Progress 这一列所要做的事情,并且垂涎于 Ready For Todo 里面将要做的事情,每次做完还可以放到 Review/SignOff,在里面写写对这件事情的总结和感想什么的,每次挪卡都充满了敏捷的仪式感(认真脸)。

进度的把控

GitHub 在 issues 里面直接集成了 Markdown 的 TODO 语法,甚至于可以在渲染过后直接拖动某个 item 进行排序,而且可以在前面的勾选项中直接打勾 ☑️ 标记为完成。不仅如此,完成之后这个 issue 还能直接显示完成进度;前面所提到的 Epic 也能直接显示子 issues 的完成情况即 closed 比例,两者结合起来简直不能再美好。

比如说拿来作为读书列表的记录就很不错,每本书作为一个 issue,还可以把章节划分为具体的 TODOs,结合估点追踪自己看书的进度和速度,顺便在 comments 底下做个笔记也不错啊!

专注当下

ZenHub 还提供了一个基于 GitHub Issues 的 To do List,你可以只关注 Today 这一个列表,专心于当前要完成的任务。而且更有趣的是这个 list 可以加入 GitHub 的任何 issues,也就是说它是全局的,所以你可以加入很多在 GitHub 上通过 issues 写的 blog,比如徐飞的这篇文章流动的数据——使用 RxJS 构造复杂单页应用的数据逻辑 · Issue #38 · xufei/blog,被我加入到了 Reading列表当中。

与此同时我还会使用 Toggl 来记录每个 issue 具体实施的时间,以便于在时间花费上能够获得及时的反馈。这样做会让你真切地感受到时间的流逝,而在回顾记录的时候也能够进行总结分析,从而在下一次的计划当中更精确地预估时间(点数)。比方说这篇文章我估了 5 个点现在已经写了 4.5 hours 了,不过这是另外一个大话题,可以参考 记录时间这件小事儿 这个 issue。

迭代回顾与总结分析

ZenHub 也提供了 Burndown 和 Velocity tracking 图,可以得出这个迭代总体的完成情况,看看跟预期有何不同;也可以跟其他迭代进行对比,看看有何不同的地方,然后进行下一步的具体分析。

还可以根据 GitHub 和 Toggl 里面的数据进行汇总和分析,下面这个表格就是我在 11 月这个迭代完成后一部分 issues 的具体 Estimation Points 和 Time Efforts,再结合 issues 里面所记录下的各种笔记和 references,来得到一个比较直观的总结和复盘。

Number & Description Estimation Points Time Efforts
#85 记录时间这件小事儿 3 04:26:18
#96 如何对时间进行分类? 8 03:00:09
#102 建立个人 Wiki 系统 2 02:53:56
#101 技术雷达宣讲:enzyme 测试框架 5 06:11:19
#90 Working time improvement 1 33:27 min
#97 如何使用 XX 的标签系统? 1 25:21 min
其他辅助工具
  • 看板:as Jira/Trello,可视化当前进度 => GitHub Issues group by @Projects / 日历 in @滴答清单;如果你不想用 ZenHub ,可以试试 Gitlo ,可以在 GitHub issues 和 Trello 之间进行双向同步。
  • 晨间日记/每日回顾:as Stand-Up,只用关注 Timeline/Done/Todo/Blocker 以及当天的心情/天气等等,使用 @格志日记的一个特点就是可以通过问答的方式对一天进行回顾。
  • 时间记录:@时间块的优点在于记录起来非常简单、快捷,是用户评论中最省时间的时间记录工具,没有之一,推荐新手试试。但由于个人需要更加详细的记录细节和报告分析,以及多平台(包括 Chrome Extension)的支持,从而选择了 @Toggl
  • 白噪声:作为一款时间记录工具,@Toggl 本身就支持 Pomodoro 的 25 分钟提示。而作为专注力辅助的白噪声软件我在手机上用的 @潮汐,电脑上则选择了 @Noizio

后话

也许你很喜欢这个解决方案但又不太想公开自己的 issues 列表,那可以试试 GitHub 的 private repo(需要付费),免费的可以试试 GitLab,支持从 GitHub 一键导入,并且已经原生支持了 pipeline 和看板功能。当然,不限于工具或软件,这一套方法论其实是可以运用在任何地方的,甚至于我们可以来做一个结合敏捷方法论的个人学习管理软件也不错。

但是于我而言,选择在 GitHub 这样一个公开环境下记录学习的最大一个动机就在于「开源」,很喜欢一句话,大意是「在这个互联网时代,能限制住学习的只有你的求知欲」。

当你从互联网这个广阔的知识海洋当中汲取知识时,也应当有所输出,即反哺到整个互联网当中去。我会经常写博客/笔记来总结、分享自己的所学,但是一篇文章诞生的背后往往还有很多其他知识和经验的相互交融与沉淀。Issues · JimmyLv/jimmylv.github.io 这个列表里面的某个 issues 最终能否演变成一篇文章我不知道,但是基于 GitHub 开放式的学习历程都会被这些 issues 如实地记录着,任何一个想法都能追本溯源被找出最开始的缘由。

相比于软件开发这件小事儿,健康快乐地成长显然要重要得多。—— 立青


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

Share

企业敏捷转型道路

敏捷就是响应变化。敏捷的落地也必须敏捷,也必须按照实际情况而演进,所以企业必须明确自己的步伐和节奏。经过以上的实践积木化,就能够有一个相对灵活的路标。希望通过以上的积木识别,协助你的企业走向敏捷。

很多企业已经走在敏捷转型的路上,首先始于电信和互联网公司,然后是金融行业,现在连零售这样的传统行业都在尝试转向敏捷。

从2001年敏捷宣言宣布到现在,已经有将近十五年的历史。十五年,在我们这个变化迅速的软件工程行业已经是一个非常悠久的时期了。敏捷并不是什么新玩意,而已经成为我们行业主流的管理运营体系。

如果一个企业还没开始拥抱敏捷思想并付诸实践,那它很快要就out了!原因很简单,为了快速响应市场需求的变化,企业采用和拥抱一些敏捷的方法和思维是必须的。

走向敏捷并不表示完全放弃目前的工作方式。很多企业可能会觉得目前的运营有敏捷所不具备的优势,但在这个快速变化的时代中,持续改进已经成为必然,敏捷有很多成熟可操作、可落地的改进方法是完全可以被拿来借鉴的。如果一个企业对现有的工作方式太执着,结果必然是逐渐边缘化,直到被市场淘汰。

1-mind

十年前,很多企业对敏捷有所怀疑,说敏捷不成熟。但如今形势恰恰相反,一个还没有拥抱敏捷的企业会怀疑自己到底出了什么问题,为何不愿意敏捷、为何敏捷不起来。

在2007年,每当我介绍敏捷,都一定会跟瀑布模式做个比较,解释敏捷的好处。眼下我再给企业介绍敏捷时,已经不谈瀑布了,大家都知道敏捷的好处,解释也变得多余。我遇到的问题大多是如何让敏捷落地,如何把敏捷带给整个企业。

企业痛点在哪?

即使敏捷已经是主流了,一个企业也不应该为了敏捷而敏捷。敏捷是要解决具体问题的。企业具体问题在哪?有哪些痛点?涉及哪些方面?这些问题应该从组织结构开始梳理。

图1展示了一个典型的企业组织结构。上层负责指定方向,规划、预算、决策、治理和激励。在执行层面会有业务部门直接与用户对口。用户的请求和期望由业务代表来收集。如果组织有复杂的系统应用组合,往往会有一个解决方案部门,负责整理需求传达给开发和测试。开发测试交付的软件系统由运维部门来运营和支撑。

我咨询过的很多企业,从互联网企业、传统企业、到嵌入式产品厂商等,他们的组织结构大概就如图1。

1

图1 典型企业组织结构

虽然图1是一个高度抽象的组织结构展示,但它有益于让我们在讨论企业痛点时找到具体聚焦的主体:是业务侧,还是解决方案侧;是开发测试侧,还是运维侧,亦或是决策层的问题?

企业的痛点一般是如何让各部门端到端的更好协作,那么具体痛点在哪?瓶颈在哪?具体哪些部门必须更加敏捷灵活的运作来响应市场变化?

小范围的尝试、小范围的效果

很多企业在尝试敏捷的初期往往都会从一个小范围开启,大部份会从开发测试小团队开始。小团队的敏捷方法和理论非常成熟,比方说Scrum的小团队迭代运作,极限编程(Extreme Programming)的用户故事(User Story),持续集成(Continuous Integration),看板(Kanban)等。

2

图2 小范围的尝试,小范围的效果

小团队敏捷运作的方法和理论是很成熟的。有能力让小团队敏捷落地的教练和资源也很多。

  • 如果企业的应用都是十人以下小团队能够完成的,那么实施Scrum和XP就会获得一些效果。但如果只停留在小范围的尝试,必然只有小范围的效果。
  • 如果企业有比较复杂的系统,开发团队上百人的话,那Scrum和XP就远远不够了。

不管企业团队大小,如果企业敏捷落地只限于开发测试这一侧,没有执行层端到端的考虑,以及和企业上下对齐的思维,就不能发挥敏捷的潜能,就失去了获取更大效益的可能。

没有组织层面的支持,小团队的良好效果也不容易持续,反而很容易倒退。组织一旦想踏上敏捷的道路,就必须要有决心,必须要有长远的目标,必须考虑企业的整体敏捷转型。

大型企业的挑战

除了小团队必须敏捷之外,一个拥有大型开发团队的企业还必须解决一系列的问题。我与许多上千人企业的管理者和工作者交流他们面临的挑战,做了一个总结(看图 3):

3

图3 大型企业的挑战

这些企业面临的挑战包括:

  • 端到端的敏捷:如何让执行层端到端的运作更加顺畅稳定?包括前端的需求管理和后端的运维协同。前端的业务代表往往非常希望需求能够快速上线,而后端运维则希望系统稳定,能不变是最好的。在这样的矛盾中,大型组织必须思考如何建立一个快速又稳定的开发通道。
  • 跨团队协作敏捷:团队之间和项目之间如何协作得更好?每个小团队都有他们的目标和工作量,团队之间的工作计划如何更好的对齐,减少协作的成本和不必要的等待或者冲突?我经常观察到由于团队之间冲突导致工作中不必要的拖延,浪费了时间非常可惜。
  • 用户互动敏捷:如何更好得贴近用户聆听他们的需求?业界调查显示,大部份开发后的功能都没人关注,甚至没人用。用户对这些功能觉得无所谓,没太大的感觉。如何更有效的理解“用户真正想要什么”是一个挑战,企业要考虑如何让整个组织具备这样的共情能力。
  • 人力敏捷:个人能力是非常重要的。在一个大的企业里,人员能力参差不齐,如何提高各个层面人员的能力,让他们学会自我管理,是企业必须解决的问题。如果能够达到这一点,就会减少很多的管理成本。
  • 战略治理敏捷:执行层面运作如何有效的与决策层面结合?决策层的举措如何有效的落地到执行层面?执行层面遇到市场机会时如何有效反馈到规划层面从而指导方向调整?
  • 文化敏捷:敏捷以人为本。一个大型企业由于人数众多,很容易忽略个人特别是基层的战士。我们这个行业有“屌丝”和“码农”这种说法,说明对基层不够重视的情况长期存在。事实上他们也很有想法,有改进的意愿。如何激励他们,发挥他们的价值和协助他们成长是企业文化建设中必须考虑的。

当企业在考虑以上的挑战时,会发现小团队敏捷运作的实践,已经不是企业敏捷转型所关注的重点了。小团队有效的运作仅仅是个基础,企业需要的是整个组织的战略和布局。就像一名将军或总司令,看的是整个战场,不只是一兵一卒,看问题需要更加宏观。

大型企业敏捷实践

要解决一个大型组织面临的挑战,办法不是没有的。敏捷方法也在持续的演进中,从开始仅仅解决开发侧的问题,到如今已经延伸到整个组织的运营体系中。目前,业界所强调的已经不是团队的敏捷(Team Agility),而是产品端到端的敏捷(Product Agility),以及整个企业的敏捷(Enterprise Agility)。

4

图4 大型组织的敏捷实践

敏捷方法和理论有丰富的实践(Practice)和经验总结。这几年来,我花了不少时间总结这实践。在企业内,除了小团队敏捷Scrum和XP之外,还必须引入许多方法和实践(见图 4)。

  • Super Scrum:不仅小团队需要Scrum,Super Scrum拔高了一个层次,指导跨团队和项目的运作。
  • 前端协同和后端协同:当然也必须有前端和后端的敏捷。前端敏捷包括敏捷的需求管理,有效的概念过滤,需求的ROI排序,尊重开发侧的能力和容量而不强压需求。后端除了稳定上线之外,避免上线的风险,提供运营的反馈。
  • 一个产品的演进是经过很多市场需求积累的。如果需求的实现没有标准化,代码和架构很快就会腐烂。标准化不仅仅能够提高软件本身的质量,也能够提高开发的效率。有了标准,各职责都知道要做什么,实现起来简单,评估也简单。
  • 贴近客户包括与客户进行有效的接触和快速反馈,还借鉴用户行为分析,构建用户的同理心,有效挖掘客户和用户的痛点,形成明确的产品定位。
  • 质量不仅仅需要后端的测试和验证,更重要的是如何进行更有效的设计。这包括产品设计、业务设计、系统设计和不可缺少的代码设计。这些设计能力,必须融入到各成员的习惯中。
  • 大型企业必须要有针对每个个体的回顾和反馈体系。这不是一件容易的事,企业不仅仅需要时刻聆听用户,也必须有效地聆听每个成员的心声。一个团队开心就会积极,一个团队积极,什么问题都能解决。
  • 以上的实践必须有一个改进工作组来落地。这个工作组必须具备分析、说服、探索、尝试、总结等能力,改进也必须有章法。

每个实践是解决企业运营上某个问题的一种方案。每个实践(Practice)有具体的操作指导,还有交付对象、交付物、职责、活动、模式等定义,这样能够方便学习和落地。建立实践的架构也应该有方法。

大型企业敏捷转型路标

一个大型企业不是说变就变的,需要一步一步来,首先选择一些基础的实践来落地,然后逐渐延伸到整个企业的运营。图 5显示了一个可参考的大型企业的敏捷转型路标。

5

图5 大型企业敏捷转型路标(共参考)

图5的横轴代表时间。从企业当前的运营来看,可以首先让开发测试团队内部运作,通过Scrum或XP的实践,让团队先养成敏捷运作的习惯,然后是整个执行层端到端的敏捷运作,再延伸到上层的战略治理和基层的大规模回顾与激励,确保改进能够持续。

有一个敏捷转型路标非常重要,这是企业踏上敏捷转型的关键步骤!在这条走向敏捷的道路上,企业必须一开始就明确改进工作组,来协商制定这个路标。有了路标,就能给各参与者一个统一的方针,管理他们的期望,从而推动企业敏捷实践落地的方向和计划,进而有助于衡量进展和效果。 敏捷就是响应变化。敏捷的落地也必须敏捷,也必须按照实际情况而演进,所以企业必须明确自己的步伐和节奏。经过以上的实践积木化,就能够有一个相对灵活的路标。希望通过以上的积木识别,协助你的企业走向敏捷。

Share

以敏捷的方式运作一所大学

2001年,敏捷宣言在美国犹他州瓦萨奇山雪鸟滑雪胜地横空出世。时至今日,敏捷软件开发流程早已经深入人心。ThoughtWorks作为敏捷实践的翘楚,一直不遗余力的向行业推广敏捷。而ThoughtWorks自身不仅在所有项目中都使用敏捷,甚至对毕业生的培养都是敏捷的。

2001年,敏捷宣言在美国犹他州瓦萨奇山雪鸟滑雪胜地横空出世。时至今日,敏捷软件开发流程早已经深入人心。ThoughtWorks作为敏捷实践的翘楚,一直不遗余力的向行业推广敏捷。而ThoughtWorks自身不仅在所有项目中都使用敏捷,甚至对毕业生的培养都是敏捷的。

1-agile-manifesto

在印度浦那有着一所很神秘的大学,叫做ThoughtWorks Univesity,简称“TWU”。每个加入ThoughtWorks的毕业生,都要接受在TWU为期5周的洗礼。笔者于2016年以讲师的身份,参加了两期ThoughtWorks University。整个经历真的是一趟奇妙的旅程,收获颇丰。在这个教授敏捷的大学,我领略到了如何以敏捷的方式来运作一所大学。

敏捷的两个先决条件

《Practices of An Agile Developer》一书讲到,一个项目适不适合敏捷有两个先决条件:第一点是项目是否以价值为导向,第二点是团队是否能够达到高度协作。

2-team

第一点也就是说整个团队有一个总体一致的目标。TWU拥有明确的目标,一切都是围绕着培养毕业生的四个方面:Customer Serivce Mindset & Skills(客户服务意识和技能), Business Understanding(ThoughtWorks业务理解), Culture/Way of Life(文化及生活方式), Global & Social Experience(国际经验及社会责任)。

只有打造一个相对扁平的组织,给予充分的信任和自由度,才有利于敏捷的实施。这反过来又要求团队中的每个人有高度的自律性。

TWU的团队主要分为核心团队和讲师团队。核心团队统筹管理所有的TWU活动,确保所有的课程和活动都是围绕着TWU的目标开展。而讲师团队则是由全球各个办公室的员工抽调而来,负责具体实施这些活动。整个TWU团队都是完全扁平的架构,没有上下级的关系。

第二点是说必须能够保证团队中的成员能够流畅的交流。我们那期的讲师来自8个国家:中国、马来西亚、澳洲、美国、印度、巴西、英国、德国。这样的国际化战队能够在组建之后立马投入运作的最大原因就是每个人在ThoughtWorks学到的深入骨髓的合作理念。TWU的核心团队和讲师团队每周都有固定的时间碰头,讨论遇到的问题并商讨解决之道。每天早上TWU的讲师也有固定时间站会,更新各自的状态。下午也有碰头会,讨论当天的工作内容、遇到的问题,并提出行动来解决。

这两个先决条件在TWU完全符合。

敏捷的基础是反馈

《Practices of An Agile Developer》中讲到敏捷的基础就是反馈。如果别人能及时指出你走错了路,那么你就会少走点弯路。只有不断的接受反馈并付出行动,才会不断的提高。反馈也是双向的,不仅自己要接受反馈,也需要主动给同事反馈。

3-feedback

在TWU,首当其冲要接受来自核心团队和讲师的反馈。每周我们有个很独特的活动,叫做Speedback Session。在这个活动上所有的讲师会进行一对一的4分钟的谈话,相互给予反馈。这种开诚布公的行为把大家都团结到了一起。

而在每期TWU的前两周,新讲师会对课程进行试讲,这是获取其他讲师反馈的好时机。笔者本人收到了很多反馈,比如说我的语速很合适、声音洪亮等,也有鞭策我提高的反馈,比如我的引导力能力不强,有的时候课堂感染力不够等。

讲师要给学生讲课,及时收集学生的反馈也相当重要。TWU团队在每个教室都专门制作了一面反馈墙,每次讲师讲完课后都会提醒学生通过贴纸的方式留下对本堂课的反馈。从这些反馈中我找到了自己的一些问题,比如有的学生说我的口音有点重,对一些技术词汇解释的不是很清楚。这会促使我下次讲课时注意解决这些问题。同时我也收到了很多鼓舞,因为很多同学都留言说学到了很多有用的新东西,很感谢我的付出。

正是这种良好的反馈文化让我在短时间内意识到了很多不足之处,也明确了改进的方向。它能使你每天都正面面对工作和生活,每天都能保持提升自己。

敏捷的精髓是拥抱变化

《Practices of An Agile Developer》一书中讲到敏捷的精髓就是拥抱变化。TWU每一期的学生来自不同的国家和地区,各自拥有完全不同的经历。这就要求我们在短短几天内充分了解团队中的学生,并且对课程进行相应的调整。

4-change

比如有一次我们要求学生团队进行一次软件发布活动,而当时他们还没有学习功能开关(Feature Toggle),正在思考如何实现只发布想要的功能,而屏蔽掉其他正在开发中的功能。为了能让他们自行思考发布策略,我们特意把介绍发布策略的课程往后挪了一天。

我们不仅会调整课程的安排,对于课程的内容我们也会经常更新。比如有一节教授HTML和CSS的课程,我们对课程进行了大幅改动,删除了一些过时的内容,加上了一些通用的最佳实践。这样的改动能够保证TWU所有教授的内容都能赶得上IT领域日新月异的变化。相比起国内大学有些课程还在使用几十年前的教材,而我们的有些课程可能每半年就会全部更新一次。

一些重大的改动会被放到一年一度的TWU年度升级中进行处理。在年度升级中我们有两个月的时间对TWU的关键活动做升级。比如今年就将TWU使用的整个技术栈全部迁移到了AWS平台,实现能够一键式创建和删除整个学期需要的资源。

TWU在课程的设置方面一直紧跟市场的变化。ThoughtWorks最近不断接收一些关于UX和XD的业务,而TWU当时并没有专门针对UX和XD的培训内容。但是短短三个月的时间TWU一群卓越的同事就创建了相关的课程,并迎来了第一批UX和XD的毕业生。

最后

在TWU当讲师的几个月,笔者一直感觉这个大学是一个充满活力的大学。在这个大学里面,没有权威,没有各种条条框框,整个团队有一股极强的凝聚力,每个人是TWU的主人。运作一所大学不易,但如果能坚持做到持续反馈、拥抱变化的话,这所大学将始终是一所紧追时代步伐的大学。

Share

让安全实践在敏捷团队落地

很幸运地,我有机会在一个成熟的敏捷开发交付小组中经历了“从完全没有安全实践到BSI”的过程,我们也曾遇到过很多困难,但最终得到了客户的认可,并成功把安全实践推广到了整个团队,所以想跟大家分享一下我们是如何将安全在敏捷团队落地的,希望能给大家一些帮助。文中会拿Web系统举例,但一些落地的实践同样适用于非Web系统。

随着安全得到越来越多的关注,一些跟安全相关的理论(比如BSI)脱颖而出,尽管这些理论提出来已经有一段时间,却很少看到其在开发团队被成功地应用。我们知道微软曾在十多年前就提出了SDL,却没能在业界推广开来,并不是人们不认可微软这种“从软件生命周期保障安全”的理念,而是考虑到其落地实施的难度,很多企业知难而退,那么这些安全理论对我们的软件安全真的有帮助吗?安全实践能落地吗?

很幸运地,我有机会在一个成熟的敏捷开发交付小组中经历了“从完全没有安全实践到BSI”的过程,我们也曾遇到过很多困难,但最终得到了客户的认可,并成功把安全实践推广到了整个团队,所以想跟大家分享一下我们是如何将安全在敏捷团队落地的,希望能给大家一些帮助。文中会拿Web系统举例,但一些落地的实践同样适用于非Web系统。

为什么安全理论很难落地?

结合对一些团队的了解,原因大多来自以下三个方面:

  1. 认为安全不重要
  2. 认为安全太难,需要很广很深的领域知识,只有专业人员才能做到
  3. 不知道应该用什么样的流程来做安全

那么针对第一点,因为我本身也是交付团队的一员,我观察到的大多数软件开发团队,不管是业务分析师、开发人员、测试人员、体验设计师还是项目经理,都很少有人真正把“安全”作为非常重要的一件事情,尤其是在交付压力比较大的情况下,我们都会舍弃对于安全的投入,而花时间在更容易可视化出来的用户功能上。安全,很多时候就像灭火器,如果不发生火灾,我们甚至都感觉不到它的存在。那么,安全,真的重要吗?

换位思考一下,如果我们是用户,面对以下两种选择,我们会选择哪一种?

  • 系统A:设计非常完美,功能缺陷几乎没有,性能也很棒,但是没有做任何跟安全相关的防护,用户的敏感信息很容易泄露;
  • 系统B:设计比较差,有一些功能缺陷,性能也差一点点,但是采取了特别多的安全措施,能够保障用户的数据安全性;

相信几乎所有人都会毫不犹豫选择B系统,除非这是一个完全没有用户敏感数据、完全不需要安全保障的系统(那这样的系统又有什么用?),所以只要我们把自己放在产品使用者的角度,而不是产品制造者的角度,就能很容易地理解和认可安全对于软件系统来说是比功能更重要的一个因素,安全是软件的灵魂。

那么对于很多已经深刻认识到安全重要性的团队,为什么依然很难将安全理论落地呢?原因大多来自前面提到的第二点和第三点,一是从技术上认为安全是一个很难的领域,需要专业的安全人士;二是从流程上不知道该如何开展;从这两个角度出发,“安全”需要巨大的投入,所以很多团队望而却步。那么安全真的这么难落地吗? 接下来我会简单介绍一些Web安全知识,然后通过我所在团队的落地过程给大家一个答案。

如何让安全在敏捷团队落地

什么是Web安全?

所谓Web安全问题,就是攻击者可以通过非正常的手段,获得Web系统访问权限,从而破坏网站行为,盗取甚至修改用户数据的一系列问题。

那么为什么攻击者可以获得Web系统权限呢?这种几率到底有多大呢?如果可能性非常小,我们是不是不必花费太多精力在安全上面呢?

我们来看一下Web系统的组成,一个最简单的系统都至少有这么几个部分:

如上图,浏览器发送请求到服务器,服务器给浏览器响应,服务器会查询数据库,数据库返回结果。在这个过程中,我们开发的Web程序不可避免的存在安全漏洞,甚至我们开发系统所使用的编程语言也会有安全问题。在开发时,我们常常会引用一些第三方的工具、组件,而第三方的安全性也没有办法保障,甚至数据传输过程中使用的协议、操作系统本身也会有安全问题。所以可以想象一下,如果我们不做任何的安全防范,那么每一个软件都是一个非常脆弱的系统,很容易出现安全问题。

常见的Web安全问题

既然这么多环节都有潜在的安全风险,那么该如何着手呢?可以参考OWASP TOP 10,以便对最严重的Web应用程序安全问题有个大致的了解。

敏捷开发模式现状

我们是一个已经实施敏捷开发七年的团队,一共有五十多人,划分成不同的Feature小组进行日常的工作,其敏捷开发模式已经非常成熟,我所在的Feature小组有6个开发人员,1个业务分析师,1个QA,我们每个小组的交付模式都是这样的:

如上图,以用户故事为单元,所有的用户故事都会经历一个从分析到最后给客户演示的生命周期,多个用户故事组成一个Feature,然后我们会进行Feature的功能测试,给客户展示整个功能,最后在发布之前,客户会邀请第三方的专业安全公司做渗透测试,然后找我们的开发团队修复安全缺陷。

那么这种方式有什么问题呢?

  1. 守门员模式,安全测试非常滞后
  2. 安全问题的修复时间非常有限
  3. 只有少数人关注和了解安全
  4. 依赖独立的渗透测试

所谓守门员模式,指的就是把所有的问题和风险都留在最后,靠少数人来保障,在当时的开发模式下,第三方的安全公司就是我们系统的安全守门员,可想而知,如果我们的团队对安全没有任何了解,在用户故事的开发阶段引入的安全问题要等到发布之前才能够被发现,安全测试是非常滞后的,反馈周期特别长。

另外当第三方的安全公司发现问题,留给我们团队修复问题的时间特别有限,因为渗透测试是发布前的最后一个阶段,长时间的修复又会导致发布延期,所以经常会导致安全修复以补丁的方式发布。

而且除了少数修复过安全缺陷的开发人员对安全有一点点了解之外,团队内是没有人关心安全的。

最大的问题是,所有的安全防范都依赖于最后的独立渗透测试。虽然因为执行渗透测试的是专业的第三方安全公司,他们有专业的安全知识,可以发现很多公共的安全问题,也可以提供专业的极具权威性的安全报告,但这种方式的渗透测试有个致命的弱点,他们对业务知识了解不够,很难发现跟业务相关的安全问题,而这一类的安全问题又占了相当大的比重。

可以看到,这种敏捷开发模式的现状就是:试图将安全注入一个已经成型的系统中。

安全落地尝试

那么了解了之前开发模式存在的问题,安全又这么重要,客户和团队都希望可以改变这种现状,提高安全质量,减少补丁,让每一个人都关心安全,但是我们都担心安全需要巨大的投入,会影响功能的发布,所以我们决定选择一个Feature小组做为安全试点,目标周期为一个月(我们的发布周期),观察投入产出比,然后决定是否要在整个团队实行。

首先我们小组开始学习BSI,我们认为它所传递的是这样一些理念:

  1. 将安全融入整个软件开发过程中
  2. 所有团队成员一起为安全负责
  3. 安全的设计和实施一个持续进行的过程

那么在一个几乎没有安全知识储备的团队中,如何将以上理念在团队应用呢?我们遇到了很多的困难,比如:

  1. 不知道怎么把安全和日常开发结合起来
  2. 不知道如何编写安全需求,怎么做安全测试
  3. 接受了很多安全培训,不知道如何下手
  4. 对安全缺乏专业的认知,对安全开发和测试没有信心
  5. 不知道如何满足客户期望

分析这些困难,我们开始迈出了艰难的第一步。

首先,召集团队的核心成员(包括了业务分析师,开发人员,测试人员,技术主管),同时我们邀请了公司的一位安全专家帮我们解答难题,大家头脑风暴,参考OWASP TOP 10, 结合曾经项目上出现过的安全问题以及对于业务领域的深入了解,尝试总结属于我们自己的安全问题项目并且和OWASP TOP 10进行关联,比如我们讨论后的成果是这样的:

可以看到,我们总结出来的这十项并不是将OWASP TOP 10调换顺序这么简单,我们是针对业务需求,有针对性地进行了重新整理和组织,比如其中的Sensitive Data Exposure,我们就结合项目将它划分成了四类(1.Authentication,2.Error Handling,3.Code Leak,4.Cookie Management),之所以会划分的这么具体,是因为我们自己的TOP10更贴近实现。另外我们还针对每一项添加了项目上的例子作为参考,让团队每一个人都清楚地知道我们自己的TOP 10都是什么样的以及业务场景下可能出现的安全问题。

然后我们将项目专属TOP 10作为模板加入到了每个用户故事中,这么做有两个好处:

  • 第一,业务分析师在写用户故事的时候,可以将其作为参考来编写安全验收标准;
  • 第二,如果业务分析师在缺乏安全知识的情况下很难编写安全需求,我们可以将其直接作为安全需求以防遗漏。

当然这还远远不够,更理想的情况是在需求分析阶段、业务分析师和客户在讨论需求的过程中尽量参考一些基本的原则,比如最小权限原则,来确定和编写更加准确的安全验收标准。如下图。还可以让更多的人参与到需求分析阶段,通过威胁建模等手段分析出更全面的安全需求。当然这就需要我们的业务分析师增加安全相关的知识储备,我们也在向这个方向努力。

然后在用户故事的启动阶段,业务分析师、QA和开发人员会一起针对用户故事模板中我们自己的TOP 10进行筛选,将和用户故事相关的内容标识出来作为安全验收标准。如果在故事分析阶段,业务分析师已经遵循一些原则细化了安全验收标准,在这个阶段,也可以多个角色针对这些安全验收标准进行探讨,确保大家理解一致。

到了用户故事的开发阶段,通常开发人员都会按照验收标准来编写代码和测试,基于我们已经有了足够的安全验收标准,相应地,开发人员也会编码来实现这些安全条件并且添加相应的自动化测试保障,当然,除了满足安全验收标准之外,我们也会做一些静态代码的扫描和第三方依赖的扫描,双重保障。

用户故事的验收阶段非常重要,因为如果在这个阶段发现缺陷可以快速修复,我们一般是QA、开发人员和业务分析师一起,逐个验收我们之前制定的安全验收标准。当然,除了简单地从前端进行验证,针对安全验收我们需要借助一些工具(如Burp Suite),绕过前端修改请求,检查是否后端接口也作了相应的防范,如果发现安全问题,会在这个阶段及时修复并且增加相关的测试保障。

07

到了用户故事的测试阶段,QA会做跟安全相关的探索性测试,在这个阶段,需要QA从一个全新的视角来做测试,之前我们的模式是从正常用户的角度来测试功能,而针对安全的探索性测试则截然不同,我们要用攻击者的角度来思考问题,尝试各种看似不可能的手段,寻找安全漏洞。另外,在这个阶段,我们也会借助一些自动扫描工具(比如ZAP),来检测是否有一些通用的安全问题。

08

安全的演示阶段比较有挑战性,前面提到过,它不像功能需求那么可见,所以我们采用了一种全新的方式去展示,通常功能演示我们是给客户展示用户界面,如何使用系统等,而对于安全,我们尝试了展示安全缺陷以及我们的缺陷分布分析。比如在这一个月里,我们发现了六个安全问题,其中两个是通过ZAP扫描出来的共通的安全问题,另外四个是和业务强相关的安全问题(比如账户A可以通过特殊手段修改其本来没有权限的数据,属于我们自己的TOP 10的Authentication那一类)。

回顾整个过程,其实我们在用户故事的每个阶段都增加了和安全相关的实践,并且让团队所有人员都参与了进去,将安全融入到日常的工作中,不断改进,持续关注,而这些正是BSI所传达的理念。

客户看到我们的安全成果展示后非常满意,进而在我们整个团队开展了这样的安全实践。

在维持这样的安全模式几个发布周期之后,我惊喜地发现我们的开发人员开始有了安全的意识,比如前不久我们有一个用户故事需要实现一个邮件模板,系统要求能够接受用户定制化的html,功能实现非常简单,可是开发人员一筹莫展,接到用户故事后马上找到我,探讨如何让我们的系统允许接受html后还可以避免script攻击,这让我深刻感受到,BSI(Build Security in our DNA)这个理念的精确含义,我们不是为了让大家遵循实践而去实践,而是让每个人都有安全的意识,每当我们接触到一个新的功能,马上会想到可能有哪些安全问题,而不是急于实现功能,长此以往,安全就真的进入了团队的DNA。

总结

回想之前我们想要开始在团队实施安全时的恐惧以及止步不前,到最后我们成功将安全实践落地并且推广,这个过程让我体会到,从一个小组开始尝试,观察投入产出比,再推广到整个大的团队是个很好的实践。

另外,不要期望一步到位、迅速成为安全专家,安全的设计和实施是一个持续进行的过程,可以从日常工作中的点滴做起,从保障每一个安全需求做起,想象一下,如果我们每一个用户故事都注入了和安全相关的实践,那么feature就会是这些安全的用户故事的结合,系统就会变成一个充满安全投入的整体。

和之前“靠最后的渗透测试来补救安全问题”的方式相比,这种从源头就将安全渗透进软件系统的方式更能保障我们软件的安全。


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

Share

敏捷QA,从入门到放弃

做敏捷QA五年多,看到了很多人加入,也看到了很多人放弃。其中有经验丰富的测试人员,也有刚刚步入职场的新人。虽然“从入门到精通”是大多数人选择进入这个行业的初衷,但是敏捷QA一些特有的工作方式和要求,会让很多人不适应或者不喜欢,所以很多时候我们看到的是一个个“从入门到放弃”的过程。

做敏捷QA五年多,看到了很多人加入,也看到了很多人放弃。其中有经验丰富的测试人员,也有刚刚步入职场的新人。虽然“从入门到精通”是大多数人选择进入这个行业的初衷,但是敏捷QA一些特有的工作方式和要求,会让很多人不适应或者不喜欢,所以很多时候我们看到的是一个个“从入门到放弃”的过程。

那么什么样的人应该不要选择或者尽早放弃敏捷QA这条路呢?本文试图给大家提供一些参考。

敏捷QA入门

QA(Quality Assurance)通常指的是质量保障,也有一种说法是质量分析(Quality Analysis),在敏捷软件开发团队中,我们强调所有成员(业务分析师、开发人员、专职QA)为质量负责,所有人参与跟质量相关的活动,所以从宏观意义上来说,人人都是QA,很多文章都有相关的介绍,这儿不再继续探讨。本文提到的敏捷QA,指的是敏捷团队中专职的QA角色,他们的主要职责是主导并促使跟质量相关的活动在团队内发生,包括但不仅限于测试。

敏捷QA的入门阶段除了要有基本的测试知识外,必须要熟悉一些敏捷相关的基本概念以及实践,比如用户故事、迭代、迭代计划、回顾会议等等。敏捷QA几乎会参与整个用户故事的生命周期,从分析,启动,开发,验收,测试到最后的展示,尤其在启动,验收和测试这三个环节发挥着非常重要的作用。

另外,敏捷QA会同时工作在多个迭代当中,在进行当前迭代用户故事的测试验收等活动的同时,也经常需要做前一个迭代的收尾工作以及下一个迭代的准备计划等。

敏捷QA放弃

了解了基本的敏捷QA知识后,我们来看看放弃敏捷QA的四个理由。

  • 不爱说话?别做敏捷QA了

如果你之前是安安静静专心找软件缺陷的工作模式,那么进入敏捷团队你可能会经历很长时间的不适应。

因为敏捷QA不能被动地等待软件完成交到你手里再做测试,不能发现缺陷后不管不顾等着开发人员自发地去修复。你需要从软件的源头开始介入,在软件的整个生命周期中全程参与。

敏捷软件开发强调质量内建,在用户故事的生命周期中,作为质量保障的主要负责人,你需要在每个阶段跟不同的角色反复确认和验证,确保团队对需求理解一致,还要保证跟质量相关的活动发生,比如确保开发人员添加了相关的自动化测试等,所以你需要和团队的每一个成员以及客户有非常多的交流,而最直接有效的方式就是说话,沉默寡言是行不通的。

所以,如果你不喜欢说话,那么Tester也许比敏捷QA更适合你。

1-QA-talkative

  • 心态不好?趁早放弃

不知道你是否经历过这样的场景,在某些小餐厅等位严重的情况下,你需要站在某个快要结束用餐的客人边上等空位,而有些人却可以在用餐结束后无视旁边焦急等待的人群一直占着座位专注地聊天。

虽然这种行为不是很好但也无可厚非,换个角度想,这种人的心理是非常强大的,因为很少有人能够不顾及别人而我行我素。而这种“能力”对敏捷QA是非常有用的,比如在故事验收环节,这个阶段就是业务分析师、开发人员和QA三种角色一起在开发人员的机器上验证用户故事是否被正确地实现。当然任何角色都可以主导这个环节,但效果最好的是由QA来主导,因为可以提前发现缺陷并快速修复。

但是因为这个阶段所有角色都会参与,大家关注点又有所不同,所以心态不好难免就会有各种顾虑,比如,自己会不会太慢了?会不会耽误太多人的时间了?别人会不会很着急?

太多顾虑就会影响你做验收测试,尤其验收阶段的探索性测试。从而使你不能充分发挥QA的作用,而这个环节对于敏捷开发模式下的质量保障来说非常重要,这时候如果具备前面提到的强大的心理素质,就能专注地按照你的想法测试你的场景,当然可以配合一些解释让别的角色了解你的思路,而不是左顾右盼思前想后影响这个阶段的发挥。

所以,如果没有强大的心理素质,也许应该考虑趁早放弃做敏捷QA。

2-strong-heart

  • 对业务、代码没兴趣?敏捷QA不适合你

相信很多人进入测试这个行业,是因为对测试领域的技术和方法论有浓厚的兴趣,但是对于敏捷QA来说,仅仅对测试感兴趣是不够的。

敏捷QA需要对整个系统以及业务足够熟悉,这样才能从QA的视角帮助业务分析师和团队发现业务不合理或者缺失的部分(可以在故事审查或者启动阶段帮团队澄清需求)。

另外如果可以具备一些编码能力,对于做敏捷QA也是非常有帮助的。当然,术业有专攻,并不要求每个QA都会写代码,但是要对代码有一定的兴趣,愿意听开发人员讲解他们的逻辑和实现,并通过提问题了解他们的思路,至少了解他们编写的测试代码。因为在验收阶段,敏捷QA会通过审查开发人员的自动化测试是否合理和全面,来帮助团队建立对自动化的信心。

所以如果对业务、代码没有丝毫兴趣,那么也许敏捷QA不太适合你。

3-QA-content

  • 不会管理工作的优先级?做敏捷QA很难

敏捷QA最大的挑战是,每时每刻都同时工作在很多事情上,我们可以细数一下敏捷QA的活动:当前迭代的故事审查、故事启动、故事验收、故事测试用例准备、部署、缺陷管理、缺陷分析,前一个迭代的故事收尾,后一个迭代的测试计划、故事审查、故事启动等等。

另外敏捷QA希望可以做的更多,比如日志分析、性能监控、安全测试等等。

可以看到,敏捷QA的工作是非常杂乱琐碎的,而且大多活动是和团队中不同成员一起进行的,我听过很多刚刚加入敏捷QA的新人抱怨没有自己思考的时间,忙乱没有目标;也见过很多优秀的测试人员转做敏捷QA后因为不适应这种多线程的工作选择了放弃。确实,在这样一种工作模式下,如果QA不能清晰定义自己工作的优先级,就会被各种杂事牵着鼻子走。

不擅长管理自己的工作任务、不会划分优先级,做敏捷QA会非常难。

4-priority

总结

敏捷QA,不管性格还是心态,都需要足够强大,否则在整个工作过程会非常艰辛;另外仅仅掌握专业的测试技能是不够的,还需要更多地了解业务甚至代码;最后必须能够管理自己工作的优先级,否则会事倍功半。

5-summary

了解了这些方面后,可以认真思考一下,自己是不是真的适合做敏捷QA。如果依然坚持步入这个领域,那么希望我们可以一起从入门到精通。

Share

敏捷教练培养的“守、破、离”

敏捷转型是一个长期的任务,需要一个教练的角色,要关注和推动持续改进。其实我们每个咨询顾问本身也是一个敏捷教练。我想从自己的成长和近些年的一些指导经验,给大家一些启发。

敏捷转型是一个长期的任务,需要一个教练的角色,要关注和推动持续改进。

其实我们每个咨询顾问本身也是一个敏捷教练。我想从自己的成长和近些年的一些指导经验,给大家一些启发。

nqu8ubgmadim5tktxcn1

敏捷教练的定义

首先看看什么是教练。 WiKI上的解释是’who supports a learner in achieving a specific personal or professional goal’

古文:“师者,传道授业解惑者也。”

套用到敏捷教练『通过传达敏捷精神,教授敏捷实践,帮助组织或团队扩大产品业务价值』

为了能达到教练的目标,教练应该具备以下主要能力:积极的客户引导能力,严密的逻辑思维能力,清晰的语言沟通能力。

  • 客户引导能力:团队就是客户,虽然是教练,但是教练的目标是自组织团队,如果过分教授,团队的自组织的能力会变得很慢,有时候甚至会越来越被动。教练更应该采用的方式是引导的方式,通过问问题,实例分析,通过教授学习方法和思维方式,激发团队成员的积极性,来组成团队逐步成为自组织团队。
  • 逻辑思维能力:不同的团队会遇到不同的问题,教练需要不断的思考,举一反三,把以前工作的经验结合当前的问题,再有就是结合敏捷的核心价值观,能够给出经得起推敲的回答。说的不好听一点,没有正确答案,只有逻辑清晰,令人信服的答案。
  • 语言沟通能力:教练最根本的目标是让团队理解,团队进步,不是为了吵架争个输赢。这样就需要具备一些最基本的沟通能力,总结能力,语言表达,演讲等能力。

从教练需要具备的能力来看,敏捷教练需要具备的两个维度的能力,一个是基于敏捷价值观和体系的敏捷知识;另外一半主要是转型,教练,演讲,演讲等软技能。而“实践”又是敏捷价值观的来源,接下来就谈谈教练如何通过“守、破、离”来成长的。

武术中照着姿势做,学毛笔字临摹字帖,学古文背诵范文,其实都是找了个model,先要照着做。

“三人行必有我师焉”。要学人所长,不一定只选择一个导师,而是要是学习导师的擅长领域。从我的成长经历中,也是这样做的,刚开始当项目经理的时候,我把项目群经理的邮件都整理在一个文件夹里,每次给客户发信,都要找出相类似的邮件,照着写。刚开始当内部教练的时候,每次主持会议的时候,就会想想外部教练是如何做的。找个导师的另一个好处是,帮你解惑,当你遇到问题的时候,对方的一句点拨,会比你自己想几天都管用。

没有最好,只有更适合,一定要找适应你自己风格的导师。原来木桶理论希望我们去补短板,现在时代变了,更希望每个人发挥我们的长处,没必要去找个不适合自己风格的导师。但是换另一句话说,即使不适合的导师,只不过稍微痛苦一些,需要调整的比较大。在这个阶段关键是照着做,通过实践来体会背后的价值。

对于教练的要求是,必须找个导师,必须模仿着导师做,但是导师可以自己选。对于团队,如果选择一种敏捷实践,开始的时候要严格遵守实践的准则。

在这个阶段就是要广泛实践,尝试解决不同的问题,遇到问题自己要先思考,尝试举一反三,发现新问题的解决方式。

从我的成长经验来说,这个阶段非常重要,很幸运的是,当时作为敏捷教练,整个产品线有10个团队,在开始转型的半年内,有了充分的实践机会,目前我咨询的大部分经验都是来自那个时期自己的实践经验。有利有弊,当初我个人是没有外部咨询师长期驻场的,在自己摸索的半年中,曾两次想辞职放弃。这个阶段最重要的是实践和坚持,通过PDCA的方法,不断尝试,总结,调整。对于这个阶段的教练,应该是充分去尝试,思考,改进。只有在充分思考,实践后,再去尝试问你的导师,否则会对外部有很强的依赖性。

对于教练的要求是,按照PDCA的方式,短周期反馈,要亲身体会敏捷的思想。最好是每周总结上周的实施内容,然后作出调整制定这周的实践计划。

如果真正到了这个阶段,应该是处理任何事情,都不会超出所信仰的理论,这里就是指做实践都不违背敏捷宣言的价值观。

这里介绍一下怎样到达这个状态,有丰富的经验以后,再通过阅读,思考,总结等任何方式,把理论体系化。

想要到达这个阶段,教练应该已经具备一些培养别人的经验了,那么自己更应该身体力行的去实践自己的理论。我个人形成自己体系的方式是通过大量的阅读,毕竟自己遇到的场景还是不够,通过阅读别人的案例,来思考到底应该怎样解决,不断验证自己的体系。

这个阶段,教练应该已经具备自我成长的能力,自己应该找到合适的方法。这里只是给大家一些建议作参考,多读书,多读论文,同时也要多总结,实时验证自己的体系。

最后,想强调的一点,敏捷不是只能运用到团队项目中,可以运用到个人成长,甚至家庭中的,大家一定要充分实践,既然信服它,就要身体力行的去执行他。

Share

敏捷宣言到底有几句?

“Hi,A同学,敏捷宣言有几句?”,“4句呀,分别是个体和互动…”

如果你的答案和A同学一样,也认为是4句,那么请你请继续往下读,相信此文章会对你有所帮助;

如果你的答案和A同学不一样,认为不是4句或者是不知道,那么此文章你可以选择性阅读,它不一定会对你有所帮助:)

“Hi,A同学,敏捷宣言有几句?”,“4句呀,分别是个体和互动…”

如果你的答案和A同学一样,也认为是4句,那么请你请继续往下读,相信此文章会对你有所帮助;

如果你的答案和A同学不一样,认为不是4句或者是不知道,那么此文章你可以选择性阅读,它不一定会对你有所帮助:)

为什么写此文

当我还是一名敏捷实践的试行者时,接触到的第一个信息就是敏捷宣言(非4句),虽然不能完全领悟,但当时的教练让我把它熟记于心,说这个就是敏捷。我想:我终于知道敏捷了;

当我还是敏捷教练时,向大家介绍敏捷,询问大家谁知道敏捷宣言的时候,有部分同学举手,他们的答案和A同学一样。我想:有的喷了;

现在我是敏捷咨询师,接触到了一些企业内部的敏捷实践者,问他们同样的问题,他们的答案也和A同学一样。我想:你该请我们做咨询了;

就在前不久,我听了一些敏捷培训,讲师提到敏捷宣言的时候,竟然都介绍的也只是4句敏捷宣言,之后我饶有兴趣的百度了下“敏捷宣言”的关键字,发现…,我问了下周围的敏捷实践者发现…甚至我还问了是不是漏掉了什么?得到的答复是敏捷宣言就是4句呀,大家都知道的…我忽然意识到此事的严重性。我想:该写篇文章了。

宣言到底有几句

让我们来看一下原版的敏捷宣言。以下是官方的翻译:

敏捷软件开发宣言

我们一直在实践中探寻更好的软件开发方法,身体力行的同时也帮助他人。由此我们建立了如下价值观:

个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划

也就是说,尽管右项有其价值,我们更重视左项的价值。

数一数有几句?6句。此文并不想纠结于数字,你也许会说敏捷宣言中有4句价值观,这似乎也没错,但问题是你了解其余两句吗?敏捷宣言流传至今,我们心中似乎只记住了那4句,其余的两句被我们天然的屏蔽了,甚至我们还一直在做敏捷宣言只有4句这样的知识传递!难道那两句不重要吗?答案肯定是否定的(不重要为什么要写在宣言里…),两句的偏差带给我们的是敏捷转型方向上的错误。让我们来看一下这两句告诉我们了些什么。

我们一直在实践中探寻更好的软件开发方法,身体力行的同时也帮助他人。由此我们建立了如下价值观:

通过这句我们了解到敏捷宣言是通过不断实践总结出的价值观。价值观不是具体详细的目标及实践,它是要根深蒂固的在我们心里的一种思维取向,它会影响我们做出的每一件事情。所以有团队会说,我们现在已经敏捷了,因为我们做了迭代开发,这种单纯的实践=敏捷是不成立的,我们需要多维度的去了解团队的价值观是否符合敏捷的价值观。

虽然右项也具有价值,但我们认为左项具有更大的价值。

这句是敏捷宣言里最重要的一句话。如果你丢了第一句,说宣言有5句,这个还可以原谅。但如果你丢了这一句,那绝对是个错误!在做敏捷转型的过程中常遇到这样的现象:“敏捷说了不需要文档,太好了,我们以后就不用写文档了”,“敏捷说了不需要计划,我为什么要给你计划”,这样实施的后果可想而知,这样的案例比比皆是,这就是敏捷转型方向上的错误。

为什么会有这样的错误呢?原因就是忽视了宣言中的最后一句话。宣言的价值观中英文用了“over”中文翻译是“高于”,A高于B,多数人的理解就是A比B好,那么为了敏捷转型我们就只用A舍弃B,这似乎是字面上的正常的理解,但这不是宣言中要表达的意思。想必当初17位大牛早已预见了这样问题,他们用最后这句强调,给大家正确的引导。告诉大家宣言中的价值观不能理解为取A舍B这样的二分。敏捷的价值观是承认右项是有价值的,不过我们要更重视左项的价值,这不是二分!当初软件开发在不断发展的过程中,大家越来越的重视右项的价值,这时敏捷站了出来,提出在这个过程中我们要更加重视左项的价值,它并不是让我们要放弃右项实施左项。

在我们实际做敏捷转型的过程中,左右两项通常情况下也是共存的,不过我们更重视左项。例如你在帮一个团队在做敏捷转型,你发现产品把需求都录入系统中,告诉大家他的任务已经完成,之后研发按照系统中录入的需求进行研发,期间他们无任何沟通。这时你应该做的是加强他们之间的互动,例如让产品给研发对着系统的需求需求讲一遍,研发在过程中发现问题立刻和产品沟通,不过度的依赖系统中的描述等,你不能认为宣言里说了互动比工具更重要,就让他们停止使用系统只靠互动,这样团队会“手忙脚乱”,就算团队勉强坚持下来了(且不说效果好坏),最后你会发现数据统计的工作如果没有工具,对团队来说就是一场噩梦。这样的例子还有很多。

总结

作为敏捷实践者、教练、甚至咨询师。敏捷宣言作为基础,我们不能“断章取义”的只记住那4句,甚至还在做只有4句这样的知识传递,我们需要把敏捷宣言中的6句话都“掰开了揉碎了”去理解清晰,尤其是最后一句,来给自己给别人树立正确的敏捷价值观。所以敏捷宣言到底有几句?6句,一句都不能少!

最后我想到了两句话:“天才就是99%的汗水+1%的灵感”和“知识就是力量”,这两句作为的名言警句被流传至今,但如果你只记住了这两句,恐怕无法正确的理解爱迪生及培根当时想表达的意思,因为它们都有后半句:)

ps:感谢我刚接触敏捷时候的教练,他对我正确的引导。他曾也是一名ThoughtWorks的咨询师。

Share