<?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: Zachęta, przynęta i takie tam&#8230;</title>
	<link>http://www.agilers.com/teamblog/zacheta-przyneta-i-takie-tam/</link>
	<description>Metody agile w realiach polskiego IT</description>
	<pubDate>Fri, 18 May 2012 19:01:51 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.0.4</generator>

	<item>
		<title>by: Marcin Niebudek</title>
		<link>http://www.agilers.com/teamblog/zacheta-przyneta-i-takie-tam/#comment-9141</link>
		<pubDate>Fri, 27 Mar 2009 12:13:17 +0000</pubDate>
		<guid>http://www.agilers.com/teamblog/zacheta-przyneta-i-takie-tam/#comment-9141</guid>
					<description>Może zagram ostrzej :-)

"&lt;b&gt;Czy ktoś z was pracuje w zespole utrzymaniowym, który działa w modelu nearshoringowym/outsourcingowym i z czystym sumieniem może powiedzieć, że jego zespół robi wsztystko aby być jak najwydajniejszy bo się mu to opłaca?&lt;/b&gt;"

Pytania pomocnicze:
1. Co zrobiliście, żeby tak ułożyć współpracę?
2. Co zrobił klient, żeby was do tego zachęcić?</description>
		<content:encoded><![CDATA[<p>Może zagram ostrzej :-)</p>
<p>&#8220;<b>Czy ktoś z was pracuje w zespole utrzymaniowym, który działa w modelu nearshoringowym/outsourcingowym i z czystym sumieniem może powiedzieć, że jego zespół robi wsztystko aby być jak najwydajniejszy bo się mu to opłaca?</b>&#8221;</p>
<p>Pytania pomocnicze:<br />
1. Co zrobiliście, żeby tak ułożyć współpracę?<br />
2. Co zrobił klient, żeby was do tego zachęcić?
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Marcin Niebudek</title>
		<link>http://www.agilers.com/teamblog/zacheta-przyneta-i-takie-tam/#comment-9140</link>
		<pubDate>Fri, 27 Mar 2009 12:09:03 +0000</pubDate>
		<guid>http://www.agilers.com/teamblog/zacheta-przyneta-i-takie-tam/#comment-9140</guid>
					<description>No powiedzmy, że to jak oszacować w story points zgłoszenia, które potraktujemy jak user story to jest dla mnie jasne. Techniczny aspekt takiego projektu jest tutaj najprostszy. 

Moim problemem jest coś innego co jest niezależne od przyjętej przez zespół metody. Chodzi o ustalenie... "osi współpracy"(?) w takim miejscu, żeby żeby obu stronom opłacało się dbanie od wydajność i jakość. Bo jak na razie to mam wrażenie, że to tak nie funkcjonuje i zespół utrzymaniowy wyoutsourcowany poza firmę macieżystą najlepiej powinien "spieszyć się powoli". To dla mnie jest bardzie problem z samym modelem outsourcingu tego typu usługi i jakoś nie mogę uwierzyć w jego powodzenie, więc proszę o przykłady, które wyprowadzą mnie z tego przeświadczenia :-)</description>
		<content:encoded><![CDATA[<p>No powiedzmy, że to jak oszacować w story points zgłoszenia, które potraktujemy jak user story to jest dla mnie jasne. Techniczny aspekt takiego projektu jest tutaj najprostszy. </p>
<p>Moim problemem jest coś innego co jest niezależne od przyjętej przez zespół metody. Chodzi o ustalenie&#8230; &#8220;osi współpracy&#8221;(?) w takim miejscu, żeby żeby obu stronom opłacało się dbanie od wydajność i jakość. Bo jak na razie to mam wrażenie, że to tak nie funkcjonuje i zespół utrzymaniowy wyoutsourcowany poza firmę macieżystą najlepiej powinien &#8220;spieszyć się powoli&#8221;. To dla mnie jest bardzie problem z samym modelem outsourcingu tego typu usługi i jakoś nie mogę uwierzyć w jego powodzenie, więc proszę o przykłady, które wyprowadzą mnie z tego przeświadczenia :-)
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Tomek Dąbrowski</title>
		<link>http://www.agilers.com/teamblog/zacheta-przyneta-i-takie-tam/#comment-9139</link>
		<pubDate>Fri, 27 Mar 2009 11:32:42 +0000</pubDate>
		<guid>http://www.agilers.com/teamblog/zacheta-przyneta-i-takie-tam/#comment-9139</guid>
					<description>Ja zaproponowałbym inne rozwiązanie. Z opisu wynika, że jedynym zadaniem zespołu jest praca utrzymaniowa, czyli naprawa błędów. Rozumiem więc, że istnieje jakaś lista błędów (Bugs backlog). Zróbmy więc spotkanie z zespołem, oszacujmy w Story Points każdy z błedów. Następnie określmy jakie jest &lt;i&gt;velocity&lt;/i&gt; zespołu np. w ciągu 2 tygodni. Mając tą metrykę i wstępnie oszacowane błędy, oraz priorytety błędów wg upodobań klienta, mamy możliwość zobligowania się do naprawienia konkretnych rzeczy w mniej więcej określonym czasie.</description>
		<content:encoded><![CDATA[<p>Ja zaproponowałbym inne rozwiązanie. Z opisu wynika, że jedynym zadaniem zespołu jest praca utrzymaniowa, czyli naprawa błędów. Rozumiem więc, że istnieje jakaś lista błędów (Bugs backlog). Zróbmy więc spotkanie z zespołem, oszacujmy w Story Points każdy z błedów. Następnie określmy jakie jest <i>velocity</i> zespołu np. w ciągu 2 tygodni. Mając tą metrykę i wstępnie oszacowane błędy, oraz priorytety błędów wg upodobań klienta, mamy możliwość zobligowania się do naprawienia konkretnych rzeczy w mniej więcej określonym czasie.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Jacek Rybicki</title>
		<link>http://www.agilers.com/teamblog/zacheta-przyneta-i-takie-tam/#comment-8947</link>
		<pubDate>Fri, 20 Feb 2009 21:58:01 +0000</pubDate>
		<guid>http://www.agilers.com/teamblog/zacheta-przyneta-i-takie-tam/#comment-8947</guid>
					<description>Należy dążyć do tego, aby sprawy były proste, ale nie prostsze. Jeden wskaźnik: koszt/ilość problemów to nie jest wystarczające rozwiązanie. Dobre statystyki, to tylko takie, które pokazują że nadal zbyt duże jest ryzyko przeniesienia wszystkiego do Chin :)

Idea, którą rozumiem, jest taka: dać obu stronom to czego potrzebują: podkładki dla wyższego managementu, gwarancję stałych wpływów i wypływów, motywację do zwiększenia efektywności pracy.

Nasuwa mi się taki model: Koszty utrzymania są wyznaczane na podstawie statystyki i umów ramowych.

Co rozumiesz przez wydajność zespołu utrzymaniowego? Średni koszt rozwiązania problemu? Ilość rozwiązań, które zostały odrzucone? Średnia ważoną opóźnień względem zobowiązania dla danego priorytetu zgłoszenia?

Może spróbuj wynająć (oczywiście taniej zaprosić na piwo, ale to grozi zajęciem kilku wieczorów) na jeden dzień kogoś z firmy, która zajmuje się na poważnie utrzymaniem od kilku lat. Zaoszczędzisz więcej niż wydasz :)

pozdrawiam,
Jacek</description>
		<content:encoded><![CDATA[<p>Należy dążyć do tego, aby sprawy były proste, ale nie prostsze. Jeden wskaźnik: koszt/ilość problemów to nie jest wystarczające rozwiązanie. Dobre statystyki, to tylko takie, które pokazują że nadal zbyt duże jest ryzyko przeniesienia wszystkiego do Chin :)</p>
<p>Idea, którą rozumiem, jest taka: dać obu stronom to czego potrzebują: podkładki dla wyższego managementu, gwarancję stałych wpływów i wypływów, motywację do zwiększenia efektywności pracy.</p>
<p>Nasuwa mi się taki model: Koszty utrzymania są wyznaczane na podstawie statystyki i umów ramowych.</p>
<p>Co rozumiesz przez wydajność zespołu utrzymaniowego? Średni koszt rozwiązania problemu? Ilość rozwiązań, które zostały odrzucone? Średnia ważoną opóźnień względem zobowiązania dla danego priorytetu zgłoszenia?</p>
<p>Może spróbuj wynająć (oczywiście taniej zaprosić na piwo, ale to grozi zajęciem kilku wieczorów) na jeden dzień kogoś z firmy, która zajmuje się na poważnie utrzymaniem od kilku lat. Zaoszczędzisz więcej niż wydasz :)</p>
<p>pozdrawiam,<br />
Jacek
</p>
]]></content:encoded>
				</item>
</channel>
</rss>

