敏捷那些事儿（二）

上篇初步讲了下敏捷迭代的出现即一些自己的看法，今天说一下有关敏捷的一些概念和原则。

 

      2001年，一群致力于推广敏捷方法的人组成了一个小组，并制造了“敏捷方法”这个术语。敏捷联盟（Agile Alliance.www.agilealliance.com)从此诞生。

      敏捷小组成员发布了一个宣言，并且归纳总结了相关的原则：

 

                                      敏捷软件开发宣言

      个体和交互                        胜过                   过程和工具

      可以工作的软件                  胜过                   面面俱到的文档

      客户合作                           胜过                   合同谈判

      响应变化                           胜过                   遵循计划

 

      虽然右边的这些项也具有非常高的价值，但左边的项价值更大。

 

 

                                     敏捷软件开发遵循的原则

     1、我们最先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。

     2、即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。

     3、经常性的交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。

     4、在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。

     5、围绕被激励起来的个体来构建项目，给他们提供所需要的环境和支持，并信任他们能够完成工作。

     6、在团队内部，最有效果并且富有效率的传递信息的方式，就是面对面的交谈－－Face To Face(FTF).

     7、工作的软件是首要的进度度量标准。

     8、敏捷过程提倡平稳的开发。

     9、发起人、开发者和用户应该能够保持一个长期的、恒定的开发速度。

     10、不断的关注优秀的技能和好的设计会增强敏捷的能力。

     11、简单－使未完成的工作最大化的艺术－是根本的。

     12、最好的架构、需求和设计出自于自我组织的团队。

     13、每隔一定的时间，团队会在如何才能更有效的工作方面进行反省，然后相应的调整自己的行为。

 

 

     相对于一般软件开发流程，在项目管理中，管理者的角色在敏捷开发中有了本质的区别。

     敏捷项目的管理者工作的原则，首先要保证交付一些有用的东西给客户并检查它们的价值，在项目中，要经常启发关键利益相关人员，当然，这其中包括业务人员和开发人员。不能以管理自居，而是要以领导－协作的风格进行团队管理，并构建竞争、协作的团队，使团队能够做出决策，而不是自己一巴掌拍死所有的决定。管理者能使用“短期时间箱迭代”来迅速交付特征，鼓励自适应，并且提供最好的技术支持。需要时刻关注交付活动，而不是遵从过程的活动。

      在Scrum和XP中，敏捷项目管理者的主题是－－控制和计划都移交给整个团队，而不只是个项目管理者。项目管理者不必进行工作分解、规划进度或估算，反之，这些都应该是团队应该做的事情。最重要而且也是现在很多敏捷项目过程中的一个诟病和盲区就是：敏捷项目管理者不再指挥别人做什么，也不再定义和分配许多详细的团队角色和相关责任，而只是教练式的指导、服务性的领导。提供资源、维护远景、扫除障碍、倡导敏捷原则等。所以，对已经习惯于类似瀑布式开发的项目管理者来说，敏捷项目管理其实是一个很大的挑战，而从实际情况来看，很多的项目管理者往往在敏捷项目中会迷失自己，依然以传统开发模式的管理方式进行，从而导致敏捷项目的失败。