java敏捷开发的优缺点_你如何理解敏捷开发？

当你以300km/小时的速度飞奔的时候，敏捷就显得至关重要，因为这是你闪避前方障碍物唯一的保障。

敏捷不只是快，更是规避风险。敏捷开发也是如此。敏捷，拼音是mǐn jié，意思指反应(多指动作或言行)迅速快捷。

如：敏捷地跳上敞篷车，敏捷地翻身上马，敏捷地躲过攻击。

出自《汉书·酷吏传·严延年》：“延年为人短小精悍，敏捷於事。”

现在我们通过虚拟一款“知鸟”的APP来了解敏捷开发——这是一款通过拍照就可以识别鸟类具体信息的艾普。

敏捷开发的第一步，并不是先跑起来，而是确定项目的关键章程。

第一步：关键章程

1.项目的远景——为什么做这个项目？引发项目的最初想法是什么？

2.项目的任务——创建一个尖端的技术平台，将网页、手机应用程序和位置感知功能结合起来，帮助用户识别鸟类。

3.成功的标准——在初始版本的三个月内注册10,000个用户，第一年就注册10万用户。在一年内识别出5000只鸟。第一年有99.999%的正常运行时间，并得到一位鸟类学专家的认可。在第二年创造一个年收入125万的高级版本。

第二步：创建用户故事

虚拟出一位用户，她的性格、喜好、说话方式，甚至她喜欢的电影都可以融入虚拟画像之中。

虚拟用户的说话方式以“我想/需要/可以”为开头。比如虚拟用户会说：“我想看到高级会员的好处列表，这样就可以看看是否值得花费这个成本。”

这里可以用到极限编程的3C方法：卡片(Card)、对话(Conversation)和确认(Confirm)。卡片的正面写着虚拟用户的“我想/需要/可以”。团队与卡片进行对话，并在卡片背后写下用户需求的验收标准。

第三步：有效的用户故事

如果创建的用户故事并不符合，对敏捷开发来说，这已经飞出了跑道。

有效的用户故事分为6个部分：独立、可协商、有价值、可估计、轻量级、可测试。

独立：其中一位虚拟用户从拍摄到识别的整个体验流畅(寻找继续优化的方案)；

另一位虚拟用户从拍摄开始就遭遇到了诸多问题，比如应用启动过慢、拍摄识别的过程出错等等；

可协商：开发团队与产品经理进行协商。开发人员应该决定通过用户故事交付其中价值的最佳方式。

有价值：提取用户故事中最有价值的部分，没有它，就无法进行优先级排序，也就没有办法完成整个故事。

可估计：当开发团队不能准确虚拟与用户的对话时，通常意味着对话跑题或描述不准确。通常，与用户的对话越短，就越清晰。

轻量级：对话越清晰、简洁，团队就越容易理解它所包含的一切。这使得团队更容易进行评估。

可测试：像“简单”、“干净”、“容易”、“快”、“好”这样的词，只会让评估变得更加困难。使用3C卡片背面的验收标准，比如“列表将一次返回10条记录，这样鸟类查找器就可以识别它们。”

第四步：相对估计

相对估计不是为精确而设，它只是提供一个起点。

就像你猜不出一头狮子有多重，但你能估计它≈三只或四只狗的重量。

相对估计能消除精确带来的虚假舒适感，接受估计将是不精确的。如果你告诉同事回家只需要20分钟的承诺，你不会担心同事冲进你的办公室指着你的鼻子说她用了30分钟才到家。

承诺通常是给主管的东西。

因此使用简单方法来做最佳的猜测，而不是浪费时间制定“精确的时间表”。

这是一种：“你不知道没关系，现在是时候猜了”的方式。

第五步：规划扑克

用于对抗群体思维，帮助每个人发声并游戏化，这样可以对用户需求做出相对评估。每位参加者都有一副扑克牌，采用指数数列，许多团队使用斐波那契数列1、2、3、5、8、13和？、举手。(？意思为不明白用户需求，举手意思为对此条需求有新的想法)

团队确定一个较小的需求，并将其赋值为2，这将是估计的基线。

评估最高和评估最低者向其他成员说明他们的道理。比如同一任务，一位开发人员预估要5小时，另一位开发人员预估要1小时，需要他们各自说明。

整个团队都需要参加评估，产品经理将进行记录。

评估过低可能是团队成员不了解某个任务，“规划扑克”能让他们有机会说明。

第六步：规划冲刺

冲刺本是切分成段的马拉松，并不是每次拼尽全力的百米狂奔。可以准备一个类似Word表单的白板，将第一列标记为“需求”、第二列是“To Do”、然后是“Doing”和“Done”。

每个任务应该按天数计算，如果有8个需求，意味着需要8天。

这些应该让团队用直觉来完成，比如一个用户需求从设定到验收完成可能需要2天，另一个需求可能只需要半天。

通常，团队至少需要6个月才能到达1天准确设定1个需求的工作标准。

第七步：编写计划如果让你选，你会选择用几个月的投入为可能永远不会存在的软件编写全面的文档，还是选择几个月后拥有有价值的软件。

软件有价值，没有软件的文档几乎没有价值。

敏捷团队应该不断的编写文档，而不是等待最终的草稿。

编写文档的主要目的是确保项目成员能够理解工作。

所以，所有的文档都应该是协作的，不应该是扔在别人桌上的活页夹。

而且团队不应该通过创建文档来实时了解项目。敏捷团队有许多方式可以深入了解项目，比如每天早晨15分钟的站立会议等等。

最后，避免：“我们没有计划，我们很敏捷”

敏捷确有规划。

它只是不同于传统项目的管理规划。

通常团队成员更喜欢开始工作，而不是计划工作，很少有开发人员真正喜欢编写文档。

这时候，团队的心态将是决定你的组织能否成功实施敏捷的关键。

如果你能改变你的思维，那么你就能改变你的工作方式。

如果你改变了你的工作方式，那么你就能变得更加敏捷。

所以，敏捷是一种可以改进而不能完善的心态，你的团队将始终处于敏捷之旅。