<?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"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Комментарии к записи: Что такое Agile.</title>
	<atom:link href="http://simsym.com/agilemanifesto/feed/" rel="self" type="application/rss+xml" />
	<link>http://simsym.com/agilemanifesto/</link>
	<description>NewVision WEB-development Team Blog</description>
	<lastBuildDate>Thu, 17 Jun 2010 19:44:37 +0300</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.5</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>Автор: Developer</title>
		<link>http://simsym.com/agilemanifesto/comment-page-1/#comment-147</link>
		<dc:creator>Developer</dc:creator>
		<pubDate>Wed, 28 Apr 2010 16:04:53 +0000</pubDate>
		<guid isPermaLink="false">http://simsym.com/?p=523#comment-147</guid>
		<description>Из моего конкретного опыта эта методика годится только если соответствует главной идее - выдать программу заказчику здесь и сейчас несмотря на...

И это несмотря легко выбрасывает все то во что раньше свято верили теоретики software engineering: разработка спецификаций, дизайн, UML... Грубо говоря - после нас хоть потоп. Для коробочного продукта подобный подход
 - увеличение сроков разработки в результате отсутсвия спецификаций и постоянной переделки кода, 
 - ухудшение качества продукта вследствие отсутсвия дизайна как заклятого врага,  - непредсказуемость в планировании из-за незнания предмета разработки в начале цикла, как следствие - перенос сроков, 
- поддержка реализоканного продукта осложняется отсутсвием документации и людей, отношения с которыми были поставлены выше этого.</description>
		<content:encoded><![CDATA[<p>Из моего конкретного опыта эта методика годится только если соответствует главной идее &#8211; выдать программу заказчику здесь и сейчас несмотря на&#8230;</p>
<p>И это несмотря легко выбрасывает все то во что раньше свято верили теоретики software engineering: разработка спецификаций, дизайн, UML&#8230; Грубо говоря &#8211; после нас хоть потоп. Для коробочного продукта подобный подход<br />
 &#8211; увеличение сроков разработки в результате отсутсвия спецификаций и постоянной переделки кода,<br />
 &#8211; ухудшение качества продукта вследствие отсутсвия дизайна как заклятого врага,  &#8211; непредсказуемость в планировании из-за незнания предмета разработки в начале цикла, как следствие &#8211; перенос сроков,<br />
- поддержка реализоканного продукта осложняется отсутсвием документации и людей, отношения с которыми были поставлены выше этого.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Автор: bkitaec</title>
		<link>http://simsym.com/agilemanifesto/comment-page-1/#comment-139</link>
		<dc:creator>bkitaec</dc:creator>
		<pubDate>Wed, 07 Apr 2010 07:58:22 +0000</pubDate>
		<guid isPermaLink="false">http://simsym.com/?p=523#comment-139</guid>
		<description>сделайте подписку на блог, а то как вас читать?))</description>
		<content:encoded><![CDATA[<p>сделайте подписку на блог, а то как вас читать?))</p>
]]></content:encoded>
	</item>
	<item>
		<title>Автор: bkitaec</title>
		<link>http://simsym.com/agilemanifesto/comment-page-1/#comment-138</link>
		<dc:creator>bkitaec</dc:creator>
		<pubDate>Wed, 07 Apr 2010 07:57:26 +0000</pubDate>
		<guid isPermaLink="false">http://simsym.com/?p=523#comment-138</guid>
		<description>Спасибо за статью! Такому в универах к сожалению не учат... Все принципы идеальны.)</description>
		<content:encoded><![CDATA[<p>Спасибо за статью! Такому в универах к сожалению не учат&#8230; Все принципы идеальны.)</p>
]]></content:encoded>
	</item>
</channel>
</rss>
