敏捷思想的出现让我们看到了新的曙光——以更低的风险、更高的效率开发出更具质量的软件产品。正因如此,敏捷方法得到了业内足够的重视并使各路团队相拥实践。然而,即便我们对于各种敏捷原则、范式、方法和流程了如指掌,仍会发现其所给组织带来的改善远达不到我们的预期。这究竟是为什么?造成这种困境的根源并非我们学得不精,而是实践不到位。

在我看来,敏捷宣言过于简单(好吧,是宣言总得简单一点!),以至于足以让人对之产生误解。比如:“可以工作的软件胜过面面俱到的文档”容易让人忽视对必要文档的重视;“个体和交互胜过过程和工具”容易让人误以为有了面对面的沟通就可以忽视适宜的过程和易用的工具所带来的巨大正面作用。就我的观察,只要软件开发活动中忽视了必要(言简意赅)的文档、适宜的过程及易用的工具就一定“敏捷不起来”,因为它们是塑造训练有素的个体所需的重要素材,而个体正是敏捷原则中所提到的自组织(开发)团队的组成单位。团队是否做到自组织是检验敏捷思想是否真正落地的重要判定依据。然而,团队要真正做到自组织却面临很大的挑战,让我们分别从几个方面加以探讨。

首先,从项目管理层面加以审视。最近面试了一个项目经理,他在华为和腾讯两家公司都干过,从与之的交谈中很明显地看出他对于敏捷软件开发有着良好的实战经验,也对实践中所碰到的困境有着自己独特的思考。然而,当我问他“实施敏捷软件开发的最大挑战是什么”时,他的回答却是“项目难以如期完成”。得知他的这一回答后,我立即告诉他“尽管你谈起敏捷时头头是道,但你内心深处并没有真正拥抱和理解敏捷”。在告知他我为何得出该结论后,他抱以微笑并对我的观点加以认可。我估计与他有同样想法的项目项目管理者大有人在!

“响应变化胜过遵循计划”这条宣言告诉我们,软件项目的评估是为了适应变化而非为了遵循计划。更深一层的含义是,项目计划应当保持一定的弹性(指计划时间可以经常适时地调整,项目管理也得敏捷!),即如期完成项目计划并非是敏捷所倡导的,她所倡导的应是持续地以更高的效率完成高质的软件开发工作。然而,受传统项目管理思想的影响,我们大部分管理者仍然以项目是否如期完成作为一个重要的考核指标。其实,对项目计划要求越是精确(这里的“精确”是指计划一旦制定就得严格如期执行,或者我们说项目计划很具“钢性”),实现自组织团队的困难就越大。为什么?

事实上,不论软件开发工程师的经验多么丰富,要真正精确评估实现一个软件功能的时间在很多情形下几乎没有可能。当然,现实中存在另一种“精确”,即通过更大的时间冗余使评估显得“精确”。这所导致的直观结果就是,最终单从项目计划上就能一眼看出“根本不敏捷”。项目计划一旦不具一定的弹性,所产生的另一个问题是开发工程师在实现功能时根本无法将一个功能做到让自己满意,因为将时间评估得偏少这类事总在发生。原因在于很多工程师迫于管理层的压力,不会将时间评估得保守,而是报着“我加加班应当可以搞定”的心态。最终的结果就是,工程师为了按计划完成工作只能“缺斤少两”地做事。

让项目计划保持一定的弹性会让很多管理者(包括项目经理自己)提出一个问题,即“那我如何知道项目是否进展顺利呢?”事实上,项目是否真正进展顺利并不能简单地从计划的执行情况看出,因为软件的真正质量和开发效率并非体现在项目计划的钢性上,管理者在这种情形下能做的除了信任团队外,去了解更多的团队状况、技术细节或许有助于平复自己的焦虑情绪。千万别忘记,没有信任就没有敏捷!也千万别忘记,敏捷意味着更高的开发效率和软件质量,而项目计划是否如期执行根本没有完全代表这两个诉求!

值得一提的是,我并非主张管理层该盲目、简单地信任团队,在之前一定要确保开发团队中存在合适的人可能让团队自组织起来。但管理层一定需要意识到的是,即使团队中存在那样的人,也要配合适当的管理方法才能让那些人真正将团队带向自组织。

其次,从基层技术管理的角度加以剖析。技术管理的核心内容是提高团队技能(参见《技术管理的核心内容——提高团队技能》),但不少基层技术管理者从技术走向技术管理岗位后,将(绝)大部分精力投入到项目管理事务中,忽视自己所应承担的团队管理责任。更为可怕的是,这类人很容易将团队的自组织能力放在一边,既听不进团队发出的声音,也不会去刻意培养,这种管理模式造成我们永远得不到真正自组织的团队。

