敏捷教练----敏捷项目管理-程序

https://www.atlassian.com/agile  

5.2 程序
       敏捷开发的早期采用者是小型的、独立的团队，他们从事小型的、自包含的项目。他们证明了敏捷模式是可行的，这让世界各地的软件制造商感到高兴并得到了改进。最近，更大的组织正在将敏捷扩展到单个团队或项目之外，并寻找将其应用到整个项目的方法。
       这并非没有挑战。但这并不意味着这是不可能的!
 5.2.1 瀑布和敏捷
       让我们从基础开始——比如敏捷的不同之处。
       瀑布之类的传统项目管理风格是分阶段构建的。以下是标准瀑布项目的图示。这种产品开发风格将所有内容折叠成一个单一的“大爆炸”高风险版本。一旦一个项目通过了一个阶段，重新进行该项目就很痛苦，因为团队一直在努力进入下一阶段。
                                                     
       传统的项目管理风格通常会创建“关键路径”，在这里，除非阻塞问题得到解决，否则项目无法前进。雪上加霜的是，最终用户在产品完全完成之前无法与产品进行交互。因此，产品设计和代码中的重要问题直到发布才会被发现。
       让我们将其与敏捷项目管理风格进行对比，敏捷项目管理风格采用迭代方法进行开发，并采用定期的反馈间隔。这些迭代允许团队转移到项目的另一个阶段(并在该阶段取得成果)，同时解决阻塞问题。
                                           
除了消除关键路径外，迭代还使您可以在开发过程中与产品进行交互。
       这反过来又给了团队不断构建、交付、学习和调整的机会。市场变化不会让您措手不及，团队已经准备好快速适应新需求。
       一个更大的好处是在软件团队之间共享技能集。团队的重叠技能集为团队代码库的所有部分的工作增加了灵活性。这样，即使项目方向改变，工作和时间也不会浪费。(有关更多信息，请参阅我们关于构建优秀敏捷团队的文章。)
 5.2.2 如何构建一个优秀的敏捷项目
当一个项目从传统的项目管理过渡到敏捷时，团队和涉众必须接受两个重要的概念:

• 产品所有者的重点是优化开发团队输出的价值。开发团队依赖于产品所有者优先考虑最重要的工作。
• 开发团队只能接受有能力完成的工作。产品负责人不会把工作推给团队，也不会让他们在任意的期限内完成工作。开发团队从程序的backlog中提取工作，因为它可以接受新的工作。

让我们来探索敏捷程序用迭代的方式组织、运行和构建工作的机制。
 5.2.3 路线图
       路线图描述了产品或解决方案如何随着时间的推移而发展。路线图是由主动性工作组成的，主动性工作是功能的大范围，并且包括当一个特性可用时的时间线。随着程序的发展，路线图将会发生变化，这一点已得到公认——有时变化很小，有时变化很大。我们的目标是使路线图专注于当前的市场状况和长期目标。
 5.2.4 需求
       路线图中的每个计划都分解为一组需求。敏捷需求是对所需功能的轻量级描述，而不是与传统项目相关联的100页文档。它们随着时间的推移而发展，并利用团队对客户和所需产品的共同理解。敏捷需求仍然是精益的，而团队中的每个人都通过持续的交流和协作来形成共识。只有当实施即将开始时，它们才会补充完整的细节。
 5.2.5 待办事列表
       待办事项列表为敏捷项目设定了优先级。团队在backlog中包括所有的工作项:新特性、缺陷、增强、技术或架构任务等等。产品负责人为工程团队确定待办事项列表上的工作的优先级。然后，开发团队使用优先级的backlog作为需要完成的工作的唯一真实来源。
 5.2.6 敏捷交付工具
       敏捷可以通过使用各种框架(如scrum和看板)来交付软件来实现。Scrum团队使用sprint来指导开发，而看板团队通常没有固定的工作间隔。然而，这两种框架都使用大型交付工具(如epics和版本)来构建开发，以达到同步发布到生产环境的节奏。
 5.2.7 敏捷指标
       敏捷团队依赖于度量标准。正在进行的工作(WIP限制)使团队和业务部门专注于交付最高优先级的工作。像燃尽图和控制图这样的图表可以帮助团队预测他们的交付周期，而连续流程图可以帮助识别瓶颈。这些度量标准和工件使每个人都关注于大的目标，并增强团队交付未来工作的能力的信心。
 5.2.8 敏捷依靠信任
       没有团队成员之间的高度信任，敏捷程序就不能正常工作。它需要坦诚地就程序和产品的正确之处进行艰难的对话。因为谈话的发生是有规律的，所以想法和关注都有规律地表达出来。这意味着团队成员还必须对彼此的能力(和意愿)有信心，以执行在这些对话中做出的决策。
       总之，敏捷开发是一种结构化的、迭代的软件开发方法。它使您能够在不偏离轨道的情况下响应更改。这对任何项目来说都是好消息。