Scrum+xp敏捷软件开发随笔-----敏捷精灵二三事

《敏捷无敌》上市居然引来一些好玩的事情

2009-07-07T08:48:00.003+08:00

不知道怎么就得罪了几个人，开始网上说些不入流的话。。。
估计原本想恶搞一下这本书的，没想到事与愿违，反而起到了意想不到的宣传效果。

很快让此书就冲到了china-pub某个栏目的第二位。。。

网上最大的敏捷软件开发资料站 http://incredibleagile.com/

关于http://incredibleagile.com/ 的实验结果很有意思

2009-07-07T08:45:00.001+08:00

关于http://incredibleagile.com/ 的实验

虽然只作了一个页面，稍稍做了点SEO, 很快就被google收录了。。。

并且从最初的第六页，不断上升。。。。现在已经到了第二页的正数第五的位置。。。

不过，baidu还是没有收录，看来竞价排名跟google还是不一样啊！

网上最大的敏捷软件开发资料站 http://incredibleagile.com/

做个敏捷软件开发资料站的SEO实验

2009-06-24T11:17:00.000+08:00

最近blogspot在国内普通用户又不能直接访问了，还得翻墙。。。真是不爽！

做个实验，看看能有多少流量敏捷软件开发资料站

http://incredibleagile.com/

看看多长时间能收录，然后才是流量了 :)

《敏捷无敌》终稿

2009-05-19T12:56:00.005+08:00

真可谓好事多磨，经过两个多月的调整、排版、纠错，《敏捷无敌》终于终稿。明日即将送至印刷厂进行批量印刷。这次首印5000册，价格39.00.

这里提前晒晒书皮吧。

欢迎大家拿到真书的时候多提宝贵意见，到《敏捷无敌》论坛 http://bbs.richaide.com 进行在线沟通交流。

谢谢。

欢迎大家共同建设一个《敏捷社区》

2009-02-23T12:40:00.003+08:00

好久没有更新这个Blog了，主要是因为最近正在忙于一本敏捷软件开发的小说。

现在终于完工了，跟出版社签订了合同，即将出版。

同时准备建设一个关于敏捷软件开发的社区: http://bbs.richaide.com/index.php

欢迎大家到那里去捧场！

Hire Attitude - Train Skills

2008-11-05T16:05:00.001+08:00

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更敏捷

2008-10-20T09:00:00.005+08:00

这个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工具一网打尽

2008-09-19T14:00:00.012+08:00

早就想写这个总结了，因为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

2008-09-18T08:59:00.004+08:00

刚刚发现一个《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

2008-09-18T08:55:00.003+08:00

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

---敏捷精灵

Softhouse - Scrum in Five Minutes

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

2008-09-15T13:36:00.010+08:00

在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起名字的艺术”

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

2008-09-11T21:48:00.002+08:00

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

2008-09-10T21:57:00.005+08:00

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

----敏捷精灵

需要的朋友点这里下载。

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

以后再添加其它的工具

Scrum敏捷项目管理的 ppt

2008-09-10T10:09:00.007+08:00

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

----敏捷精灵

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

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

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

2008-09-08T09:16:00.015+08:00

在过去的几个月中，我们在每个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起名字还是挺有艺术的，也是很有好处的：

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

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

2008-07-27T14:59:00.000+08:00

朋友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和投诉。而对于敏捷开发来说，希望国内的项目管理者能够抓住敏捷开发的精髓，让我们的软件能够真正的敏捷起来。

[Scrum工具]推荐一本好书---《硝烟中的Scrum和XP》

2008-07-17T14:26:00.003+08:00

这是小刀同学的力作，翻译的真好！希望能很快正式出版！

作者 Henrik Kniberg译者李剑发布于 2008年7月7日上午4时45分

在本书中，作者Henrik Kniberg讲述了他在一年的时间里，带领40人的团队实施Scrum的过程。他们试过了多种团队尺寸（3～12人）、sprint长度（2～6星期），定义“完成”的不同方式，不同的backlog格式，各种测试策略，在多个Scrum团队之间进行同步的多种方式。他们还尝试过XP实践——持续集成、结对编程、测试驱动开发等等，还试过了把XP跟Scrum组合。

本书描述的是一个成功敏捷团队的工作过程，没有理论、没有引用、没有脚注、没有废话。读者可以把它当作一些基础实践的入门指南，帮助团队进行正确实施——但不能模仿，你需要了解自己所处的环境，进而对具体实践做出取舍，创造出属于自己的过程。

本书目录

简介
我们怎样编写产品backlog
我们怎样准备sprint计划
我们怎样制定sprint计划
我们怎样让别人了解我们的sprint
我们怎样编写sprint backlog
我们怎样进行每日例会
我们怎样进行sprint演示
我们怎样做sprint回顾
Sprint之间的休整时刻
怎样制定发布计划，处理固定价格的合同
我们怎样组合使用Scrum和XP
我们怎样做测试
我们怎样管理多个Scrum团队
我们怎样管理地理位置上分布的团队
Scrum master检查列表
额外的话
有关作者

有关作者

Henrik Kniberg（henrik.kniberg@crisp.se）是一名咨询师，在斯德哥尔摩的Crisp公司（www.crisp.se）工作。他的专长是Java和敏捷软件开发。

自从第一本有关XP的书籍和敏捷宣言问世以来，Henrik就开始拥抱敏捷原则，并尝试在不同的组织中进行有效应用。在1998年至2003年间，他作为Goyada的合作创始人和CTO，构建并管理一个技术平台和30人的开发团队，充分试验了测试驱动开发及其它敏捷实践。这个网站上有他的更多信息：http://www.crisp.se/henrik.kniberg

免费下载此书

硝烟中的Scrum和XP（免费下载这本书（PDF））免费下载这本书（PDF）

原文 www.infoq.com/cn/news/2008/07/scrum-xp-book

敏捷精灵日记21

2008-04-28T10:31:00.000+08:00

[敏捷精灵日记]

人才的流动是非常正常的事情,否则,社会也无法前进.但对于一个企业或者一个团队而言,人才的流失会是一种损失.流失人才并不可怕,最可怕的是领导人没有从中学到什么,没有搞清楚人才为什么会流失,没有采取亡羊补牢的措施.长此以往,招到的人才,还会不断的流失。

敏捷精灵日记20

2008-04-08T18:29:00.000+08:00

[敏捷精灵日记]

尽管一个组织必须重视管理人员成长可能性并通过提供更大的发展空间等手段来激发他们的潜能，但彼得原理可以作为一种告诫：不要轻易地进行选拔和提拔。解决这个问题最主要的措施有三个：第一，提升的标准更需要重视潜力而不仅仅是绩效。应当以能否胜任未来的岗位为标准，而非仅仅在现在岗位上是否出色。第二，能上能下决不能只是一句空话，要在企业中真正形成这样的良性机制。一个不胜任经理的人，也许是一个很好的主管，只有通过这种机制找到每个人最胜任的角色，挖掘出每个人的最大潜力，企业才能“人尽其才”。第三，为了慎重地考察一个人能否胜任更高的职位，最好采用临时性和非正式性“提拔”的方法来观察他的能力和表现，以尽量避免降职所带来的负面影响。如设立经理助理的职位，在委员会或项目小组这类组织中赋予更大的职责，特殊情况下先让他担任代理职位等等。

成功企业的用人之道包括：
- 适当引进外来人才，好处就是用现成的人才，避开“彼得原理”所涉及的后果；
- 在企业内部逐步提升，重视潜力，重要的职位大多数由所能胜任的人。

敏捷精灵日记19

2008-04-02T02:28:00.000+08:00

[敏捷精灵日记]

招聘员工准则： ‘hiring for attitude，training for skills’，即‘聘之以态度，授之以技能’
培养员工准则：品德好、能力强的是精品；品德好、能力差的是次品；品德差、能力强的是毒品；品德差、能力差的是废品。精品要破格培养，次品要加紧培训，毒品要利用，废品要丢弃。而这些都以品德好为基本前提。
团队建设的生命周期准则：
1. 选择合适的人才
2. 设立清晰的愿景、明确的目标
3. 合理用人。人尽其才，才尽其用，充分发挥每个人的优势。
4. 建立良性竞争机制
5. 建立奖惩与监督制度
6. 建立完善的培训系统，关注员工的个人发展
7. 评估并不断改进团队
领导力应该体现在他的影响力上，而不是依靠组织赋予的Position Power
用心去领导。要去了解团队每一个成员的需求与渴望，去跟他们进行心与心的沟通！按照马斯洛的需求层次理论进行针对性的激励。
根据情境去领导（Situational Leadership）。没有最好的领导力，只有最适合的领导风格，管理者要根据员工不同情境灵活调整自己的领导风格和领导型态。

Scrum 术语表

2008-03-30T21:22:00.003+08:00

Burndown Charts 显示随时时间推移,还剩下多少工作未完成.通常以时间为横轴,未完成的工作为纵轴.