我在《如何做好基层技术管理工作?》一文中谈及了动机与方法两大方面,在本文讨论的主题下需做一些补充。当团队还不具备自组织能力时,基层技术管理者起到至关重要的作用。第一,重视工作安排策略。大多情况下,由于项目的时间压力,基层技术管理者很容易采取根据工程师的技能安排他做最能获得效率的工作这一策略。然而,长期采用这一策略将导致工程师所熟悉的模块趋于单一化,结果导致工作安排缺乏弹性,变成“每个萝卜都挪不了坑”。这种境况很不利于团队技能的发展,也使得团队很难进入自组织的状态。更为合适的做法是,在每次迭代中安排少数几个工程师做他们不擅长的。多次迭代下来,工程师所涉功能面将更广,这就为项目计划时的人员安排带来了更大的弹性,也使得各功能模块的代码能在多个工程师的视线范围内,从而更容易落实质量。第二,如果不能营造一种让工程师畅所欲言的团队文化,则同样没有将团队带入自组织状态的可能。在我看来,只要是一名管理者,如果你的下属不愿向你吐露工作中的心声,那证明你已失败!第三,在制定开发计划时,基层技术管理者一定要持续地将一只眼睛盯住改善部分,而不能只关注新功能开发。不断改善的目的,是为了防止技术债高筑而使得程序变更缺乏弹性。第四,团队在走向自组织的道路上,一定存在不少对既定目标做适当变更的情形,此时基层技术管理者一定要做好上下间的沟通工作,让团队的工作状态对高层管理者更加透明。信息的透明化有助于管理高层真实了解团队的现状,为信任提供良好的支撑,让他们不至于过于关注项目计划的钢性。第五,确保软件设计质量与编码质量落实到位。换句话说,确保在团队中落实概要设计评审和代码审查等工作流程。

我相信很多基层技术管理者想将团队带好,但不少人受能力、惰性和胸襟所限,根本不理解什么是自组织团队,也不愿意学习与自我改善,还放不下自己是“领导”的架子。然而,这类人正是自组织团队要“消灭”的。于是,我们面临这样一个悖论——“为了自己不被‘消灭’,这类人一定带不出自组织的团队”。不难发现,合适的基层技术管理者是打造自组织团队关键中的关键!

再次,我们从工程师的角度给予考量。自组织团队对于工程师来说究竟意味着什么?第一,技能多样化。技能过于单一往往会造成项目计划的实施瓶颈在于某个人无可替代地处于项目的关键路径上,这使得项目的人员安排缺乏弹性。要实现技能的多样化首先要从管理着手,即需要基层技术管理者有意识地通过工作安排加以培养,这一点我们前面已谈及。另一方面,工程师也得有意识自我培养,千万不要将自己的工作锚定在很窄的范围。为了避免出现这种境况,工程师对自己的工作内容应通过编写言简意赅的文档(比如概要设计、指南等)的方式让他人可以方便地接手。显然,文档的编写能力也涵盖于技能多样化之中。第二,律己和律他。“自组织”这个词从表面就向我们传达了“纪律”,纪律意味着质量与效率。工程师个体首先需有良好的自律能力,对于团队所达成的各种共识(规范、流程等)努力实施到位,对于已存在的好方法、好习惯积极地模仿并跟随,而不是简单地打破并自立门户。除了良好地律己我们还得关注律他,通过指出他人不足并给予帮助的方式让整个团队维持良好的工作纪律。第三,良好的方向感。这种方向感源于清楚地知道产品的定位与战略,并基于此而形成的、清晰的软件开发策略。良好的方向感使得工程师清楚地知道技术的真正价值在于为产品的核心竞争力提供强有力的支持,并努力在产品与技术之间获得平衡。在我看来,简单地偏向产品或技术,从长远来看对于整个团队都会是一种灾难。第四,主动承担责任。面对责任,与“主动承担”相反的方式是“防御”或“逃避”。自组织团队一定不会害怕责任,当出现问题时工程师会主动承担责任或帮助他人解决,呈现的是一种互帮互助的良好协作氛围。第五,自发地持续改善。在具有良好方向感的自组织团队中,工程师会时刻关注开发工作中的点滴改善,通过持续改善的方式从技术层面不断地将产品推向更高的品质。

从项目管理、技术管理和工程师三个纬度的分析可以看出,真正的敏捷自组织团队需要从上到下、各工种的理解与配合才有可能打造出来。“敏捷”所强调的更多的是“弹性”,因为具有良好弹性的团队在面对各种压力时才具韧性。试想想,如果个体被桎梏于只能容下身体的空间中,那么我们有可能做到(伸手)“敏捷”吗?

真正的敏捷不是形式,而是团队的文化与能力。如果不注重从文化与能力上去塑造,无论我们对于敏捷之形多么在意和刻意临摹,我们永远只能游离于表面。

