[读书笔记]敏捷的起源

一、敏捷的起源：

    20世纪20年代-Frederick Taylor“科学管理”给每个工人发送指令卡，工人执行，管理者比工人更了解工作状态（这和敏捷没关系为后续的“知识工人”做铺垫）。

 

    20世纪50年代-美国国防部（DOD）和美国航空航天局（NASA）开始采用迭代式的增量方法（IID）。

    20世纪60年代-科技的发展，制造业岗位的消减，”知识工人“产生，旧模式不再凑效，生产工具在人的头脑里，旧式的方法被提倡信息共享和劝导的新方法代替。

    20世纪60年代-Thomas Gilb提出演化项目管理的概念（EVO方法）。

    1970年-Winston Royce发表文章《Managing the development of large systems》阐述瀑布方法的概念，并注解说明：“是危险的的并且可能导致失败”的原因， 因为它将测试放到了最后。

    1986年-Tankeuchi和Nonaka发表白皮书《The New New Product Development Game》讨论了Scrum方法。

 

二、敏捷宣言：

    2001年-17位方法学家早Utah-Snowbird会晤，与会者包括（Xp，Scrum， DSDM .....）方法学代表进行大量的讨论后形成下面的敏捷宣言：   见附图1    

　1.个体和互动高于流程和工具

        人们认为-复杂系统不可预测性，对这样的系统实施管理， 最好采用经验主义过程控制，因此管理者应该应许自我管理的敏捷团队以经验主义的方式来构建系统。

        个体-所有敏捷方法都承认有能力的，自我管理的团队，有能力做出必要的决策以完成任务。有能力的项目团队能够根据管理者给出的指导原则创建自己的目标，能够以一个团队的方式设计出独特的方案找到解决问题的出路。

        互动-重新思考最好的交流方式 

 

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

        传统上：人们通过各功能阶段（分析，文档，编码，等）的百分比报告。我完成了-90%

        敏捷：迭代结束时，通过review会议作出决策。

        文档：敏捷不是不要文档，有些文档是不经济的，在构建过程中会产生设计的变化，产生过期的文档，要产生有价值的文档考虑因素比如：用户要求的，员工离职，政府法规，等。对于团队来说，编写并维护一份系统原理和结构方面的文档将总是一个好主意.

 

    3.同客户协作胜过合同谈判

        很多项目朝着死亡进军，每周工作80小时来满足合同中的截止日期，客户也会发现自己正在做一些没有意义的工作，仅仅是应为遵守合同协议，，

        另一方面敏捷方法上的客户协作，已经成为开发过程的组成部分。

 

    4.变更的响应胜过遵循计划

        传统上：所有需求都是被实现规定的，它被分解到任务并得到评估，成本和完成日期是根据这些粒度较细的任务通过自底向上的计算得到的，计算得到的进度计划成 为项目的一个基线，用于度量项目的性能。控制范围蔓延在计划驱动中非常重要。应为这样才能消除成本超支和进度拖延。

        敏捷：并不是说计划不重要，敏捷团队专注于制定计划和再访问这些计划，敏捷方法中的计划更加遵守波然起伏似的计划，采用自顶向下的策略。

 

三、12条敏捷原则

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

    2．即使到了开发的后期，也欢迎改变需求。 
    3．经常性地交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好 
    4．在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。 
    5．围绕被激励起来的个人来构建项目。 
    6．在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。 
    7．工作的软件是首要的进度度量标准。 
    8．敏捷过程提倡平稳的开发节奏；发起人、开发者和用户应该能够保持一个长期的、恒定的开发速度。 
    9．不断地关注优秀的技能和好的设计会增强敏捷能力。 
    10．简单化是根本（不做过度设计和预测）。 
    11．最好的构架、需求和设计出自于自组织的团队。 
    12．每隔一定时间，团队会在如何才能更有效地工作方面进行反思并对自己的行为进行相应调整。

 

相关链接: CSDN:   敏捷十年简史回顾——影响敏捷开发历程的27件事

 

图1