<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.0.4" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Comments on: Umowa fixed price w duchu agile</title>
	<link>http://www.agilers.com/teamblog/umowa-fixed-price-w-duchu-agile/</link>
	<description>Metody agile w realiach polskiego IT</description>
	<pubDate>Fri, 12 Mar 2010 06:11:47 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.0.4</generator>

	<item>
		<title>by: Marcin Niebudek</title>
		<link>http://www.agilers.com/teamblog/umowa-fixed-price-w-duchu-agile/#comment-8931</link>
		<pubDate>Thu, 15 Jan 2009 11:01:01 +0000</pubDate>
		<guid>http://www.agilers.com/teamblog/umowa-fixed-price-w-duchu-agile/#comment-8931</guid>
					<description>To troche nie tak... umowa jest normalna, tzn. jest fixed-price i jest okreslony termin. Faktycznie zaczalem troche od tylu i musze sie pospieszyc z opisem jak dochodzimy do tego jaka jest cena dla takiego kontraktu i jaki jest termin.

Innymi slowy to co tutaj opisalem to jedynie usankcjonowanie umowa procesu prowadzenia zmian w zakresie projektu opierajac sie na backlogu z okreslonym rozmiarem punktowym. Mamy ustalony zakres, ustalona cene i termin. I te punkty mowia tylko jak, zgdnie z umowa, zarzadzamy zmianami i pracujemy iteracyjnie.

