Hire Attitude - Train Skills

Frankly speaking I didn’t understand what these words meant until I had a Google just now.

It should be Hire for attitude - train for skill

Some snip from internet about the explanation of this sentence:

The most important factor in hiring is attitude. Hire for it. Through the resume process you're going to find people who have the basic skill levels you're looking for. That's the first hoop. Then with a telephone screen you can find out if people have the foundational knowledge and the intellect for what you want.

But when you bring them in for an interview, the most important question you need to answer is "Can we work with this applicant?" The second most-important question is "Is this applicant teachable?"

If you cannot answer "yes" to BOTH of those questions, a "do not hire" sign needs start flashing above your candidate's head. Move them along, wish them well, and bring in your next applicant.
阅读详细......

ScrumWorks,让Scrum更敏捷

这个Scrum工具用了很久了,但一直没有总结ScrumWorks,这次小珂同学要求写一个介绍，这才真的写下来，希望对大家的Scrum实践有所帮助。

---敏捷精灵

曲折的选择之路

在开始实施Scrum之前，除了需要对所有涉及到的人进行培训之外，另外一项重要工作就是选择一个适合自己的Scrum工具。很多关于敏捷的论文或教科书都提到了白板和Excel电子表格。但白板与Excel电子表格明显不能满足一个注重过程资产的软件项目的要求。白板虽然适合每天的跟踪汇报，但是对Product Backlog支持明显不够，也没办法保留历史纪录。Excel虽然有很多现成的模板可以用，但当是团队成员比较多时，同时修改一个共享Excel文件，会相互冲突，不好同步。

我们最初使用的是一个叫ScrumWiki的免费/开源工具。因为之前大家一直把Wiki当作知识共享工具，每个人都很熟悉Wiki的机制与语法，采用采用wiki这种共享创作模式的Scrum小工具，可以让大家随意编辑，更新任务状态，非常适合我们当时的分布式开发。但随着Product Backlog变得越来越大，变化越来越频繁的时候，ScrumWiki明显不能满足我们的需求。特别需要指出的是，作为免费开源的软件，因为已经没有人支持和维护，系统存在一些Bug只能靠自己修正，花在维护和添加新功能到这个免费工具上的时间越来越多，已经是“买椟还珠”，大家决定放弃这个工具。

几经周折，最终选定了ScrumWorks Basic作为我们实施Scrum的工具。为什么选择ScrumWorks Basic， 而不是其它如XPlanner、Version One、Mingle、Rally等工具呢？首先，这是一个商业化产品，一直有人持续开发与维护，大家不想重蹈ScrumWiki无人维护的覆辙；其次，有免费使用版，且无时间限制，如果需要，我们可以随时无缝切换到商业版ScrumWorks Pro；第三，根据当时的一个调查，业界使用率排名第三位，说明有足够的用户基础。第四，这个工具是专门为Scrum量身定做的，简洁直接，不像Version One、Mingle等工具因为需要考虑其它敏捷软件开发模式，而搞得过于庞大复杂。第五，从功能上讲，个人认为这个是对Scrum各个方面支持最好的商业产品。

一年下来，事实证明我们当初对ScrumWorks Basic的选择是非常正确的，它不仅容易安装、使用方便，还让我们的Scrum实践更加敏捷。

CS/BS两种访问模式，轻松满足Scrum项目管理需要

ScrumWorks Basic既提供了简单的web客户端，还提供了强大的java客户端，可以满足不同的使用需要。

桌面客户端需要在访问的机器上安装Java运行环境，允许用户操作所有的Scrum数据，譬如添加、修改、删除、移动Backlog条目，从Excel中导入或导出数据到Execl，后台数据备份，阻碍(Impediment)管理等。

通过ScrumWorks Basic创建或者打开一个产品后，通过桌面客户端登陆，即可以看到如上所示窗口。右侧是Product Backlog，可以通过“Releases”方式为Product Item组织分类，这点对于我们做了10多年的产品非常重要，因为产品Backlog需要分成多个发布版本来管理。左侧是以时间排序的Sprint列表以及对应的Sprint Backlog，可以根据需要，随时隐藏其中一侧。由于采用了“相对优先级”的概念，通过拖曳的方式就可以非常简单的设定优先级先后顺序（优先级高的在上面，低的在下面）。从“Product Backlog”到“Sprint Backlog”的过渡非常简单，只需要选定一组最高优先级的Backlog 条目，直接拖过去或拖回来即可，大大提高了我们开Sprint计划会议的效率。

左上角的分栏可以告诉我们正在工作在哪个产品上，因为我们一个团队就要负责三个产品，这点对多个产品的支持对我们也非常重要。

Web客户端（如下图所示）提供了一个轻量级的基于浏览器的访问方式，可以从任何一台装有Web浏览器的设备上访问。它提供了一个非常个性化的总结性的Web页面，不仅有Sprint 的Burndown Chart，还单独区分“用户自己的任务”、“全部任务”及“所有阻塞(Impediments)”, 方便单个用户更新任务状态、剩余工作量，添加备注，查看阻碍(Impediment)等。

简单高效的Sprint管理

ScrumWorks Basic提供了一个单独的Sprint管理接口，让我们的每个Sprint都变得有条不紊。