Daily Scrum Meeting 每天15分钟的每日例会,每个人回答下面三个问题:
1. 上次例会到现在我完成了哪些工作
2. 在下次例会前我将完成哪些工作
3. 有没有什么事情阻止我尽可能的高效地工作
如果会议的讨论超出了上面的内容, ScrumMaster要确保任何与会者可以发起其它会议再来讨论.每日例会最好做为每天早上每一件事来做,在所有与会者到达之后立刻召开.

Impediments 阻碍任何人高效工作的任何人或事.在每日会议上,每个队员都有权宣布任何的impediments,由ScrumMaster负责解决这些impediments.

Product Backlog 产品特性列表,主要由产品Owner负责维护并定义优先级.

Product Backlog Item 产品特性列表中的条目,每个条目就是一个工作单元,大小必须限制在团队可以在一个Sprint迭代内完成,同时一个工作单元可以被分解成许多任务.

Product Backlog Item Effort 每个条目的工作量,可以用人天来衡量.推荐的方式是用Story点,功能点或T-Shirt尺寸(大,中,小).

Product Burndown Chart 基本上是项目进度的'Big Picture',显示每个sprint开始时还剩多少工作未做.

Product Owner Role 相当于业务代表,负责确定backlog中各条目的优先级及业务决策,同时解决任何的需求问题.

Release 这个概念不用解释,大家都懂.基于预定的时间,每个release会平衡功能,成本,质量三个方面的需求.

Release Burndown Chart 与Product Burndown Chart比较相像,不同点在于前者展示单个release的内容,而后者会跨多个release.

Scrum Roles 在Scrum中有一些角色的划要,其中三个主要角色:Product Owner, ScrumMaster, Team.

ScrumMaster Role 是Product Owner和Team之间的桥梁,同时推动双方的合作.主要的作用在有详细描述:
· 消除业务代表和开发团队之间的障碍,帮助业务代表直接推动开发.

· 帮助业务代表最大化ROI,并通过Scrum达到目标.

· 通过促进创造力和能力提高开发效率.

· 想尽一切办法提高生产力.

· 改善工程实践和工具,提高产品的可用性.

· 确保最新的项目进度可以让所有人看到.

Sprint 一次迭代过程,通常是30天.这个过程是不可被打断的,不能增加额外的需求,确保迭代结束时能够获得预期的结果.现实中会有一些变化,一些项目每次会留出 20%左右的时间用于紧急事务及级别最高的产品bugs.这样做存在一定的风险,可能会导致Sprint原则被随意打破.

Sprint Backlog 一次迭代的特性列表,或者说工作列表.展示本次迭代的工作单元,源自产品特性列表.

Sprint Burndown Chart 参考其它的Burndown Chart,粒度更细的图,用于单次迭代过程中.

Sprint Goals 单次迭代的目标,可以被详细说明,可以被衡量,而不是很模糊的一句"改善伸缩性".

Sprint Planning Meeting 单次迭代的计划会议,由Team与Product Owner之间商讨sprint目标集,决定哪些工作会被放进来.这个会议被限制在四个小时之内.

Sprint Retrospective Meeting 在sprint末期,评审会议之后召开.Team与ScrumMaster共同讨论这次sprint中哪些地方做得比较好,哪些地方需要在下次sprint中进一步提高.会议时间被限制在三个小时之内.

Sprint Task 四到六小时内完成的工作单元,由队员主动认领.

Team 跨功能团队,人数限制在5-9人,可能包括的角色有工程师,架构师,分析师,QA,测试,UI设计师等.这是一个自发组织的团队,以满足sprint目标.他们自己决定如何最好地满足用户目标,并承担责任.ScrumMaster充当保护层,确保Product Owner不会干涉团队工作.

Team Member 为了达到sprint目标而完成sprint task的任何人.

Velocity 一个团队在单次sprint中完成多少特性的数值.可以从上一次sprint中估算出,通过一次次的sprint,这个数值会为下次的sprint提供相对准确的进度计划.

转自http://samuelray.javaeye.com/blog/231373

[Scrum工具] Scrum Checklists中文版

2008-03-28T21:38:00.002+08:00

作者 Sprint-IT译者 SpringSide团队 发布于 2007年12月20日下午8时0分http://www.infoq.com/cn/minibooks/scrum-checklists

SPRiNT-iT的敏捷教练，包括Scrum培训师Boris Gloger，从主流Scrum书籍中抽取了Scrum的基本要素，并融入他们集体的长期实践经验，从而为大家带来《Scrum Checklists》这本精简概炼的迷你书。这本小册子为大家带来一整套准则和行为，帮助项目团队的成员更有效地推动所有的Scrum会议并创造 Scrum成果。

本书在InfoQ中文站上提供独家免费下载。

本书的英文印刷版以封面纸印刷并用螺旋管装订，让这本书更具吸引力，而且也很容易翻阅。英文版成书“概述”页中的彩色索引与书右侧的彩色标签相对应，帮助您更快地定位和翻阅书中的页面。本书每一个清单的背后都有一页空白纸，方便读者记录个人习惯和具体适应情况。如果您喜欢这本书，请支持我们的作者和InfoQ今后的迷你书，购买本书的印刷版（本书的中文印刷版也在筹备中，请耐心等候我们的通知）。

您也可以免费下载这本书（PDF）免费下载这本书（PDF）。

关于此书

本书并不打算详细介绍Scrum，而且没有哪本书有能力取代开发团队巧妙的自组织能力。相反，这本书是为了给接受过培训的团队带来信心，让他们轻车上路，成功启动最初的Sprints——这些成功将帮助他们的组织更亲密地拥抱Scrum。您可以在“概述”一页找到本书的完整主题列表。另外，本书印刷版右侧的彩色主题标签能帮您快速翻阅到相应主题：

清单：障碍Backlog（让大洋两岸的团队都活跃起来的一项创新）
清单：全员会议（帮助团队从抱佛脚或者混乱的过程中走出来的基本规矩）
清单：评估会议（产品Backlog）
清单：Sprint计划会议1
清单：Sprint计划会议2
清单：Scrum每日例会
清单：Sprint评审会议
清单：Sprint回顾会议
Scrum团队角色
Scrum典型产物

作者指出，Scrum的新手应当严格遵循《Scrum Checklists》这本书。这样做将为他们带来信心，帮助他们成功完成最初的Sprints，而这些最初的Sprints将提升Scrum在他们组织中的接受程度。有丰富经验的Scrum教练也可以使用这本小册子作为培训的辅助材料。

本书中文译本是在SpringSide开源项目团队的肖桦、陈俊、林仪明、彭青、田淼和张礼六人的倾情努力下共同完成的，InfoQ中文站编辑赖翥翔（Jason Lai）、霍泰稳和熊节对本书译稿进行了审校，赖翥翔为本书的责任编辑，并负责排版工作。

阅读英文原书：Scrum Checklists

敏捷精灵日记18

2008-03-22T20:24:00.000+08:00

[敏捷精灵日记]

Daily Scrum主要还是为了加强团队交流和信息共享。互相了解彼此都在做什么工作，完成了什么任务。这样，每日的信息传递，可以让每个人可以更多的了解整个项目的业务和技术状况。并且如果在工作中遇到障碍或问题，也可以在这时候提出来，请求大家的帮助。
Daily Scrum晨会不是每天的工作报告，更不是项目经理进行工作检查，甚至考核。项目经理有责任营造一个安全（Safe）的会议氛围，让每个人都乐意说出真正发生的事情，就算是昨天遇到技术问题，没有任何的工作成果，也能得到谅解，而不是胆颤心惊。
敏捷方法，需要有一个英明的领导（也许就是Scrum Master），以身作则，带领着团队向前冲锋，大家齐心协力，以项目的成功作为最高奋斗目标。只有这样，才能发挥敏捷方法的威力，只有这样项目才可能获得成功。
明确的短期目标。如果让一个团队做半年的详细工作计划，一定非常困难，但如果是2周，那就完全不一样。假设，客户有100个东西要做，但团队在一个迭代（一般是2周左右）中，只能完成20个东西。那么就明确的告诉客户，一个迭代的时间，我们只可以完成20个东西，那么我们先开发其中20个最有价值的东西。不要为100个东西做半年/一年的计划,因为那不是敏捷开发，还是瀑布模式开发。

后记

羊群是一种很散乱的组织，平时在一起也是盲目地左冲右撞，但一旦有一只头羊动起来，其他的羊也会不假思索地一哄而上，全然不顾前面可能有狼或者不远处有更好的草。这就是“羊群效应”，也称“从众心理”。在一个组织中，特别对具有决策能力的管理者而言，“共同承担责备效应”(Blame 　Sharing　Effect)的存在是导致了“羊群效应”的根本原因。如果某决策者逆流而动，一旦他失败了，这一行为通常被视为是其能力不够的表现，并因此而受到责备；但是如果他的行为与大多数人一致，即使失败了，他会因看到其他许多人与他有相同的命运而不那么难堪，而他的上级也会考虑到其他的人也同样失败了而不过分责备他。这样，决策者具有与别人趋同的愿望，以推卸自己承担决策错误的责任。
作为组织的高层管理者，一定要对底层管理决策人员的这种“羊群效应”保持足够的警惕，减少这种非理性的行为的发生。

