Firmy z branży IT, szczególnie w momencie szybkiego wzrostu z małego przedsiębiorstwa do korporacji, stoją przed wyzwaniem i pytaniem: “jak efektywnie zorganizować pracę?”.
Przy gwałtownym wzroście nieformalne metody współpracy i posługiwanie się skrzynką pocztową do zlecenia zadań przestają działać. Rozwiązaniem jest wprowadzenie narzędzi wspierających.
Jest kilka różnych obszarów, w których przedsiębiorstwo organizuje swoją pracę:
- Definiowanie i zlecanie prac (wytwórczych i serwisowych);
- Gromadzenie i utrzymywanie wiedzy;
- Projektowanie i realizacja rozwiązań;
- Zarządzanie portfelem i projektami;
- Wsparcie produkcji.
Istnieje wiele metodyk adresujących przekrojowo proces wytwarzania, dla przykładu można wymienić V-model, Rational Unified Process, Scaled Agile Framework oraz ISO 12207, który jest raczej standardem niż metodyką.
Na rynku dostępne są również metodyki, które w różnym zakresie starają się wskazywać dobre praktyki w różnych aspektach pracy w IT, chociażby:
- PMI, PRINCE2 w zakresie zarządzania projektami i portfelem projektów;
- TOGAF w zakresie wytwarzania i zarządzania architekturą korporacyjną;
- ITIL w zakresie zarządzania utrzymaniem środowiska produkcyjnego i operacji;
- SCRUM w zakresie zarządzania developmentem;
Każda z wyżej wymienionych metodyk zakłada, że należy dostosować ją do potrzeb organizacji, chociaż niejednokrotnie dzieje się tak, że organizacja zaczyna pracować tak jak umie i tak jaj jej wygodnie – a potem nagina praktykę do jakiejś metodyki.
Niestety nie ma gotowych przepisów, które mówiłyby jak organizować proces wytwórczy w zakresie wytwarzania oprogramowania. Istniejące wzorce zawsze trzeba przystosować czy dostroić do specyficznych warunków organizacji. Metody pracy trzeba wypracować samemu, co często kończy się na kompromisach pomiędzy użytecznością, a ceną przy doborze narzędzi i procedur.
Ograniczenie przestojów oraz skrócenie czasu realizacji prac (czyli ograniczenie kosztów) jest często głównym celem dla większości organizacji. Przekłada się to na zapewnienie, żeby aktualna informacja była dostępna natychmiastowo tam gdzie jest potrzebna; by wiadomo było kto realizuje zadania oraz jaki jest postęp ich realizacji; również żeby było wiadomo, ile zadań jest realizowanych oraz kiedy będzie można przyjąć kolejne zadania.
Podstawowym wymaganiem dla narzędzi jest ich integracja, gdyż ręczne utrzymywanie spójności jest kosztowne, a brak natychmiastowej propagacji informacji skutkuje przestojami.
Niezależnie, czy wybierzemy jedną aplikacjęczy kilka, istotne jest by wspierały one następujące funkcje:
- Realizacja zadań i zgłoszeń (implementacja i testy);
- Wytwarzanie i utrzymywanie aktualnej dokumentacji (biznesowej, projektowej i systemowej);
- Rozwiązywanie zgłoszeń produkcyjnych i testowych;
- Zarządzanie wydaniami i wprowadzeniem zmian na systemy;
- Planowanie i raportowanie czasu pracy.
Poniżej przedstawiam poglądową architekturę dla typowego IT współpracującego z biznesem i zarządem.
Do zarządzania zadaniami można zastosować takie oprogramowanie jak Redmine, jako repozytorium kodu SVN czy nadal mniej popularny w środowiskach korporacyjnych GIT, a bazę wiedzy można oprzeć o Mediawiki lub Confluence’a. Oczywiście repozytorium kodu i architektury uzupełniane są przez developerów, analityków, testerów i architektów przez dedykowane oprogramowanie.
Istnieją pakiety komercyjne oferujące cały zestaw funkcji idealnie ze sobą współgrając, ale niestety trzeba za nie słono zapłacić, przykładem jest pakiet narzędzi od Atlassian lub IBM Jazz. Oczywiście ekosystem aplikacji wspierających pracę działu IT powinien być uzupełniony o narzędzia dedykowane do wytwarzania systemów czy zarządzania testami (do tego można używać np. HP Quality Center). Moim zdaniem częstym i poważnym błędem jest przyjmowanie założenia, że np. jak kupiliśmy sobie narzędzie do zarządzania zadaniami, to teraz będziemy tam robili wszystko, czyli zarządzali wymaganiami, zarządzali procesem testowania, zarządzali dostawcami, robli code review – niestety tak dobrze nie jest.
Realizacja zadań i zgłoszeń
Jedynym z możliwych podejść jest dekompozycja zadań i zgłoszeń na mniejsze zadania powiązane ze sobą. W hierarchii zadaniem głównym jest element określający projekt, problem lub program do realizacji, a zadania podrzędne odpowiadają głównym pracom w ramach procesu wytwarzania. Dla przykładu firmy zazwyczaj stosują procesy szacowania, analizy, projektowania, konstrukcji, testowania, wdrożenia i stabilizacji dla każdego powstającego oprogramowania. Nie oznacza to, że wytwarzanie musi być przeprowadzane w sposób kaskadowy dla całości zagadnienia, po prostu chodzi o to, że każdy kawałek oprogramowania przechodzi przez kolejne etapy, czasem może nawet przebiegające równolegle. Dla przykładu zadanie wprowadzenia nowej usługi w przedsiębiorstwie mogłoby zostać zdekomponowane na podzadania zgodnie z poniższym rozbiciem:
Uogólniając z punktu widzenia organizacji możemy rozpatrzeć następujące role użytkowników dla trzech poziomów:
Na temat zarządzania zadaniami pisaliśmy już na Trzeciej Kawie w artykule Jak nie zginąć w chaosie zadań?, gdzie główny nacisk został położony na zarządzanie własnymi zadaniami. Pozwolę sobie przytoczyć zdanie Stasia: „najważniejszym wymaganiem dla narzędzia (zarządzania zadaniami) jest prostota i intuicyjność obsługi – nakład na obsługę zadań powinien być jak najmniejszy”, z którym to zdaniem zgadzam się całkowicie. Praca specjalistów jest na tyle droga, że nie opłaca się utrzymywać skomplikowanej buchalterii, bo w tym czasie w jakim osoby zajmować się będą utrzymaniem aktualności rejestru zadań mogłyby rozwiązywać merytoryczne problemy.
Z punktu widzenia organizacji sprawa robi się trudna, bo zarządzający projektami chcieliby mieć natychmiastowy wgląd w to jaki jest postęp prac oraz jakie zadania obecnie znajdują się na ścieżce krytycznej, a to kosztuje czas raportowania.
Wytwarzanie i utrzymywanie aktualnej dokumentacji
Niewątpliwą zaletą jest umieszczanie dokumentacji on-line w postaci przeszukiwanych powiązanych ze sobą stron np. w oparciu o systemy wiki. O tym jak organizować dokumentację tak by była dostępna on-line opisywaliśmy już na Trzeciej Kawie w artykule Dokumentacja – od chaosu do bazy wiedzy. Bardzo ciekawe podejście, z jakim udało mi się zetknąć, było zintegrowanie wiki z repozytorium analizy i architektury (np. z narzędziem Sparx Enterprise Architect) tak, że na wiki automatycznie publikowane były diagramy i opisy w formie tabel dla określonego modelu i pakietu. Podejście takie pozwalało na ciągły dostęp do dokumentacji w najświeższej wersji bez koneiczności dodatkowego i zazwyczaj bardzo czasochłonnego procesu synchronizacji, czy generowania dokumentów.
Wprowadzenie repozytorium architektury, analiz i testów jest bardzo istotnym elementem w dziale IT. Informację przetwarza się nałatwiej gdy jest ustrukturalizowana, dlatego odejście od przypadkowego i dowolnego opisu systemów do repozytorium jest skokiem jakościowym jak przejście od manufaktury do produkcji.
Rozwiązywanie zgłoszeń produkcyjnych i testowych
Niezależnie od tego, czy błędy produkcyjne rozwiązuje dedykowany zespół, czy tez leży to w obowiązku ludzi rozwijających systemy, włączając dostawcę, to rejestrowanie błędów powinno odbywać się w jednym narzędziu, zarówno dla zgłaszanych problemów ze środowisk testowych, jak i produkcyjnych. Większość dostępnych pakietów komercyjnych i niekomercyjnych umożliwiających śledzenie zadań swój żywot rozpoczynało jako tzw. bugtracker-y czy issue trackery, dlatego ta funkcjonalność działa zazwyczaj bez zarzutu, natomiast problemem jest to, że narzędzia do śledzenia zadań zazwyczaj słabo nadają się do zarządzania testami, co wymusza dodatkową integrację w zakresie obsługi błędów.
Zarządzanie wydaniami i wprowadzaniem zmian na systemy
Funkcjonalność kwalifikująca kod do wdrożenia na produkcję w ramach wydania (potocznie z angielskiego zwany release). Do releasu wchodzą te zadania implementacyjne, które zakwalifikują się w ramach testów wydania. Oczywiście jeżeli nie wszystkie zadania implementacyjne pod danym zadaniem głównym uwzględnione w wydaniu, to zachodzi podejrzenie, że to zadanie główne nie jest jeszcze zakończone i nie można otworzyć szampana.
Planowanie i raportowanie czasu pracy
Zadania tworzy się prosto, jednak trzeba dostosować liczbę zadań do realizacji do możliwości organizacji. Koniecznym staje się określenie horyzontu planowania oraz alokacji czasu do realizacji zadań. Najlepiej jest jeżeli możemy przypisać osoby do zadań i czekać na efekty – jednak rzeczywistość bywa skomplikowana i często trzeba zmieniać plany. Scrum adresuje to w sposób prosty: jeżeli już coś robimy, to tego nie zmieniamy, a jak zmieniamy, to co zrobiliśmy odkładamy na bok. Podejście piękne, ale niestety nie do zaakceptowania przez wiele organizacji…
Nalezy pamiętać, że zgodnie z zasadą Heisenberga pomiar ma wpływ na wielkość mierzoną, dlatego nie warto zbyt restrykcyjne podchodzić do tego tematu. Wymaganie by pracowanicy raportowali minimum 40h tygodniowo na prace projektowe, zostanie przez raportujących na pewno spełnione, ale zaburzy to rzeczywisty obraz kosztów i rozkładu zajęć.
Podsumowanie
Inżynieria oprogramowania wymaga odpowiedniego wsparcia narzędzi, ale też dobrze określonych procesów. Nie opracować na potrzeby wytwarzania oprogramowania procesów określonych tak dobrze, jak procesy inżynierii produkcji, ale można nadać im pewne ramy, które w przypadku dużych organizacji są niezbędne. Wprowadzanie narzędzi i metod pracy oraz nieustanne ich ulepszanie powinno być tak samo istotnym działaniem w organizacji, jak inicjatywy, które koncentrują się na wdrażaniu nowych usług biznesowych pozwalających na osiągnięcie wysokiego stopnia konkurencyjności na rynku. Najistotniejszym wymaganiem dla wprowadzanych narzędzi jest automatyzacja i integracja, tak by nie poświęcać zbyt wiele czasu na ich obsługę.
Wszystko po to, by nie można było powiedzieć o dziale IT, że „szewc bez butów chodzi”.