短暂的

您负责交付公司最新、最伟大的计划，这将永远改变“Widgets International”的面貌. 这是一个软件项目，将吸引和吸引你的客户, 让你同事的生活更轻松, 并为公司带来数百万的收入. 人们充满了期待、热情、兴奋和期待. 你需要尽快完成它，这样你的企业才能开始收获收益. 公司未来的成功全靠你了. 所有的目光都集中在你身上. 你不能失败.

一开始，你会对自己说:“太棒了，我准备好迎接挑战了. 让我们把这件事做完!你停顿了一下，退后一步，对自己说:“好吧，那我们该怎么做呢??“你开始和你的同事和同事交谈. 你花时间寻找最佳实践 软件开发 和 项目管理 技术，但选择和方法是无数的. 有很多首字母缩略词和方法. 值得注意的人会上升到顶端. 怀疑悄然而至. 我们应该用哪一个? 我怎样才能保证成功? 如果我做了错误的决定怎么办?

当涉及到管理软件项目时, 有各种各样的观点支持着各种各样的选择. 房间角落里传来窃窃私语, “Try doing it this way”; others shout, “This is the only way to do it”; 和 the rest just whimper, “根本就不要管它, 继续做吧.事实上，所有这些声音都说明了一些事实. 当开始一个敏捷项目时, 特别是, 重要的是找出适合你需要的东西, 你的团队, 你的业务, 还有你的客户.

场景设置

曾经有一段时间，软件项目管理完全属于三个阵营之一. 有一些沉重的框架可以让您决定如何执行和交付，同时提供维护控制和治理的结构. 有一些规定性的顺序方法，比如 瀑布 这迫使你计划冗长的项目, 理解并遵守你的所有要求, 设计和签署复杂的系统, 编写大量代码, 然后测试(在你的客户第一次看到它之前). 最后，较少规范但迭代的软件开发生命周期(SDLC)，鼓励快速原型或设计更大的系统, 建, 并逐步交付, 每座建筑都在另一座建筑之上.

敏捷软件开发 敏捷项目管理诞生于瀑布方法的不足和软件交付迭代方法的好处. 他们的历史可以追溯到20世纪50年代, 70年代的思想领导力, 90年代的成熟, 00年代的收养. 2001年，一群从业人员和专家创建了 敏捷宣言, 旨在定义4个价值观和12个指导原则，以体现敏捷软件开发的精神并鼓励其发展. 它确实在进化.

现在，简单地称某事为敏捷并不是特别有帮助. 的 word, even in a software 上下文, means different things to different people or organizations. 有敏捷项目管理的定义、实现和解释. 每个拥抱敏捷的团体都倾向于给出自己的定义.

可以这么说，敏捷项目管理和敏捷软件开发是一组相关的行为, 按比例缩小的框架, 技术, 以及从根本上支持尽早、尽可能频繁地交付正确的工作软件的概念.

我之前提到过敏捷, 应用于软件开发或项目管理, 可以是不同的东西. 简而言之, 敏捷软件开发关注的是在业务常规(BAU)或项目环境中开发优秀的软件. 敏捷项目管理, 另一方面, 负责交付复杂项目(包括但不限于软件)所需的治理和控制.

有许多可用的敏捷软件开发方法，例如 Scrum, 看板, XP, 精益软件开发. 但是就像橄榄球比赛不仅仅是关于scrum一样，敏捷也是如此. 在隔离, 这些敏捷范例不能处理复杂项目(如治理)所需的项目管理的完整生命周期, 资源分配, 金融, 明确的风险管理, 以及许多其他重要的项目管理概念. 对于这些，您可能需要考虑 PMI敏捷 or PRINCE2敏捷-可以将其视为“受治理的敏捷性”.”

为什么我们需要敏捷?

很久以前，我们在这片土地上游荡，收集食物和住所来生存. 它们是简单的需求，但非常灵活. 一段时间后，国家和经济在经济增长和繁荣的背后 工业革命. 这是管理和控制的诞生和敏捷性的丧失. 现在我们在 信息时代还是革命在美国，企业雇佣知识工作者. 你是知识工作者吗?, 你的合作伙伴, 还有你的同事和同事, 谁努力为客户创造伟大的解决方案, 业务, 社会, 经济, 世界问题. 知识工作者应用分析, 知识, 推理, 理解, 专业知识, 和技能，往往是松散定义和不断变化的需求. 这些企业和工人需要旧工业时代的流程和程序无法满足的方法和技术. 敏捷支持交互.

实际上，没有一个软件项目能够自信地在一开始就制定好计划，并且知道它所需要的一切，以便在不进行更改的情况下交付有价值的工作软件. 变更为项目的成功提供了机会和风险. 不受管理的机会可能意味着一个伟大的公司和一个令人敬畏的公司之间的差异. 不受管理的风险意味着灾难和毁灭. 敏捷管理变更.

采用敏捷使您能够对变化的或新的需求做出响应. 它使开发团队成为专家，并在参与者的支持下做出决策, 信任, 知情商业. 它使您能够向客户提供他们真正想要的东西. 最终, 它使您和您的组织能够控制交付高质量的产品, 有价值的软件，交付客户的需求和期望，同时提取您的投资回报尽早. 敏捷创造价值.

采用敏捷是有代价的. 它不是免费的. 将软件交付转变为敏捷方法可能是一条艰难的道路. 然而, 如果你内化了敏捷哲学, 谨慎行事, 用正确的态度与正确的团队合作, 把事情分解, 让目标切实可行, 并对反馈做出回应, 你会得到回报的. 敏捷强调协作.

以下列出了一些你可以期待的好处:

• 加速上市
• 较早创收
• 定期交付真正的价值
• 保障您的投资
• 数据，数据，数据
• 更好的产品质量
• 可控的期望
• 更高的客户满意度
• 更高绩效的团队
• 改进的进度可见性
• 可预测性、透明度和信心
• 可控的风险

成功不是终点，失败也不是致命的，重要的是继续前进的勇气.

