blog.testowka.pl

Archiwum wiadomości z Grudzień, 2010

Zwinne środowisko testowe – nagranie.

opublikowany przez 19, Gru, 2010, w kategoriach Inne

Nareszcie udało się opublikować nagranie z mojej prelekcji w ramach scrum.org.pl. Niestety z powodu problemów technicznych wyciętych jest kilka minut wstępu, ale to co najważniejsze się ostało.

Zwinne środowisko testowe aplikacji webowych from Andy Brandt on Vimeo.

Dodaj komentarz więcej...

What do you mean „Agile”?

opublikowany przez 08, Gru, 2010, w kategoriach Agile, Scrum, Zarządzanie

„What do you mean Agile?” usłyszałem pół roku temu na rozmowie rekrutacyjnej w firmie w której obecnie pracuje.Agile – zwinny, elastyczny… Jak właściwie mamy rozumieć pojęcie Agile? Czy Agile to brak dokumentacji, brak ustalonych reguł, iteracyjny model wytwarzania oprogramowania, a może to tylko idealistyczny ruch społeczny? Wielu ludzi używa pojęcia Agile ale to słowo samo w sobie nie ma konkretnej definicji.

Spróbujmy może sięgnąć do historii. Pierwszych wzmianek o Agile (lub tym co właściwiej się pod tym pojęciem kryje) możemy doszukać się już w latach 60tych ubiegłego wieku w kontekście przyrostowego modelu wytwarzania oprogramowania. Wzrost popularności i uznanie Agile  jako pełnoprawnej metodyki zarządzania projektami są niewątpliwie powiązane z ogłoszeniem Manifestu Agile w 2001 roku kiedy to czołowi przedstawiciele takich metodyk jak  Scrum, Crystal Clear, Extreeme Programming, spotkali się by na podstawie swych doświadczeń sformułować cztery podstawowe zasady Agile:

  1. Ludzie i interakcje ponad procedury i narzędzia.
  2. Działające oprogramowanie ponad obszerną dokumentację.
  3. Współpraca z klientem ponad negocjację kontraktów.
  4. Reagowanie na zmiany ponad podążanie według ściśle ustalonego planu.

Oprócz powyższych filarów manifestu agile sformułowane zostało 12 dodatkowych zasad:

  • Zadowolenie klienta szybkie dostarczanie użytecznego oprogramowania.
  • Otwartość na zmianę wymagań nawet w późnej fazie developmentu.
  • Częste dostawy działającego oprogramowania.
  • Działające oprogramowanie jest podstawową miarą postępu projektu.
  • Stałe tempo rozwoju oprogramowania.
  • Bliska współpraca pomiędzy klientem a zespołem.
  • Bezpośrednie rozmowy są najlepszym sposobem wymiany informacji.
  • Projekt jest budowany wokół wysoce zmotywowanego,  godnego zaufania zespołu.
  • Ciągłe poświęcanie uwagi wysokiej jakości kodu i odpowiedniemu projektowaniu.
  • Prostota.
  • Samo-organizujące się zespoły
  • Regularne dostosowywanie się do zmieniających się okoliczności.

Niemniej jednak powyższe zasady nadal mogą być różnie interpretowane i pozostawiają wiele pola do manewru dla tych, którzy chcieli by się do ruchu Zwinnego Wytwarzania Oprogramowania przyłączyć. Nie ma żadnych zasad przystąpienia do tego ‚elitarnego’ klubu użytkowników Agile – wystarczy się zdeklarować, że powyższe zasady nie są nam obce i staramy się ich przestrzegać w naszej codziennej pracy. Czy to dobrze? Z jednej strony tak – im nas więcej tym lepiej, tym więcej ciekawych pomysłów i rozwiązań, niemniej jednak takie rozproszenie często prowadzi do powstawania ‚potworków’ opartych na zasadach Agile, które niestety próbują się zaadoptować do abstrakcyjnych sytuacji w których nie mają racji bytu.

Zatem co ja mam na myśli, gdy mówię Agile?

Moja interpretacja czterech filarów Agile wygląda następująco:

Ludzie i interakcje ponad procedury i narzędzia. Dla mnie Agile to przede wszystkim ludzie – dobrze zmotywowany zespół ekspertów (lub ludzi którzy dążą do tego by stać się ekspertami), dla którego jakość ma znaczenie, ludzie którzy znają wartość dobrego projektowania, ludzie dla których komunikacja i przekazywanie informacji jest podstawą udanej współpracy, ludzie którzy dobrowolnie biorą odpowiedzialność za to co robią i zdają sobie sprawę z konsekwencji decyzji, które podejmuj, ludzie którzy potrafią także rozmawiać z klientem, samodzielnie uzyskiwać potrzebne informacje, ludzie którzy potrafią zorganizować swoją pracę i współpracę. Procedury, narzędzia, metodyki, proces – czemu nie, ale to ludzie stanowią podstawę. Agile nie wyklucza narzędzi czy procesów, wręcz przeciwnie, XP, Scrum, czy Crystal Clear mają ściśle określone zasady, których przestrzeganie jest wskazane. Jeśli decydujemy się na używanie jakiejś metodyki czy narzędzia – np. Scrum, musimy pamiętać o tym, by używać jej zgodnie z ściśle określonym planem, używać go w celu do którego została stworzona, nie tworzyć potworków, które nie są sprawdzone i mogą doprowadzić do kalectwa procesu, takie postępowanie może wręcz zniechęcić do używania narzędzia czy nawet do samego Zwinnego Wytwarzania Oprogramowania. Po co wynajdywać koło od nowa, skoro można korzystać z tego co zostało już dosyć dobrze sprawdzone i działa.

