Tuesday, May 27, 2008

Klient, który wie, czego chce


Powszechnie przyjętym dogmatem wśród analityków, projektantów, architektów, deweloperów i innych osób biorących udział w cyklu wytwarzania oprogramowania jest, że Klient nie wie czego chce. Sytuację rodem z głuchego telefonu przedstawia rysunek (http://philhord.com/phord/wp-content/development.jpg), w którym klient opisuje swoje oczekiwania. Następnie trafiają one do poszczególnych osób zajmujących się tworzeniem systemu i w efekcie biedny klient dostaje coś, co drastycznie mija się z jego potrzebami.

Jak to zatem jest z owym klientem? Czy rzeczywiście nie ma on bladego pojęcia czego naprawdę chce? Jak wiadomo: punkt widzenia zależy od punktu siedzenia. Programiści wiedzą, że klient nie ma bladego pojęcia o swoich potrzebach, natomiast klienci są absolutnie przekonani, że deweloperzy dają im coś innego niż zostało to uzgodnione. Jaka jest więc prawda? Hmmm, żyję na świecie wystarczająco długo, by wiedzieć że każdy ma swoją własną prawdę. Jednakże twierdzę, że klient dokładnie wie, czego chce. Z doświadczenia wiem, że:

  1. Klient wie, czego chce – aktualne oczekiwania wobec systemu wyniknęły z problemów, które doskwierają klientowi w pracy, zatem chce on je rozwiązać i ma na to konkretny pomysł. Klient (metaforycznie rzecz ujmując) jest ekspertem z dziedziny problemu, więc tym bardziej wie, czego chce.

  2. Klient nie zawsze wie, czego potrzebuje – wynika to z jego niewielkiej wiedzy o możliwych technologiach. Często klient sugeruje rozwiązanie (na miarę swojej wiedzy), gdy tym czasem powinien zatrzymać się na sformułowaniu problemu i oczekiwanych rezultatów.

  3. Klient często nie uświadamia sobie konsekwencji własnych oczekiwań – jest to bolesne zwłaszcza, gdy prosi się nas o dodatkową funkcjonalność w systemie.


Przyczyna rozmijania się oczekiwań klient z rezultatem prac programistów koncentruje się wokół następujących faktów:

  1. Klient myśli procesowo – ma bardzo konkretne pomysły na sposób pracy z systemem. Potrafi określić warunki początkowe dla danego procesu oraz określić jego rezultat.

  2. Projektant myśli strukturalnie – porusza się w przestrzeni baz danych, tabel, klas, obiektów. Niejednokrotnie już podczas rozmowy z klientem myśli o implementacji. Z tego względu częste zmiany w wymaganiach oraz modyfikacje sposobów pracy z systemem, które klientowi przychodzą niezwykle łatwo, u projektanta powodują frustrację.


Mit o niewiedzy klienta nt. własnych oczekiwań bierze się powyższych różnić w myśleniu i analizowaniu informacji.

W swojej pracy wykorzystuję następujące praktyki pomagające w ustaleniu potrzeb klienta:

  1. Opisywanie cyklu pracy z systemem – tworzę zestaw procesów, które opisują co użytkownik może zrobić w systemie. Jeden proces to jedna konkretna rzecz, np.: wykonanie przelewu, zalogowanie, wygenerowanie raportu

  2. Rysowanie z klientem ekrany systemu i zaznaczanie przepływu sterowania pomiędzy nimi – puryści mówią, że tym powinien zajmować się projektant UI, natomiast do definiowania wymagań służą UML use cases. Cóż , nie spotkałem jeszcze klienta, który miałby ochotę uczyć się nowych symboli (nawet jeśli jest ich kilka), aby definiować swoje wymagania. Klient doświadcza systemu poprzez to co widzi – ekrany.

  3. Pilnowanie, aby klient precyzował jaki efekt chce uzyskać – klient jest od tego, aby wskazać problem i określić oczekiwane rezultaty. Od rozwiązywania zadania jestem ja. Dobrze jeśli klient może udzielić rad odnośnie implementacji, jednak niekontrolowane mieszanie się tych odpowiedzialności nie raz zapędziło mnie w kozi róg.

  4. Skłanianie klienta do przewidywania konsekwencji swoich oczekiwańduże korzyści przynosi to przy rozbudowanych systemach. Niestety klient patrzy lokalnie na system – skupia się na aktualnym problemie i nie ma wizji całości. Prowadzi to łatania dziur, dodawania funkcyjnie zależnych od siebie usług do systemu i ogólnego bałaganu. Prowokowanie klienta do globalnego spojrzenia na system i przewidywania globalnych konsekwencji swoich oczekiwań ma następujące zalety:

    • ulepszany system jest traktowany jako całość

    • unika się dublowania funkcjonalności

    • czasem okazuje się, że poprawa komfortu pracy o 5% nie jest warta wysiłku programistów


Monday, May 19, 2008

Ewolucja Agile


Metodyki z nurtu Agile nazywane są ostatnio nowoczesnym podejściem do programowania. Zdobywają one coraz większą popularność dzięki swojej skuteczności i przestępności dla klienta. W tym artykule chciałbym zastanowić się, czy podejście Agile jest tym oczekiwanym, „prawie idealnym”, sposobem na wytwarzanie oprogramowania.

Lekkie podejście do programowania

W odległej historii branży IT, projektanci oprogramowania zmęczeni wymogami popularnych wówczas metodyk prowadzenia projektów programistycznych, postanowili pozbyć się ciążącego balastu przeszłości. Doszli do wniosku, że wytwarzanie oprogramowania powinno przebiegać szybciej, płynniej, efektywniej, że powinno być bardziej otwarte na klienta i, co za tym idzie, na zmianę jego oczekiwań. Słowem: nowa metodyka powinna w optymalny sposób zmierzać do usatysfakcjonowania sponsora projektu, użytkownika i programistów. Efektem tych przemyśleć był Manifest Agile.

W metodykach z nurtu Agile (np.: eXtreme Programming, Scrum) oprogramowanie tworzy się przyrostowo. W krótkich iteracjach implementuje się kolejne funkcjonalności systemu. Użytkownik, przynajmniej w założeniu, jest cały czas dostępny i może podjąć wiążące decyzje dotyczące kierunku rozwoju projektu.

Lekkie metodyki są ściśle zorientowane na jak najlepszą komunikację w zespole (przypominam, że zespół stanowią programiści wraz z klientem). Poleganie na relacja pociąga za sobą rezygnację z formalizmu. Ogranicza się tworzenie produktów ubocznych tak bardzo jak jest to możliwe bez szkody dla projektu. Mówiąc o produktach ubocznych mam na myśli: dokumentację projektu, podręczniki użytkownika, biblioteki programistyczne, itp.

Granice Agile

Na podstawie tego, co zostało już wyżej napisane rodzi się pytanie: czy Agile jest ukoronowaniem ewolucji inżynierii oprogramowania? Moim zdaniem jest etapem pośrednim. Zniechęcenie tradycyjnymi metodykami spowodowało „huraoptymistyczny” odwrót w stronę metodyk lekkich. Mniej dokumentacji, mniej wymagań formalnych, mniej pracy – być może myśleli programiści. Takie rozumowanie nie jest zgodne z prawdą. Programowanie w Agile jest równie (jeśli nie bardziej) wymagające co programowanie w metodykach tradycyjnych. Narzuca ono na członków zespołu dość dużą dyscyplinę. Dzięki krótkim iteracjom, które absolutnie muszą zakończyć się konkretnym (czytaj: widocznym dla użytkownika) efektem nie ma miejsca na zajmowanie się mało istotnymi, lecz interesującymi, miejscami w systemie. Postępy pracy monitorowane są z dokładnością do jednego osobodnia.

Wyobraźmy sobie system zarządzania siecią elektrowni stworzony przez zespół pracujący według wytycznych Agile. System taki można nazwać dużym systemem informatycznym. Z pewnością będzie on rozwijany i modyfikowany przez lata. Co najważniejsze, ze względu na problematykę, wymaga dokładnej specyfikacji. Tego typu systemy są poza zasięgiem zainteresowania lekkich metodyk. Przedsięwzięcia informatyczne wspomnianego kalibru wymagają takiej metodyki prowadzenia projektu, która precyzyjnie definiuje każdy element procesu wytwarzania oprogramowania (np. metodyka RUP). Stosowanie twardej metodyki jest konieczne ze względu na skalę i potencjalny czas trwania projektu. Ma ona za zadanie zapewnić bezpieczeństwo przedsięwzięcia oraz osiągnięcie postawionych celów.

Podsumowując zakres stosowalności metodyk Agile można powiedzieć, że świetnie nadają się do realizowania małych i średnich projektów programistycznych o relatywnie krótkim czasie wykonania, np.: serwisy internetowe lub oprogramowanie dedykowane specyficznym potrzebom klientów. Nie bez znaczenia dla skuteczności metodyki jest ilość osób biorących udział w pracach. Powyżej 12 osób Agile przestaje być lekką metodyką, a staje się metodyką chaotyczną.

Metodyka „Adaptable Process

Obszar dużych i długotrwałych projektów programistycznych jeszcze nie został zdominowany przez nurt Agile. Sądzę, że nie stanie się to aż do chwili, gdy zwinna metodyka zapewni wysoki poziom kontroli prac nad projektem w każdym momencie jego trwania, przy jednoczesnym zachowaniu lekkości. Taką metodykę można by oprzeć z jednej strony na jednej z implementacji Agile, z drugiej na twardej metodyce o ściśle zdefiniowanym procesie realizowania projektu. Na własny użytek nazwałem taką metodykę Adaptable Process. Wyobrażam ją sobie jako proces, który może być dopasowywany do zmieniających się wymagań klienta. Można pokusić się o wskazanie kryteriów, które powinna spełniać metodyka Adaptable Process, np.:

  1. Posiada zdefiniowany proces wytwarzania oprogramowania. Każdy element procesu ma określone kryteria wejścia i wyjścia.

  2. Umożliwia szybką reakcję na zmianę oczekiwań klienta.

  3. Pozwala utrzymać wysoki poziom kontroli prac nad projektem – w każdym momencie (nawet po zakończeniu projektu) wiadomo z jakiego powodu podjęte zostały określone decyzje w projekcie.

  4. Angażuje do pracy klienta/użytkownika.

  5. Angażuje programistę do prac projektowych – nie wydziela osobnych ról: projektanta i programisty.

  6. Definiuje standardy pracy programisty np. jakość kodu, pokrycie kodu testami, technika programowania.

  7. Umożliwia zespołowi pracę w rozsądnym tempie i przez rozsądną ilość godzin w tygodniu...

Jeśli chodzi o inżynierię oprogramowania, z pewnością jeszcze długo nie zostanie wypowiedziane ostatnie słowo. Nowe wyzwania, które przed nią staną, sprowokują specjalistów do stworzenia nowych kreatywnych podejść. Dzięki temu następuje rozwój i możliwe coraz lepsze spełnianie oczekiwań klientów.


Artykuł ukazał się w kwietniowym numerze czasopisma DDI, http://ddinformatyku.pl