<?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>第8音 PD  ID  UE &#187; 产品管理</title>
	<atom:link href="http://blog.d8in.com/posts/category/uee/feed" rel="self" type="application/rss+xml" />
	<link>http://blog.d8in.com</link>
	<description>Design is a  Life Style</description>
	<lastBuildDate>Wed, 10 Mar 2010 12:44:03 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>敏捷估计和规划的12条指导原则</title>
		<link>http://blog.d8in.com/posts/618.html</link>
		<comments>http://blog.d8in.com/posts/618.html#comments</comments>
		<pubDate>Sun, 08 Nov 2009 14:22:34 +0000</pubDate>
		<dc:creator>xw</dc:creator>
				<category><![CDATA[产品管理]]></category>

		<guid isPermaLink="false">http://blog.d8in.com/?p=618</guid>
		<description><![CDATA[最近读完了《敏捷估计和规划》，这本书对于实现敏捷开发具有很强的实战意义，提供了很多实际的操作方式和工具集，下面就是这本书的核心“敏捷估计和规划的12条指导原则”
1.让整个小组参与。
特定活动的主要职责可能会落在某个人或者某个分组身上，例如确定需求的优先级主要是产品所有者的职责。但是，在最求可能具有高价值的项目时，要让整个小组参与进来并做出承诺。例如，我们可以在一条建议中看到这一点，这条建议就是虽然可能很明显只有1~2个特定的小组成员会处理正在估计的故事或任务，但整个小组做出的估计才是最好的。小组成员分担的职责越多，小组可以共享的成功也就越多。
2.在不同层次上进行规划。
不要错误地认为发布计划会让迭代计划没有用，反过来也一样。发布计划、迭代计划和每日计划分别以不同的精度覆盖了不同的时间范围，而且各有其特定的用途。
3.使用不同度量单位，让对规模和持续时间的估计保持独立。
让对规模和持续时间的估计保持清晰区别的最佳方法是使用不会造成混淆的独立度量单位。使用故事点来估计规模，再使用速度把规模转换到持续时间是完成这一工作的好办法。
4.用功能或者日期来体现不确定性。
没有哪个计划是必然发生的。要确定您制定的任何发布计划中都包含对不确定性的体现。如果新功能的量是固定的，就把不确定性表示为一个日期范围（“我们会在第三季度完成”或者“我们会在7~10次迭代中完成”）。如果日期是固定的，就需要表示在要交付的确切功能上的不确定性（“我们将在12月31日完成，产品至少会包含这些新功能，最多可能只会再包含那些新功能”）。不确定性较大的时候，就使用较大的单位（例如迭代、月，季后是季度）。

5.经常重规划。
利用每次新迭代开始的时候评估当前发布的关联度。如果发布计划是根据过时的信息或现在被证实为错误的假设制定，就更新它。使用重规划的机会来保证项目总是瞄准着向公司交付最大的价值。
6.跟踪进度并沟通
有许多利益相关者会对项目的进度很敢兴趣。通过经常发布有关小组进展的简单而易于理解的指示器来让他们了解进度。耗散图和其它让人一眼就能看明白的项目进度指示器是最好的。
7.承认学习的重要性。
由于项目既是向产品增加新能力，也是产生新的知识，所以必须更新计划来包含这些新知识。随着我们更多地了解客户的需要，会把新功能增加到项目中。随着我们更多地了解我们使用的技术或我们合作的情况，会调整对进度率的期望和希望采用的方法。
8.规划具有适当规模的功能。
在不久的 将来（接下来几次迭代中）就要增加的功能应该分解成相对较小的用户故事&#8211;通常就是需要1~2天，最多不超过10天的事项。我们最善于估计规模处于一个数量级内的工作。让用户故事都处于这一范围内，可以让我们在估计和规划中付出的工作量和得到的准确度达到最佳的组合。它还可以提供足够小的用户故事，让大多数小组合一在一次迭代中完成。当然，在较长时间的项目中，使用小用户故事会很费事。为了平衡这个影响，如果您要建立的发布计划覆盖的时间范围超过了未来的2~3个月，也许可以编写一些更大型的故事（称为史诗）或者使用主题，来对时间更遥远的工作进行估计，从而避免过于提前把大故事分解成小故事。
9.确定功能优先级。
按照让项目总价值最高的顺序来处理功能。确定优先级时除了考虑功能的价值和成本，还要考虑它能带来的学习效果以及开发它能够减少的风险。可以在早期消除一个显著的风险的可能性，往往就足以保证先开发某个功能的合理性。与之相似，如果开发特定的功能可以让小组获得大量有关产品或他们开发它的工作的知识，也应该考虑尽早开发这个功能。
10.把估计和计划建立在事实上
只要有可能，就把您的估计和计划建立在现实的基础上。确实，有些时候在某些公司中会需要在没有什么事实根据的情况下对类似速度之类的事做出估计。但是，只要有可能，就应该根据事实的测量值建立估计和计划。这同样适于一个功能完成了多少的问题。很容易知道一个功能完成了0%的时候（我们还没有开始处理它），也相当容易知道我们已经完成了100%的时候（产品所有者的所有满意条件测试都通过了）。在这两者之间就很难度量了&#8211;这项任务完成了50%还是60%？由于这个问题太困难，最好还是坚持您所知道的：0%或100%。
11.保留一些松弛度。
尤其是在规划一次迭代的时候，不要规划用掉所有小组成员100%。就像公路达到100%容量的时候完全停滞一样，如果将所有人的时间都规划成满负荷工作，开发小组的进度也会减慢。
12.通过前瞻规划协调做个小组。
在涉及多个开发小组测项目中，应该通过滚动前瞻规划来协调他们的工作。通过前瞻和把特定功能分配到即将来到的特定迭代，可以规划和调节小组间的依赖。
]]></description>
			<content:encoded><![CDATA[<blockquote><p>最近读完了《敏捷估计和规划》，这本书对于实现敏捷开发具有很强的实战意义，提供了很多实际的操作方式和工具集，下面就是这本书的核心“敏捷估计和规划的12条指导原则”</p></blockquote>
<p><strong>1.让整个小组参与。</strong></p>
<p>特定活动的主要职责可能会落在某个人或者某个分组身上，例如确定需求的优先级主要是产品所有者的职责。但是，在最求可能具有高价值的项目时，要让整个小组参与进来并做出承诺。例如，我们可以在一条建议中看到这一点，这条建议就是虽然可能很明显只有1~2个特定的小组成员会处理正在估计的故事或任务，但整个小组做出的估计才是最好的。小组成员分担的职责越多，小组可以共享的成功也就越多。</p>
<p><strong>2.在不同层次上进行规划。</strong></p>
<p>不要错误地认为发布计划会让迭代计划没有用，反过来也一样。发布计划、迭代计划和每日计划分别以不同的精度覆盖了不同的时间范围，而且各有其特定的用途。</p>
<p><strong>3.使用不同度量单位，让对规模和持续时间的估计保持独立。</strong></p>
<p>让对规模和持续时间的估计保持清晰区别的最佳方法是使用不会造成混淆的独立度量单位。使用故事点来估计规模，再使用速度把规模转换到持续时间是完成这一工作的好办法。</p>
<p><strong>4.用功能或者日期来体现不确定性。</strong></p>
<p>没有哪个计划是必然发生的。要确定您制定的任何发布计划中都包含对不确定性的体现。如果新功能的量是固定的，就把不确定性表示为一个日期范围（“我们会在第三季度完成”或者“我们会在7~10次迭代中完成”）。如果日期是固定的，就需要表示在要交付的确切功能上的不确定性（“我们将在12月31日完成，产品至少会包含这些新功能，最多可能只会再包含那些新功能”）。不确定性较大的时候，就使用较大的单位（例如迭代、月，季后是季度）。<br />
<span id="more-618"></span></p>
<p><strong>5.经常重规划。</strong></p>
<p>利用每次新迭代开始的时候评估当前发布的关联度。如果发布计划是根据过时的信息或现在被证实为错误的假设制定，就更新它。使用重规划的机会来保证项目总是瞄准着向公司交付最大的价值。</p>
<p><strong>6.跟踪进度并沟通</strong></p>
<p>有许多利益相关者会对项目的进度很敢兴趣。通过经常发布有关小组进展的简单而易于理解的指示器来让他们了解进度。耗散图和其它让人一眼就能看明白的项目进度指示器是最好的。</p>
<p><strong>7.承认学习的重要性。</strong></p>
<p>由于项目既是向产品增加新能力，也是产生新的知识，所以必须更新计划来包含这些新知识。随着我们更多地了解客户的需要，会把新功能增加到项目中。随着我们更多地了解我们使用的技术或我们合作的情况，会调整对进度率的期望和希望采用的方法。</p>
<p><strong>8.规划具有适当规模的功能。</strong></p>
<p>在不久的 将来（接下来几次迭代中）就要增加的功能应该分解成相对较小的用户故事&#8211;通常就是需要1~2天，最多不超过10天的事项。我们最善于估计规模处于一个数量级内的工作。让用户故事都处于这一范围内，可以让我们在估计和规划中付出的工作量和得到的准确度达到最佳的组合。它还可以提供足够小的用户故事，让大多数小组合一在一次迭代中完成。当然，在较长时间的项目中，使用小用户故事会很费事。为了平衡这个影响，如果您要建立的发布计划覆盖的时间范围超过了未来的2~3个月，也许可以编写一些更大型的故事（称为史诗）或者使用主题，来对时间更遥远的工作进行估计，从而避免过于提前把大故事分解成小故事。</p>
<p><strong>9.确定功能优先级。</strong></p>
<p>按照让项目总价值最高的顺序来处理功能。确定优先级时除了考虑功能的价值和成本，还要考虑它能带来的学习效果以及开发它能够减少的风险。可以在早期消除一个显著的风险的可能性，往往就足以保证先开发某个功能的合理性。与之相似，如果开发特定的功能可以让小组获得大量有关产品或他们开发它的工作的知识，也应该考虑尽早开发这个功能。</p>
<p><strong>10.把估计和计划建立在事实上</strong></p>
<p>只要有可能，就把您的估计和计划建立在现实的基础上。确实，有些时候在某些公司中会需要在没有什么事实根据的情况下对类似速度之类的事做出估计。但是，只要有可能，就应该根据事实的测量值建立估计和计划。这同样适于一个功能完成了多少的问题。很容易知道一个功能完成了0%的时候（我们还没有开始处理它），也相当容易知道我们已经完成了100%的时候（产品所有者的所有满意条件测试都通过了）。在这两者之间就很难度量了&#8211;这项任务完成了50%还是60%？由于这个问题太困难，最好还是坚持您所知道的：0%或100%。</p>
<p><strong>11.保留一些松弛度。</strong></p>
<p>尤其是在规划一次迭代的时候，不要规划用掉所有小组成员100%。就像公路达到100%容量的时候完全停滞一样，如果将所有人的时间都规划成满负荷工作，开发小组的进度也会减慢。</p>
<p><strong>12.通过前瞻规划协调做个小组。</strong></p>
<p>在涉及多个开发小组测项目中，应该通过滚动前瞻规划来协调他们的工作。通过前瞻和把特定功能分配到即将来到的特定迭代，可以规划和调节小组间的依赖。</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.d8in.com/posts/618.html/feed</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>守.破.离</title>
		<link>http://blog.d8in.com/posts/600.html</link>
		<comments>http://blog.d8in.com/posts/600.html#comments</comments>
		<pubDate>Mon, 26 Oct 2009 14:28:06 +0000</pubDate>
		<dc:creator>xw</dc:creator>
				<category><![CDATA[产品管理]]></category>
		<category><![CDATA[敏捷]]></category>

		<guid isPermaLink="false">http://blog.d8in.com/?p=600</guid>
		<description><![CDATA[最近在看《敏捷软件开发》，其中有一段讲到了守.破.离。感觉非常的首启发，下面这段就是摘抄自里面一段关于守破离的描述
守（Shu或Mamoru）的意思是保持、保护或维持。在守的阶段，学生建立了技艺的技术基础。守也暗示了对于一个流派（ryu，流）的忠诚或者坚持，用现代的语言来解释ryu，就是一个师傅。在守的阶段，学生应当努力按照所教的那样来复制技术，不做一点修改，也不试图花经历去理解学校或者教师的技术背后的原理。按照这种方式，就能打下厚实的技术基础，而这正式能对这门技艺有更深的理解的所需要的基础。
守是一个合理的技术基础，通过仅遵循达到目标的一条路线能够最高效地建立这一基础。在理解你所熟悉的东西之前就混合进其它流派的技术，是让你走上错误道路一种诱惑。开发技术的道路不会有合理的理论价值和实践价值。在对于守阶段的额外解释中，由师傅来决定学生在什么时候从守进步到破，而学生不能决定。学生应该像一个等待注入的空容器一样，听从师傅的教诲。
破是这一过程的第二个阶段。破的意思是突破，即学生打破流派的传统而进行一些扩展。在这个阶段，学生必须反省他所学到的每件事情的形式和目的，从而对于这门技艺有所充许的纯粹重复性的联系更深入的理解。在这一阶段，因为已经完全学到了每一门技术，并已把它融入到了记忆中，因此学生应该准备去思考这些技术背后的背景。在学院里，破阶段就好比是这样一个阶段：学生的基础知识已经充足了，可以期望他写一些探寻本质的研究性文章了。
离的意思超过或者超越。在这一阶段，学生不再是通常意义上的学生，而是一个从业者。从业者必须进行独创地思考，从关于这门技艺的原始思想和背景知识出发有所发展，针对他的知识背景、结论和日常生活的需要的实际情况来测试发展出新的东西。在离这个阶段，这门技艺真正变成了从业者自己的技艺，并且从某种角度上讲，成了他自己的创造。这类似于学院里的博士或者更高的阶段。
]]></description>
			<content:encoded><![CDATA[<blockquote><p>最近在看《敏捷软件开发》，其中有一段讲到了守.破.离。感觉非常的首启发，下面这段就是摘抄自里面一段关于守破离的描述</p></blockquote>
<p>守（Shu或Mamoru）的意思是保持、保护或维持。在守的阶段，学生建立了技艺的技术基础。守也暗示了对于一个流派（ryu，流）的忠诚或者坚持，用现代的语言来解释ryu，就是一个师傅。在守的阶段，学生应当努力按照所教的那样来复制技术，不做一点修改，也不试图花经历去理解学校或者教师的技术背后的原理。按照这种方式，就能打下厚实的技术基础，而这正式能对这门技艺有更深的理解的所需要的基础。<span id="more-600"></span></p>
<p>守是一个合理的技术基础，通过仅遵循达到目标的一条路线能够最高效地建立这一基础。在理解你所熟悉的东西之前就混合进其它流派的技术，是让你走上错误道路一种诱惑。开发技术的道路不会有合理的理论价值和实践价值。在对于守阶段的额外解释中，由师傅来决定学生在什么时候从守进步到破，而学生不能决定。学生应该像一个等待注入的空容器一样，听从师傅的教诲。</p>
<p>破是这一过程的第二个阶段。破的意思是突破，即学生打破流派的传统而进行一些扩展。在这个阶段，学生必须反省他所学到的每件事情的形式和目的，从而对于这门技艺有所充许的纯粹重复性的联系更深入的理解。在这一阶段，因为已经完全学到了每一门技术，并已把它融入到了记忆中，因此学生应该准备去思考这些技术背后的背景。在学院里，破阶段就好比是这样一个阶段：学生的基础知识已经充足了，可以期望他写一些探寻本质的研究性文章了。</p>
<p>离的意思超过或者超越。在这一阶段，学生不再是通常意义上的学生，而是一个从业者。从业者必须进行独创地思考，从关于这门技艺的原始思想和背景知识出发有所发展，针对他的知识背景、结论和日常生活的需要的实际情况来测试发展出新的东西。在离这个阶段，这门技艺真正变成了从业者自己的技艺，并且从某种角度上讲，成了他自己的创造。这类似于学院里的博士或者更高的阶段。</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.d8in.com/posts/600.html/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