温斯顿·丘吉尔可能从来没有说过这句话, 但我认为这是对敏捷的一个很好的总结. 我们知道敏捷对于大多数项目来说是最好的一步. 它鼓励你为成功而奋斗，但我们总是在此基础上不断迭代和发展. 敏捷会鼓励你失败，但要早点失败，然后继续前进. 有勇气继续并根据客户的见解构建正确的解决方案，这将带来回报.

要记住的是，您可以根据自己的需求定制敏捷. 使用适合您业务的方法和治理. 无论你从哪里开始, 忠于内容, 上下文, 你使用的方法的精髓是，保持香草味. 如果你刚开始工作， 学习. 如果你已经做了一段时间， 理解. 如果你变得很棒， 应用. 最后，如果你的业务和项目复杂且相互依赖， 管理. 随着时间的推移，您和您的团队将找出最适合您的业务的方法.

可行性

所以现在你会想，“好吧，我明白了. 我该如何开始? 我从哪里开始呢??“好吧，所有的好事，我们都要从头说起. 对于敏捷，你可以问自己“我想要交付什么业务价值??“毕竟，这就是我们承接项目、创造商业价值的原因. 为了确定项目是否值得进行，从而得出商业价值, 你需要了解它是否可行.

愿景

你的项目会增加收益吗, 进入一个新市场, 获得更多客户, 改善顾客认知, 或者让你发现的问题变得更简单? 记住这一点，你就可以陈述你的“愿景”了.”

• 你的愿景可能来自不同的来源——你自己大胆的创业来解决一个共同的问题, 企业管理策略, 你CEO最喜欢的项目, 一个特定的产品团队, 甚至是客户的需求.
• 试着从自己的角度退后一步，“看看”你的新产品或服务在客户手中的未来是什么样子.
• 让你的利益相关者——CEO、产品负责人和客户——参与进来. 研究它，不要孤立地尝试. 挑战假设并验证论点.
• 写下来，保持简短. 关注业务价值.
• 不断完善它，直到大家都同意这个愿景与大家产生共鸣，并达到一个共同的解释，说明你的前进方向.
• 你的愿景，如果有效的话，很少会改变. 你怎么才能到达那里.

人们买的不是你做的东西，也不是你怎么做的. 他们相信你为什么这么做. 这就是在你的企业和客户之间建立情感联系的原因. 这个愿景将有助于说明这一点.

可行吗??

可行性至少有几个方面. 通常, 你会想要了解，你对企业和客户更光明未来的愿景，在技术上是否可行，对你的企业来说，实现它是否可行.

• 如果你的愿景是在一小时内到达世界上任何一个地方, 你们可能在技术可行性上有问题. 因为科学, 物理, 科技还没有完全赶上这个梦想, 你的技术解决方案可能只是理论上可行. 此外，如果您的解决方案是新的，那么这将远远超出a的概念 最小可行产品 (MVP).

• 测试你们产品的技术可行性, 可以考虑在Discovery原型项目中进一步探索它，或者通过运行 斯派克 在项目的早期阶段. You’ll know which method to use by 认为ing about the scale or complexity of the solution you have in mind.

  “我的团队在理解技术可行性方面获得的一些最好的知识来自于执行峰值. 通常，最简单的解决方案会胜出!”

• 第二个要考虑的可行性因素是你是否, 你的团队, 或者你的企业有能力和动力去实现它. 举个例子，如果你很擅长在家里为孩子的生日烤蛋糕，那就很甜蜜. 但如果你想把它变成一门生意，卖给全世界最好的蛋糕, 你需要了解你是否能够将其规模化, 处理业务和生产, 管理分销和履行, 还要做好客户服务.
• 从长远来看，这种愿景是可以实现的. 但就目前而言，可能不会. 所以缩减规模, 认为小, take a small chunk that looks realistic 和 concentrate on 交付ing the best smaller aspiration you can. 如果这能够吸引并取悦你的客户, 让他们回来买更多，并告诉他们的朋友, 然后在此基础上扩大规模，将客户反馈作为你的指南和指南针.
• 此外，你需要知道你的项目在预算和时间框架方面是否可行. 你的公司能负担得起交付这个项目吗 ? 这个时间表是否可行? 在敏捷项目中，时间和金钱是三个固定约束中的两个. 我们的目标是在给定的固定时间和给定的固定预算内交付.
• 产品的质量是指您的客户使用的最终产品，以及您的团队用于交付出色产品的工程实践, 健壮的, 以及可靠的软件. 质量也是我们不会亏欠的东西. 另一方面，质量标准是可以改变的. 如果你不打算造一辆法拉利，你的产品可能不会有高质量的感觉. 如果你不是在建造太空火箭, 那么在生产条件下达到的公差可能会高得多. 尽早设定适当的基调和期望.

所以现在你已经确认了你的梦想不仅仅是巧克力的幻想, set about 测试 your assumptions 和 proving to people that this endeavor is worth investing in.

的理由

现在，根据你的情况，辩护会有不同的形式. 但本质上, 您想要证明这个项目将满足客户的成功标准, 有成功的机会吗, 会带来价值, 而且价格合理.

• 根据客户的需求陈述你的假设，然后验证它们. 的 精益创业 在识别和证明你的产品是你的客户所需要的，并将创造价值方面提供了很好的指导.

• 编写、测试和验证你的商业计划. Now this looks nothing like the ones your bank or 你的业务 和 finance major told you to produce. 别用了——墨水还没干就过时了. 相反，请查看 商业模式画布. 这本质上是一个简短的商业计划，让你专注于你的价值主张, 你的客户, 收入, 和成本. 用它来验证你的生意是否可行.

  “I ignored this advice once 和 spent a long time writing a lengthy traditional 50 page 业务 plan. 这让我一无所获. All the assumptions I had made were unfounded, all the projections I made couldn’t be validated. 这是一次痛苦而昂贵的经历，它教会了我再也不要这样做了.”

• If you’re in a mature 业务 with portfolios of projects being 交付ed in a complex environment, 那么金融建模可能是必要的. 如果你必须这样做，只有在你证明了以上几点之后.
• 一旦你建立了你的MVP, 例如，可能有一个创建更传统的商业计划的案例, 如果你必须在公司的竞争项目和资源组合中寻求资金或选择. 但这将是一个基于以上所使用的工具的商业计划. 它也会更轻.
• 在任何情况下，使用这些工具作为活的，呼吸的工件. 把他们当作你的向导和风向标. 它们从来不是静态的. 参考它们，并随着项目或业务的发展而修改它们.