Natomiast to w jaki sposo ustalamy cene i termin, czyli tez jak estymujemy wstepny zakres o zakladamy nasze velocity zeby zgrac zakres z terminem i z tego wyliczyc cene do kontraktu, opisze w kolejnym poscie.</description>
		<content:encoded><![CDATA[<p>To troche nie tak&#8230; umowa jest normalna, tzn. jest fixed-price i jest okreslony termin. Faktycznie zaczalem troche od tylu i musze sie pospieszyc z opisem jak dochodzimy do tego jaka jest cena dla takiego kontraktu i jaki jest termin.</p>
<p>Innymi slowy to co tutaj opisalem to jedynie usankcjonowanie umowa procesu prowadzenia zmian w zakresie projektu opierajac sie na backlogu z okreslonym rozmiarem punktowym. Mamy ustalony zakres, ustalona cene i termin. I te punkty mowia tylko jak, zgdnie z umowa, zarzadzamy zmianami i pracujemy iteracyjnie.</p>
<p>Natomiast to w jaki sposo ustalamy cene i termin, czyli tez jak estymujemy wstepny zakres o zakladamy nasze velocity zeby zgrac zakres z terminem i z tego wyliczyc cene do kontraktu, opisze w kolejnym poscie.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Wiktor Kapanowski</title>
		<link>http://www.agilers.com/teamblog/umowa-fixed-price-w-duchu-agile/#comment-8930</link>
		<pubDate>Thu, 15 Jan 2009 10:20:42 +0000</pubDate>
		<guid>http://www.agilers.com/teamblog/umowa-fixed-price-w-duchu-agile/#comment-8930</guid>
					<description>Marcin,

W mojej opinii ta umowa reguluje zarządzanie zmianą oraz prawa i obowiązki obu stron w iteracyjnym podejściu. Nie rozwiązuje ona moim zdaniem problemu fixed-price - pierwszy punkt określa datę zakończenia projektu (której pochodną jest wartość kontraktu). Skąd możesz wiedzieć przed rozpoczęciem projektu jakie będziesz miał velocity zespołu w danym projekcie, kiedy skończysz projekt i ile powinno kosztować? 

Być może rozwiązaniem byłoby określanie w umowie przybliżonej daty zakończenia (np. między 1 września a 15 października), a po 5 iteracjach precyzowanie daty zakończenia, ale czy klient się na to zgodzi? Macie jakieś dobre pomysły lub doświadczenia w tym zakresie?</description>
		<content:encoded><![CDATA[<p>Marcin,</p>
<p>W mojej opinii ta umowa reguluje zarządzanie zmianą oraz prawa i obowiązki obu stron w iteracyjnym podejściu. Nie rozwiązuje ona moim zdaniem problemu fixed-price - pierwszy punkt określa datę zakończenia projektu (której pochodną jest wartość kontraktu). Skąd możesz wiedzieć przed rozpoczęciem projektu jakie będziesz miał velocity zespołu w danym projekcie, kiedy skończysz projekt i ile powinno kosztować? </p>
<p>Być może rozwiązaniem byłoby określanie w umowie przybliżonej daty zakończenia (np. między 1 września a 15 października), a po 5 iteracjach precyzowanie daty zakończenia, ale czy klient się na to zgodzi? Macie jakieś dobre pomysły lub doświadczenia w tym zakresie?
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Marcin Niebudek</title>
		<link>http://www.agilers.com/teamblog/umowa-fixed-price-w-duchu-agile/#comment-8813</link>
		<pubDate>Thu, 11 Dec 2008 20:13:14 +0000</pubDate>
		<guid>http://www.agilers.com/teamblog/umowa-fixed-price-w-duchu-agile/#comment-8813</guid>
					<description>@ursus
Doświadczeń z Telekomami nie mam, ale zauważ, że w tych zapisach nie ma mowy o tym, że cena jest nieznana. wręcz przeciwnie - jest fixed. Chodzi bardziej o uregulowanie w umowie zmian zakresu w trakcie projektu - bo tak faktycznie do tego się tylko sprowadza przy fixed price. Czym innym natomiast jest to, czy taki Telekom będzie chciał spojrzeć na coś tak obrzydliwego jak user story i jakieś tam punkty.

@maciek
No sprawa własności kodu wyglądała jak dotąd raczej normalnie, tzn. nie stosowaliśmy żadnych zapisów dotyczących stopniowego nabywania własności po każdej iteracji (bo jak rozumiem to jest intencją twojego pytania). Zwykle prawa majątkowe podlegają przekazaniu klientowi na koniec i wtedy stosujemy np. takie zapisy:
&lt;ul&gt;
	&lt;li&gt;Z dniem akceptacji ostatecznej wersji Systemu przez Zamawiającego, autorskie prawa majątkowe do elementów Systemu wykonanych przez Wykonawcę przechodzą na Zamawiającego.&lt;/li&gt;
	&lt;li&gt;Razem z przeniesieniem autorskich praw majątkowych, na Zamawiającego przechodzi wyłączne prawo udzielania zezwoleń na wykonywanie autorskiego prawa zależnego.&lt;/li&gt;
	&lt;li&gt;Przeniesienie autorskich praw majątkowych, z zastrzeżeniem prawa Wykonawcy do wynagrodzenia, następuje nieodpłatnie/odpłatnie.&lt;/li&gt;
&lt;/ul&gt;
Do tego dochodzi gwarancja i w czasie gwarancji klient nie ma np. prawa niczego zmieniać na własną rękę. Jeśli natomiast mówimy o zatrzymywaniu praw do kodu (albo do jego części - np. bibliotek bardziej ogólnego użytku) to wchodzimy w temat licencji i zapisy bywają różne, ale jak już pisałem to nie ma wiele wspólnego z agile.</description>
		<content:encoded><![CDATA[<p>@ursus<br />
Doświadczeń z Telekomami nie mam, ale zauważ, że w tych zapisach nie ma mowy o tym, że cena jest nieznana. wręcz przeciwnie - jest fixed. Chodzi bardziej o uregulowanie w umowie zmian zakresu w trakcie projektu - bo tak faktycznie do tego się tylko sprowadza przy fixed price. Czym innym natomiast jest to, czy taki Telekom będzie chciał spojrzeć na coś tak obrzydliwego jak user story i jakieś tam punkty.</p>
<p>@maciek<br />
No sprawa własności kodu wyglądała jak dotąd raczej normalnie, tzn. nie stosowaliśmy żadnych zapisów dotyczących stopniowego nabywania własności po każdej iteracji (bo jak rozumiem to jest intencją twojego pytania). Zwykle prawa majątkowe podlegają przekazaniu klientowi na koniec i wtedy stosujemy np. takie zapisy:</p>
<ul>
<li>Z dniem akceptacji ostatecznej wersji Systemu przez Zamawiającego, autorskie prawa majątkowe do elementów Systemu wykonanych przez Wykonawcę przechodzą na Zamawiającego.</li>
<li>Razem z przeniesieniem autorskich praw majątkowych, na Zamawiającego przechodzi wyłączne prawo udzielania zezwoleń na wykonywanie autorskiego prawa zależnego.</li>
<li>Przeniesienie autorskich praw majątkowych, z zastrzeżeniem prawa Wykonawcy do wynagrodzenia, następuje nieodpłatnie/odpłatnie.</li>
</ul>
<p>Do tego dochodzi gwarancja i w czasie gwarancji klient nie ma np. prawa niczego zmieniać na własną rękę. Jeśli natomiast mówimy o zatrzymywaniu praw do kodu (albo do jego części - np. bibliotek bardziej ogólnego użytku) to wchodzimy w temat licencji i zapisy bywają różne, ale jak już pisałem to nie ma wiele wspólnego z agile.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Jacek Laskowski</title>
		<link>http://www.agilers.com/teamblog/umowa-fixed-price-w-duchu-agile/#comment-8810</link>
		<pubDate>Thu, 11 Dec 2008 11:14:26 +0000</pubDate>
		<guid>http://www.agilers.com/teamblog/umowa-fixed-price-w-duchu-agile/#comment-8810</guid>
					<description>&lt;i&gt;"o tym jak taka listę do umowy budujemy w następnym poście"&lt;/i&gt; - już nie mogę się doczekać! Bardzo zwięźle przedstawiasz temat. Obyś posiedział jeszcze w hotelu, nie przez 1,5 tygodnia, ale np. 1 miesiąc (brrr, powiedziałem to na głos?! Oby się nie spełniło, co? ;-))</description>
		<content:encoded><![CDATA[<p><i>&#8220;o tym jak taka listę do umowy budujemy w następnym poście&#8221;</i> - już nie mogę się doczekać! Bardzo zwięźle przedstawiasz temat. Obyś posiedział jeszcze w hotelu, nie przez 1,5 tygodnia, ale np. 1 miesiąc (brrr, powiedziałem to na głos?! Oby się nie spełniło, co? ;-))
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: maciej.zawadzkI@o2.pl</title>
		<link>http://www.agilers.com/teamblog/umowa-fixed-price-w-duchu-agile/#comment-8809</link>
		<pubDate>Thu, 11 Dec 2008 10:49:45 +0000</pubDate>
		<guid>http://www.agilers.com/teamblog/umowa-fixed-price-w-duchu-agile/#comment-8809</guid>
					<description>Jestem bardzo ciekawy jak przy takich umowach wygląda właność kodu źródłowego. Mógłbyś przytoczyć jakies punkty które regulują prawa do źródeł i modyfikacji?</description>
		<content:encoded><![CDATA[<p>Jestem bardzo ciekawy jak przy takich umowach wygląda właność kodu źródłowego. Mógłbyś przytoczyć jakies punkty które regulują prawa do źródeł i modyfikacji?
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: ursus</title>
		<link>http://www.agilers.com/teamblog/umowa-fixed-price-w-duchu-agile/#comment-8808</link>
		<pubDate>Thu, 11 Dec 2008 10:18:40 +0000</pubDate>
		<guid>http://www.agilers.com/teamblog/umowa-fixed-price-w-duchu-agile/#comment-8808</guid>
					<description>Masz projekt dla Telecomu - przetarg na fixed price. Zgłasza się 15 firm wybierany jest zawsze najtańszy z najlepszych. Klienta interesuje tylko końcowa cena, nie przyjmuje do wiadomości, że czegoś z zakresu możesz nie dostarczyć. Złożenie oferty z proponowaną umową podobną do tej, którą sugerujesz - od razu Cię dyskwalifikuje :(

Nie udało mi się jeszcze wynieść Agile na zewnątrz do poziomu kontraktu. Z zewnątrz dla klienta był zwykły kontrakt fixed price - fixed scope. Wewnętrzna organizacja zespołu to już inna bajka, ale to na ogół klienta nie interesuje.</description>
		<content:encoded><![CDATA[<p>Masz projekt dla Telecomu - przetarg na fixed price. Zgłasza się 15 firm wybierany jest zawsze najtańszy z najlepszych. Klienta interesuje tylko końcowa cena, nie przyjmuje do wiadomości, że czegoś z zakresu możesz nie dostarczyć. Złożenie oferty z proponowaną umową podobną do tej, którą sugerujesz - od razu Cię dyskwalifikuje :(</p>
<p>Nie udało mi się jeszcze wynieść Agile na zewnątrz do poziomu kontraktu. Z zewnątrz dla klienta był zwykły kontrakt fixed price - fixed scope. Wewnętrzna organizacja zespołu to już inna bajka, ale to na ogół klienta nie interesuje.
</p>
]]></content:encoded>
				</item>
</channel>
</rss>
