<?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>Proje Doğru da Olsa, Beklentiler Önemli! yazısına yapılan yorumlar</title>
	<atom:link href="http://www.emreguzer.com/index.php/2008/12/28/dogru-zamanda-dogru-proje/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.emreguzer.com/index.php/2008/12/28/dogru-zamanda-dogru-proje/</link>
	<description>Küçük şeyler büyük farklar yaratır!</description>
	<lastBuildDate>Fri, 03 Feb 2012 18:29:27 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.1.3</generator>
	<item>
		<title>Yazar: Zekeriya KOÇ</title>
		<link>http://www.emreguzer.com/index.php/2008/12/28/dogru-zamanda-dogru-proje/comment-page-1/#comment-1619</link>
		<dc:creator>Zekeriya KOÇ</dc:creator>
		<pubDate>Sun, 28 Dec 2008 15:08:19 +0000</pubDate>
		<guid isPermaLink="false">http://www.emreguzer.com/?p=427#comment-1619</guid>
		<description>çevik yazılım geliştirme manifestosunu yapıştırıyorum aşağıya:

* Bireyler ve onlar arasındaki etkileşimi süreç ve araca tercih etmek
* Çalışan bir yazılımı detaylı bir dokümantasyona tercih etmek
* Müşteri ile işbirliğini, anlaşma görüşmelerine tercih etmek
* Değişikliklere istenildiği anda cevap verebilmeyi sınırları belirli bir plana tercih etmek

bu ilkeler temelinde geliştirilen projelerde kısa (hafta bazında) periyodlarla çalışan uygulamalar sunulur ve kullanıcıdan devamlı geri bildirim alınır. bu şekilde kullanıcının sisteme tepksini daha projenin başında ölçebilir ve buna göre devam edebilirsiniz. 

klasik proje yönetimi teknikleri ile hem müşteri hem de geliştiriciler tarafında yanlış seçilebilecek analistler sebebi ile, sunulan ürün ile istenen arasındaki fark çok geç anlaşılmaktadır. 

tabii ki bazı projeler geleneksel yöntemlere daha uygun olabilirler ama çevik proje yönetimi kesinlikle göz önüne alınması gereken bir yöntem bence. 

http://enveraltin.com/sunumlar/ adresindeki değişimikucaklamak.pdf dosyasındaki sunumdan giriş yapılabilir.</description>
		<content:encoded><![CDATA[<p>çevik yazılım geliştirme manifestosunu yapıştırıyorum aşağıya:</p>
<p>* Bireyler ve onlar arasındaki etkileşimi süreç ve araca tercih etmek<br />
* Çalışan bir yazılımı detaylı bir dokümantasyona tercih etmek<br />
* Müşteri ile işbirliğini, anlaşma görüşmelerine tercih etmek<br />
* Değişikliklere istenildiği anda cevap verebilmeyi sınırları belirli bir plana tercih etmek</p>
<p>bu ilkeler temelinde geliştirilen projelerde kısa (hafta bazında) periyodlarla çalışan uygulamalar sunulur ve kullanıcıdan devamlı geri bildirim alınır. bu şekilde kullanıcının sisteme tepksini daha projenin başında ölçebilir ve buna göre devam edebilirsiniz. </p>
<p>klasik proje yönetimi teknikleri ile hem müşteri hem de geliştiriciler tarafında yanlış seçilebilecek analistler sebebi ile, sunulan ürün ile istenen arasındaki fark çok geç anlaşılmaktadır. </p>
<p>tabii ki bazı projeler geleneksel yöntemlere daha uygun olabilirler ama çevik proje yönetimi kesinlikle göz önüne alınması gereken bir yöntem bence. </p>
<p><a href="http://enveraltin.com/sunumlar/" rel="nofollow">http://enveraltin.com/sunumlar/</a> adresindeki değişimikucaklamak.pdf dosyasındaki sunumdan giriş yapılabilir.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