一旦你有了理由，所有的利益相关者都同意了，你就会火起来.

可行性阶段通常在项目的生命周期中执行一次. 您可能会重新审视项目的愿景和可行性, 特别是如果你的数据, 客户, 市场, 或者商业表明是这样的. 至少，他们会一直是你的指路明灯.

初始化

太棒了. 决定已经做出，项目已经开了绿灯，你可以开始建造了. 嗯,近. 我知道你在想，“来吧，真的? 如果我们现在不做，就永远不会做了. 让我们开始表演吧!但是考虑到这一点——如果不是尽早交付价值，并且经常在此过程中取悦客户，敏捷就什么都不是. 花点时间找出交付项目的最佳方式是成功的最佳基础.

这个团队

在体育, 想想你最喜欢的团队比赛, 您将能够识别使团队能够正常工作的关键角色. 传统上，你会看到一个经理，一个队长，和其他队员. Outside of that, you’ll find coaches, physios, nutritionists, an assortment of 支持ing staff. 但是如果我们看一下橄榄球比赛，一个团队中有一个团队:球员们组成了 scrum. This pack is made up of designated players whose job it is to win the ball back 和 continue play. 当比赛进行时, 然后双方球员开始工作, 没有领导, 作为一个单一的单位进行协作, 自始至终, 尽可能高效地把球收回控球权. 是橄榄球运动激发了我的灵感 Jeff Sutherl和 将他的软件开发方法命名为“Scrum”.”

• Scrum并不是敏捷剧本中唯一的软件开发方法. 但它是最能描述敏捷概念和团队工作行为的, 激励人, 建立信任关系, 自组织, 仆人式的领导风格、沟通、透明和协作.
• 你的团队很大程度上取决于你所处的环境. 你可能有 开发人员 您可以使用. 他们中的一些人，没有一个人，或者所有人可能在不同程度上熟悉敏捷. 你可能想要雇佣一个新的团队或与第三方合作.
• 还需要其他角色，但我们稍后将讨论这些角色.
• 有人说，如果你组建了自己的开发团队，那么你就选择了自己的技术. 根据你的团队来自哪里，他们会有特定的技能. So, 仔细考虑您如何组建您的开发团队，以及在您的旅程到达这一点之前是否需要执行技术评估.
• 这给我们带来了跨职能团队. 团队在一起工作时工作得最好, 当每个人都投入到工作中，不管他们的头衔是什么. 试着建立一个自给自足的团队，每个人都扮演不止一个角色.
• 营造环境, 文化, 关系中心——团队可以交付的地方, 不受约束或限制的. 为团队提供有效和高效的工具、人员、资源和空间.
• 保持团队规模不超过7或8人. 如果你需要更多的开发人员，将团队分成多个新团队. 然后每个团队可能负责一个给定的功能区域. 如果你在多个地点有多个团队，可以考虑举行Scrum of Scrum. 如果在复杂的环境中有很多这样的项目，那么就使用敏捷项目管理.
• 确保团队、业务、涉众，甚至客户能够相互访问. 确保他们沟通和合作，并消除任何阻碍进展的东西. 日常沟通是治疗项目病痛的最佳方法. 当人们说话时，他们会把事情做完.

有许多方法可以将一个团队组合在一起来交付软件.

项目介绍

可行性步骤, 你找到了项目的“原因”，要么建立了继续创业的信心，要么得到了支持. 项目简介是一个活生生的文件，它将“为什么”、“什么”、“何时”和“谁”结合在一起.它是“活着”，因为随着你的进步，你的知识、理解和道路可能会发生变化. 一旦写完这份文件就离开，再也不去看它，只会让你的思想停留在一个时间点上. 在敏捷的世界里, 你的时间点参考可能每周甚至每天都在变化, 所以保持新鲜很重要.

• Jonathan Rasmusson在他的书中称之为“inception deck”，这是一个封装和维护项目简介的好工具 敏捷武士. 在这里, 你会找到很好的建议，确保每个人都感兴趣, 受, 或者参与你的项目的人在同一页上.
• 交付项目的最大敌人是有一个不明确的目标, 不一致的, or just plain different 理解 of what the project is 和 what “requirements” are to be satisfied. 即使一个重要的利益相关者对你正在做的事情有不同的理解或看法, 其后果可能是巨大的.
• 一个好的项目简介传达:
  1. 涉众和团队成员之间的共同和一致的期望.
  2. 对项目的理解，各方都有相同的理解.
  3. 目标、远景、目标、范围和项目环境.
• 你会从可行性项目中收集到很多有用的信息. 项目简介将帮助您定义并找到搜索问题的答案. 它将把利益相关者，你的 存在的理由、高级范围、风险、目标解决方案、预算、时间表、期望和优先级.

A colleague stopped me in a corridor once 和 asked me where he could get the project brief for the project. 我打趣道:“我们不需要简报，我们是敏捷的。”. 他看起来很困惑，好像在质疑我的理智或权威. 他这样做是对的.

在你继续之前, 确保每个人都在同一页上, 车间,, 问困难的问题, 把它钉在人们可以停下来的地方, 读它, 评论一下, 并帮助修改它.

文化和工作方式

你知道你的企业的运作方式和文化，以及它做事的方式. 敏捷, 就其本质而言, 可能会挑战你公司多年来培养的一些工作方式吗. 不要期望敏捷被实现，并且每个人从一开始就喜欢地采用它. 有些人可能会感到困惑，只会带着恐惧和恐惧来看待它. 有些人可能会公开拒绝参与其中. 这些都是你必须克服的挑战和认知. 但在你的早期, 不要到处挥舞着敏捷的大棒去打那些不听它的人. 这不会建立信任、采纳或参与.

我曾经是挥舞大棒的粉丝，这给我带来了很多负面报道. 我扭转了局面，但在此之前，我经历了相当大的痛苦.

