Miło mi poinformować, że do ściągnięcia gotowa jest już wersja 1.1 systemu tinyPM. Najnowsza wersja zawiera między innymi:
- dodatkowe wersje językowe (niemiecką i polską, obok dostępnej od początku wersji angielskiej)
- wybór koloru kart dla user stories
- konfigurowalne na poziomie projektu skale estymacji (jeśli ktoś woli szacować np. w godzinach a nie w punktach według skali 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100),
- usprawnienia w zarządzaniu uprawnieniami wiki
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:
June 24th, 2008
Marcin Niebudek
Dlaczego decydujemy się na próbę wprowadzenia procesów agile? Najczęściej skuszeni jesteśmy obietnicą:
- szybszego dostarczania działającego oprogramowania (a co za tym idzie, lepszej wydajności naszych zespołów),
- lepszej jakości wytwarzania oprogramowania,
- szybszego reagowania na zmiany wymagań (i lepszego ukierunkowania się na klienta)
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…)
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:
- Ogólne informacje na temat NSN oraz na temat platformy @dvantage, przy której pracują obaj autorzy.
- Krótkie przypomnienie modelu kaskadowego (ang. waterfall) i jego wad.
- Manifest agile i główne założenia iteracyjnego tworzenia oprogramowania.
- Wprowadzenie do Scrum z omówieniem cyklu projektu i ról w projekcie.
- Część praktyczna, czyli spojrzenie na implementację Scrum w NSN jako dużej globalnej korporacji.
(more…)
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…)
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.
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.
January 24th, 2008
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.
December 1st, 2007
Marcin Niebudek
Jeden z pierwszych artykułów, jakie zamieściłem na tym blogu był moim atakiem na kontrakty o ustalonej cenie. Byłem przekonany, że ciężko tego typu kontrakty pogodzić z ideą agile, z gotowością do zmian oraz dobrą współpracą z klientem. Dzisiaj muszę nieco zrewidować ten pogląd. Największym problemem takich kontraktów wcale nie jest ustalona cena, czy termin, tylko ustalony zakres projektu. Barierą dla agile jest zamrożenie tych trzech elementów na raz w danym kontrakcie. Jeśli natomiast klient uwolni zakres, dopuści możliwość zmian funkcjonalności opisanych w umowie lub wymiany ich na inne, to stwarza to doskonałe warunki do tego, żeby jednak agile zastosować.
Co sie jednak stanie kiedy uwolnimy wszystkie trzy czynniki - czas, budżet i zakres? Coraz bardziej skłaniam się ku myśli, że taka wolność może być dużo bardziej problematyczna. (more…)
November 24th, 2007
Marcin Niebudek
Piątek spędziłem na Java Developers Day 2007. Dlaczego piszę tutaj o konferencji Java? W zeszłym roku agile było praktycznie w każdym wystąpieniu. Wszystkie produkty, praktyki, frameworki były agile. W tym roku coś się zmieniło… terminem agile nie wiało już z każdej prezentacji, co w sumie jest nawet lepsze, bo przywykliśmy do zbytnich nadużyć w kwestii stosowania agile wszędzie gdzie się tylko da.
Ale nie myślcie, że agile zniknęło z JDD. Także i tegoroczna edycja miała swój akcent w postaci wystąpienia Jakuba Dziwisza na temat “Test Driven Development w Java”. Wykład powinien być niedługo dostępny w wersji wideo na stronach organizatora konferencji, a na blogu Jakuba powinien się pojawić artykuł uzupełniający samą prezentację. Zaczęło się nieźle… (more…)
October 28th, 2007
Marcin Niebudek
Pół roku… bez postów… ale nie bez bitwy. Mój syn Tomek za kilka dni kończy cztery miesiące :-). W tym miesiącu uruchomimy wersję demo naszego nowego systemu do zarządzania projektami agile o nazwie tinyPM. Jesteśmy w trakcie dwóch nowych projektów, gdzie udaje się stosować coraz więcej praktyk agile. Bitwa trwa, a już niedługo nowe posty oraz więcej informacji na temat tinyPM’a.
October 3rd, 2007
Marcin Niebudek
Previous Posts
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.