Działające oprogramowanie ponad obszerną dokumentację. Będę Szczery- czytam dokumentację projektową tylko w ostateczności, uważam to za stratę czasu, jeśli tylko mam dostęp do osoby która daną dokumentację pisała to w pierwszej kolejności wolę porozmawiać i uzyskać potrzebne mi informację bezpośrednio u źródło. Dosyć często już podczas takich rozmów znajdujemy błędy w założeniach (często już zaimplementowane) bez odpalania komputera. Uważam, że efektywność jest nieporównanie większa niż gdybym musiał przedzierać się przez czasem kilkadziesiąt stron dokumentów. Nie mówię, że cała dokumentacja jest zła – warto dokumentować niestandardowe rozwiązania, nowe technologie, albo przynajmniej gromadzić w jednym miejscu referencje do informacji na ich temat. Niewątpliwą zaletą dokumentacji jest to iż wraz z odejściem pracowników wiedza nie ginie. Niemniej jednak utrzymanie aktualnej dokumentacji może nawet przewyższyć koszty samego wytworzenia oprogramowania. Jeśli dbamy o jakość kodu, o to by był jak najbardziej czytelny, o to by stosowane były znane powszechnie wzorce projektowe to nie musimy się martwić o dokumentację – dobrze napisany kod sam się dokumentuje, a testy jednostkowe/funkcjonalne/integracyjne stanowią dokumentację funkcjonalną.

Współpraca z klientem ponad negocjację kontraktów. Agile opiera się na zaufaniu klienta do firmy, zaufaniu managera do zespołu, zaufaniu członków zespołu do siebie na wzajem. Stosy dokumentacji projektowej zawartej w załącznikach do kontraktów stają się niepotrzebne, gdy klient ma pewność tego, że funkcjonalność, której potrzebuje zostanie rzetelnie wyceniona i zaimplementowana z gwarancją wysokiej jakości. Ponadto klient zyskuje możliwość wpływania na projekt w trakcie jego trwania – może nawet zmieniać wymagania. Nie ustala się ceny z góry, co najwyżej obie strony ustalają dopuszczalne widełki. Idealnie do tego typu projektów sprawdza się Scrum, w którym można określić stałą cenę za sprint. Niemniej jednak jak wspomniałem wyżej tutaj też podstawą jest zaufanie.

Reagowanie na zmiany ponad podążanie za ścisłym planem. Szczegółowe planowanie przed rozpoczęciem projektu to strata czasu. Nie jesteśmy w stanie zaplanować szczegółowo przebiegu projektu. Nie możemy przewidzieć interakcji ze światem zewnętrznym, które mogą mieć wpływ na projekt. Niemniej jednak Agile nie odrzuca całkowicie planowania! Dużo bardziej efektywne okazuje się częste planowanie w krótkich etapów projektu – iteracji/sprintów. Dzięki krótszym okresom czasu możemy dokładniej przewidzieć to co się wydarzy – nikt nie jest w stanie dokładnie określić co będzie robił za pół roku, dużo łatwiej jest nam powiedzieć czym będziemy się zajmować za tydzień, a jeszcze łatwiej co planujemy na dzisiaj. Dlatego idealnie sprawdzają się codzienne spotkania typu stand-up, które pozwalają na szczegółowe zaplanowanie pracy w najbliższym dniu, oraz rozliczenie samego siebie z zadań wykonanych od ostatniego spotkania, ponadto jest to świetna okazja do wymiany informacji pozwalająca na bardzo wczesne reagowanie na zmiany zachodzące wokół nas. Możecie mi wierzyć lub nie ale WYMAGANIA SIĘ ZMIENIAJĄ, nie da się zaplanować wszystkiego z góry, dlatego warto korzystać z mechanizmów pozwalających na szybką reakcję.

Dla mnie powyższe zasady są pewną podstawą wokół której możemy dalej rozwijać nasz proces wytwarzania oprogramowania. Agile nie odrzuca wszystkiego innego, z moich doświadczeń wynika że np. idealnie ze zwinnym wytwarzaniem oprogramowania sprawdza się stosowanie wykresów Gant’a czy ustalanie ścieżek krytycznych, albo stosowanie wzorów optymalizacyjnych dla szeregów produkcji. Dodając do tego Continous Improvement możemy osiągnąć na prawdę wiele, niemniej jednak należy pamiętać o tym by zapewnić sobie dobry start do wprowadzania zmian, ale o tym może innym razem.

A Ty co masz na myśli, gdy mówisz „Agile”?

Dodaj komentarz więcej...