每次新开一个Sprint时，会有一个单独的对话框，只需要输入起止时间、Sprint名称、Sprint目标，以及选择对应的Scrum 团队即可。在Scrum开发模式下，为每个Sprint起一个名字，不但可以增加团队软件开发的乐趣，提高大家的参与程度，还可以记录下Scrum Team当时的心情，这点非常重要，而ScrumWorks Basic正好提供了这个接口。列举我们的几个Sprint名称，创意来自于《加里森敢死队》：

• Sprint1---"兵不厌诈（the Big Con）"
  因为大家第一次采用Scrum, 对这个Agile流程都很期待，同时呢，对于怎么做，如何用，还很模糊

• Sprint2---"越狱记（Breakout）
  经过了第一个Sprint后，大家干劲十足，士气高涨，认为我们可以在第二个Sprint取得重大突破（breakout）

• Sprint3---"虎口余生（Hours to doom day）"
  这个Sprint里面有很多技术难点需要破解，如果解决不了，那么后面的工作就无法进行，将是非常关键的一次攻坚战。

• Sprint4---"大结局(The Big End)"
  这次计划会议，作为Scrum Master，自己因为有事没有参加，汗！但大家认为工作基本差不多可以做完了，起了个结局的名字。

每天开站立例会时，可以把如下图所示的Sprint明细窗口用投影仪直接投放到墙上。让大家可以看到Sprint目标、Burndown Chart、Sprint Backlog 条目的状态及剩余时间等，提高沟通的效率和紧迫感。

如果遇到阻碍（Impediments），可以通过如下接口及时添加并更新进展。

通过“主题”分类管理Backlog

ScrumWorks Basic提供的“主题”功能可以更方便的组织和管理product backlog条目。“主题”就象关键字或者标签，可以分别应用到每个Product Backlog条目，从而实现Product Backlog条目的分组管理，这种方式比“文件夹”更有效，因为同一个条目按照自己的需要，可以施加一个或多个主题。 这样就可以轻松的按照指定的“主题”对backlog进行过滤，迅速找到你关心的条目。这种管理方式，对一个庞大的Product Backlog是非常有效率的。

对主题的分类，没有任何限制。可以按照需求列表划分，也可以按照功能列表花粉，或者你想到的任何其它分类模式。

我们把主题用到需求变更管理上后，获得了非常好的效果。把每一个需求，定义成一个主题。当某项需求变更的时候，我们通过该主题进行过滤，可以迅速找到可能受到影响的Backlog条目，分析影响的大小，再对回归测试计划进行相应调整，可以保证产品功能的完整性不受干扰。

多种报表
Scrum象其它敏捷软件开发方法一样，依靠的是经验管理，ScrumWorks Basic提供的多种报表与衡量机制，为经验管理提供了超强的支持。

Product Burndown Chart – 从更高的 角度展示当前Product的完成状况.	Enhanced Product Burndown Chart* 通过区分由于添加或者删除Backlog条目引起的变化，可以更准确地预测出产品可能的完成日期。
Dashboard Report – 通过一种简洁的 方式，将一个或多个产品的状态集成 在一起，并以颜色分别标示是否延迟、 是否正常，让高层管理团队对所有实 施Scrum的项目进展状况一目了然。	Sprint Change Report – 详细勾勒出Sprint中任务添加/删除/重新估算对整个产品backlog的影响。

其它亮点

ScrumWorks Basic除了提供多用户机制外，还提供了虚拟团队管理模式，一个用户可以加入不同的团队，这样可以让我们成功实现以下项目管理模式：

• 单个团队工作于单个项目
• 单个团队同时工作于单个产品的多个版本
• 单个团队工作与多个项目
• 多个团队工作于单个项目
• 多个团队工作与多个项目

此外，ScrumWorks Basic还提供了支持SOAP协议的API接口， 可以订制add-ons、报表，或跟其它应用程序集成。

缺失与遗憾

以上介绍都是基于ScrumWorks Basic这个免费版本的，同ScrumWorks Pro这个收费的商业版本相比，缺乏如下重要特性：

l 缺乏对Bugzilla和Jira的集成
ScrumWorks Pro与Bugzilla和Jira的集成，体现在它可以导入两者中的条目作为backlog条目，并且可以像对其他backlog条目一样，对这些条目进行操作。可以使用搜索来选择感兴趣的条目，并进行单独或多项导入操作。

l 没有带有主题过滤功能的burndown图表，及其他辅助了解项目状况和走势的功能
ScrumWorks Pro中，将backlog按照主题进行组织后（类似于web 2.0中使用标签），可以高亮或是过滤这些backlog，并且能够使用同样的主题针对burndown图进行过滤，这点对定量分析还是非常有用的。

l 不能添加附件
对于Backlog条目而言，如果能添加需求、设计等文档或其它文件，将是很有用的。

l 邮件自动通知

l 跨团队、跨产品、跨项目的“我的任务”视图

l Sprint日历订制，主动剔出周末或者其它假期的干扰，生成真正的Burndown Chart

如果不想忍受这些缺失与遗憾，而且资金充裕的情况下，可以选择ScrumWorks Pro。