敏捷精灵日记17

2008-03-09T01:23:00.000+08:00

[敏捷精灵日记]

1。同步进行的sprint有如下优点：

· 可以利用sprint之间的时间来重新组织团队！如果各个sprint重叠的话，要想重新组织团队，就必须打断至少一个团队的sprint进程。

· 所有团队都可以在一个sprint中向同一个目标努力，他们可以有更好的协作。

· 更小的管理压力，即更少的sprint计划会议、sprint演示和发布。

2。最佳的团队尺寸

· 5到9个人被公认为是“最佳的”团队构成人数。

3。在Scrum中，团队分割确实很困难。不要想的太多，也别费太大劲儿做优化。先做实验，观察虚拟团队，然后确保在回顾会议上有足够的时间来讨论这种问题。迟早就会发现针对你所在环境的解决方案。需要重视的是，必须要让团队对所处环境感到舒适，而且不会常常彼此干扰。

4。宁可团队数量少，人数多，也比弄上一大堆总在互相干扰的小团队强。要想拆分小团队，必须确保他们彼此之间不会产生互相干扰！

5。在Scrum团队中含有兼职成员一般都不是什么好主意。如果有一个人需要把他的时间分配给多个团队，就像DBA一样，那最好让他有一个主要从属的团队。找出最需要他的团队，把它当作他的“主队”。如果没有其他人把他拖走，那他就得参加这个团队的每日scrum会议、sprint计划会议、回顾等等。

Scrum介绍系列9--- 产品发布计划(release plan)

2008-02-28T17:31:00.000+08:00

Sprint 持续直至产品所有者决定产品已经可以准备发布，此时会有“发布Sprint“来进行最后的整合和发布产品前的检测。如果开发团队一直贯彻很好的开发方法，不断地重构和持续集成，在每一Sprint 中的有效测试，就不会存在许多遗留问题需要清除。

有这样一个问题有时会被提到，是怎样在一个迭代的模式中产生长期的发布计划。在一个项目的起始阶段，开发团队会作出粗线条的发布计划；他们不可能预先得知工作的结果，其重点是创建一个大体的计划提供给项目发展一个大体的方向，并阐明交易决策如何形成（比如范围相对于进度表）。以此作为路标来指引你向目标迈进；在行程中你实际挑选的路程和所做的决策都是途中决定的。

有一些产品发布是以日期界定的；比如：“我们会在11 月10 日的产品展示会上发布我们项目的2.0 版。“在此种情况下，开发团队会在现有的可利用时间内完成尽可能多的Sprint（构建尽可能多的功能）。有些产品要求某部分构建完成才可以说明整个产品的完成，产品不会在这些要求满足前被发布，无论周期长短。Scrum 强调在每一Sprint 中都生产出可以随时交付的编码，开发团队可以进行中间的发布，使客户可以更快的收到产品的效益。

大多数产品所有者会选择一个发布方式，但是会通知其他的——比如，他们会决定发布日期，他们会与开发团队成员一起对Backlog 中项目的完成日期做一大体的估算。在“固定价格/固定日期/固定交货期”的情况下——比如，合同制开发——在这些变量中至少有一个内部存在缓冲区，可以容许不确定因素和变更；在此方面，Scrum 于其他的开发方法并无区别。

Scrum介绍系列8--- 如何开始下一个Sprint

2008-02-22T17:00:00.000+08:00

在Sprint 评审会议之后，产品所有者将提取所有建议，和在Sprint 中产生的新的优先权项目，并将这些项目合并于Product Backlog 之中；增加新的项目，现有项目进行了更改，重新排序或删除。当Product Backlog 的更新完毕，循环周期可以再次开始，以下一个Sprint 计划会议为开端。

许多开发团队感觉在每个Sprint 末期进行优先化的会议很有意义，和产品所有者一起对下一Sprint 中的Product Backlog 项目进行评审。除了给开发团队的一个机会提醒产品所有者其未注意的事项——技术维护，比如——此会议也开始了在Sprint 计划会议之前所需的初步想法。

在各Sprint 之间没有间隔期——开发团队通常在下午时间进行了Sprint 评审，第二天上午就进行下一Sprint 计划会议。Agile 开发的价值观之一是“可持续性“，只有在正常的工作时间和劳动强度下，开发团队才可以继续此周期的持续。

敏捷精灵日记16

2008-02-19T23:21:00.000+08:00

[敏捷精灵日记]

1。产品层次的Scrum-of-Scrums

议程安排：由每个团队的Scrum Master描述一下上次开会以来各自的团队都完成了什么事情，下次开会前计划完成什么事情，遇到了什么障碍。除了这些常规话题外，尤其应该交流跟跨团队协作相关的的问题，例如集成问题，团队平衡问题。

2。团体层次的Scrum-of-Scrums

会议形式为：
1) 开发主管介绍最新情况。例如即将发生的事件信息。
2) 大循环。每个产品组都有一个人汇报他们上周完成的工作，这周计划完成的工作，及碰到的问题。其他人也会作报告（配置管理领导，QA领导等）
3) 其他人都可以自由补充任何信息，或者提问问题。

会议组织：

建议全体开发人员都来参加，让每个人了解其他团队在做些什么。主要以报告形式进行，由每个组的Scrum Master负责自己团队的报告。会议主持人要严格控制会议的时间，尽量避免出现真正的讨论。

3。 Scrum-of-Scrums的议程无关紧要，关键在于要有定期召开的Scrum-of-Scrums会议，进行沟通交流。

Scrum介绍系列7--- Sprint 回顾(sprint retrsopective)

2008-02-11T02:39:00.000+08:00

同学门，请注意！这个阶段也是Scrum的核心之一，只有回顾，才能真正做到六个西格玛里面的PDCA！

在Sprint 评审之后,开发团队会进行Sprint 回顾。有些开发团队会跳过此过程, 这是不合适的,因为它是使Scrum 成功的重要方法之一。这是提供给开发团队的非常好的机会，来讨论什么方法能起作用而什么不起作用，并一致通过改进的方法。Scrum 开发团队，产品所有者和ScrumMaster 都将参加会议，会议由外部中立者主持；一个很好的方法是由ScrumMaster 互相主持对方的回顾会议，可以起到各团队间信息传播的作用。

组织Sprint 回顾的最简单方法是在墙上挂两张张贴画大小的白板纸，纸上注明“哪些项工作顺利”，“哪些项不成功或者哪些项可以做的更好”——让与会者在每一类别下增加些项目。当项目重复时，可以在该项旁边记正字累计，这样一些比较普遍出现的项目就一目了然了。然后团队成员共同讨论找寻这些项目出现的根本原因，同意在下一个Sprint 中的改进计划，并负责在下一个Sprint 回顾会议上评审项目结果。

另一种方法是让团队成员在每一类下的项目中，用“C”标记如果其根源是Scrum，或用“V”标记如果其是由Scrum 显现出来的（换句话说，无论Scrum 存在与否该项目都会发生，但是Scrum 使开发团队注意到了该项目的产生）。开发团队会在“哪些项目工作顺利”下发现许多的C 标记，在“哪些项目不成功”下有许多的V 标记；这是个非常好的现象，即使“哪些项目不成功“是比较长的列表，因为解决问题根本原因的第一步就是让其显现出来，Scrum 正是此作用的强有力的促进因素。

Scrum介绍系列6--- Sprint 评审(sprint review)

2008-02-08T16:37:00.000+08:00

在Sprint 结束后，将进行Sprint 评审，团队在此期间展示他们所构造的产品。出席此会议的有产品所有者，开发团队成员，ScrumMaster，加上客户，项目管理者，专家，高层人士和任何对此感兴趣的人。这不是开发团队做成果“演讲”——会议上不会有PowerPoints 图片文件，通常会议不会需要超过30 分钟的准备时间——这只是简单的展示工作结果，所有与会人员可以提出问题和建议。会议可以持续10 分钟，也可以是两个小时——会议目的只是对工作结果的展示和听取反馈

Scrum介绍系列5--- 每日站立例会（Daily standup meeting）

2008-02-03T01:28:00.000+08:00

每当Sprint 开始, Scrum 开发团队将会实施另一个Scrum 的重要实践方法:每日（站立）例会。这是在每个工作日特定的时间举行的短小（15 分钟）的会议，Scrum 开发团队的每一成员都将参与；为了保证其短小精悍，与会成员都保持站立（因此为“站立会议”）。以此提供给开发团队机会来汇报交流成果和阐述任何存在的障碍。