当你踏上收养的道路时，要小心翼翼，尊重他人，并怀着同理心. 如果你从事的是一个老旧的传统行业, 也许这不是让整个业务保持一致的最佳方法. 从小事做起，逐渐赢得尊重和认可. 只从你的团队开始. 一旦你开始交付比以前更快、质量更好的软件, 人们会开始注意到你的游戏，并想要玩你的游戏. 当他们这样做的时候，给他们一个球，带他们出去喝杯咖啡，让他们慢慢进入你的新世界. 帮助他们.

和你的团队, 现在他们已经知道了项目是关于什么的，并且你们对敏捷采用的计划也达成了一致, 让团队决定他们希望如何作为一个团队行事和运作.

• 指导您的团队识别敏捷概念, 技术, 行为, 以及您认为符合您的集体需求的框架.
• 听取团队成员的请求，了解他们需要哪些需求来帮助他们尽可能地表现得最好. 其中一些请求，您将能够立即解决. 另外，你可能需要获得预算或外部帮助. 尽你所能让它发生.
• 这些是你成为一个真正的仆人式领导者的第一步.
• Consider organizing some appropriate training in the concepts 和 技术 你的团队 is choosing to adopt. 这是确保所有团队成员, 甚至是利益相关者, 是否在同一页面上并得到相同的信息. 与能够根据你的需求定制产品的供应商组织合作.
• 是明智的. 没有人会在几天的研讨会上学习如何成为敏捷的忍者. 你的路还很长. “成为”这个词很有定义意义. 只有当你真正拥抱敏捷时，你才会看到它的价值. 这应该会让你兴奋. 如果它让你兴奋，那就去让别人也兴奋起来.
• 既然你的团队已经就概念和技术达成了一致, 他们的愿望实现了吗?, 并且正在接受敏捷培训, 把你的团队的注意力转向他们自己，以及他们对你的期望, 业务, 彼此之间.
• 在团队内部和团队内部定义一些工作方式(WoW)有助于建立信任, 的关系, 和期望. 魔兽世界没有 战争与和平. 它应该简短扼要，在七到十个句子之间. 这些句子清楚地说明了人们的行为举止, 沟通, 合作, 支持, 交付, 一起表演. 它还应该说明团队对业务的期望.

• 敏捷既是一种思维方式，也是一种指导原则和概念. 它帮助你发展你的行为方式, 认为, 谈判, 交互, 沟通, 执行, 和改善. 它依赖于有动力的个人相互支持，以达到共同的目标，团结一致. 有一句非洲谚语:

到目前为止，你的团队应该非常兴奋，充满活力和动力. 现在，让他们进一步参与到积压的用户故事中来.

待办事项列表

毫无疑问，你的项目中存在不确定性. 在产品的早期阶段，你不可能确切地知道为客户打造合适的产品需要什么. 你不可能满怀渴望地盯着水晶球预测未来.

“待办事项列表”或“产品待办事项列表”是您的需求所在. 敏捷倾向于编写短小精悍的语句，抓住“需求”的本质.“积压只是一长串条目, 每个条目定义一个, 作为用户场景的离散“需求”. 从现在开始，我们将使用“用户故事”这个词，而不是“需求”.你可能会问“为什么”?“这是个好问题. 似乎是永远, 说明客户在软件项目中需要的特性或方面总是被称为需求. 这个词的解释在敏捷中没有任何价值. 牛津词典将其定义为:

必需品:需要或想要的东西. 或者，一个东西 强制; a necessary 条件.

不幸的是, 如果我们开始定义我们的解决方案, 说明事情是“强制性的”,“我们最终会陷入困境. 说所有这些用户故事都是强制性的，这太容易了. 如果我们持这种观点, we run the risk of running over schedule 和 over budget in the attempt to 交付 all of a given scope. 这样说没什么问题, 对于这个产品，这些故事是解决方案可行的必要条件, 我们只是想避免对这个词的解释.

• 总是从一个人的角度来写故事 角色. 角色代表解决方案的用户或涉众. 在开始待办事项之前，最好先开发这些角色.
• 在这个阶段, 只写简短的, 这些简单的陈述基本上是在提醒你，在合适的时机就用户故事展开更深入的对话.
• 真正的人会根据他们需要完成的任务来实现一个目标. 从人物角色的角度和他们需要做的事情来写你的故事.
• 你不需要写完整的待办事项——只要写尽可能多的你能想象到的你的客户需要你的产品是可行的.
• 您将在以后的产品生命周期中发现，用户故事会发生变化, 变得或多或少重要, 或者可以完全删除. 经常释放，得到反馈，评估什么是优先级，这些都将会影响你的行为.
• 不要孤立地写故事. 让你的团队，利益相关者，甚至你的客户参与进来. 故事可以在项目生命周期的任何时候更新，但应该避免在开发工作开始后进行更改.
• 你的一些故事可能被认为是“史诗”.“这些都是大故事，涵盖了很多内容, 并且会在接近交付时间时被分解成更小的故事.
• 考虑使用 投资 模型，用于验证一个好的用户描述的质量的检查表.
• 任何人都可以在待办事项列表中添加故事. 它应该放在底部，或者在一个专门创建的“停车场”.“这个额外的故事可以作为与团队和业务讨论的提示. 如果业务和团队支持它，那么就可以对其进行评估并确定优先级
• 您还可以考虑系统中风险最大的部分. 如果你有一个复杂的用户故事或功能, 新, 或者说是技术上的未知, 把这些放在待办事项的最前面. 这种方式, 你不会试图在第一次发布前几周交付产品中具有挑战性和关键的部分.

一旦你的待办事项满足了你的需求, 你可以估计其中的故事, 把它们按优先级排序, 制定一个发布计划.

高级评估和优先排序

高级评估是确定待办事项规模的过程. 项目有多“大”，它交付了什么价值? 优先排序是决定哪些故事对你最重要的过程, 产品的可行性, 以及客户的利益. 我们希望尽早交付最高价值的项目，从而为业务提供最大价值, 从客户那里得到反馈, 不要为小事担心. 输出将是按优先级和适当大小排序的有序待办事项.

