Joanna bardzo sceptycznie podeszła do zakresu merytorycznego warsztatu. Tuż przed jego rozpoczęciem przekartkowała 120 stronicowy podręcznik i podzieliła się uwagą z jednym ze swoich współpracowników „ja to wszystko wiem”, „chyba wrócę do pracy”.
A jednak został została. Została do końca. Była bardzo aktywną uczestniczką kursu.
Muszę przyznać, że byłem zaskoczony, kiedy w końcowej sesji pytań i odpowiedzi padło z jej ust stwierdzenie - „nie widzę dużych różnic w stosunku do używanych dzisiaj przez nas narzędzi”, „może zobaczę je, jak sama spróbuję” (cytuję z pamięci).
Celem warsztatu nie była „ewangelizacja” technologii Microsoft. Nie było „łopatologicznego” wyłożenia zalet metodyki (MSF) i narzędzia (TFS).
Zwykle prowadząc cztero, czy pięciodniowy kurs tzw. sesja strategiczna „wdrażać czy nie?” jest jego ostatnim elementem. Tym razem kurs był dwudniowy, a jego kontynuacją będzie laboratorium przeprowadzone przez firmę trzecią …
Odpowiedziałem Joannie na postawiony problem - w czym - moim zdaniem tkwi siła metodyk i narzędzia. Poprzednio opowiadałem o tym na konferencjach w Polsce, Hiszpanii, na Łowie, w Estonii, czy na Litwie jak również na naukowych polskich i międzynarodowych konferencjach inżynierii oprogramowania.
Może warto przytoczyć tutaj 10 najważniejszych argumentów.
Zanim odpowiem na pytanie muszę ustalić terminologię:
VSTS - Visual Studio Team System (Devloper, Architect …) to dodatkowe narzędzia – rozszerzenie w stosunku do Visual Studio (2005, czy 2008) dla członków zespołu wypełniających odpowiednią w zespole role. Każda wersja VSTS zawiera w sobie Team Explorer, dzięki któremu użytkownik Visual Studio (VS), czy VSTS może korzystać z Team Foundation Server.
TFS - Team Foundation Server (2005, czy 2008) – serwer pozwalający na pracę zespołową - m. in zarządzanie projektem w oparciu o jednostki robocze (work items), udostępniający portal projektu, repozytorium kodu projektu, maszynę do tworzenia kodu wynikowego itd.
W czym tkwi siła metod pracy Microsoft opartych o TFS:
1. Zarządzanie projektem w dwu warstwach (poziomach) – budowanej użyteczności dla klienta (jednostki robocze typu requirements, czy scenario, QoS) i wykowanych zadań (tasks).
2. Śledzenie postępów w projekcie z dokładnością do drobnych zadań (aktywności) i wydarzeń (np. odrzucenie błędu przez dewelopera, który nie jest w stanie go zlokalizować).
3. Prostota raportowania stanu projektu (np. ilość aktywnych błędów, scenariusz do zbudowania, zadań do wykonania itd.).
4. Łatwy dostęp do indywidualnych raportów poprzez łatwy dostęp do „kostek” analitycznych hurtowni danych wydarzeń projektowych (np. z MS Excel 2008) i bieżących stanów jednostek roboczych.
5. Wersjonowanie kodu i wyszukiwanie różnic pomiędzy dowolnymi przekazaniami kodu do repozytorium (check in) przez deweloperów. Automatyzacja rejestracji zdarzeń z przekazaniem kodu (zamykanie zadań, scenariuszy, błędów wraz z poprawnym „build'em”).
6. Maszyna „build'ująca” (tworzenie kodu wynikowego) dająca codziennie rano testerom aktualny kod wynikowy (realizacja idei nocnych „builds”), czy pozwalająca na ciągłą itegrację (continus integration) – po każdym przekazaniu kodu do repozytorium (tylko TFS 2008)
7. Workflow pracy z jednostkami roboczymi – co powala na modelowanie procedur z weryfikacją działań przez inną osobę niż twórca (deweloper pisze kod, jego rezultaty sprawdza tester, czy deweloper poprawia błąd, zmienia jego status na poprawiony, ale o „zamknięciu” błędu decyduje tester).
8. Łatwość dostosowania szablonu używanej metodyki do potrzeb konkretnego zespołu (poprzez wykorzystanie narzędzi graficznych – tzw. TFS Power Tools). Możliwość wykorzystania wielu szablonów wewnątrz jednej organizacji.
9. Dostępne szablony przygotowane przez firmy trzecie, w tym 3 różne szablony dla metodyki SCRUM, szablon dla RUP itd. Niedoścignionym dla mnie wzorcem jest rozwiązanie australijskiej firmy Object Consulting, której szablon – Process MeNtor dostarcza 12 tzw. „map drogowych projektu” – od budowania internetowego portalu do zarządzanego procesowo projektu.
10. Możliwości szybkiego zamodelowania posiadanego przez konkretną organizację narzędzia. Przykładowo – każda poważna firma IT posiada (zwykle własne) narzędzie do zarządzania procesem poprawy błędów projektowych. Stworzenie odpowiedniej bazy błędów na serwerze TFS to przyporządkowanie pól do już istniejących plus dodanie brakujących pól. Zamodelowanie procesu pracy z błędami zajmuje zwykle 1-3 dni. I można stary system porzucić, a rozwój nowego modelu nie wymaga prac programistycznych.
Obiecałem, że będzie to 10 powodów. Na kolejne argumenty przyjdzie pora …
Może to, co wyżej przyda się nie tylko Joannie.
Brak komentarzy:
Prześlij komentarz