一个接一个，每个团队成员只可以向其他人汇报三件事情：

从上次会议之后完成了哪些工作，
在下次会议之前准备完成哪些工作，
在工作进行中存在哪些障碍。

ScrumMaster 将会把障碍内容记录下来，在会后协助团队成员铲除障碍。在每日的（站立）例会中不容许讨论，只是将以上三个重点信息做一汇报；如果需要讨论，将在会后进行。产品所有者，经理和项目管理者可以参加会议，但是他们应该在会议结束以前避免问问题或提出讨论——每一与会者应该清楚的是开发团队是在互相汇报和交流情况，并不是向产品所有者，经理或ScrumMaster 汇报。这个会议并没有标准形式，有些团队感觉邀请产品所有者参加并将其每日工作做一简要阐述，是对团队工作极其有意义的。

在会议结束后，开发团队成员将对其负责的Sprint Backlog 中的项目做剩余时间的更新。这些信息会记录在Sprint Burndown Chart 图表中（图示5）。它是用来显示每日直至开发团队完成全部任务的剩余工作量（以小时或天计算）。理想的情况下，抛物线轨道在Sprint 的最后一天应该接触零点。有些时候会是这样，但是大多数情况不是这样。重要的是它体现了团队在相对于他们的目标的实际进展情况——并不是目前花费了的时间的多少（对于Scrum 来说这是不太相关的事项），而是仍剩余多少工作量——开发团队仍距离完成任务多远。如果此曲线的轨道在Sprint 末期不是趋于结束，那么开发团队应该加快速度，或简化和削减其工作内容。此图表也可以使用Excel 表格管理，许多团队认为在他们工作室的墙上用图纸标明更为简单和有效，并可以用笔随时更新；这个技术含量不高的做法比电子表格更快速，简易和更可见。
Scrum 的核心原则之一是Sprint 的周期不可以延长——其结束于指定的时间不论开发团队完成任务与否。如果开发团队未完成其Sprint 目标，他们将在Sprint 的末期声明他们没有完成预期的任务。这个方法创造了反馈循环的可视性，并强制开发团队在Sprint 预期估算时做出更好的判断，并确保可以按时完成任务不会失败。开发团队通常在前几个Sprint 时试图完成许多任务，但实际上并不可以达到Sprint 目标；然后他们可能会过度小心而挑选较少的任务，结果会提前完成；在第三或第四个Sprint 时，开发团队通常会了解自己的工作效率，他们会按时完成Sprint 的目标。鼓励开发团队在某一Sprint 中挑选一个周期（比如两周）并且不经常变化——固定的周期可以帮助开发团队了解他们的实际工作效率，并且可以帮助其达到工作的节奏性（此指团队的统一“心跳”）。

Scrum介绍系列4--- Sprint 计划会议

2008-01-23T13:33:00.000+08:00

Sprint 计划会议是保证整个Scrum顺利进行的重要一环之一！如何开好，非常关键！

Sprint 计划会议在每一Sprint 的启始阶段进行。在Sprint 计划会议的第一部分，产品所有者和Scrum 开发团队（在ScrumMaster 的协助下）共同评审Product Backlog，讨论Backlog 中各项目的目标和背景，并提供Scrum 开发团队深入了解产品所有者想法的机会。在会议的第二部分，Scrum 开发团队从Product Backlog 中挑选项目并承诺在Sprint 的末期完成任务，从ProductBacklog 的顶端开始（换而言之，从对产品所有者具有最高优先权的项目开始）并按列表顺序依次工作。这是Scrum 的重要实践之一：开发团队决定承诺完成工作量的多少，而不是由产品所有者安排工作量。这就使任务的交付更可靠；第一，因为开发团队承诺工作量，而不是其他人代替其“承诺”工作量；第二，开发团队自己决定所需要的工作量，而不是其他人决定工作量“应该”是多少。产品的所有者对于开发团队承诺任务多少没有控制权，他或她只知道开发团队负责的项目是由Product Backlog 中按顺序从上至下进行的——换而言之，是从他或她选择的最重要的项目开始。开发团队可以从列表底层选择项目提前完成，如果其对于整个开发具有意义（比如，提升和快速完成较低优先权的项目，作为完成较高优先权项目的一部分）。

Sprint 计划会议通常会持续几个小时——开发团队对于承诺完成的任务作出认真地抉择，这些责任要求通过仔细地考虑以达到成功的目标。团队将从估算每一成员拥有的完成Sprint 相关工作的时间开始——换句话说，是团队成员平均的工作时间减去他们花费在检修bug 和其他必要的维护工作，参加各种会议，回复电子邮件，午休等的时间。大多数人会有4 到6 个小时每个工作日可以完成Sprint 相关的工作。（图示3）

当可利用时间确定下来，开发团队会从Product Backlog 的顶端第一项开始工作——换句话说，从产品所有者的最高优先权项开始——团队共同工作，将其分配为小块任务，并记录在SprintBacklog 中（图示4）。当任务确定后，团队成员可以自愿承担任务，在考虑任务间依赖关系和次序的情况下，给每一项任务估算时间，并保证每一个人的工作量合理。在此流程中将会和产品所有者有往复交流，阐明要点，核实交易，将较大型Backlog 分割成小块，并保证开发团队真正全面了解开发的需求。开发团队将按Product Backlog 序列继续计划，直至消耗所有可利用时间。在会议的末期，开发团队将提供所有任务的列表，并写明每一项工作由谁完成和他们的估算时间（一般以小时计算或每天的一小部分）。许多开发团队也使用可视任务跟踪工具，利用墙体面积大小的任务板，任务（写在便签上）在Sprint 中跨越栏目，“未开始”，“在进行”，“需校验”，和“已完成”。

Scrum 的重要支柱之一是当Scrum 开发团队确认承诺任务后，产品所有者在此Sprint 期间不可以添加新的需求。这就意味着即使在Sprint 中途，产品所有者想要添加新要求，他或她在下一新的Sprint 开始前不可能作出任何变更的决定。如果一个外部情况出现致使项目优先级的变化，意味着如果开发团队按原计划工作将会是浪费时间，产品所有者此时可以结束该Sprint；意味着开发团队停止一切工作，重新开始Sprint 计划会议等等。此种决断会产生很大的影响,除非在非常特别情况下，不会采用这种方式。

保证开发团队在Sprint 中目标不被变换有着正面影响。首先，开发团队确信在工作开始时的承诺是不会变化，这样会集中开发团队的注意力。第二，这样也可以培养产品所有者在安排Product Backlog 中项目的优先权时，适时作出正确的抉择。他们知道任务的承诺是在整个Sprint 中不可变更的，使其在决定从哪一项目开始工作更为细心。

作为回报，产品所有者也可以得到两个好处。首先，他或她有充分的信心，开发团队对所承诺任务强烈负责，并随着时间推移，Scrum 开发团队将会做的很好。第二，产品所有者可以在下一Sprint 开始前，提出他或她希望的变动。在这一点上，增加条件，删减条件，更改条件和重新排列优先权都可以被接受。但产品所有者不可以在Sprint 进行中提出任何变更，他或她只是需要等待一个Sprint 的完成时间或更短。不再僵持于是否变化——方向的变更，条件的变更，或只是简单的想法的变更——可能正式此原因，使得产品所有者成为Scrum 拥护者中最热衷的成员。

敏捷精灵日记15

2008-01-22T22:19:00.000+08:00

[敏捷精灵日记]

为Sprint中任务给出明确的”DONE” 定义是非常重要的，但即使你遵循这个最佳实践，但最终仍然会有集成问题，会存在Bug, 以及晚期的需求变更。所以，在正式发布前，单独计划1-2个Sprint, 专门做Bug修复，是非常合理的，并不是“反Scrum”的模式。

Scrum介绍系列3--- 如何启动Scrum

2008-01-17T10:05:00.000+08:00

Scrum 的第一步是产品所有者清晰地展示产品的未来景象（vision）。这些是以按需求的优先列表展示的，按客户和商业价值排序，最高价值的项目排在列表顶端。这就是Product Backlog,它存在（并发展）于产品的整个生命周期（图示2）。Product Backlog 包括许多的不同项目，例如功能（“使用户可以把所选书籍放入购物车”），开发需求（“重新改进处理流程模块，使其可以升级”），探索式的工作（“研究关于加速信用卡确认过程的方法”），和已知的bugs（“判断并修复定单流程中的错误”）。

Product Backlog 是由产品所有者随时更新，以反映客户需求的变化，竞争对手的发布，新的想法和见识，出现的技术障碍等等。

在项目开发的任何时候，Product Backlog 是唯一具有权威性的“需要完成的所有任务”的概况。只可以存在唯一一个Product Backlog；这就意味着产品所有者需要在所有的工作范围中作出优先项的决策。

