Scrum i Team Foundation Server cz.4 - Tworzymy projekt

W poprzednich wpisach opisałem ogólne zasady metodyki Scrum, przedstawiłem sposób instalacji i konfiguracji - TFS. W tym wpisie pokażę podstawowe zasady jak połączyć teorię z praktyką. Podobnie jak w poprzednich wpisach bazował będę na Team Foundation Server 11 DP, konieczne również będzie Visual Studio 11 DP.

Załóżmy, że chcemy wytworzyć grę komputerową - One Card Master. Gra ta będzie niczym innym niż uproszczoną wersją gry w wojnę. Każdy z graczy otrzymuje po jednej karcie - wygrywa osoba, która ma największą kartę.

 

1. Połączenie z TFS

Uruchommy Visual Studio. Posiada ona specjalną sekcję odpowiedzialną za elementy zarządzania projektem. Jeżeli nie jesteśmy połączeni widzimy tylko jedną opcję - "Connect to Team Foundation Server", po połączeniu pojawi się ich więcej. Wybieramy opcję połączenia.

Ukaże nam się okno wyboru serwera, z którym chcemy się połączyć. Ponieważ jest to nasze pierwsze połączenie lista wyboru jest pusta.

Naciskamy przycisk "Servers" by zdefiniować połączenie. 

Ponieważ chcemy dodać nowe połączenie naciskamy przycisk "Add"

W pole na górze wpisujemy nazwę (lub adres) naszego serwera - w moim przypadku jest to "win-mpmq6e2dm0c". Naciskamy "OK" i w oknie wyboru serwera "Close".

Teraz w oknie wyboru serwera w liście rozwijalnej powinniśmy zobaczyć nasz serwer. Wybieramy go i naciskamy przycisk "Connect". Zostaniemy poproszeni o dane autoryzacyjne - podajmy dane administratora serwera.


2. Utworzenie projektu


Jesteśmy już połączeni z serwerem, możemy przejść zatem do utworzenia naszego projektu.
Do zarządzania projektem służy "Team Explorer". Można go włączyć poprzez Menu=>View=>Team Explorer.

Aby utworzyć nowy projekt naciskamy "Create New Team Project".

Wpisujemy nazwę naszego projektu i ewentualnie opis i kilkamy "Next".

 

Team Foundation Server pozwala na definiowanie i używanie szablonów projektów. W ich obrębie można m.in. definiować typy zadań, przepływy między nimi. TFS dostarcza od razu kilka z nich oraz pozwala na pobranie innych z MSDN. Ponieważ chcemy prowadzić nasz projekt przy pomocy metodyki Scrum, wybieramy szablon "Microsoft Visual Studio Scrum 2.0 - Preview 1" i naciskamy przycisk "Finish". Nastąpi teraz proces konfiguracji nowego projektu, po jego pomyślnym zakończeniu naciskamy przycisk "Close".
Po dodaniu projektu Visual Studio automatycznie połączy nas z nim - widoczne to będzie od razu po wyglądzie menu Team Explorera.

3. Utworzenie zespołu

Podobnie jak w filmach typu "Parszywa dwunastka", czy "7 wspaniałych" pierwszym krokiem w konfiguracji naszego projektu jest utworzenie zespołu. 

Konta w TFS powiązane są z kontami systemowymi. Możemy tego dokonać poprzez systemowe okno zarządzania komputerem (dostępne przez Start => All Programs => Administrative Tools=> Computer Management).

Dodajemy kilku "Janów Kowalskich" w celach testowych i zamykamy okno.


TFS przy konfiguracji serwera tworzy bardzo przydatną rzecz jaką jest strona pozwalająca na zdalny do niego dostęp. Pozwala ona w wygodny sposób zarządzać zadaniami, użytkownikami i procesami projektu. Dalszej konfiguracji będziemy dokonywać przy jego pomocy. Aby się do niej dostać naciskamy "Web Access" w Team Explorerze.

Domyślnie została utworzona grupa projektowa dla naszego projektu. Aby dodać do niej inne osoby klikamy na "My Team" oraz w kolejnym ekranie przycisk "Administration" (znajdujący się w prawym górnym rogu).

Wchodzimy do sekcji "members", w liście rozwijalnej "Actions" wybieramy "Manage Team Membership".

Aby dodać użytkownika naciskamy przycisk "add members". 

W pole wpisujemy użytkownika, którego chcemy dodać, naciskamy "check name", a następnie "Save Changes".


Należy dodać jeszcze naszą grupę projektową do grupy uprawnień pozwalającej na dostęp do projektu i działanie na nim. Dokonujemy tego naciskając link z  nazwą naszego projektu znajdujący się w górnym menu strony.

Przechodzimy do zakładki "project groups" i wybieramy grupę uczestników projektu - "contributors".

W sekcji "Group membership" naciskamy przycisk "manage membership". W znanym nam już oknie wybieramy "add tfs group" i z listy wybieralnej bierzemy grupę [One Card Master]\My Team. Dzięki temu, każdy nowy użytkownik, którego dołączymy do zespołu projektowego automatycznie nabędzie stosowne uprawnienia.


4. Przygotowania do pierwszego sprintu


Mając wybrany i utworzony zespół możemy przystąpić do planowania projektu. Zgodnie z metodyką Scrum będziemy go dzielić na Sprinty oraz pomocniczo grupować je w Release'y. Grupowanie takie jest przydatne z tego względu, że pozwala na lepszą motywację, grupowanie faz oddawania projektu klientowi (np. jeden release to utworzenie konkretnego modułu). Tak jak wspomniałem we wcześniejszym artykule długość Sprintu być w przedziale 2-4 tygodnie (z tym, że każdy Sprint powinien trwać tyle samo). Liczba sprintów w Releasie też jest kwestią ustaleń.
Dostęp do Sprintów oraz Release'ów znajduje się w sekcji Iterations.

