Super, udało się pozyskać nowe zlecenie! Ten fakt cieszy nie tylko poszczególne działy firmy, ale i również przełożonych. Po pierwszej fali radości, trzeba obrać drogę realizacji i rozpocząć pracę. Oczywiście wszyscy są pełni energii i zapału. Nikt nie myśli o porażce. Wszyscy są przekonani, że nowy projekt wniesie w życie team-u nowe doświadczenia i umocni reputację firmy. Jednak czy na pewno?

Dlaczego planowanie jest tak ważne?

Niezależnie od tego jaki cel jest obierany, nieodłącznym elementem przygotowań jest zaplanowanie całego przedsięwzięcia / wyprawy. Jeżeli np. cel stanowi atak na szczyt Mont Everest, z pewnością podczas przygotowań postawi się m.in. na trening wytrzymałościowy, zakup odpowiedniego sprzętu oraz sprawdzenie warunków pogodowych na trasie. Przeglądając mapę w poszukiwaniu szlaków natarcia, w zależności od kondycji i sprawności alpinisty, wybierze on taki, który w jego mniemaniu będzie możliwy do zdobycia.

Podobnie należy podchodzić do określania targetów w pracy. Przyjmując projekt do realizacji, nie można oceniać jego czasu bez dokładnego przeanalizowania założeń i określenia potrzeb Klienta.

Najgorszą z możliwych opcji jest tworzenie oprogramowania zgodnie z metodą wielkiego wybuchu, czyli zbyt pochopne wyciągnięcie wniosku o posiadaniu wystarczającej wiedzy na temat wszystkich aspektów założeń oraz przystąpienie do wytwarzania oprogramowania przy jednoczesnym wykluczeniu klienta z tego procesu.

Mimo iż zrozumiałym jest, że programiści najbardziej cenią sobie pracę w atmosferze absolutnego spokoju, to całkowite lub częściowe pozbawienie klienta możliwości wyrażenia opinii na temat stanu oraz przydatności zrealizowanej części oprogramowania, prowadzi wprost w ślepą uliczkę. Przez cały bowiem okres produkcji nie jest on wstanie zgłosić swoich uwag. Co więcej zespół przeświadczony o obraniu właściwego kursu, narażony jest na zboczenie ze szlaku wyznaczone przez potrzeby oraz aspiracje klienta i odbiorców, którym docelowo dedykowane jest oprogramowanie.

Konsekwencje takiego stanu rzeczy będą nie tylko nie do przewidzenia ale mogą wręcz doprowadzić obie strony do nieodwracalnej zapaści finansowej. Wszystkiego powodem będzie brak realnego planu działania oraz systematycznej weryfikacji bieżącego stanu realizacji pod kątem wymagań klienta.

Warto zatem, przed przystąpieniem do napisania pierwszej linii kodu, pochylić się głębiej nad przedmiotem zamówienia ze szwajcarską precyzją. Z pewnością dobrze zaplanowane przedsięwzięcie ma większą szansę powodzenia, co w prostej linii przekute zostanie na reputację wykonawcy.

Burza mózgów, czyli bujanie w obłokach

Niewielu jest klientów, którzy potrafią określić precyzyjnie swoje potrzeby. Co więcej, określając je, tak naprawdę określają potrzeby własnych klientów. W większości przypadków etap ten wymaga specjalistycznej wiedzy z zakresu np. designu, usability, marketingu elektronicznego czy chociażby psychologii zakupu. Nie można wymagać, że klient będzie posiadał te wszystkie umiejętności lub chociażby cząstkową wiedzę na ich temat. Ponieważ jego wiedza i umiejętności z pewnością są skromniejsze w porównaniu do wiedzy specjalistów, którym powierzyć zamierza realizację dzieła, często przedstawiona przez niego specyfikacja jest niekompletna lub chaotyczna. W pierwszej fazie rozważań nie jest on świadom konsekwencji płynących z wyboru pewnych rozwiązań a już na pewno nie będzie on potrafił przewidzieć ram czasowych i finansowych w odniesieniu do kontaminacji zadań i budżetu.