打造敏捷的自组织团队相关推荐

  1. 敏捷开发绩效管理之二:用中医理论管理团队及其绩效(绩效考核,团队管理,自组织团队)...

    这是敏捷开发绩效管理的第二篇.(之一,之二,之三,之四,之五,之六,之七) 团队管理是个由来已久的话题,各式各样的管理理论和方法层出不穷.笔者因为工作原因在过去16年里与100多家企业的团队或团队领导 ...

  2. 敏捷开发生态系统系列之四:计划跟踪II(自组织团队-开发团队自己估算-PO挑战估算-同行压力)...

    这是敏捷生态系统系列的第四篇(之一,之二,之三,之四,之五).一半内容属于需求管理生态,一半内容属于计划跟踪生态. 在实际开发环境中,产品负责人常常和开发组存在潜在的利益对立.前者往往希望在更短的时间 ...

  3. 敏捷开发讲义---如何打造敏捷团队

    PPT下载链接:http://pan.baidu.com/s/1bncprTd 敏捷开发分享讲义-修改版 第1页:个人信息 就不做自我介绍了,我的基本信息就在PPT第一页.7月26日,也就是上周六,我 ...

  4. 敏捷团队建设︱如何组建和管理高效的自组织团队

    什么是自组织团队? "知识工作者必须要自我管理.他们必须有自主权",管理学大师Peter Drucker在他<二十一世纪的管理挑战>的书中说. 这和敏捷思想是不谋而和的 ...

  5. 打造敏捷化的高绩效项目团队︱北汽研发项目管理中心项目经理张志强

    打造敏捷化高绩效项目团队︱北汽研发项目管理中心项目经理张志强 北汽研发项目管理中心项目经理张志强先生受邀为"2021第二届中国项目经理线上会议"演讲嘉宾,演讲议题为"拥抱 ...

  6. 论敏捷管理与团队文化的契合度

    前言 说到敏捷管理,很多程序员或者软件开发公司的管理人员第一反应就是"小步快跑,频繁发布".这令公司决策层(老板)觉得敏捷能解决一切问题,想啥时候上线就啥时候上线. 其实这只是一种 ...

  7. 自组织团队理念和实践

    1 前言 我加入Thoughtworks已经快两年.作为一名工作多年的程序员,在加入TW初期,对于公司的文化和做项目的方式并不是很适应.后来我和其他一些也是工作多年后加入TW的同事聊天,他们也有着同样 ...

  8. 自组织团队建设很容易吗? (问题与对策的思考)

    自我驱动或者自组织团队是现在软件公司努力建设的方向,自我驱动也常常挂在嘴边.但以我的观察,自我驱动或自组织团队建设并没有带有真正的团队生产力提升,反而很易遇到发展瓶颈! 自组织团队的困境 问题在哪里? ...

  9. 《天天学敏捷:Scrum团队转型记》读书笔记

    读书给人以快乐.给人以光彩.给人以才干. -- 培根 基本信息 作者:杨蕾,郑江著 推荐值:76.7% 微信读书:天天学敏捷:Scrum团队转型记 收获 & 思考 阅读目标:提前明确目标,有助 ...

  10. 数据北京研发中心CTO王东:如何打造有战斗力的团队

    讲师简介 王东,现任融数数据北京研发中心CTO,负责公司大数据平台.微服务框架以及DevOps平台的研发工作: 毕业于天津大学,毕业后一直从事软件相关研发和架构设计工作,曾在普元软件任资深架构师.IB ...

最新文章

  1. jQuery操作Select
  2. 官宣!中央广播电视总台《2021年春节联欢晚会》总导演组公布
  3. 通俗易懂。HTTP请求行、请求头、请求体、响应行、响应头、响应体详解
  4. Nginx 附录A 编码风格 和 附录B 常用API
  5. 鹦鹉助手模拟器 梦幻西游 找不到服务器,模拟器玩梦幻 17173鹦鹉助手模拟器上线...
  6. 老男孩python第一天笔记
  7. 如何在在线直播网站源码中,实现视频连麦直播?
  8. NeoKylin-Server使用docker部署跨主机redis集群
  9. 【推荐】“汇新杯”新兴科技+互联网创新大赛——IT人大展拳脚的创业大赛
  10. Winform中HelpButton的用法总结
  11. 小白都能学会的Python基础 第一讲:Python初了解
  12. java输出hello word,新手求教如何输出helloword
  13. 阿里王坚:人工智能是一个非常傲慢的提法,这个提法最后会害死大家
  14. 计算机名和DNS域名的关系,域名、DNS、IP地址的对应关系
  15. preg_replace函数去除字符串中的空格,逗号(,)等
  16. 网易易盾反作弊实践:如何抵御烦人的羊毛党?
  17. 微信IFTTT,用微信同步照片或信息到facebook和twitter
  18. ES8——Generator函数的使用
  19. 养儿子是建设银行,女儿是招商银行
  20. Excel 2010 SQL应用055 SQL中使用三角函数

热门文章

  1. 东方联盟郭盛华获100亿战略入股,到底谁支持他?网友:不敢猜
  2. python报错 unexpected keyword argument ‘categories‘
  3. C语言中括号的用法[]
  4. 2022-06-08 iPhone快捷指令自动切换壁纸
  5. 各代iphone尺寸_iPhone所有机型对比尺寸
  6. 程序员如何转职区块链开发
  7. 超好用的线上评选微信小程序、投票微信小程序
  8. 《菜鸟教程》C语言学习
  9. 51单片机STC89C52控制LED跑马灯左移(使用C51自带库_crol_()实现),详细注释
  10. 杭州电子科技大学计算机考研复试分数线,2019杭州电子科技大学考研复试分数线通知...