不少公司在尝试实施敏捷开发，敏捷实践在中国越来越流行，但当中敏捷涉及思想和意识上的转变，容易造成各种管理和实践上的差异，笔者常见的有三种情况。 一、小瀑布开发 敏捷当然不是小瀑布开发，很多团队开始四周迭代时，都希望可以逐步改变团队以前的开发习惯，例如：单一功能团队、团队之间交接，然后就会发现团队在这四周内依然像瀑布式开发。 我们都鼓励短迭代，两周比四周能得到更快的反馈，两周迭代比四周迭代更有效打破前面提到的老习惯，而要达到两周迭代，就必需要适当的实践配合，用户故事纵向划分、敏捷建模、测试驱动开发、持续集成、验收测试驱动开发都是有效帮助团队达到短迭代的方法。 而这里又引伸到另一个问题，就是组织能投入多少时间让团队学习这项新技能，从组织的角度去看这些问题，就是这些的回报期要多久，当然，就如丰田公司也是发展了很多年才累积到今天的成果，管理者也需要耐性才可以看到成果，而招聘优秀的开发人员更是非常重要的事情，这也引伸到下一个误区。 二、敏捷开发只是开发团队的事 写程序的是开发人员，实施敏捷时对他们的影响的确会是最大的，但不代表组织里其他角色不会受影响，亦不要以为自己不是开发人员就可以置身事外，这会改变其他员工的配合方式，所以他们的参与都很重要。 以产品管理为例，传统开发基本是顾客与开发团队的博弈，两方为自己的利益在拉锯，而焦点也不在于如何交付价值，而是各种各样的局部优化的行为。而在提倡开发团队与产品管理紧密合作和提高透明度的前提下，打破传统 “产品管理VS开发团队” 的矛盾以及如何把真正客户和开发团队拉得更近就是真正问题。 同样，大公司有各种各样的政策，有些政策却成为实施敏捷上的障碍，要改变相关政策，一定要跟人事部门做好沟通，也有案例是邀请人事部门的同事接受敏捷组织相关的培训，让他们知道如何更好去配合团队开发的需要。 跟人事管理政策息息相关的还有绩效管理和汇报架构，传统的管理模式下集中管理个人绩效却忽略作为团队的表现，而一个团队内各自有自己的汇报上司，更会令这团队无法做到应有的集中力。在实施敏捷的时候，亦应该检讨组织内影向个人绩效的措施，并加大鼓励团队合作精神，给客户最大的价值。 三、敏捷转型 “项目” “敏捷转型项目” 是常听到的词语，这会是什么误区呢？这种说法的误区在于视敏捷转型为有时限和终点的活动，其实不论是敏捷、Scrum或者精益，都提倡持久的改善，通过学习、实践提升团队解决问题能力，简单点就是说：“没有最敏捷，只有更敏捷”。而管理者的角色不是管理转型项目，而是走到现场了解前线工作人员的工作实况，协助消除组织里的阻碍，并提供支持团队所需要的环境、工具、培训等的支持。 敏捷不是银弹，“敏捷”本身是形容词，在敏捷开发中是指能适应变化而作出改变，而且有持续学习的特质，在一些案例中这些意识和观念没有扩展到整个组织里的时候，就会出现一种“做敏捷”的情况，依旧以为敏捷实施只是另一个转型项目，以为敏捷只是另一种开发过程，以为做了书上提到如站立会、写用户故事等等的实践就当是 “敏捷了”，以为办公室里加放了状态墙就是实施了“看板”或者“精益”，这些为做而做的事情，如二次世界大战时期太平洋群岛上土人见到飞机和军人所做出的模仿和膜拜行为。对此，笔者的建议是：鼓励组织深入并持续去认识敏捷，了解背后的思想，尝试不同的实践，并多参与社区交流活动。 作者麦天志，现职于Odd-e公司从事敏捷教练工作，协助不同企业实施敏捷，积极参与相关社区活动，并担当过 Scrum Gathering，美国 Agile 2009 活动上的演讲者。毕业于香港大学，主修计算机科学，并于伦敦帝国学院获取工商管理学硕士学位。 本文选自《程序员》杂志2010年10期，更多精彩内容敬请关注10期杂志 《程序员》杂志订阅火热进行中