更多敏捷实践总结，可以参考笔者的敏捷软件开发随笔(http://scrumxp.blogspot.com)。

阅读详细......

Scrum工具大比拼---流行Scrum工具一网打尽

早就想写这个总结了，因为SCRUM很好， 工具却难找，但一直没有出台，是想等自己都试用过后，这样才更有发言权。可有些工具真的是很难搭起一个环境，这样只好摘录一些网友们的评论了！

---敏捷精灵

白板
最直接的方式，用于每天的tracking，还是非常不错的，但是对Product Backlog支持明显不够

Excel
我们最初也用过，主要是成员多的情况下，修改时会相互冲突，不好同步。。可以参考我写的这个文章[scrum工具]用excel表格工具实现Scrum

ScrumWiki
这个也用过，一开始感觉还不错。但当你的需求变多变复杂的情况下，就不容易用了。后台脚本使用Perl写的，我们的一个外国同事还对他专门进行了修改，增加了好多feature,这样才好用起来。作为免费的软件，目前已经没有人支持和维护。

Scarab

Java server 平台, 支持灵活定制，免费

Double Chocco Latte
基于PHP , 支持Apache 或IIS, MySQL or SQL Server , web 客户端，免费

VersionOne
商业化产品！没什么好说的，业界老大！

从 功能上看，的确非常新颖，贯彻了敏捷中的User Story为先的原则，和VSTS类似，将Issues、Defect、Task合并概念成为Task(在VSTS中更加优雅，叫做WorkItem)， 并且必须挂在UserStory下，这个工具值得看看，有试用版可以下载，或者可以使用他们在线提供的试验平台

基于ASP.NET and IIS和 SQL。

团队可以使用“V1：敏捷团队”来管理产品和sprint backlog，通过交互式的“任务板（taskboards）“和"测试板（testboards）" 进行每日开发活动，藉由报表和燃烧图查看进度，以及其他活动。
通过这些功能，“V1：敏捷团队”的用户可以做到：

• 从电子表格中快速导入故事与缺陷，管理合并后的产品backlog。
• 利用简单的多条目拖放操作，方便地完成计划制定、对故事划分优先级。
• 使用电子白板界面同时制定多个版本的发布计划，提高效率。
• 通过交互式的任务板（Taskboard）、测试板（Testboard）、每日Scrum dashboard来对版本和sprint进行可视化追踪。
• 针对版本和sprints的关键敏捷度量数据生成图表，如Burndown、Velocity、Estimate trends、Cumulative Flow Reports。

唯一的问题就是提供的选择过多，对于寻求简单明了工具的人，并不是一个好产品！.

GNATS
GNATS 传统来讲，属于缺陷跟踪工具, 但根据Jeff Sutherland， 已经支持 Scrum. 免费

欢迎访问 "敏捷软件开发随笔---敏捷精灵二三事"

Select Scope Manager
商业化产品，有试用版可下载。定制性比较差.

XP Plan-it
仅仅支持把你的数据放在他的server上，你通过下载的客户端更新和查看数据。。 好像对大多数人来讲意义不大

XPWeb
另一个基于web的分布式方案。免费！

使用PHP+MySql可运行于Linux, Windows, or Mac.但其演示在IE7下工作不怎么样，没法详细测试.

XPlanner
最牛的祖父级的开源工具，完全免费，业界使用率排名第四，真的是穷人的项目管理工具！

作为一个基于Web的XP团队计划和跟踪工具，要求 Apace Tomcat。

XP 独特的开发概念如iteration、user stories等，XPlanner都提供了相对应的的管理工具，XPlanner支持XP开发流程，并解决利用XP思想来开发项目所碰到的问题。 XPlanner特点包括：简单的模型规划，虚拟笔记卡(Virtual note cards),iterations、user stories与工作记录的追踪，未完成stories将自动迭代，工作时间追踪，生成团队效率，个人工时报表，SOAP界面支持。.

ScrumWorks
个人认为对Scrum个方面支持最好的商业产品，市场排名第三位,我们一直在用。可支持不同的Team工作于不同的项目上，非常灵活。既有简单的web客户端，也有强大的java客户端。

有免费使用版，且无时间限制，我用的就是。

支持对Bugzilla和Jira的集成，带有主题过滤功能的burndown图表，以及其他辅助了解项目状况和走势的功能，还有众多别的特性。

ScrumWorks Pro与Bugzilla和Jira的集成，体现在它可以导入两者中的条目作为backlog条目，并且可以像对其他backlog条目一样，对这些条目 进行操作。可以使用搜索来选择感兴趣的条目，并进行单独或多项导入操作。Infoq与Danube科技的JD Aspinall进行了交流，讨论了这个特性的本质，以及如何与ScrumWorks Pro一起使用Bugzilla和Jira。

我想提出这个特性请求的用户们都希望同时使用这两个工具。

产品的许多用户将他们全部的bug作为Product Backlog条目录入到ScrumWorks Pro中并进行跟踪。不过也有很多其他用户，由于其他种种原因，使用不同的工具来跟踪问题，并且只选择导入某些特定的缺陷到ScrumWorks Pro中。

Burndown图表现在可以按照主题 进行分组。将backlog按照主题进行组织后（类似于web 2.0中使用标签），你可以高亮或是过滤这些backlog，并且能够使用同样的主题针对burndown图进行过滤。

ProjectCards
ProjectCards 维持项目管理的索引卡片，精确的具体内容，一个项目控制盘，搜寻和过滤能力和拖放反复计划。六十日免费的试用。

基于 Client/Server结构，支持plug-in for Eclipse.

TargetProcess
是一个敏捷项目管理与Bug跟踪系统。企业版提供很多定制的功能，包括Pre-paid 20 hours of development by TargetProcess stuff和提供开发指南与API参考的全部源代码。

这个工具挺适合小项目团队的。

这儿有个 Demo 帮助读者理解这个产品，内容是通过创建一个新的项目，在迭代计划时给开发人员指派故事（Story）。

他们的价格模式包括“按站点 / On Site”（需要安装）和“按需 / On Demand”（Web版），并提供折扣。

ExtremePlanner
一个基于web的工具，它的功能几乎与ProjectCards完全一样，但是它添加了在任务级别进行评估的功能，这一改进非常棒。由于是基于web的， 所以它的界面可能不够漂亮，但是由于基于浏览器，它获得了一些灵活性（例如，当项目成员想在线查看状态报告时，如果是使用ExtremePlanner，就无需安装任何东西。）

我还在进一步考察这个工具，但是它看起来相当不错。

要求Windows, Linux, or MacOSX平台 (with Java 1.4.2 or higher and Apache Tomcat 4.1 or higher)

Rally
商业软件用户使用率排名第二位！支持用户需求的筛选、扩展的筛选标准、改进版本剩余时间表、新的通知规则（notification rules），以及用于Eclipse和CruiseControl.NET的连接器。

有免费在线试用体验版本.

Mingle

Mingle在ThoughtWorks官方站点可以免费下载，且5个用户以下的可以永久免费使用。Mingle是用纯Ruby打造的且运行在JRuby上 的一个产品，由于ruby是一门脚本语言，所以其移植性就很好，用其编写的程序安装起来也甚是容易，在Windows、Mac和Unix多种主流平台上跑 都是没有问题的；但也正是由于采用ruby编写，Mingle对硬件的要求也甚高，在我这台512M内存的机器上跑是超慢的、让人闹心的，建议还是放到性 能好的、单独的服务器上，内存容量官方建议是2G。还遇到了好几次ie错误，只好放弃了。

Mingle后台存储采用数据库方式，目前仅支持mysql和Postgres两种数据库版本，这个比 较遗憾，我无法使用现成的Oracle数据库了。

简单用了一下，发现如下很好的Features：
- 支持建立"个性化"项目模板，便于复用；
- 附带项目wiki，便于"项目知识积累和管理"；
- 丰富的card properties，使需求驱动的管理流程更加清晰；
- 支持card和源代码之间的link；.

TRICHORD
这个名为“TRICHORD”的敏捷项目管理工具，是基于精益思想的，对Scrum也适用。TRI指的是三种视角（时间、任务和团队），CHORD则是和谐的意思。

它作为全团队分享项目状态的一个工作空间来运作，里面提供三种层次的看板图——特性看板（发布—特性）、故事看板（故事—迭代）和任务看板（工作日—任务）。特性看板用停车场图来归纳，故事和任务看板用延烧图来归纳。

具体可以参考这篇文章 用“看板图”实现敏捷软件开发项目的可视化
阅读详细......

Scrum介绍---Scrum in 90 minutes

刚刚发现一个《Scrum in 5 min》，而这个43页的ppt介绍地更加具体和详细, 可以真正让你懂得什么是Scrum。

---敏捷精灵

This is a 90 minute introduction to Scrum that is fully redistributable and reusable. Use it to introduce Scrum to your user group or organization. Provided as a PowerPoint file so you can customize it. For Mac users, the presentation is also available in Keynote, which is what it was created in. Please acknowledge the source but please use it widely. ……

Thank you to these translators to their generous contributions.

This is a completely updated, much fancier version of this popular file that has been available for download since 2002.

…

阅读详细......

Scrum是什么---Scrum in 5 min

Scrum是什么？什么是Scrum? 想简单了解一下吗？这是一个关于Scrum的快速介绍，只有16页，有一些很有趣的图，非常容易理解，是不错的扫盲书。

---敏捷精灵

Softhouse - Scrum in Five Minutes

阅读详细......

[最佳实践]在Scrum敏捷软件开发模式中，我们是如何开Sprint 计划会议的

在Scrum敏捷开发框架下，最重要的一环就是 Sprint计划会议，这个会议开不好，整个Sprint会让Scrum Team痛苦不堪，也很难完成最初的Sprint目标。经过多次尝试后，我们终于找到了我们自己的模式。这些方法和原则对我们来讲是最好的，这基于我们自 己的知识，我们自己的项目情景，对于其他团队不一定试用。

---敏捷精灵

• 跟任何其他会议一样，确定好会议日程

sprint计划会议一定是要基于Time-Boxed, 在规定的时间内，一定要结束，就像一个Sprint一样。

我们的日程一般是这样的

Agenda:

Part I : Product Backlog Review [Product Owner, Scrum Team]

Time: 2 Hours

1) Enrich Product Backlog (60 Minutes)

