Battle for Agility

tinyPM

December 1st, 2007 Marcin Niebudek

Tym razem trochę prywaty… Jak już wspominałem, brak wpisów na blogu przez jakiś czas był spowodowany między innymi pracą nad systemem do zarządzania projektami. tinyPM, bo tak nazywa się nasz system, jest nastawiony ściśle na iteracyjną pracę z projektami na bazie spisanych dla projektu user stories. Od samego początku staraliśmy się stworzyć system, który byłby prosty, lekki i zawierał tylko kluczowe funkcjonalności.

tinyPM

Dlaczego nie staramy się gonić gigantów rynku i ich rozbudowanych narzędzi? Prowadząc projekty z wykorzystaniem technik agile chodzi nam o pozbycie się zbędnego bagażu procedur, papierów i czasu jaki musimy spędzać nad wszelkimi narzędziami do raportowania stanu projektu. Wielu ze światowych guru agile uważa, że najlepszymi narzędziami wspomagającymi prowadzenie takich projektów są pisak, kartki i tablica magnetyczna. I byłbym nawet skłonny przyznać rację w tej kwestii, tylko, że to dotyczy tylko projektów, których zespół znajduje się w jednym miejscu. Niestety rzeczywistość jest coraz częściej inna i zespoły zostają rozproszone po różnych lokacjach, nawet krajach czy kontynentach. Zadaniem tinyPM’a jest umożliwienie rozproszonym zespołom pracy z projektem, tak jakby wszyscy siedzieli w jednym pokoju i dzielili ze sobą user story wiszące na wspólnej tablicy magnetycznej.

Podczas pracy nad tinyPM zebrałem kilka spostrzeżeń na temat pracy rozproszonego zespołu i metod agile, o których niedługo postaram się napisać szerzej. Tymczasem więcej informacji na temat samego produktu znajdziecie na stronie www.tinypm.com, którą właśnie uruchomiliśmy. Na stronie także informacja o tym jak można tinyPM’a wypróbować na żywo.

Kategorie: Narzędzia

(No Ratings Yet)

Loading ...

7 komentarzy Dodaj komentarz

1. Jacek Rybicki | December 12th, 2007 at 10:50

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
2. Jacek Rybicki | December 12th, 2007 at 19:24

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,
3. Marcin Niebudek | December 12th, 2007 at 19:55

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 :-)
4. Jacek Rybicki | December 13th, 2007 at 13:40

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ę.
5. Jacek Rybicki | January 9th, 2008 at 11:10

Jeszcze jeden podobny produkt
6. Piotr Gabryanczyk | March 12th, 2008 at 20:54

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
7. Battle for Agility »&hellip | March 31st, 2008 at 22:38

[…] Podczas dyskusji na temat tinyPM, obiecałem odnieść się do opisanej przez Joela Spolsky’ego metody szacowania czasu wykonania projektu o nazwie “Evidence Based Scheduling“. 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… […]