BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

由J. Sutherland、K. Schwaber、D. Star、M. Lacey及D. J. Anderson撰写的关于敏捷的文章合集

| 作者 Abel Avram 关注 7 他的粉丝 ,译者 姚九强 关注 0 他的粉丝 发布于 2012年4月16日. 估计阅读时间: 8 分钟 | GMTC大前端的下一站,PWA、Web框架、Node等最新最热的大前端话题邀你一起共同探讨。

微软公司为Visual Studio开发者汇总了很多资源,包括敏捷软件开发的原则、实践和准则。这些资源浓缩了Jeff Sutherland、Ken Schwaber、David Star、Mitch Lacey和David J. Anderson这些有影响力的敏捷开发领袖的文章,内容涵盖很多敏捷方法论的精华并对所有软件开发者都有助益。

这些资源分为下面三个部分:敏捷原则、敏捷实践、精益与CMMI。

敏捷原则

敏捷原则和价值

Jeff Sutherland详细说明了在敏捷软件开发宣言中描述的四个核心价值:

  1. 个体及交互

  2. 交付可工作的软件

  3. 客户合作

  4. 拥抱变化

他同时区分了敏捷、方法论和实践,详细讲述了Scrum及XP的含义及它们之间的互补关系。

敏捷十年回顾:我们在下个十年如何改进

在这篇文章中,Jeff Sutherland回忆了2011年在犹他州Snowbird举行的敏捷10年回顾会议,一些当年敏捷宣言签署者与敏捷思想领袖会面,庆祝这10年来敏捷所取得的成绩,并指出在接下来的10年中继续保持成功的四个关键因素:

  1. 追求技术卓越

  2. 鼓励个体改变并引领组织转型

  3. 组织的知识及改进教育

  4. 在整个过程中最大化价值创造

中列举了几个通向成功之路的几个阻碍之后,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

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT