一 项目管理的基本概念
- 什么是项目?
事先规划好的工作计划,需要在定义好的时间、工作量和计划下去完成。项目有其目的和目标，并 且经常必须在限定的时间和预算内完成
- 什么是项目管理?
用于完成一个项目的过程。
- 什么是项目管理?
用于完成一个项目的过程。
- 什么是敏捷项目管理?
这种项目管理的风格专注于商业价值的尽早交付、项目产品和流程的持续改进、范围的 灵活性、团队投入以及能反应客户需求且经过充分测试的产品交付。
- 什么是瀑布?
传统的项目管理模式。瀑布依赖于在不同阶段完成的工作，像需求、设计、开发、测试和部署。 在瀑布项目中，知道你已经完成了前面一个阶段才能开始下一个阶段。
- 什么是需求?
项目期望的产品特性清单。
- 什么是设计?
为创建单个产品特性而设置大纲和计划的阶段。
- 什么是开发?
产品特性创建的阶段。。
9. 什么是测试?确保产品开发的性能正常运行的阶段。
- 什么是部署?
项目的最后阶段，产品的全部性能达到可以使用的状态。
- 敏捷管理中的范围
项目中包含的一切。
- 敏捷管理中的估算（动词）
确定工作量、时间长度、成本或任务的优先级、需求、发布、甚至整个项目。
- 敏捷管理中的估算（名词）
工作量、时间长度、或任务成本、需求、迭代、发布甚至整个项目。
二 敏捷软件开发的历史
历史介绍
敏捷技术的萌芽的产生已经有很长一段时间。最早可以回溯至上个世纪30年代沃尔特·休哈特（Walter Sherwart）在项目质量方面的计划-执行-学习-行动-（PDSA）方法。
1989年，竹内弘高（Hirotake Takeuchi）和野中郁次郎（IkujiroNonaka）在《哈佛商业评论》（Harvard Business Review）上发表了一篇名为，《新产品开发的新游戏》（New NewPruduct Development Game）的文章，竹内弘高和野中郁次郎在文章中描述了一种快速、灵活的开发策略以满足快速的产品需求。该文章吧产品开发与英式橄榄球比赛进行类比，第一次将Scrum这个术语与产品开发相关联。Scrum逐渐演变成敏捷项目管理中最常用的方法。
敏捷宣言
2001年，一组软件和项目的专家聚在一起讨论他们项目成功的相通之处。该小组创建了敏捷宣言，一份对成功的软件开发所需价值的声明：
敏捷软件开发宣言
我们一直在实践中探寻更好的软件开发方法，身体力行的同时也在帮助他人。由此，我们建立了如下价值观：
个体和互动高于流程和工具；
可工作软件高于详尽的文档；
客户合作高于合同谈判；
响应变化高于遵循计划；
也就是说，尽管右项有其价值，但我们更重视左项的价值。
三 敏捷与传统
更大的灵活性和稳定性
相比传统项目管理，敏捷方法能够提供更大的灵活性和更大的稳定性。首先，你要了解敏捷 项目管理如何提供灵活性，然后我们在讨论稳定的性。
一个项目团队，无论它使用什么项目管理方法，都要在项目开始之初面临两个重大挑战。
一、项目团队对产品最终状态的认知有限；
二、项目团队无法预知未来；
对产品知识和未来商业需求的有限了解，几乎注定了项目的变更。
敏捷宣言的第四个核心价值观是“响应变化高于遵循计划”。敏捷框架是以灵活性为基础创建的。
- 减少非生产性任务
漫长的工昨日=疲劳的开发人员=不必要的漏洞=更多的漏洞修复=延迟发布=实现价值需要更长时间.产品开发是一种需要持续专注的高强度工作。许多开发人员在正常的工作日里忙于其他类型 的工作任务，因而不能获得足够的开发时间来跟上项目进度。从而形成以上的因果链。 最大化工作效率的目标是消除加班，开发人员在工作日专注于代码开发。为了提高效率，我 们必须减少非生产性的任务和时段。
敏捷过程只包括一些正式会议。这些会议目标应该非常明确，有特定的主题和有限的时间。 在敏捷项目中，当前的项目状态对整个组织来说都应该是可视化的。
敏捷团队应该有高效的沟通方式。敏捷团队通过面对面的讨论，而非发送电子邮件来解决问题。
- 专题展示
演示，而非展示。换言之，给客户演示你的开发成果，而不是单纯的描述。
展示软件是如何满足需求与达到验收标准的。换言之，就是在表述：“这是需求。这些是证明已完成特性的验收标准。这是符合这些标准的特性成果。
避免正式的幻灯片展示和相关工的准备工作。当你演示可工作软件时，可工作软件本身就是最好 的展示。
- 过程文档
文档是项目经理和开发人员们长期以来的负担。敏捷项目团队可以使用以下方式来简化文档
使用迭代开发： 许多文档的目的是做为决策参考，敏捷团队通过产品和相关的自动化测试而非大 量文档来证明做出决策。
一个规格不能适合所有项目： 你不需要为每个项目创建相同的文档，而应该为特定的项目选择所 需要的文档
使用非正式的、灵活的文档工具： 白板、记事贴、图表和其它可视化的工作计划展示表都是很好 的工具
使用那些简易且能够提供足够信息的工具来管理项目进程：不要单纯的为了报告而去创建特殊的 项目进程报告，敏捷团队应该使用直观的工具来更快速的传达项目状态。
更高的质量更快的交付
- ** 短期的迭代开发限制了特性的数量和复杂程度**
- 持续集成测试在整个项目过程中维护可工作产品
- 产品负责人参与每天的问题解答，并快速地澄清误解
- 保证开发团队的工作状态，减少代码漏洞
- 每次冲刺结束后进行评审总结，及时修正优化工作流程提高团队绩效：
提高团队绩效
敏捷项目管理的核心是项目团队成员的经验。
相比传统的项目管理方法，敏捷团队能够能够获得 更多的支持，可以花更多的时间专注于自己的工作，并致力于持续的过程改进。 使用敏捷过程，可以让开发团队把尽可能多的工作时间 专注在产品的研发上。每个冲刺回顾讨论都会收获一些可以让敏捷项目团队持续改进的方法。
严格的项目控制
敏捷过程提供了持续的信息流： 早例会一起规划工作任务，随时更新任务状态。
需求变更影响最小化：每一个冲刺中，客户都有机会基于业务需求来更新产品的优先级。无论优先级在下一个冲刺前几周或者几分钟确定，工作量都不会有什么不同，需求变更几乎不会增加任何的管理成本和时间，也不会干扰当前的工作。
敏捷方法使得项目终止更容易：在每一次迭代结束时，都可以判断当前产品特性是否已经足够，而低优先级的特性可能永远不会被开发。
速度更快，失败成本更低：
更早和更频繁的检测故障的机会；
每隔几周进行评估和采取行动的机会；
失败成本降低
782
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
