为什么敏捷开发(为什么敏捷开发在亚洲实行不了 开源中国)

为什么那么多程序员讨厌敏捷开发

因为敏捷开发在实施中需要考虑很多因素，而这些因素暂时达不到要求，强行开发敏捷对互联网来说并非有利。

1.敏捷开发产生是源于企业软件交付的诸多难题，比如变更、缓慢、高成本等。这类交付大多以项目形式组织、以产品为结果。

2.项目有两个核心特征“为客户服务”、“一次性”。

3.项目的发起是从客户需求出发的，这隐含了客户必定是存在的，而且是明确的，通常客户是一个人或一个公司的需求提出人。通常是一对一服务的。他们的需求一般也是明确的，至少方向是明确的。

4.所以敏捷开发中“客户合作”、“客户现场”等都是对客户重要性的确认，一旦客户不存在，例如自主产品研发早期还没有用户的时候，需求的挖掘、产品的验收就都成了问题。

5.项目一般是为一个确定目标所完成的一次性活动，所以项目是以客户验收为结束标志的。然而产品因为存在大量用户，它是持续交付的过程，再加上产品的更新换代，还需要对老用户进行升级。

6.敏捷开发中强调“客户验收”的重要性，要求与客户频繁验收，从而尽早发现问题，尽早调整，减少返工浪费，同时收敛项目范围。但这并不是用于产品，因为产品的功能是越做越多的，不断发散，同时还无法快速与用户验收，甚至无法验收，因为用户太多，不知道以谁为准，或者用户拒绝对未成形产品验收。这都让敏捷开发更多的局限在项目交付范畴之内。

参考资料

百科.百科[引用时间2017-12-28]

敏捷开发是为了解决什么问题出现的?

传统开发方法是基于客户能够在需求阶段就给出完整、准确的需求的假设，所以期望于在项目初期获得详细的需求，然后严格控制需求变更，最终完成符合需求的软件。

但我们发现实际上往往需求是“涌现”出来的，也就是说是随着开发的不断进展而不断发现出来的，而无法在项目初期就明确的定义它，也就是说传统开发方法的基本假设是错误的，这一新的假设导致了敏捷方法的一系列实践。

另外，传统的软件开发方法认为需求是可以确定，所以采用的是基于工程的开发方法，也就是说期望通过事先的详细策划定义开发的整个过程，而敏捷认为需求是无法在早期完全确定的，所以采用的是基于经验的开发方法，也就是说事先不详细定义整个开发过程，而通过多次迭代来逼近最终目标

为什么敏捷开发不采用增量的方式设计体系结构?

敏捷开发不采用增量的方式设计体系结构的原因：增量开发通常都不会成功，根据变化重构构件通常相对容易。

敏捷开发不利于架构设计，不会编写那些融入了很多设计模式的具有良好的扩展性、足够灵活并且易维护的代码。增量开发是逐步构建的过程中,有迷失全局的风险。敏捷开发有多种方法。这些方法将系统/产品的开发分解为小的增量/迭代。这种中断使您可以减少实施前所需的规划和设计量。在每次发布/迭代时，产品发布到生产中，对系统必须满足的需求的感知发生变化，重新制定系统规划，纠正其进程以达到新的目标，上一个增量的释放。

敏捷架构本质上是一组积极支持系统设计和演进架构的价值观、实践和协作。这种方法采用DevOps思维方式，允许系统的架构随着时间的推移不断演进，同时它支持满足当今用户的需求。敏捷架构是关于设计/选择系统的结构组件和标准，使其能够响应其构建过程中感知需求的变化。

为什么敏捷开发在中国实行不起来？

Joshua Partogi是scrum.org的一位资深敏捷教练，他最近就这个话题写了一篇文章，说亚洲的大多数银行都没有把敏捷开发推行得很彻底，Partogi就这个问题给出了一些解释。

最主要的原因是大多数亚洲人都对现在的管理文化很熟悉很习惯。

他们知道自己在组织中的角色，也知道在什么样的情况下该怎么办事。有人希望有人告诉自己该干什么，也有人总想指挥别人干事，整个组织工作井然有序。亚洲人习惯于和自己的伙伴保持和谐的关系，避免冲突，这就影响了亚洲的敏捷小组在从事敏捷开发时的工作方式，包括迭代计划、迭代回顾及日常敏捷工作 等。据Partogi说，人们习惯于保留意见，因为他们无法适应一个他们可能会犯错误的环境，即使在这样的环境下犯错误也无所谓。

Claudio Caballero是Goodwill Group Foundation的CTO，他在博客里写过一篇文章《在亚洲推行敏捷开发遇到了大困难》，也提到了一个原因，就是亚洲人是羞于当面说出逆耳之言的。敏捷开发需要大家当面直言问题所在，而这有悖于亚洲文化，因为亚洲人特别注意对别人表示尊重、给别人留面子，这一点与西方文化特别不同，而西方正是敏捷思想的发源地。

