Koniec roku sprzyja podsumowaniom, no więc i ja się o jedno malutkie pokuszę. Co się działo w polskim agile w roku 2008?
Rok zaczął się nieźle, bo w lutym odbyło się pierwsze spotkanie Agile Underground, które w Krakowie zorganizowali Bartosz Bańkowski, Adam Byrtek i Jakub Dziwisz. Kraków niewątpliwie jest aktywny jeśli chodzi o agile. Niestety skończyło się na iteracji pierwszej :( (more…)
Dodaj komentarz December 30th, 2008 Marcin Niebudek
Nie tak dawno powstała grupa, której celem jest wypracowanie pewnego szablonu kontraktu na wykonanie aplikacji wg metodyk agile.
Tak faktycznie w Polsce cały czas ciężko uciec od kontraktów typu fixed price ze względu na pewne przyzwyczajenia i strach przed innym rodzajem umowy, która nie zabezpieczałaby odpowiednio klienta (chociaż to raczej pobożne życzenie z tym zabezpieczeniem). No więc zamiast z tym walczyć może należy się z taką sytuacja “zaprzyjaźnić”. Żeby po raz kolejny nie wdawać się w pustą dyskusję na temat tego jakie to fixed price jest złe, postaram się tym razem zamieścić fragmenty faktycznych zapisów z umów jakie sami stosujemy u siebie. A więc podyskutujmy o konkretach… (more…)
4 komentarzy December 10th, 2008 Marcin Niebudek
Hotelowa nuda sprzyja pisaniu, a ja właśnie nudzę się w hotelu po szkoleniu… no dobrze - nie nudzę, ale nie bardzo wiem dzisiaj za co zabrać się najpierw, to może jednak czas na małe wynurzenie się z okopów.
Na początek małe wyjaśnienie do tego dziwacznego tytułu :-) Otóż chciałbym napisać dzisiaj parę słów na temat śledzenia projektu. Zdarzyło mi się jakiś czas temu słyszeć co iterację “We are on the right track!” (o matko minęło już prawie pół roku), co natchnęło mnie później do napisania niniejszego posta. No więc jak się pewnie domyślacie “We are on the right track!” miało ze stanem faktycznym tyle wspólnego co “We are in the right truck!”.
Ale po kolei. Na co wam to wygląda (brazek):
2 komentarzy December 8th, 2008 Marcin Niebudek
Nowa wersja naszego narzędzia tinyPM do zarządzania projektami w duchu metodyk agile jest dostępna już od tygodnia, a w niej między innymi:
Dokładniejszy opis nowych funkcji znajdziecie na blogu produktu. Wszystkich, którzy używają darmowej wersji tinyPM zachęcamy również od zgłaszania pomysłów i głosowania nad rozszerzeniami na specjalnym forum jakie uruchomiliśmy dla tinyPM pod adresem:
tinyPM w wersji do 5 użytkowników dostępny jest za darmo. Jest to wersja w pełni funkcjonalna, bez żadnych dodatkowych ograniczeń. Do instalacji konieczny jest serwer Tomcat 5.5.x/6.0.x + MySQL.
2 komentarzy November 1st, 2008 Marcin Niebudek
Miło mi poinformować, że do ściągnięcia gotowa jest już wersja 1.1 systemu tinyPM. Najnowsza wersja zawiera między innymi:
tinyPM w wersji do 5 użytkowników dostępny jest za darmo do ściągnięcia ze strony www.tinypm.com. Jest to wersja w pełni funkcjonalna, bez żadnych dodatkowych ograniczeń. Do instalacji konieczny jest serwer Tomcat 5.5.x/6.0.x + MySQL.
Szczegółowe informacje na temat instalacji można znaleźć w archiwum dostępnym do ściągnięcia oraz na blogu produktu:
Zachęcam do zapoznania się z systemem oraz wyrażania opinii na jego temat. Na dobry początek polecam także zajrzeć do artykułu:
2 komentarzy June 24th, 2008 Marcin Niebudek
Dlaczego decydujemy się na próbę wprowadzenia procesów agile? Najczęściej skuszeni jesteśmy obietnicą:
Pewnie w głowie każdy obiecuje sobie jeszcze kilka rzeczy, ale skupię się na tych trzech. A raczej na tym, co się stanie jeśli zaczniemy się skupiać na jednej z nich… (more…)
2 komentarzy June 10th, 2008 Marcin Niebudek
23 kwietnia 2008 na Politechnice Wrocławskiej w ramach IT Days 2008 obył się wykład pt. “Agile techniques in big IT venture” poprowadzony przez Marcina Kołtonowskiego i Marka Majchrzaka z Nokia Siemens Networks (dalej NSN). Poniżej przedstawiam garść informacji o tym co na wykładzie można było usłyszeć i o tym czego niestety nie usłyszałem, a nie ukrywam, że chciałem :-)
Prezentacja podzielona była na 5 części:
4 komentarzy April 28th, 2008 Marcin Niebudek
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… (more…)
4 komentarzy March 31st, 2008 Marcin Niebudek
Na polskiej grupie dotyczącej lekkich metodyk Piotr Gabryanczyk zaprosił do więcia udziału w ankiecie. Również zachęcam do jej wypełniania i czekamy na wyniki.
Dodaj komentarz March 12th, 2008 Marcin Niebudek
No właśnie… W metodyce Scrum używamy określenia sprint dla, zwykle trzydziestodniowej, iteracji. I tak sobie myślę, że to bardzo trafne określenie. Tylko czy sprinter jest w stanie być długodystansowcem? Ideą iteracyjnego podejścia do tworzenia oprogramowania jest zachowanie stałego rytmu i dyscypliny pracy oraz skupienie się na ciągłym dostarczaniu działającego produktu.
Rytm. Iteracje z założenia są równe. Czasem robi się odstępstwo dla tych początkowych, ale później staramy się utrzymać już jednakową długość, bo tylko wtedy można coś sensownego wyczytać z liczonych po drodze metryk takich jak np. velocity (czyli wydajność zespołu) i obserwować jakieś trendy. Rytm dodatkowo pomagają utrzymać spotkania na początku i końcu iteracji, kiedy planujemy i podsumowujemy efekty naszej pracy.
Dyscyplina. Wymaganie dostarczania co iterację nowej, działającej wersji produktu powoduje, że czas jest lepiej wykorzystywany. Dobrze znany z podejścia kaskadowego efekt wypoczywających na początku projektu programistów, którzy potem nadrabiają przez ostatni tydzień braki w projekcie nie powinien zdarzyć się w podejściu iteracyjnym. Iteracje są na tyle krótkie, że nie można sobie pozwolić na zbyt długie rozluźnienie i bujanie w obłokach, albo na prywatne wycieczki programistów w rejony, które ich szczególnie kuszą, ale niekoniecznie muszą być związane z kluczowymi funkcjami systemu i wymaganiami klienta. Tutaj trzeba zamknąć kolejną wersję w 2-3 tyg. i ma ona działać. Opowiadanie klientowi, jaki to fantastyczny schemat bazy danych udało nam się w tym czasie zaprojektować nie pomoże, jeśli nie pokażemy systemu w działaniu. Liczą się zaimplementowane funkcjonalności.
Skupienie. Chodzi przede wszystkim o skupieniu się na głównym celu i kluczowych funkcjach. Czasu w iteracji jest stanowczo za mało, żeby pozwolić sobie na implementację funkcji o niskim priorytecie, bo nie zdążymy z rzeczami dla klienta najważniejszymi. I on szybko się o tym dowie - w najgorszym wypadku pod koniec iteracji.
Ten tryb pracy przynosi naprawdę dobre efekty. Ale ile takich iteracji jest w stanie wytrzymać programista? Czy stojąc właśnie u progu 30-tej iteracji nadal jest taki skupiony i zdyscyplinowany? Przyjęło się, że velocity powinno się w zespole ustabilizować po 2-3 pierwszych iteracjach i potem można już zacząć przewidywać kiedy zespół jest w stanie skończyć kolejne zaplanowane i oszacowane funkcje oraz ile ich wejdzie w każdą kolejną iterację. Jednak pracując iteracyjnie jesteśmy jak sprinter - wiemy, że mamy przebiec krótki dystans i wkładamy w to całą swoją energię. Nie jesteśmy tak jednak w stanie przebiec maratonu.
Rys. Utrata wydajności zespołu agile.
Wydaje mi się, że ta ustabilizowana z czasem wydajność zespołu agile musi prędzej czy później się załamać. Tylko kiedy jest ten moment? Ciekaw jestem jakie wy macie doświadczenia z tego typu projektami? Jaki był wasz najdłuższy projekt prowadzony wg. agile? Jaką długość iteracji uznajecie za idealną? Ja osobiście chyba najbardziej lubię iteracje dwutygodniowe a pojedynczy projekt nie przekroczył jeszcze w moim przypadku 7-8 miesięcy. Obawiam się jednak, że blisko już jestem maksymalnego pułapu.
4 komentarzy January 24th, 2008 Marcin Niebudek
tinyPM
jest lekkim narzędziem służącym do zarządzania projektami według metod agile i wspierającym
iteracyjne wytwarzanie oprogramwania, wymagania na bazie user stories, estymacje punktowe,
tablice z kartami zadań czy wiki.
Copyright (c) 2006-2007 Battle for Agility. Some rights reserved. 
Blix Theme by Sebastian Schmieg. Icons by Kevin Potts . Header illustration by Vladstudio.com . Powered by WordPress . Login
