<?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: Czas to pieniądz?</title>
	<link>http://www.agilers.com/teamblog/czas-to-pieniadz/</link>
	<description>Metody agile w realiach polskiego IT</description>
	<pubDate>Fri, 18 May 2012 18:33:56 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.0.4</generator>

	<item>
		<title>by: Marcin Niebudek</title>
		<link>http://www.agilers.com/teamblog/czas-to-pieniadz/#comment-18</link>
		<pubDate>Thu, 30 Nov 2006 19:08:09 +0000</pubDate>
		<guid>http://www.agilers.com/teamblog/czas-to-pieniadz/#comment-18</guid>
					<description>Czynniki ryzyka jak najbardziej. Cała idea szacowania zadań w jednostkach "idealnych" i śledzenia wydajności (ang. &lt;em&gt;velocity&lt;/em&gt;) bierze się chyba właśnie z potrzeby dobrego a przy tym prostego uwzględniania takich czynników. Bardzo trudne  jest określenie wpływu liczbowego/godzinowego poszczególnych wymienionych przez Ciebie czynników osobno. Natomiast badanie rozbieżności pomiędzy ilością godzin/dni idealnych i roboczych z iteracji na iterację stanowi moim zdaniem próbę uchwycenia wpływu na projekt tego typu czynników jako całości.

Jak najbardziej zgadzam się, że szalenie istotne jest poznawanie wielkości takiego współczynnika w swoim zespole/organizacji. Obserwacja stosunku godzin idealnych do roboczych w trakcje trwania projektu może stanowić bardzo ciekawą pierwszą informację na temat działania procesu. I całkowicie zgadzam się z Tobą, że tych liczb nie da się wziąć z sufitu, wymyślić, przeczytać w książce. Z resztą techniki agile w większości opierają się na danych empirycznych. Można, a czasem nawet trzeba założyć coś na początek (przed pierwszą iteracją, w nowym projekcie), ale bardzo szybko nasze założenia powinny zostać zweryfikowane przez życie. Zwinny proces ma nam natomiast przynieść tą weryfikację jak najszybciej i jak najprościej, tak abyśmy mogli uniknąć niespodzianek. Jeśli nasze przewidywania są mocno chybione to dowiemy się o tym za raz na początku drogi i będziemy mieli dużo czasu na podjęcie działań naprawczych.

Sztuką tutaj nie jest nie popełnienie błędu, tylko szybkie wyciągnięcie z niego wniosków. Zysk będzie tym większy im bardziej podejście takie wejdzie w nawyk. Z każdą nową iteracją, z każdym projektem poznajemy swoje zespoły pod kątem ich indywidualnej wydajności. To pozwala nam coraz dokładniej określić wspomnianą przez Ciebie skalę kosztów na początku, kiedy negocjujemy z klientem. Wiemy lepiej czego możemy się spodziewać po swoich ludziach.

Pamiętajmy też, że te działania nie mają się przerodzić w krucjatę na rzecz odkrycia magicznego mnożnika X w naszej organizacji. Za każdym razem będzie on trochę inny. Chodzi tylko o to, żeby mieć narzędzie i wiedzę do dostrzegania tych zmian i identyfikowania powodów.