Jak widać zostały utworzone 4 releasy, każdy po 6 sprintów. Do celów testowych tak dużo nie jest nam potrzebne. Usuńmy tak elementy by został nam jeden Release składający się z 4 Sprintów.

Każdy ze sprintów będzie trwał 2 tygodnie. Dobrą zasadą jest od razu zaplanowanie dat startu i końca kolejnych sprintów. Efekt powinie wyglądać podobnie jak na poniższym screenie:

Zwykle planując projekt dzielimy zadania na grupy np. wg biznesowych zasad (np. modułami) lub programistycznych kategorii (np. baza danych, serwer aplikacji, klient). Takie grupowanie można też dokonać w TFS poprzez zakładkę "areas".

Ja utworzyłem 3 zgodnie z planowanymi modułami:
- Administracja
- Ekran Gry
- Panel użytkownika
Oczywiście grupy można zagnieżdżać jeszcze głębiej, nie musi to być płaska struktura jak w tym przykładzie.


5. Planowanie zadań


Zadania planujemy poprzez zakładkę "backlog" projektu. Wychodzimy z administracji (przez link "Exit administration) i przechodzimy do niej.

W TFS przyjęto, że zadania grupowane są w historie użytkownika (Product Backlog Item, Bug) opisujące konkretny przypadek do zrealizowania. Gdy uznamy, że chcemy, żeby była realizowana powinniśmy przypisać do niej co najmniej jedno zadanie. Jest to odzwierciedlenie standardowego procesu tworzenia systemów informatycznych. Jako programiści zwykle dostajemy opis zadania w postaci przepływu biznesowego. Musimy wtedy zwykle dokonać zmian na bazie, dodać metody na serwisie i oprogramować klienta. 


Historię użytkownika (PBI) dodajemy poprzez przycisk "Add".

Posiada ono następujące główne elementy:
- Assigned To - osoba odpowiedzialna za realizację historii użytkownika
- Status - aktualny status zadania
- Reason - powód dokonania akcji
- Effort - wysiłek, który należy wykonać aby skończyć to PBI. Wyrażone to jest w story pointach (jaki czas ma jeden story point jest kwestią ustalenia w projekcie)
- Business Value - jest to wartość, jaką wniesie ta historia użytkownika do projektu
- Area - grupa zadań, do którego zalicza się PBI


Od razu przy dodawaniu historii użytkownika można zdefiniować zadania do niego. Można tego dokonać przechodząc do zakładki "Tasks" i naciśnięcie przycisku "New".

Zadanie posiada m.in. pola:
- Assigned To - użytkownik, do którego zostało przypisane zadanie
- State - aktualny status zadania
- Reason - powód dokonywanej akcji
- Blocked - czy zadanie jest zablokowane (nie powinno być aktualnie robione)
- Description - opis
- Remaining Work - effor pozostały do zakończenia zadania
- Backlog Priority - priorytet zadania
- Activity - rodzaj czynności wykonywanej w zadaniu (np. Development, Documentation)
- Area - grupa zadań, do których zalicza się ten task


Po dodaniu PBI i zadań w widoku rejestru produktu (backlog) pojawi się nowy wpis.


6. Realizacja sprintu


Zarządzanie realizacją sprintu można zobaczyć w zakładce "board".

Na tym ekranie widać wszystkie historie użytkownika oraz ich zadania w obrębie aktualnego sprintu. 
Tablica (dashboard) jest klasycznym Scrumowym widokiem. Zadania podzielone są na trzy grupy:
- To Do - nie rozpoczęte,
- In Progress - w trakcie robienia,
- Done - skończone.
W prostocie tego widoku tkwi jego siła. Widać na nim dokładnie, które zadania zostały już rozpoczęte, kto się czym zajmuje aktualnie oraz co zostało skończone. 
Zadania można w prosty sposób poprzez przeciągnięcie przenosić pomiędzy jednym statusem a drugim. Poprzez podwójne kliknięcie wchodzić do ich edycji. W prawym górnym rogu widoczny jest również Burndown Chart - czyli wykres postępu prac (o nim postaram się napisać w osobnym wpisie).


7. Dodanie projektu do kontroli wersji


Jedyną rzeczą, która pozostała nam do zrobienia by można było zacząć realizować projekt jest dodanie plików do kontroli wersji.


Wracamy do Visual Studio i Team Explorera. Naciskamy przycisk Source Control Explorer.

Wybieramy nasz projekt i naciskamy "Map to Local Folder". Wybierzemy to aby określić, w którym miejscu na naszym lokalnym komputerze będą przechowywane pliki projektu. Po dokonaniu mapowania, naciskamy przycisk "New Folder" aby dodać folder o nazwie "src" (z kodami źródłowymi).

Poprzez przycisk "New Project" w oknie "Start Page" dodajemy nowy projekt z lokacją w zmapowanym folderze. Zaznaczamy dodatkowo "Add to source control".

Wszystkie foldery i pliki, które utworzyliśmy do tego momentu znajdują się tylko lokalnie na naszym dysku. Aby zmiany zostały wrzucone na serwer należy przejść do Team Explorera, nacisnąć "My Work", a następnie "Check In".

Zobaczymy listę wszystkich naszych zmian. Dobrym zwyczajem jest podanie komentarza przy check inie. Po naciśnięciu przycisku Check In zmiany zostaną wrzucone na serwer.

Podstawowa konfiguracja TFS do pracy z projektem została dokonana. W kolejnych wpisach postaram się przybliżyć każdy z tych kroków dokładniej.

Scrum i Team Foundation Server cz.3 - Wystawiamy się na zewnątrz

Tym razem wpis będzie poświęcony dodatkowej czynności, nie związanej bezpośrednio ze Scrum albo TFS. Pokażę prosty sposób w jaki można udostępnić swój serwer nie posiadając stałego łącza IP, łącząc się przez router. Nie uważam, że jest to opcja najlepsza, ani najbezpieczniejsza, ale jest prosta i może być punktem wyjściowym do lepszej konfiguracji.

Jak zrobić, żeby można było się połączyć z serwerem gdy nie posiada on stałego numer IP? Można to zrobić przy pommechanizmu DynDNS. Jeżeli chcemy uruchomić serwer np. ze stroną www lub podglądem kamer monitoringu dostępny z każdego miejsca w Internecie, a nie posiadamy stałego adresu IP, tylko otrzymujemy go dynamicznie z serwera DHCP (jak np. w przypadku Neostrady) musimy skorzystać z usługi DDNS (Dynamic Domain Name System) czyli usługi dynamicznego serwera nazw. 

Jak działa DDNS? Opis tego mechanizmu można znaleźć np. na stronie dipol.com.pl. Oto wycinek z niego:

"Z pomocą idzie usługa DDNS, która tak jak DNS posiada bazę danych z wpisami zależności adresu domenowego z numerycznym, ale może być aktualizowana w dowolnej chwili czasu przez posiadacza domeny. Dzięki temu serwer może być osiągalny pod jedną, ustaloną nazwą niezależnie od tego, jaki adres IP w danej chwili posiada. Z tego powodu z serwerem można komunikować się tylko za pomocą adresu domenowego przetłumaczonego przez serwer DDNS (chyba, że znamy aktualny adres numeryczny serwera, ale nigdy nie wiemy jak długo będzie on obowiązywał)."

UsuW tym tutorialu przedstawię jak skonfigurować DynDNS przy pomocy serwisu www.no-ip.com.

Utworzenie konta i konfiguracja na Dyn.com

Tak jak zostało wspomniane wcześniej, aby móc korzystać z DynDNS konieczne jest utworzenie konta na stronie dostarczającej tą usługę. Proces ten najlepiej przeprowadzić na komputerze, który chcemy wystawić jako serwer na zewnątrz.

1. Wchodzimy na stronę www.no-ip.com/services/managed_dns/free_dynamic_dns.html. Powinna ona wyglądać następująco:

Wpisujemy nasz adres e-mail i naciskamy przycisk "Sign Up Now!".

2. W kolejnej stronie wypełniamy naszymi danymi formularz rejestracji. Akceptujemy warunki licencyjne i naciskamy przycisk "I Accept, Create my Account".

3. Jeżeli wszystko wprowadziliśmy poprawnie pojawi nam się ekran informujący o konieczności potwierdzenia podanego przez nas adresu e-mail.

4. Wchodzimy na swoją skrzynkę pocztową i naciskamy link aktywacyjny w mailu, który otrzymaliśmy od portalu NO-IP. Po kliknięciu powinna pojawić się strona:

Naciskamy link "login".

5. W kolejnym ekranie wpisujemy swoje dane autoryzacyjne i naciskamy przycisk "Login".

6. W kolejnym widoku naciskamy przycisk "Add a Host".

7. Ukaże nam się ekran konfiguracji naszego adresu. Do celów naszej konfiguracji wystarczą nam domyślne wartości. Jedyne co musimy zrobić do wpisać unikatowy identyfikator np. "testtutorialscrumitfs" i nacisnąć przycisk "Create Host".

Udało nam się zarejestrować nasz serwer w serwisie DynDNS. Kolejnym krokiem jest:

Skonfigurowanie routera do obsługi DynDNS

Nowe routery zwykle dają możliwość konfiguracji DynDNS. Dzięki niej po zmianie adresu IP routera powiadomi on o tym automatycznie serwis DynDNS. 

Przykładowa konfiguracja zostanie pokazana na przykładzie modelu DI-524 firmy D-Link.

1. Otwieramy stronę konfiguracyjną routera pod adresem http://192.168.0.1/ . Standardowo dane autoryzacyjne to dla niego:

- login - admin

- hasło - admin

Otworzy nam się strona:

Wchodzimy do zakładki "Advanced".

2. Na następnym ekranie naciskamy przycisk "DDNS"

3. Pojawi nam się ekran do konfiguracji DynDNS. Wybieramy w nim serwis No-IP.com. Wpisujemy nasz hostname (np. "testtutorialscrumitfs") oraz swój login i hasło. Zatwierdzamy przyciskiem "Apply".

Po tych krokach skonfigurowaliśmy nasz router do współpracy z serwisem DynDNS. Pozostało, jednak, jeszcze kilka rzeczy do zrobienia.

Konfiguracja przekierowania portów

Team Foundation Server nasłuchuje pod portem 8080 na naszym serwerze. Gdy użytkownik będzie chciał połączyć się z Team Foundation serwer pod adresem DynDNS łączyć się będzie z routerem. Musimy skonfigurować go tak, żeby wiedział, o konieczności przekierowania połączenia z portem 8080 na nasz serwer (tzw. port forwarding) . Oto jak można to skonfigurować na routerze DI-524 firmy D-Link.

Wchodzimy na stronę konfiguracji routera (http://192.168.0.1/) i przechodzimy do ustawień zaawansowanych (zakładka "Advanced")

Wpisujemy w kolejne pola:

- Name - nazwę przekierowania (np. TFS)

- Private IP - wpisujemy IP naszego serwera

- Protocol Type - TCP

- Private Port - 8080

- Public Port - 8080

- Schedule - Always

Naciskamy przycisk "Apply". Voilà!

Konfiguracja Firewalla na serwerze

Pozostała nam jeszcze ostatnia rzecz. Skonfigurowanie naszego serwera tak by przyjmował połączenia z zewnątrz na porcie 8080.

Konfiguracja zostanie pokazana na przykładzie Windows Server 2008.

1. Wchodzimy do ustawień Firewalla (Start=>Administrative Tools =>Windows Firewall wih Advanced Security)

2. Zobaczymy okno konfiguracji zasad Firewalla. Będziemy ustalać zarówno regułę połączeń przychodzących (Inbound Rules) jak i wychodzących (Outbound Rules).

Naciskamy przycisk "New Rule" znajdujący się w prawym górnym rogu.

3. Otworzy nam się wizard konfiguracji reguły Firewalla.

Wybieramy opcję "Port" i naciskamy przycisk "Next"

4. W kolejnym oknie zaznaczamy opcję "TCP" i wpisujemy konkretny port - 8080 ("Specific local ports"). Klikamy "Next".

5. Pozwalamy na połączenie z tym portem ("Allow the connection") i przechodzimy dalej.

6. Zostawiamy domyślne ustawienia dostępu (Domain, Private, Public) i przechodzimy do kolejnego ekranu.

7. W ostatnim ekranie wizarda wpisujemy nazwę (np. TFS) i pełni samozadowolenia naciskamy przycisk "Finish".

8. Pozostało nam przeprowadzić analogiczny proces dla reguły połączeń wychodzących. W głównym ekranie przechodzimy do "Outbound rules" i wciskamy przycisk "New Rule". Wizard jest taki sam jak w przypadku reguły przychodzącej, więc oszczędzę Wam i sobie mojej pisaniny wierząc, że sobie poradzicie.

Test poprawności działania konfiguracji

Najprościej przetestować konfigurację próbując się z TFS przez Visual Studio.

1. Otwieramy Visual Studio (np. wersję 11). Menu => Team => Connect To Team Foundation Server

2. W kolejnym oknie naciskamy przycisk "Servers"

3. Aby dodać połączenie do naszego serwera naciskamy przycisk "Add"

3. W popupie, który nam się pojawi wpisujemy adres naszego serwera (np. "testtutorialscrumitfs.no-ip.com"). I naciskamy OK. 

Jeżeli okno się bez problemów zamknie to znaczy, że nasza konfiguracja się powiodła. (Jeżeli pojawi się prośba o podanie loginu i hasło podajcie dane administratora systemu, na którym zainstalowany jest TFS)

Udało się? Gratuluję! 

Jeżeli nie (odpukać), to piszcie szczegóły w komentarzach.

Scrum i Team Foundation Server cz.2 - Instalacja TFS

Tak jak zapowiedziałem w poprzednim wpisie, część druga mojej opowieści o Scrum i TFS będzie opisywała instalację oraz wstępną konfigurację Team Foundation Server. Po tych wpisach powinno być wiadomo co chcemy robić oraz czym, część trzecia przedstawi jak.

Przykłady będą przedstawione na podstawie Team Foundation  Server 11 Developer Preview.

Instalacja serwera TFS

1. Pierwszym krokiem jest pobranie pliku instalacyjnego TFS 11 DP. Dostępny jest bezpłatnie pod adresem:  

- http://www.microsoft.com/download/en/details.aspx?id=27542#system-requirements

2. Po udanym pobraniu pliku uruchamiamy go. Pokaże nam się ekran:

 Akceptujemy licencję i naciskamy przycisk "Continue".

3. W kolejnym ekranie zaznaczamy, że chcemy mieć włączone aktualizacje i rozpoczynamy proces instalacji naciskając przycisk "Install Now".

 4. Rozpocznie się proces kopiowania plików instalacyjnych.

5. Po zakończeniu tego procesu pojawi nam się okno z wyborem rodzaju instalacji.

Dostępne są następujące tryby:

- Basic - powinniśmy ją wybrać gdy chcemy mieć skonfigurowany system kontroli wersji, zarządzanie zadaniami oraz serwisy buildów. Wybór tej instalacji pozwala nam na wybranie istniejącej już bazy danych lub instalację SQL Express, gdy nie mamy żadnej bazy na komputerze. Jeżeli chcemy mieć skonfigurowanego Share Point lub Reporting Services powinniśmy wybrać inny tryb instalacji

- Standard Single Server - instalacja ta różni się od instalacji podstawowej tym, że konfiguruje również Share Point

- Advanced - mamy w niej dostęp do wszystkich opcji konfiguracyjnych. Pozwala m.in. na konfigurację TFSa do użytkowania zewnętrznych serwerów SQL, wybór instancji baz danych, Reporting Services oraz Share Point, użycie autentykacji Kerberos

- Application-Tier Only - pozwala na dodanie kolejnej instancji Team Foundation Server do istniejącego i skonfigurowanego środowiska

- Upgrade - pozwala na uaktualnienie aktualnej wersji Team Foundation Server

Wybieramy instalację w trybie Basic i naciskamy przycisk "Start Wizard".

6. Pojawi się pierwszy ekran Basic Wizarda. Naciskamy w nim przycisk "Next"

7. Kolejny ekran pozwala na wybór czy chcemy zainstalować nową wersję bazy danych czy chcemy wybrać istniejącą instancję. W tym opisie zostanie zaprezentowana droga z zainstalowaną bazą danych. Zaznaczamy opcję "Use an existing SQL Server Instance" i naciskamy przycisk "Next".

8. W tym kroku powinniśmy wpisać nazwę instancji naszego serwera (w moim przypadku "WIN-MPMQ6E2DM0C"). Warto nacisnąć przycisk "Test", który sprawdzi, czy nasz serwer jest rzeczywiście dostępny, lub czy nie zrobiliśmy jakiejś literówki. Jeżeli po teście pojawi nam się zielona "fajka" możemy śmiało nacisnąć przycisk "Next".

9. Jeżeli wszystko przebiegło pomyślnie to powinien pojawić nam się ekran z podsumowaniem dotychczas dokonanych wyborów. Naciskamy przycisk "Next".

10. Następuje teraz proces intalacji/konfiguracji baz danych, serwera IIS oraz Firewalla. Po jego zakończeniu ekran powinien wyglądać:

Naciskamy przycisk "Next".

12. W kolejny ekranie otrzymujemy jakże przyjemny napis "Success". Udało nam się zainstalować i skonfigurować pomyślnie TFS.

Naciskamy przycisk "Close".

Konfiguracja proxy TFS

13. Skoro udało nam się "zainstalować i skonfigurować pomyślnie TFS" to skąd kolejny punkt? OK, trochę nagiąłem prawdę. Co prawda TFS już stoi i ma się dobrze dokofigurujemy jeszcze dwie rzeczy. Proxy serwera, które pozwoli nam zmniejszyć obciążenie naszego serwera oraz serwisy Buildów. Wna głównym ekranie (przedstawionym w punkcie 5) na "Configure Team Foundation Server Proxy" . Powinien pojawić nam się ekran:

Naciskamy przycisk "Next".

14. Wybieramy użytkownika, przy pomocy którego proxy będzie łączyło się z TFS. Użytkownik ten powinien kontem serwisowym oraz zostać dodany do grupy użytkowników mających uprawnienia do TFS. Co prawda nie do końca bezpiecznie, ale dla ułatwienia wybrałem konto "NT AUTHORITY\LOCAL SERVICE". Po wyborze naciskamy przycisk "Next"

15. W kolejnym ekranie określamy port, na którym ma działać Proxy oraz miejsce, w którym ma być przechowywany jego Cache. Możemy pozostawić domyślne wartości oraz nacisnąć przycisk "Next".

16. Zobaczymy podsumowanie opcji, które wybraliśmy. Możemy zweryfikować ich poprawność naciskając przycisk "Verify" lub gdy ufamy sobie bezgranicznie nacisnąć od razu przycisk "Next".

17. Nastąpi proces sprawdzania konfiguracji i jeżeli wszystko poszło pomyślnie, wszystko zostanie oznaczone na zielono i będziemy mogli nacisnąć przycisk "Configure".

18. Po udanej konfiguracji powinniśmy zobaczyć ekran:

Naciskamy przycisk "Next".

19. Po raz kolejny możemy poczuć się dumni. Odnieśliśmy kolejny sukces - skonfigurowaliśmy proxy dla naszego serwera TFS. Po jego odtrąbieniu możemy zamknąć okno naciskając przycisk "Close"

Konfiguracja serwisu Buildów

20. Tym razem darowałem sobie żart o zakończeniu procesu instalacji. Pozostało nam jeszcze bowiem skonfigurowanie serwisu Buildów. W głównym ekranie (patrz punkt 5) zaznaczamy "Configure Team Foundation Build Service" oraz naciskamy przycisk "Start Wizard". Pojawi nam się okno:

Jeżeli nie mamy na komputerze zainstalowanych innych serwerów TFS możemy bez zastanowienia nacisnąć przycisk "Next".

21. W kolejnym ekranie mamy możliwość wybrania liczbę "agentów buildów". Im więcej ich mamy tym więcej buildów będzie mogło być naraz wykonywanych. Należy wziąć jednak pod uwagę, że każdy proces budowania zużywa zasoby systemowe, więc jeżeli nie mamy mocnego komputera nie ma sensu zwiększać ich liczby. W tym tutorialu wybrałem rekomendowaną liczbę - 1. Po wybraniu liczby agentów naciskamy przycisk "Next".

22. Musimy wybrać również użytkownika, na którego koncie będzie działał serwer buildów oraz port, na którym będzie łączył się z TFS. Ja wybrałem systemowe konto "NT AUTHORITY\LOCAL SERVICE" oraz sugerowany port 9191.

Przycisk "Next" będzie standardowo dobrym wyjściem by przejść do kolejnego kroku.

23. Pojawi się znany już nam ekran z podsumowaniem wybranych opcji. Jeżeli jesteśmy dokonanych wyborów możemy śmiało nacisnąć "Next".

24. Instalator przetestuje teraz czy wszystkie nasze ustawienia były poprawne. Jeżeli wszystko przebiegnie bez problemów powinniśmy zobaczyć ekran z przyjemnie zielonymi kolorami.

Pozostaje nam tylko w następnym widoku nacisnąć przycisk "Configure".

25. Nastąpi teraz instalacja i konfiguracja potrzebnych składników. Po jego zakończeniu powinniśmy mieć wszystkie paski w kolorze zielonym tak jak na screenie widocznym poniżej.

26. Na koniec powinniśmy zobaczyć jakże miły napis "Success". Gdy już się nim nacieszymy możemy nacisnąć przycisk "Finish" i zakończyć proces konfiguracji.

Udało nam się zatem zainstalować Team Foundation System. Mamy już wiedzę teoretyczną, mamy narzędzie, w kolejnym wpisie dowiemy się jak z niego skorzystać.

Scrum i Team Foundation Server cz.1

1. Wstęp

W kilku najbliższych postach postaram się przybliżyć ideę zarządzania projektem w metodyce Scrum przy pomocy Team Foundation Server (TFS). W tym poście opiszę zasady i cechy jakimi charakteryzuje się SCRUM. W kolejnych przedstawię jak TFS może nam pomóc w prowadzeniu projektu w tej metodyce.  Ponieważ, mimo posiadanego doświadczenia  w niej nie czuję się ekspertem będę bardzo rad z każdego, nawet najbardziej krytycznego komentarza, który pozwoli udoskonalić mi te wpisy.

2. Trochę historii

Pierwsze systemy komputerowe były zwykle tworzone dla organizacji rządowych, wojskowych lub dużych korporacji. Wszystkie one miały zwykle ściśle określone normy, przepisy, które miały cechować tworzone systemy. Dzięki temu można było sobie pozwolić na to, żeby przed powstaniem systemu przeprowadzić długą i kompleksową analizę biznesową, architektoniczną z tonami dokumentacji i dopiero po ukończeniu tego etapu wziąć się do prac programistycznych, a na samym końcu testerskich. Cykl życia tych projektów zwykle opierał się na modelu kaskadowym lub modelu spiralnym. Popularność zdobyły takie metodyki jak PRINCE2 lub RUP. Wraz z rozwojem komputerów osobistym oraz popularyzacją Internetu na przełomie XX i XXI wieku okazało się, że systemy informatyczne przestały być domeną dużych firm i organizacji - również małe i średnie przedsiębiorstwa zaczęły ich potrzebować. 

Okazało się, że metody prowadzenia projektów dla dużych przedsiębiorstw nie koniecznie są dobre dla małych. Długotrwały proces analizy, bez żadnych widocznych efektów w postaci gotowych fragmentów był nie do zaakceptowania dla firm oczekujących szybkich efektów. Często okazywało się również, że mimo długiego etapu analizy po zakończeniu implementacji i testów wewnętrznych, klient mówił, że "on inaczej to sobie wyobrażał nie działa to tak jak powinno". Prowadziło to do zmian, które jak wiadomo im później są robione tym są bardziej czasochłonne, a co za tym idzie kosztowne.

Na przeciw tym zmieniającym się realiom wyszły metodyki zwinne (Agile). W 2001 roku został ogłoszony Manifest Agile (Agile Manifesto), w którym m.in. Martin Fowler, Ken Schwaber określili ogólne zasady dla wszystkich metody z tej grupy. Oto one:

"Wytwarzając oprogramowanie i pomagając innym w tym zakresie, 

odkrywamy lepsze sposoby wykonywania tej pracy. 

W wyniku tych doświadczeń przedkładamy: 

Ludzi i interakcje ponad procesy i narzędzia. 

Działające oprogramowanie ponad obszerną dokumentację. 

Współpracę z klientem ponad formalne ustalenia. 

Reagowanie na zmiany ponad podążanie za planem. 

Doceniamy to, co wymieniono po prawej stronie, 

jednak bardziej cenimy to, co po lewej."

Oprócz tego przedstawiono 12 zasad wytwarzania zwinnego oprogramowania (numeracja dodana przeze mnie):

"1. Najważniejsze dla nas jest zadowolenie Klienta

wynikające z wcześnie rozpoczętego i ciągłego dostarczania

wartościowego oprogramowania.

2. Bądź otwarty na zmieniające się wymagania

nawet na zaawansowanym etapie projektu.

Zwinne procesy wykorzystują zmiany

dla uzyskania przewagi konkurencyjnej Klienta. 

3. Często dostarczaj działające oprogramowanie

od kilku tygodni do paru miesięcy,

im krócej tym lepiej z preferencją krótszych terminów.

4. Współpraca między ludźmi biznesu i programistami

musi odbywać się codziennie w trakcie trwania projektu.

5. Twórz projekty wokół zmotywowanych osób.

Daj im środowisko i wsparcie,

którego potrzebują i ufaj im, ze wykonają swoją pracę.

6. Najwydajniejszym i najskuteczniejszym

sposobem przekazywania informacji do

i ramach zespołu jest rozmowa twarzą w twarz

7. Podstawową i najważniejszą miarą postępu jest działające oprogramowanie. 

8. Zwinne procesy tworzą środowisko do równomiernego

rozwijania oprogramowania. Równomierne tempo

powinno być nieustannie utrzymywane poprzez sponsorów,

programistów oraz użytkowników.

9. Poprzez ciągłe skupienie na technicznej doskonałości

i dobremu zaprojektowaniu oprogramowania zwiększa zwinność.

10. Prostota – sztuka maksymalizacji pracy niewykonanej – jest zasadnicza.

11. Najlepsze architektury, wymagania

i projekty powstają w samoorganizujących się zespołach.

12. W regularnych odstępach czasu zespół

zastanawia się jak poprawić swoją efektywność,

dostosowuje lub zmienia swoje zachowanie." 

Te zasady stały są punktem wyjściowych dla metodyk Agile - w tym również dla Scrum. Jakie cechy ją charakteryzują? Dlaczego warto jej używać?


3. Scrum

Jako się rzekło Scrum jest zwinną, iteracyjną metodyką. Jej nazwę zaproponował wymieniony już wcześniej Ken Schwaber. Uznał, że zasady gry w rugby świetnie obrazują to jak powinien wyglądać proces wytwarzania oprogramowania. Gra w rugby wygląda tak, że co jakiś czas następuje przerwa w grze, w której ustalany jest plan tego jak rozpocząć kolejną akcję, cała drużyna ustawia się w pozycję zwaną "młynem" (z ang. scrum). Rozpoczynana jest gra, występuje próba realizacji planu, aż do momentu zatrzymania gry.

Dokładnie w ten sposób wygląda proces wytwarzania oprogramowania w metodyce Scrum. Cykl życia aplikacji podzielony jest na okresy zwane sprintami, w których występuje etap planowania, realizacji, podsumowania. No ale po kolei.

Elementy metodyki Scrum można podzielić na:
- zespół (z podziałem na role),
- zdarzenia,
- artefakty,
- reguły postępowania.

Wszystkie te elementy dają pełen obraz zasad, które kierują Scrumem. Zostaną one opisane w kolejnych punktach.


4. Zespół Scrumowy

W przeciwieństwie do metodyk "twardych" w Scrumie nie ma dużej ilości ról, zostały zdefiniowane tylko 3 role: 
- Właściciel Produktu,
- Scrum Master
- Zespół

Źródło: Resnick, Steve; Bjork, Aaron; de la Maza, Michael (2011).
Professional Scrum with Team Foundation Server 2010. Wiley

4.1 Właściciel Produktu (Product Owner) - osoba będąca łącznikiem pomiędzy zespołem a klientem. Odpowiada za ustalenie wymagań biznesowych, nadanie im priorytetów oraz ocenę ich realizacji. Osoba ta kontaktuje się z klientem, ustala jego zapotrzebowania i oczekiwania.

4.2 Scrum Master - odpowiada za to, żeby proces wytwarzania i oddawania produktu przebiegał płynnie i bez zakłóceń. Czuwa nad tym, żeby wszystkie zasady były stosowane, żeby członkowie zespołu mogli skupić się tylko na swoich zadaniach, nie byli rozpraszani, rzez inne nie będące w ich kompetencjach. Nie jest zalecane, żeby Scrum Master był również  Właścicielem Produktu.

4.3 Zespół (Team) - tutaj sytuacja jest bardziej zamglona i trudniejsza do określenia. Liczebność Zespołu powinna się wahać od 5 do 9 osób. Zgodnie z zasadami scrum, Zespół jest odpowiedzialny za utworzenie produktu. Każdy z członków zespołu jest sobie sterem, żeglarzem, okrętem powinien pełnić funkcje analityka, testera, programisty. Aby to było możliwe projekt powinien być prowadzony zgodnie z zasadami Test Driven Development (TDD), według których funkcjonalności (szczególnie przepływy biznesowe) powinny posiadać testy pozwalające na weryfikację ich działania.

5. Zdarzenia

Tak jak już wspomniałem wcześniej cykl wytwarzania produktu podzielony jest na Sprinty. Sprint jest najmniejszą jednostką czasową w scrumie. Każdy sprint jest zamkniętą całością. W jego obrębie następuje planowanie, realizacja i podsumowanie prac projektowych. Po jego zakończeniu powinna zostać dodana konkretna, weryfikowalna wartość biznesowa do projektu. 
Sprinty powinny trwać taki sam przedział czasu. Dzięki temu wprowadzona do projektu zostaje większa systematyczność. Pozwala to również lepiej określić jaki zakres pracy zespół jest w stanie wykonać podczas jednego Sprinta. Sugerowany czas trwania sprinta to od dwóch do pięciu tygodni.

Oprócz tego sprint cechują następujące zasady:
- nie można dokonywać zmian mających wpływ na realizację celów sprintu,
- nie można zmieniać składu Zespołu w trakcie sprintu,
- nie można obniżać celów jakościowych,
- czas zadań nie powinien się zmieniać. Kiedy jest jednak taka potrzeba to może to być dokonane tylko po konsultacjach pomiędzy Zespołem a Właścicielem Produktu.

W obrębie sprinta występują następujące zdarzenia:
- codzienny scrum,
- planowanie sprintu,
- przegląd sprintu,
- retrospektywa sprintu.

Źródło: http://www.sadhanbiswas.com/myblog/techsavvy/agile-methodology/

5.1 Codzienny scrum jest spotkaniem Zespołu mającym na celu zrelacjonowanie postępów w realizacji zadań, pojawiających się problemów oraz przedstawienie swoich planów na najbliższy dzień pracy. Powinny one się odbywać z rana o jednakowej godzinie, nie trwać dłużej niż 15 minut na stojąco. Najlepiej w tym samym miejscu. Dlaczego na stojąco? Dla niewygody. Dzięki tej niezbyt przyjemnej do dyskusji pozycji zmniejszamy szansę na to, że osoby uczestniczące będą się rozwodziły bardziej nad swoimi rzeczami niż to konieczne. 
Ważne jest również to, że w trakcie Codziennego Scruma nie rozwiązujemy problemów, relacjonujemy je i ewentualnie ustalamy, czy jest ktoś kto ma pomysł na jego rozwiązanie.
Scrum Master na tych spotkaniach odgrywa rolę moderatora.

5.2 Planowanie sprintu odbywa się jak można się łatwo domyśleć na początku sprintu. Określane w nim jest to co ma zostać wykonane w jego obrębie. Nie powinno ono trwać dłużej niż 8h dla sprintu 4 tygodniowego, 4h dla dwutygodniowego. 
Pierwszym etapem planowania jest wybranie z pośród puli zadań dla całego projektu (zwanym Rejestrem Produktu lub z ang. Product Backlog) tych które zostaną w nim wykonane (zadania te zostają wrzucone do puli zwanej Rejestrem Sprintu lub z ang. Sprint Backlog). Odbywa się on poprzez dialog Zespołu z Właścicielem Produktu. Oszacowany zostaje również wstępny czas jaki jest potrzebny na zrobienie danego zadania.
Przy wyborze zadań do Sprintu powinny być brane pod uwagę takie czynniki jak:
- liczebność zespołu,
- analogie z poprzednimi sprintami, porównanie ile udało się w nich zrobić,
- oraz to, żeby zadania składały się w logiczną całość, tak, żeby po zakończeniu Sprintu została oddana konkretna wartość biznesowa.
Określony zostaje również Cel Sprintu. Jest nim zwykle kamień milowy w obrębie danego produktu np. utworzenie konkretnego modułu, funkcjonalności. 
W drugiej części planowania Zespół określa szczegóły implementacji wybranych zadań. Dekomponuje je na podzadania, tak aby odzwierciedlały one lepiej etapy programistyczne konieczne do ich wykonania. Weryfikowane są również poprzednie szacunki czasów wykonania zadań. Możliwa jest też zmiana zawartości Rejestru Sprintu, ale tylko i wyłącznie po konsultacji i akceptacji Właściciela Produktu.


5.3 Przegląd Sprintu - jest to podsumowanie dokonywane na zakończenie Sprintu. Ustalane jest na nim co się udało a co się nie udało zrobić. Określone zostaje jak duży był Przyrost (Effort) wykonany w trakcie Sprintu. Omawiane zostają również problemy na jakie natrafiono w trakcie realizacji zadań. Zadania, które nie zostały zrealizowane wracają do Rejestru Produktu.
Zwykle odbywa się prezentacja aktualnej wersji produktu dla Właściciela Produktu, który jest osobą akceptującą realizację zadań. Określana jest też wstępna wizja tego co będzie działo się w kolejnym Sprincie.
Przegląd nie powinien trwać dłużej nić 4 godziny dla Sprintu 4 tygodniowego i 2 godziny dla 2 tygodniowego.


5.4 Retrospektywa Sprintu - Odbywa się ona po przeglądzie. Jest to chwila, w której Zespół może przeanalizować to co dobrego/złegoT wydarzyło się w ostatnim Sprincie. Zespół powinien określić co i jak można było by poprawić, które działania, metody należało by kontynuować. Zadaniem Scrum Mastera jest przeprowadzić tak dyskusję, żeby każdy z członków zespołu aktywnie brał udział w opracowywaniu nowych zaleceń.
Spotkanie to nie powinno trwać dłużej niż 3 godziny.


6. Artefakty


Artefakty są to elementy, które opisują wykonywaną pracę wykonywaną podczas trwania projektu w Scrumie. Są to:
- Rejestr Produktu (Product Backlog),
- Rejestr Sprintu (Sprint Backlog),
- Przyrost (Effort)

6.1 Rejestr Produktu - jest to zbiór wymagań, zmian oraz zadań, które muszą zostać wykonane, żeby produkt został utworzony w całości. Zadania te są zwykle w postaci Historii Użytkownika (User Stories), czyli opisu tego jakie ma być zachowanie systemu w kontakcie z użytkownikiem. Każda historia użytkownika powinna zawierać kryteria akceptacji jego realizacji.
Za zarządzanie i pielęgnację Rejestru Produktu odpowiada Właściciel Produktu. Rejestr Produktu ewoluuje wraz z produktem. Na podstawie kontaktów z użytkownikami, pracami Zespołu w trakcie sprintów pojawiają się uwagi, doprecyzowania, zmiany, błędy. Rejestr Produktu pozostaje pusty dopiero gdy nie będą dokonywane żadne prace nad produktem.

6.2 Rejestr Sprintu - w trakcie realizacji produktu, wraz z kolejnymi Sprintami przenoszone zostają elementy z Rejestru Produktu do Rejestrów kolejnych Sprintów. Wszystkie te elementy wchodzą w skład zdefiniowanego celu dla danego sprintu. Ponieważ Historie Użytkownika nie są wystarczająco precyzyjną formą opisu zadań dla Zespołu, zwykle dzielone są na podzadania, wg logicznego programistycznego podejścia.
Jedynie Zespół może zadecydować o dodaniu czegoś lub usunięcia z Rejestru Sprintu. Po zakończeniu Sprintu Zespół wraz z Właścicielem Produktu decydują co zrobić z niezrealizowanymi historiami użytkowników (czy je zamknąć czy wrzucić z powrotem do Rejestru Produktu).


6.3. Przyrost - jest to wskaźnik, mówiący o tym co do tej pory udało się zrealizować. Każda historia użytkownika jest opisana przez punkty przyrostu. Poprzez sumę przyrostów poszczególnych Historii Użytkownika wyrażona jest ilość zrealizowanych funkcjonalności.


Ufff. Trochę się spisałem, a i tak wydaje mi się, że póki co przeskoczyłem tylko po łebkach przez tematy związane ze Scrumem. W kolejnych wpisach przedstawię jak Team Foundation Server może nam pomóc w codziennej pracy ze Scrumem, jak ją ułatwić i pozwolić sprawnie go prowadzić.


Tak jak wspominałem proszę Was gorąco o uwagi co do niejasności/błędów/zamglonych opisów.


Kolejny wpis to instalacja i wstępna konfiguracja TFS.



Źródła:
- Resnick, Steve; Bjork, Aaron; de la Maza, Michael (2011). Professional Scrum with Team Foundation Server 2010. Wiley [Amazon]
- Schwaber, Ken; Sutherlanda, Jeff (2011) - The Scrum Guide [Link]
- Agile Manifesto (2001) - [Link]