Biorąc powyższe pod uwagę, podejmując się realizacji zadania, należy być merytorycznym wsparciem dla klienta ale jednocześnie pozwolić mu na określenie priorytetów. Aby jednak mógł on je wyznaczyć należy przedstawić mu możliwie największy horyzont możliwości. W tym celu najlepiej zorganizować burzę mózgów. Ważnym jest by na tym etapie opisywać wszystkim wszystko językiem prostym, nie wprawiającym rozmówców w niezręczny stan niezrozumienia. Im więcej pomysłów zostanie zanotowanych, tym większa szansa, że osiągniemy jakość, której oczekuje klient. Ponieważ dla zamawiającego oddanie oprogramowania do użytku zaczyna się z chwilą zainteresowania się nim przez odbiorców docelowych, o ile nie ma przeciwwskazań, należy pozwolić tej grupie na tym etapie również zabrać głos. Dopiero pełne spektrum założeń i przedstawionych możliwości oraz dróg rozwoju, zweryfikowanych z klientem pod kątem luk funkcjonalnych, może stać się punktem wyjścia do określenia priorytetów.

Szacowanie czasu i określenie priorytetów

Na początku, gdy wszystkie możliwości nie zostały wyłożone na stół łatwo jest generalizować i spłycać wnioski. Jednak, gdy pełen obraz sytuacji w jakiej został postawiony team ukazuje realne ramy założeń, otwiera on oczy ze zdziwienia a realizacja staje się bardziej skomplikowana. Już pierwsze spojrzenie bowiem rodzi w głowie widmo długiej i żmudnej pracy.

Wyobrażenie to przekute na wstępne szacunki czasowe wyrażone w dniach, pozwoli klientowi na określenie grupy funkcjonalności podstawowych, które wejdą w skład pierwszego wydania oprogramowania. Ważnym jest aby już we wstępnej fazie określone założenia i tzw. opowieści użytkowników wstępnie przekuć na zadania. Warto również wyliczając szacunkowy czas wziąć pod uwagę potencjalną efektywność pracy zespołu tj. tzw. prędkość. Zmienna ta ulega doprecyzowywaniu przez cały okres trwania projektu, przy czym początkowo można bezpiecznie wyznaczyć ją na poziomie 0,7 (max 1). Oznacza to, że w przedziale 10 dni roboczych średnio 7 z nich będzie czasem produktywnym. Przy określaniu tzw. deadline’u , tj. tzw. granicy czasu jaki zespół otrzymuje na realizację, nie można zapomnieć o dniach wolnych od pracy, prywatnym czasie poszczególnych członków zespołu czy chociażby o czynnikach technicznych takich jak tworzenie środowiska pracy, systemu backupów, konfiguracji repozytorium, wykrywania i naprawy błędów etc. W czas ten należy wliczyć również ten potrzebny na udostępnienie wydania oprogramowania. Szacuje się, że na 30 dni kalendarzowych, 20 dni jest dniami roboczymi a zatem 15 dni przypada na efektywną pracę!

Każdy dąży na rynku do tego by przekonać klienta, że jego oferta jest najlepsza a konkurencyjność jest celem stałym każdego biznesu. Etap ten jednak decyduje tak naprawdę o powodzeniu lub klapie całego przedsięwzięcia a więc i reputacji wykonawcy. Oznacza to, że nie można zaniżać ani zawyżać znacznie szacunków. Priorytety powinny być określane na podstawie realnych ram czasowych jakie są konieczne do realizacji określonych założeń.

Dla określenia priorytetów należy używać skali od 10 (najwyższy priorytet) do 100. Przy czym warto poprosić klienta by używał do tego celu wielokrotności liczby 10. Pozwoli to na wprowadzenie w kolejnych etapach priorytetów roboczych o wielkości mieszczącej się pomiędzy wielokrotnościami liczby 10, w celu segregacji zadań wewnątrz grupy priorytetowej. Używanie też tej metody pozwoli na spojrzenie na całość założeń przez pryzmat grup.

Jeśli nie można znaleźć porozumienia pomiędzy czasem jaki jest konieczny do realizacji a czasem i budżetem posiadanym przez klienta lepiej pozwolić przejąć konkurencji odpowiedzialność za projekt, niż narazić obie firmy na stratę czasu i pieniędzy.

