敏捷开发系列之如何走向敏捷
1个回答
展开全部
团队向敏捷的转变 向敏捷开发转换,管理层的支持是关键,而团队的认同则决定了敏捷执行的程度和结果。这个转换过程可以分几步、有选择性地在一些项目中开始。
许多企业走向敏捷是从组织培训开始的。培训可以是内部的,也可以聘请外部顾问,最重要的是负责培训的讲师一定要有丰富的敏捷经验。因为敏捷开发是一种经验科学,书本上的知识只能帮助了解,真正的掌握需要在实践中训练。
培训一般从公司的管理层开始,尤其是负责开发或工程的副总裁、经理等。培训的过程是一个认知的过程,也是一个取得管理层支持的重要步骤。开发团队的负责人是培训的重点。这些阶段比较典型的培训是两天的Scrum培训,培训以Scrum为主,但会涉及敏捷的方方面面。
项目实施是敏捷思想落地的过程。一般应选择在小型新项目中实践敏捷开发,这样可以降低风险。也有公司不得不从项目的中间开始实施敏捷开发,同样也有很多成功的例子。一般只要有上层的支持和得力的指导,并完成一两个敏捷周期,团队一般会完全转入敏捷开发的模式并不断提高。
在实施敏捷开发的过程中,团队的组织也是关键环节。敏捷开发团队有以下两个特点:
1. 是跨领域的平行联合团队,团队中应该有来自各个平行领域的人员,包括测试人员,甚至客户代表。目的是让这个团队能胜任开发周期中的所有任务。
2. 团队的职责和功能除了日常的开发任务外,还要完成各种自我管理和组织功能。大多数的管理和决策不再由管理层单独掌握,而是整个团队商议决定。每个成员都要对项目管理中的范围、时间、成本、风险等管理负责,每个成员在一定程度上成为项目经理。
课堂上的培训对团队来说只是个很好的开始,实践中的指导和训练更为重要。项目中的问题各种各样,所以,在敏捷项目的进行中最好能由经验丰富的敏捷顾问指导。由敏捷顾问带团队走完一个或几个开发周期,帮助团队解决、纠正敏捷实施中的具体问题,这样开发团队会更快地进入敏捷的思维和模式。
PMBOK定义和描述了一套有关项目管理的知识体系。这套知识体系比较全面,涉及项目计划的集成以及项目的范围、质量、成本、风险、人力和物流等各个方面,与敏捷开发相比,PMBOK的主要不同点体现在以下方面:
1. PMBOK是计划推动的开发,一般来说要求有大量的前期规划和评估,而敏捷是价值推动,靠经验来优化。
2. PMBOK重视文档,每个阶段都有正式的文档要求,敏捷重视结果,文档往往被认为是一种浪费。
3. PMBOK的项目管理是自上而下的命令式管理,而敏捷的管理是团队的自我管理和经理们的服务式管理。
值得注意的是,尽管PMBOK和敏捷有以上原则性区别,但并不等于说PMBOK在敏捷开发中就没有价值。实际上,PMBOK中的大多数知识、概念和过程在敏捷中都被用到。
在PMBOK中,项目开始前要在范围、执行、成本等方面制定出详细的计划。在转向敏捷的过程中,这些计划并不是完全不用,而是被分散到各个短小的开发周期中了。例如,PMBOK要求项目开始前有尽可能详细的需求,并制定正规的需求更改规范和过程。而在敏捷开发中,项目开始前只有一个关于产品的远景规划,产品的功能需求是在开发过程中由用户的反馈和开发团队反馈一起来推动并逐步明确和细化的。正式的需求文档变成了分散的多个需求条目、功能或用户使用案例等。至于需求变动规范,大多数敏捷方法都积极预期这种变化并把对变化的管理嵌入到每个周期甚至每天的开发过程中了。
还有一点经常被用来当做敏捷的不足,即敏捷开发不能在一开始给出项目的成本计划,因此敏捷项目似乎无法进行成本的控制和管理,让许多外包性的项目无法采用敏捷。而实际上,PMBOK也无法做到准确的项目成本评估。PMBOK的做法是把所有的需求细化,然后把每个最小单位的估计总和起来。这样看似合理,但由于要对很久以后的开发作出估计,往往有很大的偏差。敏捷项目中的成本预算和管理可以用由上而下的方法。项目开始前,从总体的规划出发,讨论评估出一个大概的范围。在每个周期开始前,团队和用户再对周期的成本进行比较准确的预估和管理,这时PMBOK中的由下而上的方法就完全适用了。此后,在每个周期结束时再次根据当时的状况来调整对整个项目的成本估计。这样的成本控制和管理往往更准确、实用。
PMBOK对时间、质量、风险等的计划和管理可以遵循同样的原则转化为敏捷中的阶段性计划和管理来实施。
管理方式的转变是比较难的一方面。PMBOK中的项目管理风格是由上而下的计划、分配、指定、跟踪、评估和管理; 在敏捷开发中,团队要自我管理,计划的制定、任务的分配、质量的管理、项目的执行等都由整个团队协作进行。项目经理的职责是协调团队完成这些自我管理任务,并帮助团队排除遇到的障碍。项目经理要从命令式的管理思维转换成服务式的思维和行为。换句话说就是,原来PMBOK的项目经理是靠自己指挥一些人完成一项任务,而在敏捷中项目经理可能更需要做的是建立一种机制使所有的人能在其中自我协调完成某种任务,项目经理主要负责维护这种机制的正常运作和不断改进。
从实用主义走向敏捷 实用主义经常被处于无序或半无序状态的团队拿来标识自己。实际上,其中很多团队也并非都没有实施任何有序的方法,很多时候,其技术负责人会凭经验或自己掌握的一些方法来进行管理,有的也会采用敏捷中的一些方法。这些团队如果能和经验丰富的顾问或其他运用敏捷比较成功的团队交流,往往会认识到自己的局限性和离高层次敏捷开发的差距。
这些差距往往不在于敏捷的形式,例如故事或需求条目墙、站立会议等,而在于团队的开发和应变的速度、效率和自我管理能力。一旦决定采用敏捷开发,由于这些团队通常比较小而且没有任何成型的包袱,也没有摆脱固有过程的障碍,可能会更容易地过渡到敏捷开发。
总体而言,敏捷模式继承和发展了以往的软件工程理论和实践,并融入了人们对于软件开发的新的理解和理念。我们相信敏捷是为我国的软件企业带来高效率、高质量并促使开发团队职业化,推动我们赶超世界软件先锋的一个很好的机会。
作者简介 刘松 合络众成(北京)科技有限公司总裁。刘松曾在美国IBM硅谷实验室、Sybase等从事研发及项目管理工作,有着丰富的软件研发及管理经验。
推荐律师服务:
若未解决您的问题,请您详细描述您的问题,通过百度律临进行免费专业咨询