<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>漫天风 &#187; agile pratice</title>
	<atom:link href="http://blog.thinklet.net/mantian/tag/agile-pratice/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.thinklet.net/mantian</link>
	<description>把细小的事情做到极致</description>
	<lastBuildDate>Mon, 18 Jan 2010 16:28:45 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.5.2</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>敏捷团队的信息辐射器</title>
		<link>http://blog.thinklet.net/mantian/2009/03/18/%e6%95%8f%e6%8d%b7%e5%9b%a2%e9%98%9f%e7%9a%84%e4%bf%a1%e6%81%af%e8%be%90%e5%b0%84%e5%99%a8/</link>
		<comments>http://blog.thinklet.net/mantian/2009/03/18/%e6%95%8f%e6%8d%b7%e5%9b%a2%e9%98%9f%e7%9a%84%e4%bf%a1%e6%81%af%e8%be%90%e5%b0%84%e5%99%a8/#comments</comments>
		<pubDate>Wed, 18 Mar 2009 08:36:16 +0000</pubDate>
		<dc:creator>mantian</dc:creator>
				<category><![CDATA[Agile]]></category>
		<category><![CDATA[agile pratice]]></category>

		<guid isPermaLink="false">http://blog.thinklet.net/mantian/?p=299</guid>
		<description><![CDATA[敏捷团队要能达到自管理的能力，除了理解敏捷的理念和必要的素质外，其实空间（协作空间）环境也很重要。信息辐射器（Information Radiator，The Ideal Agile Workspace）中介绍了好几种常用的方式，稍微整理一下，分享如下：

Sprint Backlog，这是整个项目团队自我管理的核心。实时反映项目的状况。通过 Sprint Backlog可以了解到任务分配，项目进展（燃尽图），缺陷，困难等等。Sprint Backlog上的不同类任务用不同颜色区分，一目了然。很容易就可以了解任务分配，Sprint的瓶颈以及困难（用红色表示）在哪里。
故事墙，较为长期的开发计划。
Build Monitor， 一般包括一个红绿灯，一个大屏幕显示器。红绿灯监控主分支的持续集成系统的状况，如果构建失败（可能 原因包括编译错误，单元测试问题，冒烟测试以及回归测试问题等），立刻显示红灯，同时也会发出声音（XXXX project is &#8220;still&#8221; btoken）。大屏幕显示器主要是反映一些大家主要关注的持续集成项目的状态。其实如果采取按组件做分支的方式，每个Scrum Team还可以有一个熔岩灯，用来监控团队分支的状态。
各种白板，团队成员可以用白板对具体需求，具体模块架构以及其实现进行讨论。然后将白板的内容作公示，指导团队成员的日常开发。如果发现问题，随时修改白板的内容。
团队日历，主要是表明一些重要的日期以及成员请假情况。
系统框架图，招贴画。团队成员可以了解整个系统的高层次的系统架构。
各种手绘表格。用于过程改进或者其他作用的手绘表格，常见的例子有在回顾会议里面发现的问题；测试用例数目；测试覆盖率；结对编程轮换表；要重构的函数；Burnup Chart等。
产品愿景，团队成员对具体开发中遇到的问题，需要做决定的时候，能够基于愿景做出取舍。
系统词汇表，统一语言和隐喻。只有开发团队和客户用同样的语言，才会减少沟通中的误解。
团队可根据自身的需求设计更多的信息辐射器。

信息化工作空间的关键是信息，最终目的是使任何人只要进入一个团队的工作区域，就可以立刻了解项目的进度，项目的运行情况，现有的问 题，每个人现在的任务，一些团队需要改进的地方等等。大家每天来上班，只要看一下板，立刻就知道自己该做什么。不光是团队成员，一些 Stakeholder也可以到工作区域去看一看信息辐射器，了解最新的状况。即使Stakeholder不能到现场，只要经常发送一些照片，或者经常参 加一些演示，效果也会不错。实现信息化工作空间的前提是团队成员要坐在一起，如果不能坐在一起，那只能通过一些电子手段进行同步。当然信息辐射器也不能太 多，太多也会导致混乱。
]]></description>
		<wfw:commentRss>http://blog.thinklet.net/mantian/2009/03/18/%e6%95%8f%e6%8d%b7%e5%9b%a2%e9%98%9f%e7%9a%84%e4%bf%a1%e6%81%af%e8%be%90%e5%b0%84%e5%99%a8/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>yahoo实施Scrum敏捷方法的成果</title>
		<link>http://blog.thinklet.net/mantian/2008/12/30/yahoo%e5%ae%9e%e6%96%bdscrum%e6%95%8f%e6%8d%b7%e6%96%b9%e6%b3%95%e7%9a%84%e6%88%90%e6%9e%9c/</link>
		<comments>http://blog.thinklet.net/mantian/2008/12/30/yahoo%e5%ae%9e%e6%96%bdscrum%e6%95%8f%e6%8d%b7%e6%96%b9%e6%b3%95%e7%9a%84%e6%88%90%e6%9e%9c/#comments</comments>
		<pubDate>Mon, 29 Dec 2008 16:32:30 +0000</pubDate>
		<dc:creator>mantian</dc:creator>
				<category><![CDATA[Agile]]></category>
		<category><![CDATA[Erlang]]></category>
		<category><![CDATA[agile pratice]]></category>
		<category><![CDATA[yahoo]]></category>

		<guid isPermaLink="false">http://blog.thinklet.net/mantian/?p=79</guid>
		<description><![CDATA[今天例会的时候听到Lion将要介绍yahoo敏捷实践的东东，网上搜索了一把，发现yahoo其实已经实施3年多了，而且据说获得了比较大的成功，3年后，Yahoo!已经有了200多个开发团队在使用敏捷实践。明天记得找boots 要点资料哈。此外，这本书是yahoo人写的，可以考虑购买看看哦：敏捷估计与规划
Scrum 产生的收益在开发团队经验中体现在不同的方面。在Yahoo!公司，在上18 个月中将近50 个开发项目采用Scrum，一共近600 人参与，采用Scrum 的团队数量在快速发展。这些项目从客户界面，网页设计如Yahoo! Photos, 到后端基础构造服务如服务上百万客户的Yahoo!Mail；从全新的产品如Yahoo! Podcasts，其利用Scrum 作为从构思到发布的流程（并获得该年度同类产品的Webby 奖），到一些增量的项目，包括开发新的部件并维修bug 和其他的维护工作；我们也利用Scrum 来分配分布式项目。每一个季度，我们对Yahoo!公司每一位Scrum 的使用者进行调查（包括产品所有者，开发团队成员，ScrumMaster 和这些人员的经理），并让他们将Scrum 于以前的开发方式做一对比。我们正在准备Yahoo!公司的深入调查报告，以下是相关的资料显示：

生产效率：68%回复显示采用Scrum 后生产效率提高（4 分或5 分在以5 分为衡量标准上）；5%显示采用Scrum 后生产效率降低（1 分或2 分在以5 分为衡量标准上）；27%显示采用Scrum 后无变化（3 分在以5 分为衡量标准上）。
团队精神：52%回复显示采用Scrum 后团队精神加强；9%显示采用Scrum 后团队精神减弱；39%显示采用Scrum 后无变化。
适应性：63%回复显示采用Scrum 后适应性加强；4%显示采用Scrum 后适应性减弱；33%显示采用Scrum 后无变化。
责任性：62%回复显示采用Scrum 后责任性加强；6%显示采用Scrum 后责任性减弱；32%显示采用Scrum 后无变化。
协作能力：81%回复显示采用Scrum 后协作能力加强；1%显示采用Scrum 后协作能力减弱；18%显示采用Scrum 后无变化。
在产品所有者估算下，开发团队的生产效率平均提高了36%
85%的开发团队成员表示如果其拥有决策权的前提下，将会继续使用Scrum。

ADTmag.com的编辑Kurt Mackie与Gabrielle Benefield（这些团队的核心组织者之一）就Scrum在Yahoo中的应用情况进行了对话。
Kurt问到，是什么原因促使Yahoo!转向了敏捷和Scrum开发，Benefield说：
有些公司一起步官僚习气就很严重。可是，Yahoo刚开始时规模很小、发展很快，他们最开始的做法非常敏捷，几个创始人坐在一间屋子里面开发软件。然而当规模扩大到某种需要更加频繁交流的阶段后，他们提出了使用传统的瀑布流程……但是在我们这种创业型文化中，它很难实现。我们的员工都很聪明，富有创新能力，他们习惯于时时刻刻提出自己的想法。瀑布流程对他们来说太古板太做作了，它降低了他们的效率。于是，团队中的一名工程师开始给大家布道，他说：“嘿，我们应该更敏捷一些”……所以在2005年2月，我们就启动了一个敏捷开发的试点项目。
随后Benefield又谈到其在实施敏捷开发的过程中的一些心得体会：
…… 那些我曾参与其中的敏捷团队，尤其是那些对其进行过大量辅导的团队，他们的生产力很容易就提升了200～300%。有些团队做的尤为出色，因为他们真正地 实施了敏捷。某些团队可能由于没经过太多的辅导和训练，或存在系统性的阻碍，所以改进情况就不那么明显。但从整体来看——包括那些最差的情况——生产力的 提升幅度大约在35～36%之间。综合所有情况考虑，这个估算还是相当保守的。
Kurt又问道：“在敏捷/Scrum的世界里，变化是好事吗？”Benefield坦然道：
我 们 的想法发生变化是很自然的事情。当你开始构建一个产品并看到一些结果后，你就会想做出一些改变。我们不会说“你不能改它”，我们是在拥抱变化。在互联网上 面，你不得不拥有快速变化的能力。举个例子来说，当我们搭建Yahoo邮件的大规模存储后端时，中途有一个竞争对手提供了容量更庞大的邮箱存储空间。我们 当时必须迅速做出响应，假如当时我们用的是传统的瀑布模型的话，我们势必无计可施，但最终我们成功地对抗了对手的威胁。在开发产品的过程中，我们曾一次又 一次面临这样的局面。
当其被问到开发中想法常常变化所带来的影响时，Benefield说道：
敏 捷有着严格的纪律。对于类似所有的代码都有全方位的测试这种事情，我们是纪律严明的，所以你有勇气去尝试变化，理解变化所造成 的影响。这里不会出现那种所有人都在尝试自己念头的无序状态。我们允许团队进行自组织，各种想法从团队中源源涌出。但管理层和产品所有者对选用哪种想法来 实施有着最终决定权，会从业务层面上来制定优先级，因为他们对其了如指掌。他们从根本上控制着何时发布产品、发布哪些功能，而团队自己决定如何完成工作。
在最后，Benefield以下面这段话结束了本次访谈：
在Yahoo，我们永远不会命令别人使用这个过程。我认为过程的优点要靠它自身体现出来，人们也应该有选择的自由。敏捷正在Yahoo中慢慢取得主导地位……我相信，随着时间的推移，为了能够在竞争中真正胜出，敏捷会是公司最佳的选择。
]]></description>
		<wfw:commentRss>http://blog.thinklet.net/mantian/2008/12/30/yahoo%e5%ae%9e%e6%96%bdscrum%e6%95%8f%e6%8d%b7%e6%96%b9%e6%b3%95%e7%9a%84%e6%88%90%e6%9e%9c/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
<a style="display: none;" href="http://mcinside.com/">MC Inside</a>