Iteracje, czyli bierzemy się za realizację założeń!

Skoro cel został już określony, a team nie ma więcej wątpliwości ani pytań, pozostaje już tylko zabrać się za pisanie kodu. Nie można jednak zapominać, że metoda wielkiego wybuchu to pułapka! Aby uniknąć tych sideł należy konfrontować poszczególne wersje oprogramowania z klientem, w celu korygowania „lotu twórczego”.

Poszczególne wersje oprogramowania będą miały sens, gdy wniosą do całości chociażby jedną sprawną i kompletną funkcjonalność. Biorąc więc pod uwagę określone przez klienta priorytety można podzielić wszystkie funkcjonalności na grupy, których indywidualna realizacja nie powinna przekroczyć 20 dni roboczych. Jeśli poszczególne funkcjonalności wymagają więcej czasu można pomyśleć o dołączeniu do teamu kolejnej osoby. I tak 40 dni przydzielone do 2 osób można wykonać wykorzystując połowę tego czasu ale należy pamiętać, że są to wciąż 40 dni i tak powinny być rozliczane.

Na zakończeniu każdej iteracji powinna być sprawdzana efektywność zespołu, która była wykorzystywana na początku do obliczenia szacunkowego czasu realizacji. Stała aktualizacja tej zmiennej pozwoli na doprecyzowanie szacunkowego czasu realizacji kolejnych iteracji. Należy również przy określaniu nowej wersji oprogramowania skonsultować ją z klientem aby potwierdzić jej zgodność z oczekiwaniami oraz określić ile zadań zostało już wykonanych aby mieć stałą kontrolę nad tym co się dzieje w projekcie.

Tak naprawdę aby dokonać tego nie potrzebujemy zmyślnego oprogramowania, wystarczy zwykła tablica a na niej tabela z trzema kolumnami:

  1. TO DO – spis zadań jakie musimy wykonać
  2. IN PROGRESS – spis zadań w trakcie realizacji
  3. CLOSED – spis zadań zamkniętych

Kolumn może być więcej ale te trzy stanowią podstawę zarządzania pracą zespołu. W przypadku większych realizacji można pokusić się jeszcze o kolumny związane z procesem testowania oprogramowania, jeżeli za testy odpowiada inna osoba lub team.

Z pewnością może się też przydarzyć sytuacja, w której klient nagle oświecony błyskotliwym pomysłem lub potrzebą zrealizowania nagłej prezentacji przed zarządem firmy rozmyje nasze plany i założenia organizacyjne. Wówczas może pojawić się problem z osiągnięciem pierwotnego terminu oddania iteracji klientowi do testu. Można tą sytuację rozwiązać na dwa sposoby. Pierwszym z nich jest przeorganizowanie zadań tak by uwzględnić czas potrzebny na dołączenie nowego zadania. Jeśli jest to jednak absolutnie niemożliwe i istnieje ryzyko przekroczenia granicy deadline’u to wówczas klient musi mieć świadomość tego, że wprowadzając do harmonogramu nowe założenie/zadanie wydłużą tym samym czas realizacji. Pamiętać należy kto jest decydentem czyt. klientem :-) i kto płaci za realizację określonych założeń i zadań.

Nie każde zadanie jest kluczowe!

Podczas rozbijania założeń na poszczególne zadania, które będą przypisywane w następnej kolejności konkretnym osobom, nie można zapominać o tym, że zbyt duża ilość zadań w obrębie poszczególnych funkcjonalności, może doprowadzić do znacznego przesunięcia się oddania całości projektu. Aby tego uniknąć należy zastosować podobną technikę, jak w przypadku wyznaczania priorytetów założeń. Najpierw wyznacza się te zadania, których realizacja jest absolutnie konieczna dla poprawności działania określonej funkcjonalności. Jeśli zatem celem jest stworzenie galerii zdjęć, z pewnością podstawowym zadaniem będzie umożliwienie uploadu fotografii. Ocenianie stanowi dodatkowy bajer.

