成功实施敏捷之十荐(2)

发表于:2012-08-06来源:InfoQ作者:Allan Kelly点击数: 标签:敏捷测试
我们生活在一个后现代、后BPR、后裁员、后萧条,后一切的世界里。别把员工当作小孩子,他们能洞察一切。最常见的是在管理层启动变更前,特别是有顾

  我们生活在一个后现代、后BPR、后裁员、后萧条,后一切的世界里。别把员工当作小孩子,他们能洞察一切。最常见的是在管理层启动变更前,特别是有顾问参与的变更,已经与敏捷和精简背道而驰了。如果你想精简人员那就裁掉他们,启动敏捷模式吧。

  就一条简单原则:要引导、不要生拉硬拽。

  当有人说“变更管理”的时候,他已经不知不觉地在硬拽变更,所以请慎用“变更管理”这个词。

  如果你身处管理层,那你需要营造一股合力来推动变更:一方面员工对于变更的热情自下而上,另一方面来自管理层的支持自上而下,一拍即合。笔者觉得自上而下地硬拽敏捷模式无异于失败,员工自然而然地会去质疑自上而下的强制变更。

  相反,尝试去寻找一种方法激励每个员工和团队,让他们反过来向你建议采用敏捷模式,这远比强调变更自上而下要好得多。管理者必须首先培养并点燃人们的好奇心,然后等着人们主动来问问题并寻求帮助,最后创建出自下而上的变更方案并给予支持。

  想办法点燃人们对于敏捷模式的好奇心,当他们来问的时候,给予帮助,并提供他们所需的东西:同意书本花费的支出,对讲师、培训师和教练提供预算,对会议说“是”。总之一句话,支持,全力地去支持! 别置身事外,即使你都了解,你也需要去学习,当团队在形成共识时你需要在场。并且你也需要改变,学着改变你自身的行为去适应它。

  7) 实施敏捷模式的动机

  抛开你在敏捷体系中属于哪个阶层,工程师测试,项目经理还是主管,问一问自己,你想要敏捷模式为你解决什么问题?搞清楚为何你想要改变并且明确你从中期望获得什么。

  不要因为赶时髦而去实施敏捷模式,让敏捷模式帮你实现更重要的东西。去理解每个成员想要从敏捷模式中获得什么,以至于让他们的生活变得更美好。理解组织下想要从敏捷模式得到什么 ——是创新?是可靠的日程表?还是更少的Bug数?

  问问你的团队,问问你的老板,问一问“你认为你的老板想要获得什么?”如果每个人都能从中受益,那每个人都愿意帮助实施敏捷模式。反过来,当人们看不到利益,变更将变得异常困难。

  当你的敏捷模式进行实施的时候,你需要依靠这些问题的答案来选择你的工具,优化你的流程并衡量你的成败。

  8) 流程与技术,兼而有之

  千万别认为你只要改变下流程,所有情况都会变得好起来。你必须同时考虑技术层面,你必须改进质量,并支持你的工程师,测试人员以及其他进行编码实施工作的人。

  我曾遇到过那些认为忽视技术层面的大公司:他们的态度似乎是“那只是技术”或者“他们将弄脏他们的手”或者“我们可以外包给低成本国家做”。如果你是这样的态度,那你必将失败。

  “弄脏”你的手,跟工程师们谈话,实施测试驱动的开发模式,实施重构,避免大规模的前端设计架构,学着接受粗略设计和演化架构,这些才是真正的反馈循环。

  9) 使需求更清晰、更干净

  敏捷模式要解决的不仅仅是编程方面的问题,还包括需求分析的改进。特别是在有专职业务分析员的产品负责人或者产品经理,与开发团队之间保持通畅的途径。更深层次的谈判将首先发生在“什么”上,然后再是“何时”上。必须有人有与需求相关业务的授权,能够拍板儿。

  太多公司没能对此引起足够重视,敏捷模式使需求理解更刻不容缓,需求上的瓶颈将对之后的开发产生连锁反应。

  自己跟自己做个智力测试吧:如果敏捷模式将开发人员的生产率提高一倍将发生什么? 答案是你将需要在需求分析上花两倍多的精力。首先你可能会干掉一个长长的backlog,但你这样做之后,你的余额价值(Marginal value)也将减少。

  10) 结构变更——功能组

  以功能组的方式,将所负责工作不同的员工构建成不同的团队——例如:将数据库开发和用户界面开发分成独立的团队。这仅仅是你所要做的结构变更的第一步。但如果你在这里失败了,你就不可能再做一次了。

  但带来的问题是团队之间请求特殊技能支持或所需的授权将受到影响,因为其他组有另外的优先级。尽量减少这些,因为这将会拖整个团队的后腿,影响团队士气,让你的敏捷实施更为困难。

  就是这样

  就这些了,其实这每一项都可以再写一篇文章去深入讨论,也许有一天我会那么做,但现有内容已足够改变现状。

  如果说还有第十一项,那就是:忘记过去,改变无时不在,敏捷也不单纯只是添加剂。如果你不勇敢地停止一些你现在正在做的事情,你永远不会知道这样做的后果。但你完全可以等到你有了成功的资本后,再开始转变。

  关于作者

胜任过软件开发领域的似乎所有职位,从系统管理员到开发经理。如今他帮助团队实施敏捷模式并将其发挥到极致,他在如何与软件产品公司打交道及如何调整企业产品与流程使之符合公司长远战略上有着专长。他最新的著作《软件开发人员的业务模式(Business Patterns for Software Developers)》已由Wiley于今年年初发行。他的Twitter是 @allankellynet.

原文转自:http://www.ltesting.net