Product Backlog 中的项目在规模上会相差甚远；有些大的项目通常在Sprint 计划会议上被划分为许多较小的项目，而小的项目有些会被合并为一。关于Scrum 的误解之一是它会阻止你记录详细的规范说明；而现实中，这是由产品所有者和开发团队共同决定详细资料的多少，这些从其中一个Product Backlog 到另一个有可能存在不同。一般的建议是，在所需的最少的空间中说明最重要的事情——换而言之，不需要描述某一项目的所有可能的详细资料，只需要阐述清楚产品被认为是完成品所具备的要求。在Product Backlog 列表中越底端的是更大和粗略的项目；当它们接近被开发时，产品所有者会添加更多的详细资料。

Scrum介绍系列2--- Scrum 中的角色

2008-01-09T09:58:00.000+08:00

在Scrum 中有三个基本的角色：产品所有者，开发团队成员和ScrumMaster。

产品所有者（Product Owner）负责收集相关于产品的所有信息——从客户或产品的终端使用者，开发团队成员和项目管理者中获取——并将信息转化为产品的形式。在一些情况下，产品所有者正是客户本人；在另一些情况下，客户可能是有不同需求的成百上千的人。产品所有者这一角色在许多企业中是由产品经理或产品市场经理担任。

开发团队成员构建客户将会购买的产品：软件，网站，或者是任何一种产品。Scrum 团队通常包括五到十个成员，尽管团队大到15 个成员和小到3 个成员也有很好的收效。团队应该包括所有交付工作所需的专门人员——例如，一个软件项目的开发团队包括程序员，界面设计师，检测员，市场人员和研究人员。开发团队不仅构建产品，他们也向产品所有者提供让产品尽善尽美的建议和想法。开发项目包括15 个或以上的人员时，通常会被划分为若干的Scrum 团队，每一团队注重于产品开发的不同方面，并相互紧密的协作。团队成员同时可以参与其他项目开发，这样比只限制开发团队致力于Scrum 更能提高生产效率。团队内部成员也可以在不同Sprint 中变化，但是这样会减少整个团队的生产效率。

ScrumMaster 的任务是以任何方式帮助整个团队取得成功。ScrumMaster 不是团队中的经理；他或她是服务于整个团队，帮助团队铲除壁垒而取得成功。协助团队会议，并支持Scrum 的实践。在一些团队中会有某一人专心致力于担任ScrumMaster，而另一些团队可以是其中一个成员兼职担任（此人会适当减少日常工作量）。一个好的ScrumMaster 可以有不同的背景和学科：项目管理，工程技术，设计，检测。ScrumMaster 和产品所有者不应是同一人；有时，ScrumMaster 可能会号召拒绝产品所有者（例如，他们有时会在某一Sprint 中期试图加入新的条件）的要求。不同于项目经理，ScrumMaster 不会指示和分配工作——他们只是协助流程的实施，推动团队自我组织和管理。

除以上三个角色之外，还有其他对于项目成功作出重要贡献的人员：可能其中最重要的是经理。他们的角色在Scrum 中的发展, 他们仍保持了相当重要的位置——他们支持开发团队使用Scrum，他们为整个项目的开发提供知识，技术和各种必要的协助。在Scrum 中，这些人转化了以前“保姆”式的角色（布置任务，收取进程报告，和其他一些谨小慎微的管理方式），取而代之的是承担起更多的“指导“作用（指导职业发展，在职辅导培训，扮演魔鬼的代言人，协助铲除障碍，帮助解决问题，提供创新的建议和指导团队成员的技能发展）。为了能更好地实现这一变化，经理们需要改进他们的管理方式方法；比如，运用苏格拉底哲学提问方式来帮助开发团队找寻问题的解决办法，而不是简单地决定解决方法并分配给开发团队。

敏捷精灵日记14

2008-01-08T22:35:00.000+08:00

[敏捷精灵日记]

无论一个测试人员有没有发现Bug，都不能说明他有没有好好工作。测试人员的职责更多的应该是‘保证质量’（quality assurance），而不是“控制质量”（quality control）。一个好的测试人员应该是在问题出现之前，防止其成为Bug。
对于一个敏捷团队而言，再单纯以测试人员发现的Bug数量，作为衡量其绩效的唯一标准，是非常没有意义的。
如果有一个核心测试集，能够覆盖用户如何使用一个产品的常用情形，会更有价值。对所有用户使用情形都做自动化测试是没有必要的。

Scrum介绍系列1--- 基础知识

2008-01-07T09:52:00.000+08:00

Scrum 是迭代的，增量型的流程。
Scrum 构造的产品迭代周期为Sprints, 工作的迭代时间一般为一到四周。Sprints 是有固定的周期——结束于固定明确的日期，无论该工作完成与否，从不延长。
在每一Sprint 的启始阶段，一个多职能的团队从已优先化的要求列表中挑选若干项目，并承诺在Sprint 的末期完成这些项目。
每一工作日，团队成员互相通告工作进度，并更新简易的剩余工作量直观表示图表。在Sprint 的末期，团队将对这一阶段工作结果作一展示并取得相关的反馈，为下一Sprint 做好准备。

Scrum 强调生产可以使用的产品，意指在Sprint 的末期产品的“完成”；在软件方面，是指编码已经被检测并可以随时交付使用。

Scrum方法Agile (敏捷) 开发和 vs 传统的软件开发

2008-01-02T09:33:00.001+08:00

传统的软件开发

各类大中小型企业所运用的传统软件构建方法，即是众人在很多变体，但其典型性是在开发初期制定详细的计划，计，并且一切详细资料都记录在案。任务已设计制定，并工具和Microsoft Project 项目管理软件。开发团队预计开发而得出的。当项目管理者(stakeholder)全面审核开发计划并团队成员完成他们所专长的部分工作，即刻转交给其他成工作都已完成，成品将会转交给产品质量控制部门，在这的全面检测。在整个流程中，所有相对于原始计划的分歧成品与原始设计保持一致。

此种模式有优点但也有不足之处。它的最大的优点是非常记录下来，按照计划实施，保持各项事务尽可能的有组织参与,人对于此种工作方式并不适合。

比如：此种方式要求所有的建议和想法都要在开发周期的可以被容入开发计划之中。但是众所周知，好的想法和建开发最启始阶段，在开发中期，有时可以在产品交付使用许变化的产生，那么将会遏制创新的产生。在使用“瀑布新将不是好的征兆，而是对整个产品开发产生的危机。

瀑布型开发方式特别注重将事件记录在案，以此作为传递重要信息的首要方法。因此最合理的假定是如果我可以把我的想法尽可能都记录下来，这样将会使信息更可靠的传输到团队每一个
成员的头脑中；另外，因为所有东西都记录在案，这将是我完成任务的最实际的证据。但是实
际上，在大多数情况下，没人会读这些100 页左右的详细规格要求资料。同样，如果有人读取
该资料，那么将会产生许多的误解。记录的资料只是我头脑中想法的抽象提取；当你阅读此资
料时，你将会产生另一个抽象的概念，此时与我的真正想法已经相距甚远了。所以严重误解的
产生也就不足为奇了。

当人参与时,还有一种情况会发生——“实际应用中产生的灵感”——在第一次实际应用产品
时，你可能会立刻产生20 种方法以使产品更加完美的灵感。但是遗憾的是，这些非常有价值的
想法通常会在产品开发的末期产生，这时创新是最困难和最具有分裂性的——换句话说，是做
正确抉择最昂贵的时刻。

人的预知未来的能力是有限的。比如，某场比赛的最终结果是出人意料的。不可预测的技术问题的突然出现，会强制开发方向的转变。此外，人们往往非常欠缺对于未来作出长远计划的能
力——今天猜测未来八个月中每周你如何工作将如幻觉般渺茫，这正是Gantt (根特)图表的衰败
表现。

另外，瀑布型方式将会促使团队成员在交接工作时产生敌对的关系。“他要求我构建在规范要
求中不存在的东西。”“她经常改变主意。”“我不可能对我不能控制的东西负任何的责任。”这些指引我们对瀑布方式的另一思考——在此种方式中工作毫无兴趣可言。事实上，进一步说，瀑布型方式是造成产品开发人员苦恼的根源，并且最终产品将不会体现出他们的创造力，技能和开发创造者的激情。人不是机器人，此种将人认为是机器人的流程将会造成人们工作激情的丧失。

一个僵硬的，拒绝变革的流程也会造成低劣产品的产生。客户可能会得到根据他们第一需求所生产的产品，但是在产品在形成阶段时还是客户真正需要的吗？在开发之前收集所有的需求并
将它们嵌入毫无改变可言的顽石般的计划中，此产品将被宣告只会和最起始的想法保持一致，
而不是开发团队在实践中不断发现可能性而使其尽善尽美。

