<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>開発スケジュール作成のヒント へのコメント</title>
	<atom:link href="http://ec-cube.ec-orange2.jp/pm_blog/2009/02/12/project_management-50/feed/" rel="self" type="application/rss+xml" />
	<link>http://ec-cube.ec-orange2.jp/pm_blog/2009/02/12/project_management-50/</link>
	<description>エスキュービズムの敏腕プロジェクトマネージャー陣のブログです。</description>
	<pubDate>Mon, 21 May 2012 06:11:46 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5.1</generator>
		<item>
		<title>こじ より</title>
		<link>http://ec-cube.ec-orange2.jp/pm_blog/2009/02/12/project_management-50/#comment-17</link>
		<dc:creator>こじ</dc:creator>
		<pubDate>Fri, 13 Feb 2009 00:17:18 +0000</pubDate>
		<guid isPermaLink="false">http://ec-cube.ec-orange2.jp/pm_blog/?p=72#comment-17</guid>
		<description>どうも

スケジュールに遊びがあった方が、
「リスクもあるけどリターンも大きい」ような攻めの開発手法を取り易い
ってのもあると思ってます。

例えば、以下の2通りある場合
1. 100%間に合うけど確実に1日かかる開発方法
2. 80%の場合は半日で済むけど、20%の確率で2日かかる開発方法
（実際はこんなにハッキリしてませんが）

後者の方が効率はいいんですけど
納期が「明日まで」となっていると、1 の選択肢を選ぶ人も少なくないです。

なんで、納期は広ければ広い方が、
開発側としてはうれしいっすねー

ただ、管理側は、進捗が見えにくくなると思うので
そこはデメリットですけど。</description>
		<content:encoded><![CDATA[<p>
どうも<br />
<br />
スケジュールに遊びがあった方が、<br />
「リスクもあるけどリターンも大きい」ような攻めの開発手法を取り易い<br />
ってのもあると思ってます。<br />
<br />
例えば、以下の2通りある場合<br />
1. 100%間に合うけど確実に1日かかる開発方法<br />
2. 80%の場合は半日で済むけど、20%の確率で2日かかる開発方法<br />
（実際はこんなにハッキリしてませんが）<br />
<br />
後者の方が効率はいいんですけど<br />
納期が「明日まで」となっていると、1 の選択肢を選ぶ人も少なくないです。<br />
<br />
なんで、納期は広ければ広い方が、<br />
開発側としてはうれしいっすねー<br />
<br />
ただ、管理側は、進捗が見えにくくなると思うので<br />
そこはデメリットですけど。</p>
<br />
]]></content:encoded>
	</item>
</channel>
</rss>