2) Re-Prioritize Product Backlog Items (10 Minutes)

Break(10 Minutes)

3) Set Sprint Goal (20 Minutes)

4) Select Product Backlogs to Sprint (20 Minutes)

Part II: Sprint Planning [Scrum Team]

Time : 3-4 Hours

1) Work Breakdown by Two groups. (60 Minutes)

Break(10 Minutes)

2) Agree with the definition of "DONE" for each task with estimation (20 Minutes)

3) Critical Path Analysis (20 Minutes)

4) Resource Plan (20 Minutes)

Break(10 Minutes)

5) Find owner for each task. (40 Minutes)

6) Risk/Dependecy Analysis (20 Minutes)

7) AOB

• Sprint计划会议必须在一个完整天内开完

Sprint计划会议开始的那一天，也就是Sprint开始的一天。如果Sprint计划会议要跨越两天，可不是什么好玩的事情，你的Burndown Char就会象我们的这样很难看。因为我们是在前一天的下午开了4小时，第二天上午又开了3小时，对任务进行细化。。。

• 采用Delphi方法进行任务工作量的估算

当进行任务细化的时候，每个人的估算是不一样的，当出现分歧的时候，采用Dephi估算方法，如果最高估算值跟最低估算值相差一半以上，而者就要进行沟通一下，看看为什么二者的理解相差这么多。沟通明白后，再重新估算