Po wypunktowaniu wszystkich zadań podstawowych i oszacowaniu ich czasu, jeżeli suma jest mniejsza od całkowitego szacunku realizacji założenia, można dodać zadania dodatkowe, uatrakcyjniające końcowy efekt działania funkcjonalności. Na tym etapie, jak i na każdym innym, należy zachować umiar. Musimy zadbać o to by efekt nie był zbytnio skromny ale i nie doszło do przerostu formy nad treścią.

Stand-up, praktyczne narzędzie podczas trwania iteracji

Ponieważ podstawowym zadaniem iteracji jest porządkować prace wg priorytetów, ale i również wychwytywać ewentualne odchylenia kursu od pierwotnie wyznaczonego, koniecznym jest wykorzystywanie narzędzi werbalnych. Tablica niewątpliwie organizuje pracę, ale jest tylko bezdusznym zapisem. I nawet jeśli będzie zawierać elementy humorystyczne, w postaci ciekawych magnesów z buśkami lub kolorowych pinesek z flagami, to i tak będzie tylko zapisem postępów.

Pracując natomiast w zespole ważnym jest by project manager miał werbalny kontakt z poszczególnymi osobami. Ludzie nie są maszynami i czasem, będąc np. pod wpływem silnego stresu, nie potrafią znaleźć prostych rozwiązań. 5min. rozmowa na temat bieżących zadań może wnieść w projekt nowe spojrzenie.

Stand-up, jest jednym z takich narzędzi. Poświęcenie 15 min. na rozmowę o tematach bieżących, problemach i pomysłach, jest w stanie czasem skrócić czas pracy lub przeorganizować zadania w przypadku stwierdzenia przekroczenia bariery terminu zakończenia iteracji, co pozwoli osiągnąć podstawowe założenie tj. dostarczyć funkcjonalny projekt zgodny z założeniami i na czas.

SRP, DRY…

Kiedy już wszystko jest zaplanowane a prace nad projektem postępują w najlepsze, nie można zapomnieć o jeszcze jednym ważnym aspekcie. Każda osoba pracująca w team’ie ma obowiązek również systematyzować powierzone jej zadania. W przypadku programistów muszą oni dbać, o to by wersje plików i poszczególnych elementów kodu były wersyfikowane oraz by panował porządek w strukturze plików, nazewnictwie klas itd.

Warto również pamiętać o dwóch zasadach wspierających te zadania. Pierwszą z nich jest metoda SRP, której celem jest pisanie kodu tak by każdy obiekt miał tylko jedno zadanie. Pozwala to w trakcie pracy łatwo dotrzeć do metod i modeli wykonujących określone zadania.

Inną metodą, w zasadzie rozwijającą SRP, jest DRY. Stosując się do niej zadbamy o to by kod nie pęczniał bez powodu. W przypadku dużych aplikacji ilość plików czasami liczy się w tysiącach, a same linie kodu – w milionach. Każda niepotrzebna linia kodu zapisana w ciągu dnia, daje 20 linii w przeciągu iteracji. W przypadku trzyosobowego teamu jest to już 60 linii i to w przypadku tylko jednego zadania! Dublując całe metody w różnych kontrolerach, sprawiamy, że linii tych przybywa w bardzo szybkim tempie. Wprowadza to niepotrzebny chaos i utrudnia rozwój oprogramowania. Staje się on również bardziej narażony na wystąpienie błędu krytycznego.

Testy

Niezależnie od tego ile osób po drodze testowało oprogramowanie podczas poszczególnych iteracji, nie można zapominać o testach końcowych. Po zakończeniu wszystkich iteracji a przed wypuszczeniem wersji stabilnej oprogramowania, trzeba jeszcze raz wszystko przejrzeć. Najlepiej by testowanie powierzyć nie tylko zespołowi technicznemu, ale i zwykłym użytkownikom. W tym celu można rozpisać kilka scenariuszy i poprosić ich o ich wykonanie. Otrzymamy tym samym konkretną informację zwrotną dotyczącą użyteczności wyprodukowanego oprogramowania. Jeśli coś użytkownikom sprawia trudność i nie jest wystarczająco intuicyjne, warto to zmienić przed określeniem wydania 1.0, w przeciwnym razie wielki start nowego przedsięwzięcia, może okazać się wielką i nieodwracalną pomyłką a zrażeni rozwiązaniami użytkownicy nie zainteresują się ponownie tematem.