• 顶部的故事被认为是最有价值的. 我们想尽早把最有价值的物品送到.
• 有许多用于确定规模和估算的技术, 但是在这一点上, 你只是想对故事的大小有一个良好的指示性感觉.
  • 使用t恤的尺寸，相对尺寸，理想的日子，或者故事点.
• 在这一点上，你也不会得到所有可用的信息，这没关系. 顺其自然吧.
• 与你的业务利益相关者或产品经理(如果你有的话)保持联系, 以及负责这项工作的团队.
• 我们想要那些将设计，开发，和 测试 需要对其进行评估，因为最适合评估的人是专家.
• 团队可能会开始将故事分解成更小的部分. 如果发生这种情况，请编写更细粒度但离散的故事.
• 团队也可能开始对一些故事进行排名, 很自然地，有些东西必须在其他东西之前交付，以支持技术或给定的用户旅程.
• 在您和团队之间，您也可能开始发现待办事项中需要填补的漏洞. 只要用新的故事来填补这些漏洞，并根据需要进行评估和优先排序.
• 使用MoSCoW分析最容易执行优先级划分. MoSCoW是一种简单的技术，可以帮助您确定哪些故事是产品成功的“必备”.
• 您可以在评估开始之前进行优先级排序. 然而, 某些元素的大小也可能决定优先级和实际业务价值的决策. 所以要把评估和优先级划分分开，但不要为此争吵!
• 没有两个故事能像另一个一样重要. 排名1的故事比排名2的故事更重要或更有价值.
• A great way to demonstrate the importance or value of a story is it to add a monetary value to it. 比如, 故事A被认为能带来5000美元的额外收益, 故事B可能吸引100美元, 那么故事A就更有价值. 同样，如果故事C比故事D更能拯救企业，那么故事C就更有价值.
• 一旦你确定了待办事项的规模，你就会得到一个数字. 当我们谈到发布计划时, that number will help us 理解 how much can be 交付ed by our team within a given timeframe.

请记住，您不需要预先了解所有的用户故事. 也, remember that it’s not necessary to 交付 all of your stories before a customer sees your product. 您希望保持敏捷——这意味着只在需要的时候创建您需要的东西, 尽量少浪费, 并对客户需求和市场情况的变化作出反应. 路线图将帮助你布局你的产品并计划你接下来的目标, 6, 9, 12个月.

路线图和故事地图

A 路线图 正如它听起来的那样，它提供了一个国家的路线图吗. 它详细说明了城市的相对位置(或者在你的情况下), 以及从A市到B市的路线, 或者特征X和特征Z. 它不会告诉你应该走哪条路，或者如何到达那里. 它没有告诉你使用哪种运输方式, 但它可能会说明选择高速公路或火车.

在一个城市里，有许多道路、建筑物、公园、服务和设施. 一个城市的所有特征. 你的产品路线图也是如此. 在这个层次上，您的路线图显示了要实现的主要目标或里程碑. 目标是主题的逻辑分组, 特性, 用户故事在一个可消费的视图中展示了有形的价值. 软件产品的路线图共享这个视图并传达您的意图. It doesn’t necessarily show you how or when 特性 will be 交付ed; only the relative value of the goals 和 特性 to you 和 你的业务.

演示路线图的一个好方法是生成一个 故事地图. 此工具指示客户重视的优先级. 它列出了产品的主干或基本构建块. 行走的骨架悬挂在脊柱上，并说明了使其成为MVP的特征. 所有其他功能都为系统增加了进一步的价值和重要性. 故事地图将特征放置在彼此的相对位置上，是一个很棒的视觉工具.

值得注意的是，在进行故事映射练习之后, 您的待办事项可能需要改进. 当故事被分割成多个故事时，这一点很明显, 被认为是多余的, 新创建的, 或者比之前认为的更重要或更重要. 故事地图是另一个不断被重新审视和修改的工件.

启动阶段通常在项目的生命周期中执行一次. 然而, 您创建的许多工具和文档将在整个项目中被重新访问和修改.

发布计划

“终于，”我听到你在哭，“终于，有些计划了。.“嗯, you have essentially been planning all through the feasibility 和 initiation stages; we just didn’t call it as such. 这是迭代或适应性计划的证据——只计划足以实现您的直接和最有价值的目标的艺术. 我们将在后面看到更多关于适应性计划的内容，但是现在发布计划是我们关注的重点.

您的发布计划很可能是由外部事件决定的. 也许你想在一个贸易展上展示你的应用, 或者你的客户在圣诞节前夕使用你的应用程序会获得最大的好处. 这些是你的目标可能与之一致的时间轴事件. 您很可能计划交付对促进这些事件最有意义的用户故事或特性. 如果没有需要考虑的外部日期, 然后你就可以按照功能优先级排序，尽早交付最有意义的内容，并为你的客户提供最大价值.

• 如果您在初始化中创建了一个故事地图，这将有助于指导您的发布计划. 用它来确定你的MVP, 将产品送到客户手中的最小功能集, 开始赚取收入, 得到反馈, 获得更多的客户.
• 故事地图也将帮助您规划未来的版本. But keep in mind that as you 学习, 得到反馈, inspect, adapt, future 释放s may change. 所以不要计划得太详细.
• 在12个月的时间里，你可能会发布2到4个版本. 不要少做, 因为你的第一个版本是你的MVP，是你的敲门砖, 在那之后，你会希望在一个常规的周期中迭代和发布更多的功能和bug修复. 不要做更多的事情，除非你表现得很好，并且有足够的敏捷技术和工具来管理持续交付.
• 每个发布都是一个时间盒，它被分解成更小的迭代. 迭代是一个时间盒. 时间盒是敏捷中最重要的控制措施之一.
• 评估你的释放:
  • 将你的释放时间除以2. 这将告诉您有多少次迭代. 所以如果你有一个12周的发布，你有6个两周的迭代.
  • 然后删除两个迭代—您将保留一个用于“s打印 0”迭代，另一个用于“发布”迭代. 这给您留下了四个开发迭代.
  • 与您的团队和产品负责人一起为每个迭代填充故事, 从待办事项的顶部开始，然后向下. 当团队认为他们已经用足够的故事填满了一个迭代时，他们就可以在两周的时间内根据自己的能力实际实现, 为下一个迭代重复. 使用发布计划和故事图来指导进入每个迭代的内容.
  • 还没有计划下一个版本吗. 当您接近当前版本的末尾时，您将这样做.
  • 从每个迭代中获取用户故事，并将故事大小相加. 所以如果你的迭代1有25个故事点, 但是迭代2, 3, 4个有10个, 45, 65分, 分别, 您将需要重构. 在每次迭代中设定相同数量的故事点. This becomes your anticipated velocity—the amount of valuable “stuff” completed for each iteration.