• PM必须在Sprint计划会议前给出Sprint参与人员的预期工作时间

根据我们的历史统计，我们的投入率基本在75%左右，譬如按一个人上班8小时计算的话，他用在项目上时间大概在6小时左右。如果这个Sprint周期需要 15个工作日，这个员工可能要休假2天，参加培训1天，那他可以投入的预期工作时间 就是 6*（15-2-1）= 78小时。这样，在这个Sprint中，会有多少“人小时”就会事先计算出来。在Sprint计划会议中，当选择和细化Sprint任务的时候，有这个总 预期工作时间总作参考，就可以避免任务不足，或者承诺过多的问题。同时，也提醒每个人在领取任务的时候，不要过度承诺。

• 为了提高任务细化的效率，将团队分成两个小组分别进行
  

最初，我都是打开投影仪，把ScrumWorks中的东西投到屏幕上去，大家一边说，我一边敲，我是挺忙活的，但是大家却不一定都能集中注意力。。。现在 回头看看，这种方法真是有点蠢！当team成员少的时候，在最初的几个Sprint，大家在兴趣还比较高的时候，这种方法还行。

当Team成员超过6个的时候，问题出现了，首先是当讨论某一个问题的时候，总会有人问，刚才你们说什么来着？很显然，他走神了。。。另外，人多地时候，对同一个任务的细化，即使采用Delphi方法，沟通成本也很高，很费时间。

把team分成两个小组，分别对任务进行细化。细化时，不再用投影仪，而是把Sprint Backlog中的内容按大块张贴在墙上，大家站在墙前，拿着纪事帖直接进行细化和估算。 当两个小组都进行完后，互相检查对方对任务的细化，解决争议，澄清模糊的地方。这样一来，就把大家的积极性调动起来，参与程度非常高，效率也高。

• 对任务"DONE"的定义一定要做好，做细！
  

这个问题不言而喻，就不多说了。

• 虽然我们采用了Scrum，但是传统的Risk/Dependency分析还是不要丢弃。

即使不再采用Gatt图，但在Sprint计划会议结束前，进行Risk/Dependency的分析，还是帮助我们发现了一些问题，通过重新调整任务的优先级，顺利保证了Sprint的成功。

• 产品负责人(Product Owner)一定要参加。

实在不能参加的话，也要指定一个人授权代理。否则，就不要开Sprint 计划会议。

• Sprint Goal一定要定义的简洁、突出，选择的Sprint Backlog Item一定要强内聚，松耦合

这样大家才能不受或者少受外界的干扰，目标明确。

• 要给Sprint起一个好的名字
  

关于这个问题，就不多说了，详见 前文 “在Scrum开发模式下，为Sprint起名字的艺术”


阅读详细......

国外敏捷软件开发相关网站资源大全

Agile Alliance
敏捷联盟
敏捷方法发源地，有许多最新的研究文章和发展动态。

Cetus-Links
历史悠久的对象技术资源网站。在“OO Project Management - OOA/D Methods”条目下提供了大量迭代与敏捷方法资源链接。

Brad Appleton
大量软件工程、迭代方法资源链接

C2 Wiki
XP、敏捷方法、设计模式等重要思想的发源地
Ward Cunningham

极限编程
Don Wells
不错的 XP 介绍

极限编程
Ron Jeffries
XP 大师介绍 XP

Agile Modeling
敏捷建模
Scott Ambler



美国南加州大学（USC）软件工程中心（CSE）
软件工程大师 Barry Boehm 多年来有关迭代方法（如螺旋模型）的研究成果。

Cutter Consortium
著名的软件工程咨询机构，有一个“敏捷项目管理”专题。

XP 敏捷大师 Martin Fowler

ASD（Adaptive Software Development）方法创始人 Jim Highsmith

Crystal 方法创始人 Alistair Cockburn

Scrum 方法创始人 Ken Schwaber

Scrum 方法创始人 Jeff Sutherland

Evo 创始人 Tom Gilb 大师
历史最悠久的迭代演进式方法之一

敏捷方法大师 Craig Larman
我向全国每一位软件项目经理推荐 Larman 的著作 Agile & Iterative Development: A Manager's Guide。

