项目管理笔记

敏捷宣言

We are uncovering better ways of developing software by doing it and helping others do it. Through this work, we have come to value:

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

虽然右边的项目有价值， 但是我们更重视左边的项目

什么是敏捷

敏捷不是一个具体的规则、严格的方法论或者高质量的证明，它更像是一种哲学，一种思维方式，一种做特定环境下如何提高工作效率的一般准则。

敏捷引入了宣言中的价值观，可以在执行特定工作时指导团队，无论是流程还是项目。 在这个宣言的背后，有十二条敏捷原则，为这个概念提供了更多细节。

计划

一个计划的执行活动可以在没有一个完整的项目计划的情况下开始，在敏捷中总是会有计划和执行的活动在进行，然而，只有在所有的事情都详细计划好之后才开始执行的规则被废除了，就像我们之前在某些项目中看到的那样

敏捷建议：当进一步的计划没有好处时，最好早点开始执行。

最初的计划并不包括所有的细节，进一步的计划是在执行过程中进行的。在短时间内完成项目工作的一小部分，比拥有详细的项目计划更有价值。

改变

在执行过程中，范围和需求可以被更新，即使需求清单在一开始就被同意了。

当一个变化出现时，与其通过文件和程序来保护计划，不如将其迅速导向为客户创造最大价值的东西。

这将确保时间和项目资源不会被浪费在因任何原因而变得不那么重要或不相关的工作上。

欢迎改变需求，即使在项目的后期。敏捷过程为客户的竞争优势驾驭变化。

协作

任何项目的产出，产品，服务或结果都应该是满足项目客户的需求。而在一个软件项目中，他们是由所谓的用户代表的。另一方面，我们有一个项目团队来创造项目产品以满足这一需求，他们就是开发者。

现在，公司尤其是大公司，有严格的结构化流程和严格的沟通渠道，这在用户和开发者之间造成了障碍。如果用户和开发者是来自两个不同的公司，这些障碍可能会更大。通常情况下，这种分离导致了对需求的不理解，沟通不顺畅。最终导致用户和客户的不满。 这里的原则建议不仅要打破这些障碍，还要确保用户和开发人员在整个项目中定期会面和互动。这将确保需求和实际产品之间的任何不匹配都能被及时捕捉到。并消除最终得到一个没用的产品的机会。

正如12条原则中所说的，业务人员和开发人员必须在整个项目中每天一起工作。

敏捷项目结构

• 预计的生命周期结构
• 项目产品交付
• 角色和责任

Initiation

这个阶段会被执行，因为他对这个特定的项目是有意义的。然后在后续进一步的发展和调整。

Execution Phase

工作不再是漫长的单一阶段，而是通过一些小的，相同的阶段来执行。这些被称为迭代，在每个小阶段中，项目产品的一个特定部分都是以这种方式创建的。执行时一步一步进行的，在迭代之间留出空间来审查部分产出。并在需要时对计划进行任何修改。注意他们都有相同的持续时间，从项目经理的角度来看，通常是几周的时间。

每个迭代都会在开始时包括一个简短而详细的计划，然后执行该计划。下一个迭代的部分将在下一个迭代之后进行，在那里将会对下一项工作进行详细的规划然后执行。就这样一次又一次的迭代，直到整个产品被创造出来。这也是为什么来自敏捷世界的产品开发方法也被称为‘迭代方法’。

Closure

值得注意的时，经验教训的收集不是在最后才进行的。而是在每一个迭代结束之后，项目组都会聚集在一起讨论哪些地方做得好，哪些地方可以在下一个迭代中改进。因此，经验教训被不断的讨论和实施改进。

但是项目工作时如何被检测和控制的呢？

在每个迭代之后，有一个和项目团队和项目客户的会议，一个所谓“演示会”，在这里对产出或创造的具体作品进行审查。我们也有关键控制点来评估项目的进展情况。

现在，另一件非常重要的事情时，在迭代之间，允许对项目计划甚至项目方向进行修改。随后的迭代可能会根据新的优先级改变其顺序或内容。

这就是敏捷的核心。它使你在执行过程中能够灵活调整计划并遵循最佳的方向。这在单一和漫长的执行阶段中要困难的多。

Scrum

Scrum出现与20世纪90年代，是一个用于交付复杂工作（如软件开发）的框架。

生命周期以传统的方式开始，在启动阶段，项目被定义和分析；然后进行规划，但在更高的层面上，团队通常进行研讨会，以了解范围，以争取高水平的时间表和预算，并在此建立项目团队。

工作的执行方式Sprint

Sprints代表了Scrum项目生命周期的一个基本部分，每个阶段的长度通常在2-4周之间，必须交付产品的某一部分。

一个项目中的所有Sprints都需要交付具有所有预期能力的整个产品。

按照敏捷的做法，每个Sprint结束都会有一个Demo，团队会向客户介绍进展情况。在这里如果需求没有得到满足，客户可以要求返工，或者如果需要的话，要求修改下一个Sprint的需求。

请注意，在Sprint执行区间的改变时不允许的，只有在Sprint与Sprint之间才可以。

在进入下一个Sprint之前，项目组会举行一次简短的会议，讨论从上一个Sprint阶段学到的经验教训。称为Retrospective。

Backlog

包含范围和要求的文件称为Backlog。代表了完整的需求列表，包括最终产品应该具有的所有功能、特点和属性。在讨论产品范围的时候，它将是参考的关键文件。

在产品开发项目中，范围不仅要包括产品本身的物理或者有形部分，还要包括人们如何使用该产品的部分。

User story

一个具体的愿望、系统的能力、产品的一句话描述。

Epic

在Scrum中，Epic被认为是一个大的工作，它指的是一组重要的产品需求。它可以被分解成更小的工作片段。

如果能在一个简单的Sprint中被定义，则是User Story，如果需要几个Sprint的冲刺和努力，则是Epic