这可能是因为有这么几个门槛。
第一道门槛是,每个人都要熟悉敏捷。
正像前篇所说的那样,拉一堆不熟悉敏捷的人去按照敏捷流程做事情,由于这些人只是按照敏捷的形式去做,而不清楚敏捷解决了什么问题,不清楚为什么要用敏捷,就可能会导致应用敏捷的效果适得其反。比如站立晨会,如果大家认为它只是一个向boss汇报工作的过程,就很可能会成为一个非常鸡肋的环节了。
类似的情况可能还会发生在敏捷的一些实践上,比如“简单的设计”,如果曲解了这个实践的含义,可能会造成对设计要求的降低,当我们滥用这个原则去拒绝一些可以预见的复杂需求的时候,我们可能不得不在下一个迭代推翻很多老的设计。
第二道门槛是,敏捷容易“水土不服”。
敏捷是思想,把它应用好需要一定的时间和经验。就好比 马 克 思 主义进中国一样,一定要适应于“中国特色”之后,才能被用好。Mary Poppendieck和Jean Tabaka在敏捷大会上都指出了,敏捷开发并不是件容易的事情,短时间内很难做到,而且这需要不断地改变过去。
举个例子,敏捷实践中有结对编程,Laurie Williams和Nosek的研究表明,结对非但不会降低开发团队的效率,而且会大大减少缺陷率。但应用到实际的项目和团队中,这个效果又会怎样呢?一些分析表明(项目总结-结对编程,http://www.soft6.com/tech/6/63739.html),这其中是存在一定的障碍的,比如老员工习惯单打独斗,性格问题,经验差距过大,企业文化等问题。结对之前首先要克服这些问题,才能达到比较好的效果。
再举个常见的例子,敏捷要求,在整个项目开发期间,业务人员和开发人员必须天天都在一起工作,可是这在许多大型公司的部门架构中,是不现实的。同样,对于甲方乙方公司,以及客户是看不见的网民的互联网公司,这个要求也多少有些严格了。
第三个门槛是,坚持敏捷很难。
我们会尝试很多敏捷的实践,我们会努力去改变一些过去的行为,这个过程可能会花很多时间。
每个人都会有自己的惯性思维,也会有自己习惯的工作方式。改变的过程不会是一瞬间的,在这个过程中,会有一定的状态起伏,甚至状态下降也说不定。如果在这个过程中因为效果不好而放弃,或者没有形成新的习惯,从而回到了老的习惯,那么就可能不会再去迈出改变的第二步。
另外就是,敏捷的一些实践(比如持续集成,自动化测试)是需要构建一些基础设施出来的,面对遗留系统,这可能会是个大成本的事情。
还有其它情况,比如进度压力太大的时候,敏捷的队形会被扭曲(敏捷之收获http://blog.tianya.cn/blogger/post_show.asp?BlogID=169274&PostID=16474714),在找到真正适合自己的敏捷实践之前,我们是否有毅力坚持下去?
还有很多其它的门槛。
我认为,很多时候,使用敏捷之所以没有获得预期的效果,主要还是在于使用方法上。敏捷的核心在于以人为本,由于人是活的,所以人既有可能做得很差,也可能做出非凡的成绩,关键在于是否找到了适合自己和团队的实践方法来。这肯定不是一朝一夕的事情。我认为,只要大家的目标是一致的,坚信敏捷是对的,那么就坚持下去,不要中途放弃,相信这样久了,就一定能找到适合的实践方法的。
分享到:
相关推荐
然而,敏捷并非银弹,实施时需要克服文化变革、沟通挑战和持续学习等难题。 总结来说,敏捷项目管理模式以灵活、迭代和以人为本的方式管理项目,鼓励团队自我组织和适应变化,以实现更高的项目成功率和客户价值。...
然而,微服务并不是解决所有问题的“银弹”,正如1987年Fred Brooks在《没有银弹:软件工程的本质性与附属性工作》中提出的观点,软件工程的本质性工作(如设计和抽象)和附属性工作(如编码和测试)是两个不同的...
书中,布鲁克斯提出了一系列创新性的观点,如“没有银弹”理论,即不存在能解决所有软件工程问题的单一方法。他还强调了软件开发中的人员协作与团队建设的重要性,认为增加人员并不总是能按比例提高生产力,甚至可能...
4. **没有银弹**:在1986年的一篇名为《No Silver Bullet》的文章中,布鲁克斯提出了一个著名的观点:“没有银弹”——即不存在一种万能的方法或工具可以显著提高软件开发的效率和质量。这一观点对于当时的软件开发...
以及“没有银弹”——指出没有一种技术或方法可以解决所有软件工程难题。 标签中的“人月神话”和“man moon”都是对书名的直接引用,“软件”和“技术”则突出了本书的核心主题。布鲁克斯在书中讨论了软件开发的...
3. **软件工程的根本问题**:Brooks认为,软件开发的核心挑战在于解决复杂性和不确定性,而不是技术本身的问题。 4. **软件工程的次要问题**:相对而言,次要问题指的是可以通过技术手段解决的具体难题,如提高编程...
#### 面对现实:为什么没有银弹? Brooks进一步解释了为何软件领域不太可能出现类似硬件领域的革命性变化: - **本质难题**:首先,必须认识到软件的本质决定了其复杂性和不确定性。软件是高度抽象的概念实体,其...
- **银弹理论**:Brooks比喻软件项目的不可预测性类似于民间传说中的人狼——表面熟悉但实质上充满未知与危险。他指出,就像需要用银弹才能杀死人狼一样,软件开发中的问题也需要根本性的解决方案。然而,他认为并不...
2. **构建与构建**:软件开发过程应当被划分为两个主要阶段——构建阶段和构建阶段。在构建阶段,团队专注于创建软件的基本框架和核心功能;而在构建阶段,则关注细节的完善和功能的优化。这种方法有助于确保项目的...
- **第16章:没有银弹——软件工程的根本和次要问题**:分析了软件工程领域的挑战,并提出没有单一的方法或工具能够在短期内解决这些问题。 - **第17章**:对《没有银弹》中提出的观点进行了更新和补充,回应了外界...
### 《人月神话》——软件工程的经典之作 #### 关键知识点概述 1. **《人月神话》的背景与作者介绍** - **作品简介**:《人月神话》是软件工程领域的经典著作,首次出版于1975年,至今仍受到广泛的关注和引用。...
7. **银弹谬论**:布鲁克斯提出“银弹谬论”,即不存在一种技术、方法或工具可以彻底解决软件工程的所有问题。他提醒我们,软件开发是一项复杂的人类活动,不能仅依赖技术解决方案。 8. **质量优先**:书中强调了...