许多使用瀑布型方式的团队不断的体验到了它的缺陷，但是它看起来是一个极其付有逻辑性的方式，所以第一的自然反应就是对内部工作的谴责：“如果我们尝试更好的使用它，它将会发
挥作用”——如果我们计划的更详尽，记录更详细，更严格的拒绝任何变革，一切将会很顺利
地进行。遗憾的是，许多开发团队只得到的相反的效果：他们越竭尽全力尝试此方法，得到的
结果越差！

Agile (敏捷) 开发和Scrum

Agile (敏捷)开发整体概念的产生是基于一种方法更接近人类活动现实情况, 以便取得更好效果的信念上。Agile 强调构建可以即时操作的软件，相对于在构建前花费许多时间记录规格要求。
Agile 注重授于小型多职能的团队决策权，相对于大型层次和部门职能的划分，Agile 注重快速
迭代，并且其中结合尽可能多的客户反馈。在学习了解Agile 的时候，经常会有这样的公认——感觉非常像回到了开发启始的阶段，我们曾经”做过”。

Scrum 是众多快速发展的Agile 方式之一。Scrum 是在十多年前由Ken Schwaber 和Jeff
Sutherland 博士共同提出的，现在此方式已被众多大中小型企业使用，其中包括Yahoo! ,
Microsoft, Google, Lockheed Martin, Motorola, SAP, Cisco, GE Medical, CapitalOne 和 US Federal Reserve. 许多使用Scrum 的团队取得了重大的改进，其中更有个别在生产效率和职业道德方面得到了彻底地改革。对于产品开发者——许多曾受到“管理层每月的一时狂热”的伤害——这
是非常重要的。Scrum 是简单的，强有力的，并立足于常识之中的。

敏捷精灵日记13

2007-12-26T03:14:00.001+08:00

[敏捷精灵日记]

正确衡量生产力的公式：生产力=已经完成的工作量 – 用于修正Bug的工作量 – 用于修正错误设计的工作量
任何想在短期内迅速提高生产力的想法都是杀鸡取卵的自杀式行为。
任何时候，工作超过40小时，都需要恢复期，无论你怎么调整；一周35-40小时可以这样安排：每天工作10小时，持续四天，然后休息三天。上述“压缩工作周”，不仅可以减少缺勤，在某些情况下，可以提高生产力10-70%
每周四天工作制会比五天工作制效率更高。
短期不超过3个礼拜的冲刺会临时提高生产力，团队可以有策略的选择加班，可以完成最近的最后期限；加班后，生产力会有同等程度的降低，应该根据这个因素马上调整计划
按照项目划分成跨功能的小团队；对于大的项目，利用’Scrum-Of-Scrums’把小团队联系在一起；制定关于创建团队、划分大团队、团队间人员流动的流程/规则
混合团队会比单一团队效率更高
好的管理人员会想办法鼓励团队去创新，会选择预留一定时间让团队去思考如何创新，而不会压榨员工的每一分钟。

敏捷精灵日记12

2007-12-19T01:23:00.000+08:00

[敏捷精灵日记]

拥抱变化（Embrace the change）

无论是多么明智，多么正确的决定，也有可能在日后发生改变。因此，团队要能够充分理解我们的利益干系人（Stakeholder）和客户代表为什么经常提出新的需求和设计要求，一句话，就是心中有数“唯一不变的是变化”。团队更要信任利益干系人（Stakeholder）做出的每次决定和需求的调整都是将产品开发推向更正确的发展方向，新变化将进一步降低风险，实现团队最大化利益，理解这是适应市场变化的必然行为。而在接受变化的同时，我们应该积极的向利益干系人（Stakeholder）和客户代表反映实现活动中暴露出来的可能的设计缺陷和错误。在实际工作中，团队成员应该用优先级制度来划分事情和目标先后顺序，在迭代周期内对于还没有最终决定的设计方案可以予以后来实现、测试，不用急于投入资源展开全面的开发、测试活动。这样一来，开发测试团队也会人员也将更加适应，真正拥抱变化。