Object Mentor
敏捷大师 Robert C. Martin 的咨询公司

Nebulon
FDD 方法发明人 Jeff De Luca 的公司网站

DSDM 方法官方网站

Rational Unified Process
IBM RUP 产品，如今叫 RMC（Rational Method Composer）

Network for Agile Methodologies Experience (NAME)
一个介绍敏捷方法研究及相关资源的欧洲网站

Agile Metrics
Robin Gibson
ThoughtWorks 的咨询顾问 Robin Gibson 创建的个人网站，其中 Agile Tool 栏目下的 Estimates/Risk Spreadsheet 很不错。

XP San Diego Wiki
美国圣地亚哥地区的一个 XP 社团 Wiki，其中的 Agile Tools、Book Reviews 以及当地采用敏捷方法的企业名单值得一看。



阅读详细......

[scrum工具]用excel表格工具实现Scrum

这是最初用Scrum的时候，搜集到的一个工具，感觉还是挺不错的。虽然现在我们改用ScrumWorks, 但我还是喜欢用这个工具生成一个初始的Burndown Chart,再把他打印出来，贴到看板上，每日开Standup meeting的时候，手工更新一下，生成实际的Burndown chart.。

----敏捷精灵

需要的朋友点这里下载。

这里还有一个实际模拟使用示例，不妨也看看。


以后再添加其它的工具

阅读详细......

Scrum敏捷项目管理的 ppt

很久以前总结的Scrum敏捷项目管理资料，给Team内部做Scrum Training用的，拿到这里，希望对大家又帮助，不过是E文的啊！

----敏捷精灵

想下载这个 Scrum敏捷项目管理.ppt 的可以直接点击这里

对于Scrum敏捷项目管理，每个人都会有自己不同的理解， 欢迎大家提出意见。

阅读详细......

在Scrum开发模式下，为Sprint起名字的艺术

在过去的几个月中，我们在每个Sprint 计划会议上，都会花上几分钟的时间，一起为当前的Sprint起名字，现在回顾一下，还是非常有意思的。

---敏捷精灵

看一下我们为项目A起的Sprint名字：

• Sprint1---"The Big Con"
• Sprint2---"Breakout"
• Sprint3---"Hours to doom day"
• Sprint4---"The Big End"
• Sprint5---"The Dragon Warrior"

熟悉加里森敢死队的同学一定会很兴奋的，因为我们这里面用了《加里森敢死队》好几集的名字，之所以选择《加里森敢死队》，是因为我觉得这个团队里面有一个很好的team leader-----
上尉加里森，以及各有所长的成员：小偷、酋长、戏子、强盗。。。他们各自发挥自己所长，完成了很多难以想象的任务，这样的团队，对于软件开发团队来讲，太需要了！

• “队长”（绰号：“头儿”）加里森中尉（Lt. Craig Garrison）由罗·哈珀（Ron Harper）饰演，西点军校毕业生，美国陆军情报部中尉，敢死队队长。童自荣配音。
• “戏子”（Actor）由塞萨·多诺万（Cesare Danova）饰演，一名诈骗犯，精通多种语言。他的特长是化妆与扮演。乔榛配音。
• “卡西诺”（Casino）由鲁迪·索拉里（Rudy Solari）饰演，一名惯盗，精通保险柜锁，对爆炸物也有一些了解。杨成纯配音。
• “酋长”（Chief）由布兰登·波恩（Brendon Boone）饰演，一名杀人犯，他的特长是飞刀、机械修理和驾驶。施融配音。
• “高尼夫”（一译“高涅夫”、“哥里弗”）（Goniff）由克里斯托弗·卡里（Christopher Cary）饰演，一名扒手神偷。尚华配音。
• “准成员”，一名杀人犯，因贪财在第一集中就丧命了。

下面具体讲解一下每个名字对于我们自己的含义:

• Sprint1---"兵不厌诈（the Big Con）"

因为大家第一次采用Scrum, 对这个Agile流程都很期待，同时呢，对于怎么做，如何用，还很模糊

• Sprint2---"越狱记（Breakout）

经过了第一个Sprint后，大家干劲十足，士气高涨，认为我们可以在第二个Sprint取得重大突破（breakout）

• Sprint3---"虎口余生（Hours to doom day）"

这个Sprint里面有很多技术难点需要破解，如果解决不了，那么后面的工作就无法进行，将是非常关键的一次攻坚战。

• Sprint4---"The Big End(大结局)"

这次计划会议，作为Scrum Master，因为有事没有参加，汗！大家认为我们的工作基本差不多可以做完了，起了个结局的名字。

• Sprint5---"The Dragon Warrior（神龙大侠）"

事实证明，我们上一个Sprint4过于乐观了，我们还需要一个Sprint才能完成所有的工作，包括Bug Fixing，文档等等。。。。正好那期间播放《功夫熊猫》，在sprint4结束后，大家提议这次的Team Building就去看电影吧（嘿嘿，我们一直坚持每个Sprint结束，就搞一次Team Building,羡慕吧！ ）。。。。。电影归来，就把 "The Dragon Warrior（神龙大侠）"颁给了Sprint5

经过半年多的时间，项目A终于顺利结束了！


