<?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: tinyPM</title>
	<link>http://www.agilers.com/teamblog/tinypm/</link>
	<description>Metody agile w realiach polskiego IT</description>
	<pubDate>Wed, 07 Jan 2009 12:36:14 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.0.4</generator>

	<item>
		<title>by: Battle for Agility &#187; Zbierać dowody czy grać w pokera?</title>
		<link>http://www.agilers.com/teamblog/tinypm/#comment-396</link>
		<pubDate>Mon, 31 Mar 2008 21:38:58 +0000</pubDate>
		<guid>http://www.agilers.com/teamblog/tinypm/#comment-396</guid>
					<description>[...] Podczas dyskusji na temat tinyPM, obiecałem odnieść się do opisanej przez Joela Spolsky&#8217;ego metody szacowania czasu wykonania projektu o nazwie &#8220;Evidence Based Scheduling&#8220;. Osobiście ta metoda wydaje mi się nieco przeładowana danymi jakie należy do jej poprawnego działania zbierać, no i w porównaniu z tym, co oferują techniki agile (story points, planning poker), zbyt czasochłonna i skomplikowana. Dodatkowo wydaje mi się, że jest obarczona pewnymi wadami, od których planning pokerowi udaje się uciec. Tak więc EBS bardziej pasuje mi do fixed time, fixed scope, ale po kolei&#8230; [...]</description>
		<content:encoded><![CDATA[<p>[&#8230;] Podczas dyskusji na temat tinyPM, obiecałem odnieść się do opisanej przez Joela Spolsky&#8217;ego metody szacowania czasu wykonania projektu o nazwie &#8220;Evidence Based Scheduling&#8220;. Osobiście ta metoda wydaje mi się nieco przeładowana danymi jakie należy do jej poprawnego działania zbierać, no i w porównaniu z tym, co oferują techniki agile (story points, planning poker), zbyt czasochłonna i skomplikowana. Dodatkowo wydaje mi się, że jest obarczona pewnymi wadami, od których planning pokerowi udaje się uciec. Tak więc EBS bardziej pasuje mi do fixed time, fixed scope, ale po kolei&#8230; [&#8230;]
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Piotr Gabryanczyk</title>
		<link>http://www.agilers.com/teamblog/tinypm/#comment-389</link>
		<pubDate>Wed, 12 Mar 2008 19:54:59 +0000</pubDate>
		<guid>http://www.agilers.com/teamblog/tinypm/#comment-389</guid>
					<description>Swietny pomysl - brakuje dobrego produktu do planowania iteracji, a do tego lekkiego i prostego w obsludze.
Uzywalem, JIRA-y, Track-a, XPlanner-a a nawet TestDirector-a, ale zaden z nich nie spelnial oczekiwan.

Co do porad (dostajecie ich pewnie wiele) to mam dwie:
1. Tam gdzie ja pracuje (bankowosc inwestycyjna - lukratywny klient) nie ma mowy o rozwiazaniu hostowanym zewnetrznie, wiec potrzebna jest wersja do instalacji w firmie

2. Nakreccie wideo - czlowiek zmeczony po pracy nie ma czasu na wklikiwanie sie w demo, a filmik obejrzy zamiast wiadomosci. Jak juz sie spodoba to chetnie wejdzie na strone i poklika. 

W firefox-ie jest problem z linkiem do dema. Cos marudzi o problemie z przekierowaniem.
W IE nazwy iteracji sa mikroskopijnie male w okienkach po prawej stronie.

Kibicuje i czekam na wersje hostowana wewnetrznie, lub na dedykowanym serwerze.

Piotr Gabryanczyk</description>
		<content:encoded><![CDATA[<p>Swietny pomysl - brakuje dobrego produktu do planowania iteracji, a do tego lekkiego i prostego w obsludze.<br />
Uzywalem, JIRA-y, Track-a, XPlanner-a a nawet TestDirector-a, ale zaden z nich nie spelnial oczekiwan.</p>
<p>Co do porad (dostajecie ich pewnie wiele) to mam dwie:<br />
1. Tam gdzie ja pracuje (bankowosc inwestycyjna - lukratywny klient) nie ma mowy o rozwiazaniu hostowanym zewnetrznie, wiec potrzebna jest wersja do instalacji w firmie</p>
<p>2. Nakreccie wideo - czlowiek zmeczony po pracy nie ma czasu na wklikiwanie sie w demo, a filmik obejrzy zamiast wiadomosci. Jak juz sie spodoba to chetnie wejdzie na strone i poklika. </p>
<p>W firefox-ie jest problem z linkiem do dema. Cos marudzi o problemie z przekierowaniem.<br />
W IE nazwy iteracji sa mikroskopijnie male w okienkach po prawej stronie.</p>
<p>Kibicuje i czekam na wersje hostowana wewnetrznie, lub na dedykowanym serwerze.</p>
<p>Piotr Gabryanczyk
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Jacek Rybicki</title>
		<link>http://www.agilers.com/teamblog/tinypm/#comment-374</link>
		<pubDate>Wed, 09 Jan 2008 10:10:13 +0000</pubDate>
		<guid>http://www.agilers.com/teamblog/tinypm/#comment-374</guid>
					<description>&lt;a rel="nofollow" target="_blank" href="http://www.axosoft.com" rel="nofollow"&gt;Jeszcze jeden podobny produkt&lt;/a&gt;</description>
		<content:encoded><![CDATA[<p><a rel="nofollow" target="_blank" href="http://www.axosoft.com" rel="nofollow">Jeszcze jeden podobny produkt</a>
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Jacek Rybicki</title>
		<link>http://www.agilers.com/teamblog/tinypm/#comment-355</link>
		<pubDate>Thu, 13 Dec 2007 12:40:28 +0000</pubDate>
		<guid>http://www.agilers.com/teamblog/tinypm/#comment-355</guid>
					<description>Zgadzam się z Tobą w wielu kwestiach, ale nie będę się o tym rozpisywać. Staram się głównie znaleźć słabe punkty, bo z tego może być potencjalna korzyść.

Zaczynanie od określenia ceny licencji na poziomie ciut niższym od  rozwiązań, które są na rynku dłużej, nie jest najlepszym pomysłem.
Przede wszystkim trzeba się na rynek wkręcić. Joel na swoim blogu opisywał zdaje się jak jego firma rozkręcała się. Dlatego też o nim wspominałem.
Nie wiem czy Wy robiliście badania rynku, ilu klientów już macie, jak bardzo są zadowoleni z produktu. Próbowałem wczuć się w rolę potencjalnego nabywcy, a przynajmniej osoby opiniującej. Z założenia taka osoba nie poświęci dużo czasu na dogłębne zapoznanie się z każdym produktem, najważniejsze są "przedbiegi", gdzie liczy się pierwsze wrażenie i opinie innych użytkowników. Zaprezentuję tinyPM kilku osobom i zapytam o opinię.</description>
		<content:encoded><![CDATA[<p>Zgadzam się z Tobą w wielu kwestiach, ale nie będę się o tym rozpisywać. Staram się głównie znaleźć słabe punkty, bo z tego może być potencjalna korzyść.</p>
<p>Zaczynanie od określenia ceny licencji na poziomie ciut niższym od  rozwiązań, które są na rynku dłużej, nie jest najlepszym pomysłem.<br />
Przede wszystkim trzeba się na rynek wkręcić. Joel na swoim blogu opisywał zdaje się jak jego firma rozkręcała się. Dlatego też o nim wspominałem.<br />
Nie wiem czy Wy robiliście badania rynku, ilu klientów już macie, jak bardzo są zadowoleni z produktu. Próbowałem wczuć się w rolę potencjalnego nabywcy, a przynajmniej osoby opiniującej. Z założenia taka osoba nie poświęci dużo czasu na dogłębne zapoznanie się z każdym produktem, najważniejsze są &#8220;przedbiegi&#8221;, gdzie liczy się pierwsze wrażenie i opinie innych użytkowników. Zaprezentuję tinyPM kilku osobom i zapytam o opinię.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Marcin Niebudek</title>
		<link>http://www.agilers.com/teamblog/tinypm/#comment-354</link>
		<pubDate>Wed, 12 Dec 2007 18:55:03 +0000</pubDate>
		<guid>http://www.agilers.com/teamblog/tinypm/#comment-354</guid>
					<description>Ha :-) dla wersji 1.0 postaramy się przygotować szczegółowe porównanie ze wskazaniem dlaczego właśnie tinyPM jest tym systemem, którego szykacie... tymczasem w skrócie...

Porównanie z darmowymi systemami jest zwykle dość interesujące. Trac to przede wszystkim bugtracker. Oczywiście architektura tego systemu pozwala na rozszerzanie, ale jakoś ciężko mi sobie wyobrazić firmę, która postawia przeznaczyć czas swojego pracownika na dopisanie pluginów do Tracka. Jednak cena 1 miesiąca użytkowania tinyPM nie przekracza moim zdaniem przeciętnej stawki za 1 roboczo-godzinę pracy programisty, a w większości przypadków firmowe stawiki dla outsourcingu są wyższe. Więc na zarządzanie projektem firma musi wydać zaledwie 1/160 swojej podstawowej ceny za wykonanie projektu. Jeśli projektów w firmie jest więcej to relacja kosztu do zysku z projektu jest jeszcze korzystniejsza.

W wielu "składanych" rozwiązaniach nie znajdziesz dobrego zarządzania backlogiem, czy przejrzystego task boardu. tinyPM z założenia jest nastawiony na to, żeby być produktem wyspecjalizowanym i lekkim, nic więcej, nic mniej ponad to co konieczne do agilowego projektu. Support nie jest też bez znaczenia. Przy darmowym projekcie należy liczyć na prężność społęczności zgormadzonej wokół projektu. Oczywiście nie lekceważymy Tracka czy innych systemów open source, raczej staramy się czerpać także z ich doświadczeń. Wiele elementów takich systemów może sie nam nie podobać, inne wyznaczyły już pewne standardy (jak posiadanie Wiki).

Raczej porównywałbym tinyPM z takimi systemami jak VersionOne, RallyDev (ogromne potwory, kiedy zespół agile ma czas tam to wszystko wypełniać), Mingle, Acunote czy Target Process. Te systemy oddzielają idę bugtrackera od zarządzania projektem. Wiele systemów robi ruch w drugą stronę próbując na siłę przekształcić bugtrackera w coś czym nie jest.

I jeszcze co do ceny... większość z wymienionych przeze mnie tutaj systemów ma cenę od 24$ - 59$ / użytkownika / za miesiąc :-), jedynie Rally oferuje support telefoniczny - my go w tej chwili nie oferujemy, ale nie wykluczam takiej opcji w przyszłości. Support mailowy nie schodzi praktycznie poniżej 24h (zwykle 48h) i jest to górna gwarantowana granica, a nie standard. Chyba więc nie jest to aż taka wygórowana oferta :-) a ocenią nas jak zwykle klienci.

Co do "Evidence-Based Scheduling" to czytałem i chyba faktycznie odniosę sie do tego osobnym postem zamiast komentarza, bo nie do końca zgadzam się jakoby była to rewolucyjna metoda. Przy całym szacunku dla wielu świetnych  artykułów na temat tworzenia oprogramowania, ta metoda chyba idzie już trochę za daleko. To co oferuje agile, czyli punkty (a nie godziny) oraz plannig poker to moim zdaniem dużo prostsza a jednocześnie co najmniej tak samo trafna metoda estymacji projektu.

Oj znowu komentarz stał się mini artykułem... muszę zacząć panować nad tym lepiej :-)</description>
		<content:encoded><![CDATA[<p>Ha :-) dla wersji 1.0 postaramy się przygotować szczegółowe porównanie ze wskazaniem dlaczego właśnie tinyPM jest tym systemem, którego szykacie&#8230; tymczasem w skrócie&#8230;</p>
<p>Porównanie z darmowymi systemami jest zwykle dość interesujące. Trac to przede wszystkim bugtracker. Oczywiście architektura tego systemu pozwala na rozszerzanie, ale jakoś ciężko mi sobie wyobrazić firmę, która postawia przeznaczyć czas swojego pracownika na dopisanie pluginów do Tracka. Jednak cena 1 miesiąca użytkowania tinyPM nie przekracza moim zdaniem przeciętnej stawki za 1 roboczo-godzinę pracy programisty, a w większości przypadków firmowe stawiki dla outsourcingu są wyższe. Więc na zarządzanie projektem firma musi wydać zaledwie 1/160 swojej podstawowej ceny za wykonanie projektu. Jeśli projektów w firmie jest więcej to relacja kosztu do zysku z projektu jest jeszcze korzystniejsza.</p>
<p>W wielu &#8220;składanych&#8221; rozwiązaniach nie znajdziesz dobrego zarządzania backlogiem, czy przejrzystego task boardu. tinyPM z założenia jest nastawiony na to, żeby być produktem wyspecjalizowanym i lekkim, nic więcej, nic mniej ponad to co konieczne do agilowego projektu. Support nie jest też bez znaczenia. Przy darmowym projekcie należy liczyć na prężność społęczności zgormadzonej wokół projektu. Oczywiście nie lekceważymy Tracka czy innych systemów open source, raczej staramy się czerpać także z ich doświadczeń. Wiele elementów takich systemów może sie nam nie podobać, inne wyznaczyły już pewne standardy (jak posiadanie Wiki).</p>
<p>Raczej porównywałbym tinyPM z takimi systemami jak VersionOne, RallyDev (ogromne potwory, kiedy zespół agile ma czas tam to wszystko wypełniać), Mingle, Acunote czy Target Process. Te systemy oddzielają idę bugtrackera od zarządzania projektem. Wiele systemów robi ruch w drugą stronę próbując na siłę przekształcić bugtrackera w coś czym nie jest.</p>
<p>I jeszcze co do ceny&#8230; większość z wymienionych przeze mnie tutaj systemów ma cenę od 24$ - 59$ / użytkownika / za miesiąc :-), jedynie Rally oferuje support telefoniczny - my go w tej chwili nie oferujemy, ale nie wykluczam takiej opcji w przyszłości. Support mailowy nie schodzi praktycznie poniżej 24h (zwykle 48h) i jest to górna gwarantowana granica, a nie standard. Chyba więc nie jest to aż taka wygórowana oferta :-) a ocenią nas jak zwykle klienci.</p>
<p>Co do &#8220;Evidence-Based Scheduling&#8221; to czytałem i chyba faktycznie odniosę sie do tego osobnym postem zamiast komentarza, bo nie do końca zgadzam się jakoby była to rewolucyjna metoda. Przy całym szacunku dla wielu świetnych  artykułów na temat tworzenia oprogramowania, ta metoda chyba idzie już trochę za daleko. To co oferuje agile, czyli punkty (a nie godziny) oraz plannig poker to moim zdaniem dużo prostsza a jednocześnie co najmniej tak samo trafna metoda estymacji projektu.</p>
<p>Oj znowu komentarz stał się mini artykułem&#8230; muszę zacząć panować nad tym lepiej :-)
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Jacek Rybicki</title>
		<link>http://www.agilers.com/teamblog/tinypm/#comment-353</link>
		<pubDate>Wed, 12 Dec 2007 18:24:27 +0000</pubDate>
		<guid>http://www.agilers.com/teamblog/tinypm/#comment-353</guid>
					<description>Przyszedł mi do głowy dosyć nowatorski pomysł. Jeżeli tinyPM jest przez Was używany, to może na stronę demo wrzućcie jakiś stary zrzut z Waszego projektu. Wtedy demo nabrałoby soczystości.
To lepiej podziałało by na wyobraźnię.

pozdrawiam,</description>
		<content:encoded><![CDATA[<p>Przyszedł mi do głowy dosyć nowatorski pomysł. Jeżeli tinyPM jest przez Was używany, to może na stronę demo wrzućcie jakiś stary zrzut z Waszego projektu. Wtedy demo nabrałoby soczystości.<br />
To lepiej podziałało by na wyobraźnię.</p>
<p>pozdrawiam,
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Jacek Rybicki</title>
		<link>http://www.agilers.com/teamblog/tinypm/#comment-352</link>
		<pubDate>Wed, 12 Dec 2007 09:50:58 +0000</pubDate>
		<guid>http://www.agilers.com/teamblog/tinypm/#comment-352</guid>
					<description>Aplikacja naprawdę ładnie zrobiona. Taki scyzoryk.

Przydało by się porównanie tinyPM z darmowymi zestawami. Przychodzi mi do głowy TRAC - z kilkoma pluginami osiąga podobną funkcjonalność.
Poza tym do TRAC'a można sobie dopisywać pluginy. Jak ktoś jest na tyle "kumaty" żeby docenić tinyPM, to potrafi też

W mojej organizacji wprowadzenie takiego narzędzia to długi proces. I na pewno ktoś zażyczy sobie dokładny spis zalet. Do tego projekty w których takie narzędzie byłoby przydatne zdarzają się od czasu do czasu, czasem więcej, czasem mniej. Stąd ten sposób licencjonowania sprawia trudności. W dodatku przy wysokich cenach - mamy znacznie bardziej "wypaśne" narzędzia kosztujące 200$ / user / rok (tinyPM to powyżej 230 euro przy tych samych ilościach)...

Jeszcze:
"e-mail support at support[at]tinypm.com with up to 48 hours response time"
Dla spokoju użytkowników trzeba napisać że można się dodzwonić do wsparcia w godzinach urzędowania i że mogą udzielić pomocy zdalnie natychmiast, w razie poważnego wypadku.

A bardziej pozytywnie: czytujesz blogi konkurencji?
http://www.joelonsoftware.com/items/2007/10/26.html

O, fogbugz Joela też jest tańszy:
http://www.fogcreek.com/FogBugz/PriceList.html</description>
		<content:encoded><![CDATA[<p>Aplikacja naprawdę ładnie zrobiona. Taki scyzoryk.</p>
<p>Przydało by się porównanie tinyPM z darmowymi zestawami. Przychodzi mi do głowy TRAC - z kilkoma pluginami osiąga podobną funkcjonalność.<br />
Poza tym do TRAC&#8217;a można sobie dopisywać pluginy. Jak ktoś jest na tyle &#8220;kumaty&#8221; żeby docenić tinyPM, to potrafi też</p>
<p>W mojej organizacji wprowadzenie takiego narzędzia to długi proces. I na pewno ktoś zażyczy sobie dokładny spis zalet. Do tego projekty w których takie narzędzie byłoby przydatne zdarzają się od czasu do czasu, czasem więcej, czasem mniej. Stąd ten sposób licencjonowania sprawia trudności. W dodatku przy wysokich cenach - mamy znacznie bardziej &#8220;wypaśne&#8221; narzędzia kosztujące 200$ / user / rok (tinyPM to powyżej 230 euro przy tych samych ilościach)&#8230;</p>
<p>Jeszcze:<br />
&#8220;e-mail support at support[at]tinypm.com with up to 48 hours response time&#8221;<br />
Dla spokoju użytkowników trzeba napisać że można się dodzwonić do wsparcia w godzinach urzędowania i że mogą udzielić pomocy zdalnie natychmiast, w razie poważnego wypadku.</p>
<p>A bardziej pozytywnie: czytujesz blogi konkurencji?<br />
<a href='http://www.joelonsoftware.com/items/2007/10/26.html' rel='nofollow'>http://www.joelonsoftware.com/items/2007/10/26.html</a></p>
<p>O, fogbugz Joela też jest tańszy:<br />
<a href='http://www.fogcreek.com/FogBugz/PriceList.html' rel='nofollow'>http://www.fogcreek.com/FogBugz/PriceList.html</a>
</p>
]]></content:encoded>
				</item>
</channel>
</rss>