对一个项目开发来说，release (发布）拥抱变化。对于一个sprint/iteration，要拒绝变化。sprint计划前，product backlog都可以变化。
ScrumMaster需要对团队作出承诺，让团队感受到有人全心全意关注其工作，在任何情况下提供保护和援助。
ScrumMaster使团队在Sprint过程中免受干预
教授产品负责人如何实现投资回报最大化，以及如何利用Scrum达成目标
在影响Scrum正常实施的众多因素中，在sprint过程中加入新需求，大部分人都很难很难抵御这样的诱惑，是scrum的第一杀手。
在一个Sprint执行过程中，如果遇到一些问题导致Sprint的原始目标不能实现，此时需要及时地调整目标。如果不愿意调整目标，任意延长sprint的时间，就严格违反了Sprint的Time-Box特性，以后大家再遇到问题时，会自然而然的想再延长Sprint，那么Sprint快跑的意义也就不存在了。
从另外一个角度讲，如果急于看到结果而压缩sprint的时间，可能得到一定的效果，但总体上会消耗的更多的资源，让团队疲惫不堪，造成生产力低下。

敏捷精灵日记11

2007-12-15T01:09:00.001+08:00

[敏捷精灵日记]

精益软件开发的七大原则：

消除浪费(eleminate waste)
强化学习，鼓励改进(Focus on learning)
“注重质量”build quality in
“推迟承诺”defer commitment.
“尽快交付”deliver fast
“尊重员工” respect people
优化整体 optimize the whole

准时化开发 = 持续集成 + 迭代开发 + 多次交付。
零库存 = TDD + 每次迭代都给出可以发布的版本。

什么是敏捷软件开发？

2007-12-12T21:29:00.001+08:00

敏捷软件开发不是一个具体的过程，而是一个涵盖性术语（umbrella term），用于概括具有类似基础的方式和方法。这些方法，其中包括极限编程（Extreme Programming）、动态系统开发方法（Dynamic System Development Method）、SCRUM、Crystal和Lean等，都着眼于快速交付高质量的工作软件，并做到客户满意。

敏捷软件开发又称敏捷开发，是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于"非敏捷"，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重做为软件开发中人的作用。

词源

敏捷一词来源于2001年初美国犹他州雪鸟滑雪胜地的一次敏捷方法发起者和实践者（他们发起组成了敏捷联盟）的聚会。

价值观

雪鸟会议共同起草了敏捷软件开发宣言。其中最重要的部分就是对一些与会者一致同意的软件开发价值观的表述：

人和交互重于过程和工具。

可以工作的软件重于求全责备的文档。

客户协作重于合同谈判。

随时应对变化重于循规蹈矩。

其中位于右边的内容虽然也有其价值，但是左边的内容最为重要。

原则

宣言中还包括以下原则：

对我们而言，最重要的是通过尽早和不断交付有价值的软件满足客户需要。

我们欢迎需求的变化，即使在开发后期。敏捷过程能够驾驭变化，保持客户的竞争优势。

经常交付可以工作的软件，从几星期到几个月，时间尺度越短越好。

业务人员和开发者应该在整个项目过程中始终朝夕在一起工作。

围绕斗志高昂的人进行软件开发，给开发者提供适宜的环境，满足他们的需要，并相信他们能够完成任务。

在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈。

可以工作的软件是进度的主要度量标准。

敏捷过程提倡可持续开发。出资人、开发人员和用户应该总是维持不变的节奏。

对卓越技术与良好设计的不断追求将有助于提高敏捷性。

简单--尽可能减少工作量的艺术至关重要。

最好的架构、需求和设计都源自自我组织的团队。

每隔一定时间，团队都要总结如何更有效率，然后相应地调整自己的行为。

对比其他的方法

敏捷方法有时候被误认为是无计划性和纪律性的方法，实际上更确切的说法是敏捷方法强调适应性而非预见性。

适应性的方法
集中在快速适应现实的变化。当项目的需求起了变化，团队应该迅速适应。这个团队可能很难确切描述未来将会如何变化.

对比迭代方法

相比迭代式开发两者都强调在较短的开发周期提交软件，敏捷方法的周期可能更短，并且更加强调队伍中的高度协作。

对比瀑布式开发

两者没有很多的共同点，瀑布模型式是最典型的预见性的方法，严格遵循预先计划的需求、分析、设计、编码、测试的步骤顺序进行。步骤成果作为衡量进度的方法，例如需求规格，设计文档，测试计划和代码审阅等等。

瀑布式的主要的问题是它的严格分级导致的自由度降低，项目早期即作出承诺导致对后期需求的变化难以调整，代价高昂。瀑布式方法在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的。

相对来讲，敏捷方法则在几周或者几个月的时间内完成相对较小的功能，强调的是能将尽早将尽量小的可用的功能交付使用，并在整个项目周期中持续改善和增强。

有人可能在这样小规模的范围内的每次迭代中使用瀑布式方法，另外的人可能将选择各种工作并行进行，例如极限编程。

敏捷方法的适用性

在敏捷方法其独特之处以外，他和其他的方法也有很多共同之处，比如迭代开发，关注互动沟通，减少中介过程的无谓资源消耗。通常可以在以下方面衡量敏捷方法的适用性：从产品角度看，敏捷方法适用于需求萌动并且快速改变的情况，如系统有比较高的关键性、可靠性、安全性方面的要求，则可能不完全适合；从组织结构的角度看，组织结构的文化、人员、沟通泽决定了敏捷方法是否适用。跟这些相关联的关键成功因素有：

组织文化必须支持谈判

人员彼此信任

人少但是精干

开发人员所作决定得到认可

环境设施满足成员间快速沟通之需要

最重要的因素恐怕是项目的规模。规模增长，面对面的沟通就愈加困难，因此敏捷方法适更用于较小的队伍，20、40人或者更少。大规模的敏捷软件开发尚处于积极研究的领域。

另外的问题是项目初期的大量假定或者快速收集需求可能导致项目走入误区，特别是客户对其自身需要毫无概念的情况下。与之类似，人之天性很容易造成某个人成为主导并将项目目标和设计引入错误方向的境况。开发者经常能把不恰当的方案授予客户，并且直到最后发现问题前都能获得客户认同。虽然理论上快速交互的过程可以限制这些错误的发生，但前提是有效的负反馈，否则错误会迅速膨胀。

方法列表

目前列入敏捷方法的有：

软件开发节奏，Software Development Rhythms

敏捷数据库技术

AD/Agile Database Techniques

敏捷建模，AM/Agile Modeling

自适应软件开发，ASD/Adaptive Software Development

水晶方法，Crystal

特性驱动开发，FDD/Feature Driven Development

动态系统开发方法，DSDM/Dynamic Systems Development Method

精益软件开发，Lean Software Development

Scrum

测试驱动开发，TDD/Test-Driven Development

XBreed

极限编程，en:XP/en:Extreme Programming

敏捷精灵日记10

2007-09-28T12:07:00.001+08:00

[敏捷精灵日记]

对Prodcut Backlog中的用户故事做估算时，如果某项太大太空难以确切估算，及时对它细化。
使用计划纸牌可以极高的提高估算速度。一次估算中，如果任何两个人的估算值相差过大，一定要停下来澄清后，再重新估算。
给团队配置两倍的人，并不能得到两倍的生产力的。人越多，交流的成本越大，效率就越低。如果希望靠增加人员来提高软件团队的生产力，无疑是南辕北辙

敏捷精灵日记9

2007-09-26T22:03:00.000+08:00

[敏捷精灵日记]

TDD 以可验证的方式迫使开发人员将质量内建在思维中, 长期的测试先行将历练开发人员思维的质量，而事后的单元测试只是惶恐的跟随者.
重构不是一种构建软件的工具，不是一种设计软件的模式，也不是一个软件开发过程中的环节，正确理解重构的人应该把重构看成一种书写代码的方式或习惯，重构时时刻刻有可能发生。
软件构建学问中总有一些理论上很美好，但是一使用就可能面目全非，比如传统的瀑布模型。敏捷里很多被称之为思想的东西，恰恰没有太高深的理论，但都是一些实践的艺术，强调动手做而不是用理论论证。TDD就是这样一种东西，单纯去研究它的理论，分析它的优点和缺点没有任何意义，因为它本身就是一个很单纯的东西，再对其抽象也得不出象“相对论”那样深厚的理论。更多的实践会给出正确的答案的。
结对编程不是一种形式化的组合，在实际的XP小组中，结对的双方应该是根据需要不断变换的，对的结成应该是自发的，应该保证双方都是对这部分工作感兴趣的人，而不是强行指定。
结对编程不是结队编程，是2个人，不是更多

就象Scrum一样，并不是所有的team都有能力实行XP，也不是所有的项目都适合实行XP，要看实际情况而定。
xp中，多数实践方法是互相加强甚至是互相保证的，不能单单拿出某一个实践来单独实施，譬如结对编程，缺乏TDD/重构/简单递增设计的实践的有效补充，效果可能会大打折扣。

敏捷精灵日记8

2007-09-23T01:01:00.000+08:00

[敏捷精灵日记]

有效限制持续集成(Continue Integration) 反模式的建议：

经常提交代码，可以防止集成变得复杂。
在提交源代码之前运行私有构建，可以避免许多破碎的构建。
使用各种反馈机制避免开发人员忽视构建状态信息。
有针对性地向可以采取措施的人发送反馈，这是将构建问题通知团队成员的好方法。
购买更强大的构建机器，从而加快向团队成员提供反馈的速度。
避免构建膨胀。

敏捷精灵日记7-2

2007-09-20T21:59:00.001+08:00

[敏捷精灵日记]

1．持续集成最大的优点是可以避免传统模式在集成阶段的除虫会议。持续集成主张项目的开发人员频繁的将他们对源码的修改提交(check in)到一个单一的源码库，并验证这些改变是否对项目带来了破坏，持续集成包括以下几大要点：

访问单一源码库，将所有的源代码保存在单一的地点（源码控制系统），让所有人都能从这里获取最新的源代码（以及以前的版本）。
支持自动化创建脚本，使创建过程完全自动化，让任何人都可以只输入一条命令就完成系统的创建。
测试完全自动化，要求开发人员提供自测试的代码，让任何人都可以只输入一条命令就运行一套完整的系统测试。
提供主创建，让任何人都可以只输入一条命令就可以开始主创建。
提倡开发人员频繁的提交（check in）修改过的代码。

2．项目 bug 的增加和时间并不是线性增长的关系，而是和时间的平方成正比，两次集成间隔的时间越长，bug 增加的数量越超过你的预期，解决 bug 付出的工作量也越大，而你越觉得付出的工作量越大，你就越想推迟到以后去集成，企图到最后一次性解决问题，结果 bug 产生的就更多，导致下一次集成的工作量更大，你越感觉到集成的痛苦，就越将集成的时间推后，最后形成恶性循环。

敏捷精灵日记7-1

2007-08-20T23:57:00.001+08:00

[敏捷精灵日记]

采用敏捷的方法并不意味着没有规矩，没有文档、没有计划、没有跟踪与控制并不意味着就是敏捷。
在 “冲刺”和“冲刺”之间，留几天缓冲时间很重要。团队需要一段时间做一下调整，赶一些非sprint计划中的事情。这段时间是一个很好的用来解决一些技术或者工具问题的机会。你会发现你慢一下后，会变得更有效率。这就是为什么叫“sprint”的一个理由，你不可能无休止的冲刺。
没有规矩，不成方圆。由团队共同制定出来的Scrum团队规则，可以更好的保证Scrum的顺利实施。

[Scrum团队规则]

1. 每日站立例会迟到，罚款￥5.
2. 对于每个，未及时更新任务状态和剩余工作量，整个Team留三次免罚机会，以后再有人违反，则罚款￥5.
3. 对于Sprint计划会议、演示会议和回顾会议，迟到超过3分钟，罚款￥5.
4. 进行任务细分时，每个任务估算最大不能超过18小时(三天)
5. 在Sprint计划会议上, 认领了一项任务的人，可以对该任务估算做出不超过50%的调整
6. 对于复杂任务的估算和分解，采用“DELPHI”方法
7. 每个人都可以添加新的product backlog条目, 但必须标示为 'Not Reviewed'，以方便Product Owner审议.
8. 为提高Sprint回顾会议的效率，在Sprint回顾会议之前,每一个人应该给出“我们做得好的地方、需要改进的地方”
10. 在Sprint计划会议上, 我们应该预留10%的估算时间作为缓冲，以应对突发事件
11。在Sprint计划会议上, 我们应该进行关键路径、风险、外部依赖的分析
12. 对于Review，发出review的人必须给出截止日期，参与Review的人，必须在截止日期前给出答复。

敏捷精灵日记7

2007-08-08T21:55:00.001+08:00

[敏捷精灵日记]

Sprint0---"兵不厌诈（the Big Con）"

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

Sprint1---"越狱记（Breakout）

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

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

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

Sprint3---"大结局(The Big End)"

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

敏捷精灵日记6

2007-08-01T01:51:00.000+08:00

[敏捷精灵日记]

管理中的愤怒和羞辱是会传染的.如果高级经理喜欢骂人,低级管理者也会这样做。
如果经理使用辱骂的方法来刺激员工，这就表现出经理的无能，而不是员工的无能。
作为一个经理，宁讲错话，不讲假话。假话一旦揭穿，底层员工从此再也无法信任上层经理。

敏捷精灵日记5

2007-07-21T02:47:00.000+08:00

[敏捷精灵日记]

Sprint 评审会议不是让开发团队做成果“演讲”——会议上不一定要有PowerPoints 图片文件，通常会议不会需要超过30 分钟的准备时间——这只是简单的展示工作结果，所有与会人员可以提出问题和建议。
在Sprint 评审之后,开发团队会进行Sprint 回顾。有些开发团队会跳过此过程, 这是不合适的,因为它是使Scrum 成功的重要方法之一。这是提供给开发团队的非常好的机会，来讨论什么方法能起作用而什么不起作用，并一致通过改进的方法。Scrum 开发团队，产品所有者和ScrumMaster 都将参加会议，会议由外部中立者主持；一个很好的方法是由ScrumMaster 互相主持对方的回顾会议，可以起到各团队间信息传播的作用。
敏捷回顾不是一场没有主题的讨论会，大家坐下来，七嘴八舌漫无目的的一阵“乱弹”，这样的形式对于项目进展没有任何帮助。
Scrum回顾会议的议程：
1、在白板上写上主要指导原则；
2、在白板上画上一个至少三页纸连在一起长的时间轴；
3、在白板上写上“我们的成功经验是什么”；
4、在白板上写上“有什么能够改进”；
5、在白板上写上“谁负责”，然后分成两个区域——“团队”和“公司”。
Scrum回顾会议的最高指导原则。即‘无论我们发现了什么，考虑到当时的已知情况、个人的技术水平和能力、可用的资源，以及手上的状况，我们理解并坚信：每个人对自己的工作都已全力以赴。'
在项目过程中，处理问题越早，那么付出的代价与成本就越小。问题是，当我们在紧张的开发任务中，有时候很难发现这些错误，更加意识不到这些错误会带来严重的影响。通过回顾会议，利用团队成员互相善意地“敲击”对方，或者反复“锻炼”开发过程与方法，就能够让每一位成员都炼就“火眼金睛”。
进行Scrum回顾时，发现问题仅仅是第一步，我们还要在回顾会议中合理分析这些问题出现的原因、所属类别，并因此划定问题的“责任田”。我们要明确这些问题是团队内部的，还是由于外在因素导致的，也就是说要明确“责任田”的归属，指定处理人和处理时间。
在每个Sprint开始的时候，我们都必须要明确这个Sprint结束的时候我们需要Review的是哪些东西。很多时候，如果一个Scrum开展不是很顺利，在Sprint Review的时候我们常常会听到这样的理由，“因为某些原因，这个功能我没有办法展示给你，但是这个功能是有了的，我只需要改动小小一点东西就可以了。 ”或者是“这个部分与另一个系统相关，我代码已经写好了，但我要一起改好了你才可以看到。”如果放任的话，这些理由到后期会泛滥成灾。我们所能做的，除拒绝通过这些相关的 User Story之外，在每个Sprint开始的时候还应该帮助团队了解到我们需要在Sprint Review上看到什么东西。强调我们重视的是可交付的版本，而不是一个口头上的功能增加。

敏捷精灵日记4

2007-07-14T01:44:00.001+08:00

【敏捷精灵日记】

Scrum 团队强调自我管理，自我引导，这其实是管理的最高境界，如果团队里面的每个人都能够时刻关注公司的或者部门的business，那么整个公司的利益自然会最大化，但是现实往往不是这样的。那么设立Scrum master时，是不是可以让每个人在每个sprint里都有这样的机会来带领团队，并感受这种business的view呢？实际操作中这个是不是有难度呢？起码在我们现在团队中还不是轮换Scrum Master的，没准以后我们可以试试！
让Daily Scrum会议保持紧凑有效的指导原则：
- 第一指导原则：主题明确，不能参杂其他无关的话题。
- 第二指导原则：站立会议只允许“猪”说话，“鸡”不能讲话。
- 第三指导原则：所有人站立围成一圈，不能围坐在一个桌子周围。
- 第四指导原则：确保整个团队都要参加每日Scrum会议。
- 第五指导原则：每日Scrum站立会议是团队交流会议，不是报告会议
- 第六指导原则：每日Scrum站立会议应该控制在15分钟之内。
- 第七指导原则：不要把每日Scrum站立会议作为一天的开始。
- 第八指导原则：Scrum站立会议要在每日同一时间同一地点举行
Scrum Master要及时解决Daily Scrum上提出的阻碍。这一点非常关键，Scrum Master必须要做到，否则会影响每个成员反应障碍的积极性。
利用burn down chart来跟踪细分任务的完成情况，可以在项目进程的任何时间点都能够看到项目进展状况，而不是每周或者项目完成之后，从而保证了开发进度处于可控制的状态。

敏捷精灵日记3

2007-07-07T02:32:00.001+08:00

【敏捷精灵日记】

· Scrum注重的是管理和组织实践，XP关注的是编程实践，可以分别解决不同领域的问题。可以组合使用，互相补充。

· 一条可以实行的实践原则，会比长篇大论的理论有用许多，没有实践原则指导的方法论没有意义。Scrum因为缺乏有效的编程实践，必须通过XP或其他方法来补充

· 使用XP，可以使开发人员成为更好的Developer，但Scrum方法能够迫使那些效率低的developer变得更有效率。

· Nokia的Scrum标准

1. Scrum 团队必须要有产品负责人，而且团队都清楚这个人是谁。
2. 产品负责人必须要有产品的Backlog，其中包括团队对它进行的估算。
3. 团队必须要有燃尽图，而且要了解他们自己的生产率。
4. 在一个Sprint中，外人不能干涉团队的工作。

· scrum虽然强调文档、流程和管理的轻量化，但并不是意味着没有控制，没有计划，只是要做轻量的短期冲刺计划。强调的是每时每刻都要根据需求和开发情况对项目进行调整，从而达到提前交付

· ScrumMaster与传统项目经理相比，必须从从传统的控制者转变为引导者。

· scrum中，对任务细分和时间估计，需要整个开发小组和Product Owner的参与。

· Sprint计划会议议程

上午(2 Hours)

1)充实并讲解Product Backlog[Product Owner] (50 Minutes)
2)重新调整Product Backlog条目优先级[Product Owner] (10 Minutes)