• 这个团队以前可能没有合作过. 他们几乎肯定是在研究新问题或新产品. 他们不会从第一天起就表现得最好. 由于这个原因，您的速度可能在最初的几个冲刺中不稳定. 但随着团队稳定下来，情况应该会稳定下来. 使用这些数据重构您的发布计划, 反过来, 帮助您以已知的速度和信心规划您的产品.
• 如果有必要，将故事分成更小的块并调整大小.
• Your 释放 plan, especially early in the life of a project 和 a 新 team, is only ever a guide. Do not treat it as a commitment or guarantee that all or these exact stories will get 交付ed as planned. 随着团队的成熟, 工作完成了，信任和信心建立起来, 你计划的准确性也是如此.
• 永远不要强迫你的团队“承诺”做他们不愿意做的事情. 相信他们的判断和专业知识.
• 未来的发布计划练习将会更简单, 因为你需要释放大小, 将迭代次数乘以团队的速度, fill the 释放 plan with the stories that add up to velocity multiplied by the number of iterations.

下面是一个例子. 如果你去餐馆吃饭, you wouldn’t go ahead 和 order all the items on the menu 和 expect to eat it all in one sitting. 你永远也吃不完的, 你可能付不起这笔费用, 你会吃腻的, 当你正在吃19道菜中的第5道菜时，餐厅可能就关门了! 你可能不会留下一个满意的客户, 餐馆可能不会觉得你是一个好顾客, 这种体验将是糟糕的. 更有可能的是，如果你喜欢这家餐厅，那是因为你曾经在那里吃过一顿美味的饭. 你会决定回去享受一顿不同的饭. 你会告诉你的朋友，你会经常去那里. 这个故事的寓意是:

• 将发布计划分成小块.
• 考虑自己的能力.
• 不要承担超出实际能力的任务.
• 经常重新审视这个计划，看看你可以改变和改进什么.
• 计划，执行，检查，学习，适应， 重复.

发布计划经常发生在软件项目中. 每个新版本都需要一个发布计划. 发布计划也可以在项目的任何时候进行重构. 只是要注意不要做得过火，不要陷入僵尸式的计划精神病. 在发布计划结束时, 您需要为第一次迭代做准备, 我们接下来要去哪呢!

产品的迭代

你的团队已经就位了, 他们的动机, 你的生意很忙, 你最初的计划已经完成——现在你可以开始构建你的梦想了.

我们在前面讨论了敏捷所使用的一些工具、技术和概念. 已经有许多可用的资源在为交付敏捷软件项目奠定基础方面做得很好. 选择一个，保持简单，然后在你的敏捷之旅中成长. To help shorten the trauma in deciding the right 敏捷软件开发 methodology to start with, 我推荐Scrum. 只有Scrum. 使用其他方法元素的诱惑将会存在. 先别这么做. 等到你在Scrum中生活和呼吸了6到12个月之后再做这种改变. 然后, 如果你已经确定单独行动不适合你，或者你想要作为一个团队成熟起来, 稳步引入新方法, 技术, 或框架.

我选择 Scrum as the recommended approach for 新 team’s adopting 敏捷 because it has all the basics 建 in. 它非常受欢迎，在网上有许多高质量的社区和资源, 在书中, 或者在训练室. 即使是最小的团队，它也会对你很有帮助. 的 rest of this post is dedicated to discussing some important aspects of software 交付y that you, 你的团队, 利益相关者应该时刻牢记.

自适应规划

敏捷项目中的计划是一个持续的过程. 我们事先做了一些初步的计划，只是为了了解我们在给定的点上知道什么. 我们最初的计划定义松散，存在缺陷. 然后我们迭代我们的计划, 适应新信息, 在我们进入交付阶段之前进行更详细的计划, 响应不断变化的范围. 这是减少浪费的一种方法——只有在需要的时候才把精力放在计划上.

• 团队和企业, 或其知情和授权的代表，如产品经理, 积极地一起计划——团队，因为他们是交付的专家，产品经理，因为他们是指导业务需求的专家.
• 对用户故事的估计越不准确，它们就离开发越远. 例如，史诗将吸引基于许多未知因素的高层评估. 在冲刺开始之前，对定义良好、粒度较细的用户故事进行估计将更加准确.
• 您可以使用许多评估“尺度”. Use the technique that feels most right for 你的团队 和 the right stage of planning—wide-b和 delphi, 规划扑克，理想时间，相对大小，故事点，或t恤大小.
• 在调整故事大小时，一个大小确实适合所有. 所有的故事都应该使用相同的技术来确定大小，并包含设计等所有元素, 发展, 测试, 和重构. 当你为冲刺做迭代计划时, 可以创建某些任务，这些任务都有助于故事的完成.
• 总是考虑风险因素, 未知数, 外界的影响, 你的团队能力, 以及不断提高的规划速度.
• 如果被纳入s打印的用户描述没有完成，我们就不会延长时间盒. 的se unfinished or unstarted items are put back to the top of the backlog 和 taken into the next s打印.
• 总是计划交付实现既定目标所需的最少数量. 确定修剪特征的技术. 减少浪费，发现在有限的时间内可以实际交付的真正价值.

创造故事

当你需要的时候，故事会被详细阐述. You don’t need full story explanations for 特性 that are six months away from being 交付ed. 当需求从范围中消失时，在开始时编写它们可能是浪费精力. 在需要之前，最多在两次迭代中编写故事. 将时间框架减少到一个s打印是更可取的.

