微软公司为Visual Studio开发者汇总了很多资源，包括敏捷软件开发的原则、实践和准则。这些资源浓缩了Jeff Sutherland、Ken Schwaber、David Star、Mitch Lacey和David J. Anderson这些有影响力的敏捷开发领袖的文章，内容涵盖很多敏捷方法论的精华并对所有软件开发者都有助益。
\这些资源分为下面三个部分：敏捷原则、敏捷实践、精益与CMMI。
\敏捷原则
\敏捷原则和价值
\Jeff Sutherland详细说明了在敏捷软件开发宣言中描述的四个核心价值：
\- \
个体及交互
\ \ - \
交付可工作的软件
\ \ - \
客户合作
\ \ - \
拥抱变化
\ \
他同时区分了敏捷、方法论和实践，详细讲述了Scrum及XP的含义及它们之间的互补关系。
\敏捷十年回顾：我们在下个十年如何改进
\在这篇文章中，Jeff Sutherland回忆了2011年在犹他州Snowbird举行的敏捷10年回顾会议，一些当年敏捷宣言签署者与敏捷思想领袖会面，庆祝这10年来敏捷所取得的成绩，并指出在接下来的10年中继续保持成功的四个关键因素：
\- \
追求技术卓越
\ \ - \
鼓励个体改变并引领组织转型
\ \ - \
组织的知识及改进教育
\ \ - \
在整个过程中最大化价值创造
\ \
中列举了几个通向成功之路的几个阻碍之后，Sutherland总结道：
\\\对于敏捷团队来说，最重要的是改进团队的实践以解决世界范围内敏捷社区最大的问题——技术卓越。准备好产品的backlog需要专业的产品经理，他们能够理解用户的需要，也需要团队的能力及交付卓越软件的激情。在一次sprint中完成产品backlog需要对工作进行优先级排序、持续集成进行中的任务并不容许缺陷。追求技术卓越是未来十年（敏捷社区）最重要的事情。
\
完成和未完成
\运用实际或假想的案例，Ken Schwaber及David Starr探讨了认为完成和实际完成，解释了如何区分这两者及为什么混淆它们会对项目的成功产生影响。他们详细的描述了透明性，技术债，交付计划及两种能够让事情真正做完的技术手段：针对Scrum的Scrum和持续集成。
\敏捷实践
\构建和管理产品的Backlog
\在这篇文章中，Mitch Lacey探讨了产品backlog的重要性，给出了创建及维护一份良好的产品backlog的实践。文中他包含了下述主题：用户故事、估算、优先级排序及保持backlog整洁，文章的最后写道：
\\\一份良好的产品backlog有助于确保构建出来的软件包含了最重要的功能，这些功能是你在与客户及项目干系人沟通的时候发现的，并采用用户故事记录下来。为了创建并维护一份好的产品backlog，你需要保持与项目干系人/客户及项目团队持续的沟通——每个sprint都要进行。
\构建良好的backlog不能保证交付一个良好的软件系统，但是如果没有好的backlog，几乎可以肯定的是，最终交付的软件系统不是客户需要的。换句话说，不保持backlog持续更新几乎可以肯定导致项目失败。
\Product owner是一份全职工作，backlog就是他们的职责所在。认真的对待这个角色。让产品backlog保持良好状态——你的客户会感谢你的。
\
优先级排序
\Mitch Lacey接着前一片文章《构建和管理产品的Backlog》写道，如何采用三种方法进行backlog优先级排序：
\- \ \ \
- \ \ \
- \ \ \
Lacey视backlog为“有生命的”，需要不断的投入精力并不断重新调整优先级，以便获得成功。
\估算
\在这篇文章中，Mitch Lacey指出了项目估算中的问题，解释了为什么做出准确的估算很困难，也谈及故事点作为度量单位，并提出两种估算技术：计划扑克，和估算墙。Lacey最后总结说：
\\\估算是困难的，因为在项目开始时有太多的不确定性。Product Owner和敏捷项目经理试图尽早让价值最大化，通过与他们的product owner和项目干系人沟通进行学习，产出可工作的软件，并不断将对软件的反馈集成进来以便能够达到可发布的状态。但是即使是敏捷项目，也必须给出某种估算，说明功能集何时能够交付。
\
Sprint计划
\Mitch Lacey以一篇针对Sprint计划的文章作为他关于敏捷实践的系列文章的结尾。在本文中，他开篇探讨了预测与承诺，接下来说明了计划及如何达成目标，在此过程中伴随着解释了一些常见的问题和解决方案。Lacey认为Sprint计划“不需要如此具有挑战性。（计划）通常是有趣的，并且这是一个让整个Scrum团队通过在一起工作建立友谊的机会”。
\精益和CMMI
\精益软件开发
\在这篇文章中，David J. Anderson介绍了精益思想，及与敏捷之间的关系，并解释了精益的价值、原则和实践。Anderson讲述了精益的价值在于：
\- \
承认个人的条件
\ \ - \
承认复杂性和不确定性是知识工作的本质
\ \ - \
共同工作以得到更好的经济效益
\ \ - \
并得到更好的社会效益
\ \ - \
探索、接受并怀疑来自各个学科的想法
\ \ - \
以价值为主导的社区，增强积极改变的速度和深度
\ \
定义一个精益开发流程的原则是：
\- \
遵从系统化思考和设计方式
\ \ - \
自发的产出可以被构架一个复杂的适应性系统的上下文所影响
\ \ - \
尊重个人（作为系统的一部分）
\ \ - \
采用科学方法（来引领改进）
\ \ - \
鼓励领导力
\ \ - \
创造可视性（在工作、工作流和系统运营中）
\ \ - \
减少流动时间
\ \ - \
减少浪费以提升效率
\ \
Anderson说道，精益软件开发“没有规定实践”，然而社区接受了很多精益实践，包括：累积流图、可视化控制、可视化看板系统、小批量 / 小件流、自动化、改善事件、每日站立会议、回顾会议和运营回顾。
\Anderson总结说：
\\\没有单独的精益软件开发流程。如果一个流程很明确的符合精益软件开发的价值和原则，那么这个流程就能被认为是“精益的”。精益软件开发没有规定实践，但是很多活动已经很常见……
\采用精益软件开发流程的组织，如果展示出所有三种类型的浪费（不均衡、浪费及负荷过重）都很少，并显示出能够通过更有效的风险管理来优化价值的交付，则可以被称为精益的。在精益中追求完美是个不断的旅程。对完美的追求没有终点。真正的精益组织总是不断寻求更进一步的改进。
\精益软件开发仍然是一个新型的领域，并且我们可以预期在下一个十年中仍会不断演进。
\
CMMI原则和价值
\这篇文章总结了这一系列有关敏捷的文章资源所谈到的内容，David J. Anderson断言，经理、流程工程师和项目干系人能够通过采用能力成熟度模型集成（CMMI）获得对一个组织有价值的洞见。Anderson解释了组织的成熟度是什么、CMMI模型、一个组织如何能够沿着各成熟度层次不断进步，以及CMMI成熟度是如何评定等级的。
\查看英文原文：A Collection of Agile Resources by J. Sutherland, K. Schwaber, D. Star, M. Lacey, and D. J. Anderson
扫一扫
3万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
