niedziela, 1 lipca 2007

Cel gry

Czytam aktutanie (po raz kolejny) książkę "Agile Software Development" Alistair'a Cockburn'a. Odkrywam za każdym razem coś nowego :-) Tym razem zaciekawił mnie fragment na wysokim poziomie abstrakcji dotyczący pojmowania procesu tworzenia oprogramowania jako gry. Dokładnie jako "zorientowanej na współpracę, ograniczonej zasobami gry inwencji i komunikacji". Gra ta ma charakteryzuje się oczywiście cechami, które mają wielki wpływ na to jaki jest najbardziej efektywny model "grania" w tą grę (po szczegóły odsyłam do książki). Ciekawsze jest to, że Alistair Cockburn zdefiniował cele gry. Dwa:

  1. Dostarczenie użytecznego, działającego oprogramowania (oczywistość)
  2. Zapewnienie najlepszego możliwego startu w kolejnej grze

Cel pierwszy jest chyba oczywisty. O co chodzi zaś z celem drugim? Kolejna gra to kolejny cykl rozwoju oprogramowania. Następna wersja, kolejna zmiana, kolejne dostosowanie do potrzeb klienta, ewentualnie nawet kolejne zadanie podejmowane przez firmę lub ten sam zespół ludzi. Celem jest takie przeprowadzenia aktualnej gry aby oprócz tego, że dostarczymy klientowi oprogramowanie jednocześnie możliwie najlepiej przygotować się do tworzenia kolejnej wersji tego samego lub innego produktu. Czy to nie jest oczywiste jak się o tym dłużej pomyśli? Przecież w znakomitej większości przypadków organizacja tworząca oprogramowanie nie istnieje tylko i wyłącznie w celu stworzenia tej jednej wersji produktu. Czas życia organizacji jest dużo dłuższy. W związku z tym jeżeli na dłuższą metę organizacja chce zapewnić sobie dobre perspektywy koniecznością staje się myślenie w kategoriach najlepszego przygotowania do przyszłych działań. Oczywiste, choć z moich obserwacji wynika, że w większości przypadków cel drugi nie jest brany w ogóle pod uwagę w realizacji projektów informatycznych.

Świadomość celu drugiego praktycznie rzutuje na większość decyzji podejmowanych w ramach zespołu projektowego. Patrząc się przez pryzmat obu celów zmienia się punkt optimum. To, co wydaje się optymalne z punktu widzenia dostarczenia szybko oprogramowania klientowi może stać w oczywistej sprzeczności z celem drugim. Na przykład użycie zamkniętej architektury. Na przykład zmuszenie programistów do pracy w nadgodzinach przez trzy miesiące z rzędu. Na przykład zaniechanie tworzenia dokumentacji, bo to strata czasu. Na przykład brak automatycznych testów, bo to się szybciej zrobi ręcznie. Takie decyzje może i sprawią, że nadgonimy z aktualnym projektem, ale czy na pewno zapewnią dobry start w kolejnym? Świadomość obu celów powinna spowodować odejście od szukania optimów lokalnych dla danego projektu a przenieść uwagę na optima globalne dla organizacji. To byłaby jakościowa zmiana dla wielu osób i zespołów. Czy wchodząc w projekt nie chcielibyście mieć wszystkiego przygotowanego na Wasze potrzeby? Każdy by chciał. A to przygotowanie jest zapewnione przez realizację celu drugiego.

Jedyny problem jaki widzę z praktycznym zastosowaniem tych zasad to mała mierzalność celu drugiego. Cel pierwszy da się zmierzyć bardzo prosto. Cel drugi nie ma zaś jasnych mierników, co może powodować, że w organizacjach nie znajdą zrozumienia decyzje podejmowane z perspektywy celu drugiego. Zostaną one zagłuszone przez żądania szybkiego dostarczenia efektu w postaci wypełnienia zobowiązań celu pierwszego (zdarzyło się Wam kiedyś dyskutować z działem sprzedaży?). To zaś będzie prowadzić do decyzji, które choć dzisiaj będą bardzo skuteczne mogą obniżyć konkurencyjność i możliwość "najlepszego startu" jutro.

3 komentarze:

Anonimowy pisze...

Czy nie jest to podobne do definicji "warsztatu zawodowego"? Jakby chwilę pomyśleć to cel drugi mimo mierzalności jest dosyć widoczny. Jest odpowiedzą na pytanie: co z tej gry wykorzystam w następnej.

Aga pisze...
Ten komentarz został usunięty przez autora.
Aga pisze...

Cel drugi nazwalabym eliminacja (lub minimalizacja) dlugu technologicznego. Odsylam do posta z 05.02.2009.