Manifest Agile – czyli co się pod tym kryje (część VI) – zarządzanie zmianą

To już ostatni artykuł z tego cyklu. W ramach poprzednich kilku omówiłem przeznaczenie manifestu zwinnego wytwarzania oprogramowania, zawiłości językowe dotyczące pierwszych trzech postulatów, nawiązując tym samym do tłumaczenia dostępnego publicznie jak i interpretacji poszczególnych postulatów.

W ramach tego artykułu postaram się wyjaśnić idee ostatniego postulatu oraz różnice pojawiające się pomiędzy oryginalnym tłumaczeniem, a moją propozycją.

Agile - odpowiadanie na zmiany

Odpowiadanie na zmiany ponad podążaniem za planem

Zacznijmy od zawiłości. W języku angielskim istnieją dwa słowa, które bardzo często są stosowane zastępczo: respondreact. Jak się okazuje oba te słowa mają ściśle określony kontekst użycia i inne nacechowanie emocjonalne.

W przypadku słowa react słownik Oxfordzki podaje taką definicję act in response to something; respond in a particular way. A bardziej psychologiczna interpretacja mówi: when people react, it seems to be defensive. Słowo respond ma zupełnie inne nacechowanie psychologiczne, to jest: responses contain reasoning. The difference may be this, responding is guided less by emotion and more by logic. Zaś słownik Oxfordzki podaje taką definicję: do something as a reaction to someone or something, react quickly or positively to a stimulus or treatment.

Chciałbym w tym miejscu zwrócić uwagę na to, że autorzy tego postulatu nie użyli słowa reacting tylko responding, dlatego też zastanawiam się, skąd wziął się u nich pomysł na użycie słowa reagowanie zamiast odpowiadanie.

Dla słowa reagować słownikowa definicja brzmi: zachowywać się lub postępować w określony sposób na jakąś sytuację, jakieś zjawisko lub zdarzenie, odpowiadać na bodźce. Dla słowa odpowiadać istnieje taka definicja: ustnie lub pisemnie dać komuś odpowiedź, słowem czynem lub w inny sposób zareagować na czyjeś słowa, zachowania itp., powodować jakiś stan lub proces.

Patrząc przez pryzmat doświadczenia, mogę śmiało powiedzieć, że odpowiadanie na zmiany jest tym, co jest bliższe idei twórców tego postulatu. Podczas wytwarzania oprogramowania zgodnie z metodami zwinnymi (np. Scrum), wielokrotnie mamy do czynienia z ekstremalnie szybko wprowadzanymi zmianami. Czasem są to zmieniające się potrzeby klienta, a czasem to nasze własne spostrzeżenia, które muszą być wdrożone natychmiastowo. Często deklaracje wykonania czegoś są „na gębę” i nie można się spodziewać ich sformalizowania, skoro kolejne wersje oprogramowania są wytwarzane w krótkich cyklach (np. tydzień). W tradycyjnym podejściu, gdyby pojawiło się żądanie zmiany (ang. change request) w wielu przypadkach trzeba by zebrać komitet sterujący (czyt. szefów wszystkich szefów), żeby zatwierdzili budżet.

Postulat ten nawiązuje do poprzednich trzech i jest kwintesencja całości. Odpowiadanie na zmiany to czasem odpisanie na mail, to czasem krytyka pomysłu klienta, to  czasem zgoda na coś ekstra lub inaczej. Ważne jest aby pamiętać, że plan choćby nie wiem jak doskonały jest niemożliwy do zrealizowania w 100% ponieważ bazuje on na estymacji, która z natury jest obarczona błędem (o metodach estymacji pisaliśmy w cyklu artykułów zaczynających się od „Metody estymacji – czyli jak określić ile czasu będzie trwał projekt cz. 1„).

Podczas podsumowania całego cyklu artykułów dotyczących Agile Manifesto, skuszę się o jedno stwierdzenie. Byłoby bardzo dobrze, gdyby ktoś kiedyś poświęcił czas i przygotował rzeczową pracę naukową o etymologii tego manifestu. Dodatkowo jako ‚ciekawostkę’ dodam, że wielu ludzi widziało stronę z manifestem ale niewiele osób zauważyło pierwszy link na tej stronie „Twelve Principles of Agile Software„, a warto tam zajrzeć :).

Wpis opublikowany w Dynamika Rozwoju BLOG i otagowany , , , przez .
Lukasz

O Lukasz

Absolwent wielu kierunków (Project Management, Inżyniera Oprogramowania, Informatyka Stosowana, Pedagogika), doktorant nauk o zarządzaniu na Uniwersytecie Ekonomicznym. Pracownik dużej międzynarodowej korporacji z wieloletnim doświadczeniem zdobytym na stanowiskach menadżerskich (Project Manager) i podczas pełnienia dodatkowych funkcji (Team Leader, Scrum Master, wewnętrzny trener trenerów). Członek Rady Dolnośląskiej Grupy IPMA (zastępca przewodniczącego), posiada szeroką wiedzę i kompetencje z obszaru zarządzania projektami, pracy zespołowej i rozwiązywania konfliktów - potwierdzone wieloma publikacjami i szeregiem certyfikatów (IPMA C/D, Scrum Master, ….). Aktywny zawodowo trener z wieloletnim doświadczeniem (setki przeszkolonych osób).

Dodaj komentarz