其实，在项目A开展的同时，我们随后又Kick Off了另外一个项目B，我还是Scrum Master，但成员有所变化。基于项目A中对Sprint起名字得良好实践，我们为项目B中的Sprint也起了名字，看到名字，大家自然就会联想到007、奥运等等。。。：）

• Sprint1---"Golden Eye" 《黄金眼》

没啥特别意义，大家觉得项目A用了《加里森敢死队》，这个就用007系列好了

• Sprint2---"Live and let Die" 《生死关头》

因为需求太不明确了，大家也不知道能不能做下去，表达了一种不甚乐观的情绪。。。。事实证明大家的感觉是对的，我在Sprint进行一般的时候，终结了这个Sprint，因为真的做不下去了：）

• Sprint3---"You only live twice" 《择日而亡》

继续的不乐观，但我们最终还是Live下来，大家想表达的是：我们不能再Fail掉这个Sprint了！

• Sprint4---"The Matrix Revolution" 〈矩阵革命〉

情形不错起来，大家心气又高了！决心做一次大的改变！

• Sprint5---"One World One Dream"

奥运月，没什么可说的，与时俱进！

这个项目B还会持续到明年才能结束，我们会一直坚持下去这个实践的！

总结一下，在Scrum开发模式下，为Sprint起名字还是挺有艺术的，也是很有好处的：

1. 增加软件开发的乐趣（不是一直说，软件开发就是协作游戏嘛！）
2. 提高大家的参与程度
3. 记录Scrum Team当时的心情

阅读详细......

[修改于Pipin版]从美式Scrum说起 (一家美国公司的Scrum敏捷项目记要与思考)

朋友Pipin发表于《程序员》08年8月刊杂志上的文章，写的非常好，这里做了些许的修改，共享给大家！

---------------------------------------------------------

从美式Scrum说起

一家美国公司的Scrum敏捷项目记要与思考

许舟平

2008年7月16日

引子 敏捷是一个过程

从计算机诞生的那一天起，如何编写最符合用户要求的代码就一直是每一个软件开发者所追求的目标。随着计算机应用领域的不断扩大，人们对软件的需求量和功能性要求不断增加，并且迫切需要缩短软件开发的周期。软件危机的到来孕育了软件工程学在1968年的诞生，计算机软件从原来面向的科学计算走到了人民大众的日常生活中。当软件产业已经向服务业靠拢的时候，软件工程也在向着需求工程倾斜着。当客户需求的变化和软件开发模式的固有矛盾相遇时，敏捷开发就从软件工程学中诞生了。

敏捷是一个过程，敏捷开发实际上是根据软件特性和用户需要的敏捷价值观，通过遵循敏捷的原则来进行软件开发的一系列过程的集合。笔者前些日子接触了一个国外运用敏捷开发的项目实例，现在拿来和读者分享，希望能对中国的敏捷开发者有所帮助。

项目背景

美国公司A是一个典型的在硅谷诞生的软件公司，以技术为导向，产品很新，更新速度很快，销售渠道稳健、高效，在销售产品的同时可以有效的把握好客户需求，并能将客户需求趋势反馈给开发团队。项目背景是在通过公司前几个产品将市场打开之后，公司急需推出一个全新版本V，能够将早期的几个产品integration到一个平台之上，并通过客户的需求反馈做产品功能的增删和Bug Fix。开发团队分为二个Team，Team1负责构建一个全新平台，用来integration原有产品；Team2负责进行原有产品的bug修复和根据客户需求变更所做的程序模块改动；Team人数分别在8至10人，项目周期以月而记，分为3个周期，采用Scrum模式来做敏捷开发（Scrum是一种寻求充分发挥面向对象和构件技术的开发方法，是对迭代式面向对象方法的改进）。项目的风险在于：1.项目开发时间紧，要求在3个月内完成开发阶段工作；2.team1和team2在各自的Scrum开发周期内要完成功能联调和集成，需要并行工作；3.产品测试部门采用外包方式，测试人员在国外，而产品质量必须得到保障。

之所以采用Scrum，是因为Scrum方法将传统开发中的分析、设计、实施视为一个黑箱，认为应加强黑箱内部的混沌性，使项目组工作在混沌的边沿，从而充分发挥每一个程序员的创造力。下面就让我们通过Scrum的方法论来深入解析Team1和Team2的开发过程。

项目组织

在公司A中，分别由二个资深的项目经理来担当每个小组的Scrum Master角色，每个Scrum Master来负责本小组中的人员协调和项目组织工作，他们的真正工作职责并不仅仅是传统意义上的Project Manager或Team Leader，其最主要的工作是使各自所在小组内的工程师有充分的交流。每个小组都是由不同专业的人员组成，其中包括了程序开发人员，UI设计人员，文档人员等。Team1小组人员的划分是按系统层次导向（按体系结构中的分层），Team2的划分则是按功能导向（即按所分配的问题包或Backlog）。

图一：Scrum流程示意图