让我们在s打印 0中慢慢来设置场景. 两周后，你将开始开发. 现在是时候从待办事项列表的顶部提取足够的故事了，这些故事可能会在s打印 1中交付. 如果你不确定你的速度，你可以多拿10-15%. 现在可以将这些一行程序扩展为具有场景的真正有价值的文档, 验收标准, 和线框图. 如果线框还没有创建，现在是时候创建了. 当你回顾这些候选故事时，你可能会发现它们需要被分解. 也许它们是不可能在短时间内完成的史诗. 如果您将故事分解，请与团队一起重新评估它们.

A 好故事 遵循以下规则: —通用格式，e.g., AS A <角色> I WANT SO THAT . -包括故事必须满足的验收标准，才能被业务部门认为是可接受的. -使用业务和客户都能理解的语言. -遵循投资模型. -包括通知开发人员的所有证明文件, 设计师, 测试者:线框图, 技术设计概述, 其他资产. -符合您的标准“完成定义”标准.

短跑

不管你称之为冲刺, 一次迭代, 或者一个时间盒, 敏捷项目的每次增量交付都是有时间限制的. 时间盒既不会变短也不会变长. 在开始的时候专注于两周的迭代. 你可能会发现1、3或4周更适合你的商业模式. 一旦你选择了长度，就不要改变它. 你要保持规律 节奏或者一个可持续的速度. 这意味着团队和业务专注于交付常规软件，而不是为了完成工作而疯狂加班，并每两周发布潜在的可交付增量.

• 以小的增量工作有巨大的好处. 这意味着你只关注近期的交货和, 有了新的输入, 反馈, 和学习, 您可以在较短的迭代周期内响应更改.
• 在发布的开始，执行一个s打印 0. 这让团队, 业务, 你的项目发布做好准备，并为成功交付设定心态. Draw out the base technical framework 和 architecture that will 支持 the foundation for the 释放. 设置环境、帐户和工具. 执行峰值来理解困难或未知的问题. 细化您的用户故事，为s打印 1做好准备. S打印 0就是做好准备.
• 在发布过程中，不断细化待办事项安排. 当你了解更多或学习新的东西, 你的优先级可能会改变, 可能会出现新的需求, 而你之前认为很棒的功能可能会被完全删除.
• 不要开始没有机会在冲刺期内完成的工作. 如果不能，那就把它分解成小块. 当之前开始的工作还没有完成时，不要开始新的工作. 如果你开始做很多不完整的事情，你就不会创造任何价值. 此外,避免 上下文切换. 这是开始一个任务的活动, 越来越不安, 开始另一个和, 最棘手的是, 都没有完成.
• 限制团队在任何时候正在进行的工作量. 例如, 如果你有三个开发人员和一个测试人员, 您可以对开发人员和测试人员设置在制品数量限制.
• 不要在s打印计划好之后再增加更多的工作. 不要中途停止冲刺. 例外情况有:
  • 如果你的表现比预期的要快, 考虑从待办事项列表的最上面取下一个故事, 只要准备得当.
  • 如果s打印的表现很糟糕，它将无法完成. 这通常只发生在某种程度上的灾难发生的时候.
  • If the s打印 objective can no longer be 支持ed due to immediate changing needs of 业务.
• 如果你取消了冲刺, 优雅地做, 花点时间重新集中注意力, 开始一个新的冲刺，就像你做任何其他事情一样.
• 在一个发布的末尾，考虑一个最终的发布冲刺. 没有编写新的特性, 有些bug是可以被清除的, preparations can be made to actually 释放 a 新 version of your product to 你的客户. 这并不是说你不能在此期间向客户发布增量版本——只是这是一个可控的过程, 测量, 可持续释放机制.
• 在发布结束时，您可能会考虑一周的冲刺. 在这次冲刺中, 你可能会与团队一起分解一些新想法或找出一些新技术. 这些都是有益于企业的伟大工具, 它给了团队一些思考和创新的空间. 这不是用来游手好闲的，而且仍然会创造价值. 同样，每个人都需要休息. Taking a vacation at this time helps keep your 节奏 和 velocity in good shape when you’re mid-释放.

定义完成

定义“完成”的真正含义非常重要. 的re are many versions of “done” within the life of your project—what it means to be “done” with a story, 释放, 或者整个项目. 这一切都归结于你, 你的团队, 业务 will consider as complete to the right level of quality to satisfy readiness to ship.

为你的团队, “完成”故事的定义类似于所有代码完成, 同行评议, 满足定义的验收标准, 单元测试, “UAT”, 并推送到代码存储库中. 使故事能够从设计人员传递到开发人员，再到测试人员, “完成”的定义必须被链中的下一个人接受. 你的产品负责人会期望这对他们意味着什么，以便向你的客户发布产品增量. 无论如何, everybody must be aware of what “done” means 和 be a responsible party in ensuring its meaning is met. 定义你对“完成”的定义，沟通它，同意它，并发展它. 做完了.

连续测量

如果你不能衡量它，你就不能管理它. 改进也是如此. 在敏捷项目中，收集经验数据的需求几乎和血液流经血管一样重要! 如果没有数据，你怎么知道什么需要管理、纠正或改进? 好吧, 简单地说, 你将依靠直觉和未经证实的猜测, 在审查下很快就会崩溃. 这取决于谁在进行审查，这可能是一个相当不舒服的地方. 所以从你的项目开始, 确保你知道你将如何展示你的进步，以及别人将以什么标准来看待你的成功.

幸运的是，敏捷带来了很多有用的工具和技术. 首先要做的是回到敏捷宣言, 在您最喜欢的文字处理器中键入以下单词, 把它们放大到96磅, 打印, 贴在墙上，让所有人都看得见;

在交付软件时，您最大的可展示的能力是向工作的人展示它, 做它该做的事. 这不仅会让你的客户满意, it will earn 你的团队 great respect 和 grease the wheels for greater adoption through 业务.

以下是其他一些工具:

• 的 每日站立会议这个仪式有几种不同的形式, 但最重要的是让所有团队成员面对面交流:尽量简短, 保持专注, 保持轻松. 如果有什么需要详细讨论的, 把它留到脱口秀结束后需要的人之间进行更长时间的交谈. 如果遇到障碍, 把它们像故事一样写下来, 把它们添加到你的待办事项列表中, 尽快解决这些问题. 任何阻碍您的团队的事情都会减慢他们的进度，并且会以降低的速度和不符合预期的软件来证明.
• 速度是一种历史工具. 这有点像你得到的那些财务警告，说过去的表现不能保证未来的表现. 但是在敏捷的情况下，我们确实希望实现一个很大程度上平滑的团队速度. 正是速度使我们能够预测未来的表现，并对我们的计划充满信心. 可能存在超出你控制范围的影响因素，这可能会降低给定s打印的故事点输出数量. 如果发生这种情况，你可能会恢复. Never use velocity as a stick to beat 你的团队 with; it will win you no favors. 有一件事是肯定的，那就是前2-4个冲刺阶段的速度是不稳定的. 然而，在这个时间框架的某个地方，你应该开始看到一致性和稳定性. 如果你的速度从一个极端摇摆到另一个极端, 你遇到了一个问题，需要和你的团队一起解决.
• 燃尽图:这个衡量进步的方法很棘手. 因为这个原因, 我没有给出一个链接去了解更多，你必须做你自己的研究，并同意作为一个团队和企业适合你. 这就是它棘手的原因? 好吧，没有一个资源告诉我们相同的故事! 大家一致同意的一点是，它会显示出来, 在一次冲刺或一次发布中, 你在时间限制下的表现如何. 如果每天保持，它会显示你是在正轨上还是偏离轨道. 有些团队用它来表示还剩下多少价值有待创造, 通常, 其他人用它来显示还有多少工作要完成. 前者是对成功和价值创造的庆祝, 后者不那么鼓舞人心和激励人.
• 燃尽图:如果必须显示工作完成率，请使用燃尽图. 但是使用燃耗图可以让你显示已经创造了多少价值，以及你计划在冲刺结束时创造多少价值. 对于团队来说，这是一个更有激励作用的工具，既可以向业务展示已经完成的工作(如果事情进展不顺利，就很少展示……)，也可以展示他们仍在关注的目标. 无论如何, 使用图表来发现进度没有按照预期进行的地方，寻找模式或偏差，并尽快解决潜在的问题. 每天为s打印更新它们，并在s打印结束时为发布版本图表更新一次.
• 任务板这些都是展示所创造价值的绝佳视觉辐射器. 当每天更新时，或者在一天中的任何时候，它们立即显示正在取得的进展. If combined with 看板, they’re also great tools for visualizing flow 和 blockages in the system. 如果你能看到很多开发已经完成, 但是测试并没有那么高效, 您可以看到问题的发生，并作出适当而迅速的反应.

其他可以考虑的工具有 敏捷挣值, 周期时间, 累积流程图 (CFD).

保持这些措施, 图表, 还有其他工具, 最好是大声骄傲地挂在墙上，让所有人都看到. 的 team, stakeholders, other interested parties can immediately see the status of a project. 它是透明的，是一种有价值的沟通工具. 如果你不能把这些文物挂在墙上, 使用可共享和协作的工具，并确保那些想要访问它的人拥有它.

持续改进

在您的敏捷生活中，您应该寻找并学习可以改进的地方. 在项目结束时没有捕获和学习经验教训. It’s like passing your driving test 和 tentatively taking your first drive without an instructor. 你会知道什么是有效的，你应该做什么, 但随着时间的推移，你会调整你的驾驶技术和能力, 学习新技术. 你甚至会染上坏习惯. 寻找它们，理解它们，并找到改进的方法.

有很多机会可以确定什么不起作用并应用补救措施. 敏捷中内置的方法是回顾. 这是反映和调整的主要工具. 在每一次冲刺结束时, 花时间和团队在一起，改进工作的完成方式, 如何交付质量, 如何使效率最大化, 如何减少浪费，如何提高产能. When you identify measures for improvement, don’t be tempted to fix all your problems right away. 确定那些影响最大并且可以在下一个s打印中实现的. 测量和观察. 如果它有预期的影响, 锁起来, 把它写进你的工作方式和完成的定义中. 如果它不起作用，再考虑一下. 任何没有在即将到来的冲刺中得到的经验教训都可以放在后面，并优先考虑下一个冲刺.

调整流程. 删除任何不起作用的东西. 移除障碍. 如果你放任不管，你作为敏捷团队的成熟度将是无限的.

超越敏捷项目管理

了解项目交付后会发生什么是很重要的. 支持和维护是确保这一点的关键, 一旦项目在客户手中, it remains 执行ant; customer 反馈 can be factored into future 释放s; 和 customer issues are dealt with appropriately. 一个项目是一个独特的、有时间限制的努力. 它交付的产品在项目团队解散后仍有生命. 确保你有能力在产品上线后提供支持.

敏捷项目与更传统的方法共存. 平衡预算控制和涉众可见性的需求与敏捷的灵活性和响应性目标.

治理框架或敏捷治理模型与标准一起使用 敏捷框架，比如Scrum. 它们以两种具体方式起作用:

• 它们通过澄清开发迭代(s打印)之外发生的过程，为敏捷项目提供了包装。. 这包括为成功完成项目启动和正确确认决策和计划提供明确的标准.
• 他们转移了标准中特定部分的重点 敏捷过程 并强调需要治理或支持治理的特定原则和技术.

在当今瞬息万变的世界, 组织和企业热衷于采用更灵活的方法来交付项目, 并希望变得更加敏捷. 然而, 对于交付项目和规划的组织, 以及已经存在的正式项目管理过程, the informality of many of the 敏捷 approaches is daunting 和 is sometimes perceived as too risky. 这些以项目为中心的组织需要成熟的敏捷方法——项目交付概念中的敏捷性敏捷项目管理.

在采用敏捷的过程中学习和成长. 只做你的团队觉得舒服的事情, 确保他们的声音被听到, 并按照他们的要求行事. 当时机成熟时，鼓励您的团队采用新的、更有价值的技术. Negotiate with 业务 和 encourage them to 理解 what it means to be an 敏捷 organization.

享受旅程.