月泉的博客

敏捷开发概念

字数统计: 2k阅读时长: 7 min
2019/06/04 Share

敏捷宣言

以下是根据Agile Alliance(敏捷联盟)一批专家以及多年的经验所总结
原文如下

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

译文如下

  • 个体和交互 胜过 过程和工具
  • 可以工作的软件 胜过 面面俱到的文档
  • 客户合作 胜过 合同谈判
  • 响应变化 胜过 遵循计划

接下来谈谈我的理解

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

个体我这里狭隘的理解为人而不是独立的物,交互即为沟通,人是要大于过程的,团队中如果没有优秀的成员而空有一套优秀的过程也难以做成功一个项目,反过来说一个非常差的过程也可以使一个优秀的团队失去效用。也就是说有优秀的成员但这些成员不能像一个团队般的进行工作也是不行的。

团队成员并非都要是一流的程序员,但基本上实力不要相差太远,必然要有强有弱,强也需度,弱也需度,团队能够有好的合作、沟通、以及交互的能力要比那些水平相差较大或全顶尖程序员团队但相互之间不能很好交流的团队更容易获得成功。

团队的构建要比环境的构建好得多,假设一下如果先构建环境,“环境”作为一个名词是指与周边有关的事物,空有周边没有与之相关的事物,就如空中阁楼等同于脱离实际的空想,多数管理者都犯了一个错误,都是先创建环境然后再去构建团队从而期盼团队自动凝聚在一起,其实应该先构建团队,在根据团队来构建环境。

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

首先声明,没有文档的软件就是一坨狗屎,当然文档也不需要时时和软件进行同步更新,也不需要非常细致,只需要这份文档短小并且足够突出主题,不要太过于注重文档的质量而导致进度的拖延,所以可以遵循文档第一定律“直到迫切需要并且意义重大时,才来编制文档“ 当然这条定律并不是用来逃避编写文档的,而是帮助你何时应当编写文档。

前期一份短小且有足够突出主题的文档是非常重要的,仔细思考一下,如果有一份足够细致的文档(花费大量的精力)当团队出现新成员的时候,大多数情况大家都会认为文档足够细致了不需要为他见解只需要将文档丢给他,这种做法就像是给一个刚学Java的人丢一本《Java编程思想》,给刚学Rust的人丢一本《Rust编程之道》,但一份简短而又足够突出主题的文档相反可以让团队成员紧挨新人帮助他们以及近距离交互使他们能够最快的速度成为团队中的一部分。

客户合作 胜过 合同谈判

软件这个东西非常的复杂,并不能像买东西一样,列个清单就完事,买瓶沐浴露选一下牌子闻一下香味价格合适就买了,而软件不同,你不能说淘宝不错,我要买一个淘宝,谷歌很不错我要买一个谷歌,亦或者是说以一个固定的价格和固定的时间去开发它,这当然是所有管理者和甲方客户所期望的,但现实并不如此,基本上抱有这种想法的项目都会以失败而告终,不要期盼开发团队消失一段时间,然后出现时给你带来一个你想要的产品,这种产品通常都是劣质或者说是失败的,想要最成功一个项目最好是以版本迭代的形式让客户也参与进来,例如三天一版,一周一版,发送给客户然后客户给一个改进清单,这样形成一个循环,成功的项目需要有序、频繁的客户反馈。

一个指明了需求、进度、项目成本的合同存在一个非常本质上的缺陷,合同中指明的条款在没有实现之前都是没有意义的。

响应变化 胜过 遵循计划

响应变化的能力就等同于一个项目的成功与失败,构建计划的时应该保证计划的灵活性,不要将细致的计划定太长,这样会导致计划难以修改,就比如我一口气制定了一个月的计划,中间我有一天修改了,那么后面的都需要跟着修改,很多人会去依赖甘特图,也许是觉得这种图能够表现每个人具体的工作量以及掌控项目的权力,他们觉得有安全感可以对时间进行偏差调整,但是这张图实际上在客户发生需求变化时这张图中的有些任务就会变得可有可无。

计划这种东西应该做短期内的细致计划来保证足够的灵活度来响应变化,粗略的了解一下中期内的目标,以及长期的战略。

我把计划这种东西分为了三节:短期=计划、中期=预热、长期=战略

敏捷原则十二条

以下是根据Agile Alliance(敏捷联盟)一批专家以及多年的经验从宣言中总结出来的原则,原则如下:

原文

  • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  • Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  • Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  • Business people and developers must work together daily throughout the project.
  • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  • Working software is the primary measure of progress.
  • Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  • Continuous attention to technical excellence and good design enhances agility.
  • Simplicity–the art of maximizing the amount of work not done–is essential.
  • The best architectures, requirements, and designs emerge from self-organizing teams.
  • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

译文

  • 我们最优先做的是尽早的、持续的交付有价值的软件来使客户满意。
  • 即使到了开发后期,也欢迎改变需求。敏捷过程利用变化来为客户创造竞争势。
  • 经常性的交付可以工作的软件,交付的间隔可以从几周到几个月,交付的间隔越短越好。
  • 在整个项目开发期间,业务人员和开发人员必须天天在一起工作。
  • 围绕激励起来的个人来构建项目。给他们提供所需要的环境和支持,并信任他们能够完成工作。
  • 在团队内部,最具有效果并且富有效率的传递信息的方法就是,面对面交谈
  • 工作软件是首要的进度度量指标
  • 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度
  • 不断的关注优秀的技能和好的设计会增强敏捷能力
  • 简单–使未完成的工作最大化的艺术–是根本的
  • 最好的架构、需求和设计出自于组织的团队
  • 每隔一段时间,团队会在如何才能更有效的工作方面进行反省,然后相应的对自己的行为进行调整。

原文作者:yuequan

原文链接:http://www.lunaspring.com/2019/06/04/agile_intro/

发表日期:June 4th 2019, 10:39:09 pm

更新日期:June 20th 2019, 4:04:37 pm

版权声明:© 月泉 - 邓亮泉 版权所有

CATALOG
  1. 1. 敏捷宣言
    1. 1.1. 个体和交互 胜过 过程和工具
    2. 1.2. 可以工作的软件 胜过 面面俱到的文档
    3. 1.3. 客户合作 胜过 合同谈判
    4. 1.4. 响应变化 胜过 遵循计划
  2. 2. 敏捷原则十二条