在项目的初始阶段，Team1和Team2的Scrum Master分别将各自负责的产品功能要求（注意：那时的产品功能并没有得到细化）、用户改进建议、技术升级等任务安装优先级排序形成一个Backlog列表，而后将Backlog列表中的各项按照其耦合性的高低分解称为不同的问题包Packets，并根据不同的问题包Packets来划分相应负责的开发人员，并由他们建立开发运行环境。在这个阶段笔者注意到了一个有趣的地方，那就是在项目设计阶段并没有一个传统意义上的架构师Architect角色。这省却了在传统的开发模型中概要设计和详细设计的时间，但并不意味着没有系统设计和文档，稍后会做介绍。而没有Architect的另一个好处是team中的每一个程序员都分担的Architect的作用，对于中国做敏捷开发的团队，由于传统的Architect存在着固有的领导思维意识，并且经常是由Team Leader或者PM来兼任，所以尽管运用了敏捷开发的方法，但却不能起到真正调动每一个程序员创造力的作用。而在美国，这种情况基本不会发生。

项目进程

经过了项目初始阶段的确定性过程后，项目进入了经验性过程的Sprint阶段。顾名思义，Sprint即为冲刺，运用在Scrum敏捷开发中的Sprint阶段就是在项目初始阶段确定了系统体系结构之后，在一段的限定时间内所完成的一系列开发活动，其中包括在前一个阶段可能没有做完的产品功能细化、设计、编码、单元测试等工作。在项目V中，Team1和Team2分别分解了3个Sprint周期，每个周期为4周，在第3个Sprint周期开始时要保证Team1和Team2完全可以并行工作和可以进行联调。一个Sprint周期结束之后即要完成在该Sprint周期中所规定需完成的Backlog项，并产生可执行的版本。对于开发人员来说，在每个Sprint周期中，他们都需要完成对所分配的Backlog工作进行分析、设计、开发、实施、测试和文档化等工作（在项目V中Team1和Team2的开发人员采用Wiki代替传统软件工程的文档管理）；在完成这些后，通过打包来封装Packets，从而产生满足各自Backlog需求的可执行版本，然后通过评审（Review）和回顾(Retrospective)，提出和解决开发中遇到的问题，并增加新的Backlog项，进行项目风险评估和相应对策，从而确定下一个Sprint的Backlog内容和完成时间。在每个Sprint进行过程中，每个Scrum Team都会通过Daily standup meeting进行沟通，交流遇到的问题，互相帮助。

当项目V进入到最后一个Sprint周期时，Team1和Team2中负责Integration接口模块设计的开发工程师将与QA人员一起进行系统联调，并由二个小组的Scrum Master在每个礼拜一下午召开Scrum Meeting（如图2中所示），来讨论系统需求变化和Bug修复情况。由此根据这个跨Scrum Team的Meeting的情况实时做出Backlog项的调整和从新分配。然后再进行打包封装交给QA人员进行测试。这个周期非常短，可能二、三天甚至一天就会有一个新的版本出现。

在这个过程中，公司A开发工程师的单兵作战能力给笔者留下了很深刻的印象。比如Team1中UI设计师具有10多年的专业设计经验，仅凭一己之力就完成了Team1中所有的界面模块设计和调用接口工作。项目中的每一个工程师都在系统建模、设计、开发环境部署、程序打包上拥有丰富经验，实际上他们已经分别完成了在传统软件工程中系统架构师、Coder、Tester和Build Manager等工作。与他们相比，国内软件公司处于的一线软件工程师大多属于拥有2-5年工作经验这一经验积累阶段，在个人技术的确存在差距，这种差距在某一方面导致我们国内的软件厂商在相似的开发项目上，同样运用敏捷开发方法，却不能充分达到一个良好的效果。这也与我们的国情有关，想想10年前老一辈的程序员，有多少现在还战斗在开发的第一线呢？不过没有关系，中国的软件产业正在慢慢成熟，一个充分良好的开发环境会让越来越多的程序员迅速成长起来，毕竟我们从事软件开发人员的基数是不可小视的。

图二：处在Sprint冲刺阶段的项目示意图

项目成果

在Scrum过程中会认为软件产品的开发是一个持续性过程，除非该软件产品经风险评估后认为可以停止。通过一系列的Sprint阶段，项目V会产生一个稳定可靠的版本交给公司的Release Manager。而处于Scrum过程中的最后阶段――软件产品交付后的巩固活动则近似于传统软件工程中的系统维护和改善工作，其目的在于整理Sprint阶段中由于压力而忽略的工作，为下一个Sprint阶段的开发做准备，以便轻装上阵。

思考：敏捷，不仅仅是敏捷

在中国软件公司的敏捷开发项目里，对比于国外，有着许多影响敏捷开发但又在敏捷开发理论以外的东西。比如开发者经验的不同，开发环境的不同，软件开发公司的管理状态等等。笔者接触过国内的很多软件企业的开发团队和项目管理者，不可否认的是，中国的软件开发在很大程度上一直处于长期借鉴国外软件开发的模式。而在借鉴的过程中，形似而神不似的情况屡屡出现，很多时候，我们只是将国外的开发模式照搬过来，并没有根据中国软件业特有的国情和我们的开发者实际情况作出合理的调整。比如当年CMM火热之时，国内的很多公司都投入巨大的人力物力来做评估，来搞文档管理和过程控制，可是到头来除了取得一纸证书以外并没有给软件产品带来本质性的提高，软件开发效率和质量依旧一塌糊涂，Maintenance team每天还是要不断的应付客户反馈回来的bug和投诉。而对于敏捷开发来说，希望国内的项目管理者能够抓住敏捷开发的精髓，让我们的软件能够真正的敏捷起来。

阅读详细......