休息(10 Minutes)

3)设定Sprint目标[Scrum Team] (10 Minutes)
4)选择Product Backlog条目，组成Sprint Backlog[Scrum Team] (40 Minutes)

下午(3-4 Hours)

1) 分成两个小组，进行任务细分，定义"DONE"，给出任务估算. (60 Minutes)
2) 小组间互相评审，解决争议(20 Minutes)

休息(15 Minutes)

3) 关键路径分析(20 Minutes)
4) 制定资源计划(20 Minutes)
5) 任务领取(20 Minutes)
6) 风险分析(20 Minutes)
7) 其他事情(10 Minutes)

敏捷精灵日记2

2007-06-19T21:26:00.001+08:00

[敏捷精灵日记]

瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。

瀑布模型有以下特点：

为项目提供了按阶段划分的检查点。
当前一阶段完成后，您只需要去关注后续阶段。
瀑布模型强调文档的作用，并要求每个阶段都要仔细验证。但是，这种模型的线性过程太理想化，其主要问题在于：
各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量；
由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险；

早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。

在做大的变革之前，积极听取其他成员的意见，努力理解其他成员的观点；获得团队主要成员的支持，是保证变革成功的重要一环。

软件开发根本就没有什么灵丹妙药可言。虽然敏捷编程技术可以很快开发出优秀的应用软件，但不是说这项技术适合每个项目。在实施敏捷之前，一定对现有项目做好分析，要对症下药。

在Scrum开发模式下，为每个Sprint起一个名字，不但可以增加团队软件开发的乐趣，提高大家的参与程度，还可以记录下Scrum Team当时的心情

敏捷精灵日记1

2007-06-13T23:12:00.001+08:00

[敏捷精灵日记]

Scrum坚持如下敏捷开发原则：保持简单、接受变化、不断迭代、不断的反馈和改善、协作和减少浪费
Scrum是一种灵活的软件管理过程，它可以帮助你驾驭迭代，递增的软件开发过程。
Scrum提供了一种经验方法，它使得团队成员能够独立地，集中地在创造性的环境下工作。它发现了软件工程的社会意义。Scrum一词来源于橄榄球运动，指“在橄榄球比赛中，双方前锋站在一起紧密相连，当球在他们之间投掷时他们奋力争球。”
Scrum这一过程是迅速、有适应性、自组织的，它代表了从顺序开发过程以来的重大变化。
Scrum的迭代过程被称为“快跑”，时间为2-4个礼拜。
Scrum团队一般由5-10人组成，Scrum团队不仅仅是一个程序员队伍，它还应该包括其他一些角色，如产品经理、设计人员和测试人员等
Scrum包含三类角色: Scrum Master， Product Owner， Scrum Team
相对于传统的开发模式来讲，agile也好，scrum框架也好，都是现在软件开发中用于应对快速变化的市场和需求快速反应的一种变通
Scrum是一个非常轻量级的流程。简单讲是先建立一个产品"订单"(backlog)，做一个短期“冲刺”(sprint)计划，执行这个计划，每天开会讨论计划中的问题和进展，计划完成后演示工作成果，再对该阶段的工作做回顾、反思，接着不断重复以上流程。