Pozdrawiam,
Marcin</description>
		<content:encoded><![CDATA[<p>Czynniki ryzyka jak najbardziej. Cała idea szacowania zadań w jednostkach &#8220;idealnych&#8221; i śledzenia wydajności (ang. <em>velocity</em>) bierze się chyba właśnie z potrzeby dobrego a przy tym prostego uwzględniania takich czynników. Bardzo trudne  jest określenie wpływu liczbowego/godzinowego poszczególnych wymienionych przez Ciebie czynników osobno. Natomiast badanie rozbieżności pomiędzy ilością godzin/dni idealnych i roboczych z iteracji na iterację stanowi moim zdaniem próbę uchwycenia wpływu na projekt tego typu czynników jako całości.</p>
<p>Jak najbardziej zgadzam się, że szalenie istotne jest poznawanie wielkości takiego współczynnika w swoim zespole/organizacji. Obserwacja stosunku godzin idealnych do roboczych w trakcje trwania projektu może stanowić bardzo ciekawą pierwszą informację na temat działania procesu. I całkowicie zgadzam się z Tobą, że tych liczb nie da się wziąć z sufitu, wymyślić, przeczytać w książce. Z resztą techniki agile w większości opierają się na danych empirycznych. Można, a czasem nawet trzeba założyć coś na początek (przed pierwszą iteracją, w nowym projekcie), ale bardzo szybko nasze założenia powinny zostać zweryfikowane przez życie. Zwinny proces ma nam natomiast przynieść tą weryfikację jak najszybciej i jak najprościej, tak abyśmy mogli uniknąć niespodzianek. Jeśli nasze przewidywania są mocno chybione to dowiemy się o tym za raz na początku drogi i będziemy mieli dużo czasu na podjęcie działań naprawczych.</p>
<p>Sztuką tutaj nie jest nie popełnienie błędu, tylko szybkie wyciągnięcie z niego wniosków. Zysk będzie tym większy im bardziej podejście takie wejdzie w nawyk. Z każdą nową iteracją, z każdym projektem poznajemy swoje zespoły pod kątem ich indywidualnej wydajności. To pozwala nam coraz dokładniej określić wspomnianą przez Ciebie skalę kosztów na początku, kiedy negocjujemy z klientem. Wiemy lepiej czego możemy się spodziewać po swoich ludziach.</p>
<p>Pamiętajmy też, że te działania nie mają się przerodzić w krucjatę na rzecz odkrycia magicznego mnożnika X w naszej organizacji. Za każdym razem będzie on trochę inny. Chodzi tylko o to, żeby mieć narzędzie i wiedzę do dostrzegania tych zmian i identyfikowania powodów.</p>
<p>Pozdrawiam,<br />
Marcin
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Jacek Rybicki</title>
		<link>http://www.agilers.com/teamblog/czas-to-pieniadz/#comment-17</link>
		<pubDate>Thu, 30 Nov 2006 13:43:33 +0000</pubDate>
		<guid>http://www.agilers.com/teamblog/czas-to-pieniadz/#comment-17</guid>
					<description>Przy szacowaniu kosztów trzeba uwzględnić czynniki ryzyka:
- braki w wiedzy i doświadczeniu,
- fluktuację kadr,
- niedostępność środowiska do testu,
- rozproszenie zespołu (często niemożliwe do uniknięcia - a może jednak się mylę?),
itd.
Wszystko to razem ze współczynnikiem wydajoności zespołu składa się na magiczne X przez które trzeba pomnożyć oszacowaną liczbę godzin "idealnych".

Wydaje mi się że najważniejszym powodem zmuszania zespołu do zmiany zeznań jest brak zaufania. Brak zaufania bierze się z braku wiedzy potrzebnej do oceny. A decydent staje się podejrzliwy na miarę swej niekompetencji w podejmowaniu decyzji.

Najlepiej było by dostarczyć wiedzę. Najpierw jednak trzeba ją zdobyć - znaleźć albo (o wiele lepiej) zebrać. Wiedza o tym że jeden UCP kosztuje średnio 23 MHR jest nieprzydatna jeżeli nie została potwierdzona w środowisku danej organizacji. Poza tym czasem trzeba szybko mieć "surową" informację na temat skali kosztów żeby móc nie wkopać się na samym początku rozmów z klientem. Baza wiedzy? Jak ją zbudować i jak ją rozszerzać?

pozdrawiam,
Jacek</description>
		<content:encoded><![CDATA[<p>Przy szacowaniu kosztów trzeba uwzględnić czynniki ryzyka:<br />
- braki w wiedzy i doświadczeniu,<br />
- fluktuację kadr,<br />
- niedostępność środowiska do testu,<br />
- rozproszenie zespołu (często niemożliwe do uniknięcia - a może jednak się mylę?),<br />
itd.<br />
Wszystko to razem ze współczynnikiem wydajoności zespołu składa się na magiczne X przez które trzeba pomnożyć oszacowaną liczbę godzin &#8220;idealnych&#8221;.</p>
<p>Wydaje mi się że najważniejszym powodem zmuszania zespołu do zmiany zeznań jest brak zaufania. Brak zaufania bierze się z braku wiedzy potrzebnej do oceny. A decydent staje się podejrzliwy na miarę swej niekompetencji w podejmowaniu decyzji.</p>
<p>Najlepiej było by dostarczyć wiedzę. Najpierw jednak trzeba ją zdobyć - znaleźć albo (o wiele lepiej) zebrać. Wiedza o tym że jeden UCP kosztuje średnio 23 MHR jest nieprzydatna jeżeli nie została potwierdzona w środowisku danej organizacji. Poza tym czasem trzeba szybko mieć &#8220;surową&#8221; informację na temat skali kosztów żeby móc nie wkopać się na samym początku rozmów z klientem. Baza wiedzy? Jak ją zbudować i jak ją rozszerzać?</p>
<p>pozdrawiam,<br />
Jacek
</p>
]]></content:encoded>
				</item>
</channel>
</rss>