Partogi说亚洲的教育机制也影响了人们在工作中的思考方式和行为。

亚洲的教育完全都是为了考高分、定级别，而不是为了尝试、自我发现和试错，可这些却正是敏捷实践的目的所在。Partogi说到因为很多公司都把项目外包到亚洲去，他们想通过采用敏捷来减少成本。可实际上敏捷需要非常高素质的队员，这些人恰好通常不便宜。那么只要大家仍然误以为转用敏捷开发方式会减少成本，在亚洲敏捷就推行不下去。

为什么敏捷开发会让人感觉这么难

敏捷开发最重要的特点是：以用户需求为中心，快速灵活，团队合作度高。

觉得难可能是实践路子不太对噢~

敏捷开发有很多方法，例如XP、精益开发。其中以scrum最为普遍。Scrum本义为带球过人，双方队员比赛前要摆开阵势，计划好进攻路线，而在软件开发中，团队领导人要做好迭代计划，排列优先级，规定必须完成的任务。

scrum3.0中有6个角色，3个工具，4个会议。

scrum3.0中的6个角色

利益相关者(Stakeholders)：

运营、市场、销售等，他们负责向产品经理提出产品需求。

业务所有者（Business Owner）：

通常是产品经理，他负责对利益相关者提出的需求进行拆解以及进行优先级排序，并负责后期的产品评审，同时负责预测一个sprint周期的时间。

团队队长(Team Captain)：

通常是我们的开发经理，负责安排一个sprint内的工作安排，通过合理安排让scrum团队的效率以及价值最大化。

行业专家(Subject Matter Experts)：

行业专家拥有Scrum团队需要的，但团队中没有的知识和专业技能。

协调人/教练(Facilitator/Coach)：

scrum制度的落实者，让scrum在团队中流畅的运作，消除他们的障碍，提高Scrum和敏捷的使用。

变更代理 (Change Agent)：

Scrum的咨询顾问，将Scrum引入团队中，并帮助教练理解如何最好地支持和与Scrum团队合作。

3个工具：交付清单、工作清单、正在进行的工作。

4个会议：计划会议、产品评审、进度回顾、团队回顾。

因此，scrum3.0既有计划会议、产品评审、进度和产品回顾会议，也有迭代期内的灵活应变过程，是一种轻重结合的比较好的敏捷方法。

随着各种敏捷团队在国内成熟，很多应用于敏捷的工具也层出不穷。

在工具集中挑选适合的工具使用，可以提高工作效率。以日事清团队为例：

在日事清软件中，利益相关者如销售、市场、运营等，在与用户平日的接触中积累的功能、缺陷、创意上的建议，并收集于计划看板的【BUG看板】、【建议看板】。

接下来，业务所有者(BO）需要维护精细的需求池，这个职责通常由产品经理担任，他需要非常明白产品的定位和发展，将需求池中的任务按照优先级排序，并拆解为一个个小的用户故事。然后设置具体的实施时间和项目名称，将可交付成果和待办清单，记录于road map中。

之后，我们的scrum团队会创建一个计划为【产品开发】，产品经理（业务所有者）以及开发经理（团队负责人）会从【roadmap】中提取功能形成work backlog，复制到【产品开发】的【规划池】中，work backlog中还包含一些开发团队必须做的工作，会直接记录在【规划池】中。

正式开始开启sprint （sprint：整个开发过程中若干个短的迭代周期组成）的第一件事，就是召开sprint计划会议。sprint会议上会确定本次sprint周期的目标是什么，我们需要完成哪些功能。在会议中，开发经理（团队负责人）需要将【规划池】中的功能拖动到【开发中】，从【开发中】到【测试中】就是日事清所实践的正在进行的工作(WIP)。

会议上会评估每个功能所需的工时以及功能的负责人，我们为确定好的功能添加时间以及任务成员。通常计划会议会开比较长的时间，它是之后迭代开始运作最关键的会议。

为使得这个会议得到很好地传达，可以通过日事清的日程应用创建好会议任务，并下发给团队成员。

sprint计划会议的开启，意味着第一个sprint开始了：从开发到测试，形成的工作成果都发布到beta版本中。执行sprint的过程中也有很多问题被发现，需要解决，应此需每日召开约15分钟的站立会。

在每日站立会上，每个团队成员需要回答三个问题：

● 昨天做了什么工作？

● 今天要做什么？

● 完成目标是否存在什么问题？

当测试人员完成了本个周期内的所有功能的测试工作时，预示着本个sprint结束。

在迭代结束前，产品负责人需要进行产品评审，产品会对测试中的功能进行验收。将达到了产品目标的成果拖动到【待发布】中。

最后整个团队还需要进行一次回顾总结会议，回顾这次迭代有哪些做的好，哪些做的不好，有什么计划。团队成员需轮流发言，完成自评和他评，分析和总结上一个迭代中遇到的问题，并列出下次的可执行任务，便于改进整个团队的效能。

至此，一个sprint周期完成，以此开始下一个sprint，不断循环往复。