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]

Ciekawostki cz. 1

Dzisiaj będę się chwalił się swoją niewiedzą. Kilka dni temu kolega zadał mi pytanie, którym skutecznie mnie zagiął. Ponieważ uważam, że głupotą nie jest brak wiedzy co raczej udawanie, że się ją posiada, czym prędzej się Wam tym pytaniem chwalę. 

Co zostanie wyświetlone po takim kodzie i dlaczego? 

string string1 = "Test";

string string2 = string1;
string string3 = "Test";

Console.WriteLine(Equals(string1, string2)); // 1.
Console.WriteLine(Equals(string1, string3)); // 2.
Console.WriteLine(ReferenceEquals(string1, string2)); //3.
Console.WriteLine(ReferenceEquals(string1, string3)); //4.

Odpowiedź 
(Pokaż)

Pierwsze i drugie porównanie pokażą oczywiście true - Equals porównujący stringi o tej samej wartości zawsze pokaże true

Drugi i trzeci pokażą również true - tutaj był mój błąd. Uznałem, że skoro string nie jest typem referencyjnym to przy przepisaniu skopiuje on wartość, a nie przepisze referencję. W teorii tak powinno być, ale w tym momencie do gry wchodzi Optymalizator Kompilacji. Ten byt czuwa nad tym, aby nasz program działał jak najszybciej maskując ile się da nasze błędy. W tym przypadku zauważył, że nie ma sensu tworzyć nie wiadomo ile obiektów, skoro i tak string ma przeładowaną metodę Equals i operatoror porównywania. Zamiast generować kolejne obiekty poprzypinał on referencje do jednego obiektu.
Optymalizator jest na tyle sprytny, że potrafi się obronić przed takimi trikami:

string string4 = string1 + String.Empty;

Console.WriteLine(ReferenceEquals(string1, string4));

Dla powyższego kodu również wyświetli true.
Dopiero coś takiego potrafi go wprawić w konsternację i każe mu wyświetlić upragniony false:

string string5 = (string3 + "a").Replace("a", String.Empty);

Console.WriteLine(ReferenceEquals(string1, string5));

(Ukryj)

Błąd "Cannot update a parent row: a foreign key constraint fails" przy pobieraniu rekordów w NHibernate

Dzisiaj kolejny krótki wpis, ponownie dotyczący NHibernate'a.
Jak pewnie zdążyliście zauważyć jest to coś co ostatnio sprawia mi najwięcej problemów.

Próbując pobrać rekordy przy pomocy zwykłego selecta zawężonego o kryteria w NHibernate, otrzymałem zaskakujący błąd 

"Cannot update a parent row: a foreign key constraint fails"

Pierwsza moja myśl była: "Pobieram rekordy, a on chce robić update? Jak to, zgłupiał?!".
Miałem klasę zdefiniowaną jako:

public class KontoBankowe
{
    public virtual int    Id           { get; set; }
    public virtual int    Oprocentowanie     { get; set; }
    public virtual int    IdBanku { get; set; }
}

oraz mapowanie klasy jako:

public class KontoBankoweMapowanie : ClassMap<KontoBankowe>
{
    public KontoBankoweMapowanie()
    {
        Table("KontoBankowe");
        Id(e => e.Id);
        Map(e => e.Oprocentowanie, "Nazwisko").Not.Nullable();
        Map(e => e.IdBanku , "IdBanku ");
    }
}

Widzicie już co jest źle? Jeżeli tak, to bardzo Wam gratuluję, bo mnie to chwilę zajęło.
Dla równie opornych na wiedzę jak ja, tłumaczenie:
1. Pobieramy wiersze konta bankowego.
2. Wśród rekordów mamy wiersze, które w kolumnie IdBanku mają nulle (tabela i mapowanie na to pozwalają).
3. Po pobraniu nulla NHibernate ustawia wartość właściwości IdBanku klasy KontoBankowe jako domyślna wartość typu int, czyli 0.
4. Ponieważ encja pobrana przez nas jest różna od tej, która jest w bazie (0, zamiast null) to NHibernate przy wywołaniu metody Session.Flush() próbuje uaktualnić pobrany rekord. Nie istnieje, żaden bank o id równym 0, więc update wyrzuca błąd na kluczu obcym łączącym tabelę KontoBankowe z tabelą Bank.

Rozwiązanie problemu jest proste. Wystarczy w klasie KontoBankowe ustawić pole IdBanku jako int ?. Po poprawkach klasa będzie wyglądała:

public class KontoBankowe
{
    public virtual int    Id           { get; set; }
    public virtual int    Oprocentowanie     { get; set; }
    public virtual int ?  IdBanku { get; set; }
}

Do zapamiętania: Zawsze sprawdzać czy ustalone pole jako nullable jest typem, który może przyjąć wartości null (ze szczególnym uwzględnieniem typów prostych i struktur).

Jak odblokować workspace w TFS

Dzisiaj kolejny przykład z życia wzięty, krótszy ale miejmy nadzieję, przydatny. Zmieniłem na swoim komputerze nazwę grupy roboczej, do której należę. Po uruchomieniu Visual Studio i próbie checkoutu pliku okazało się, że pojawił mi się komunikat o błędzie:

A local workspace is required.  
Workspace NazwaGrupyRoboczej;Nazwa użytkownika 
does not reside on this computer.

Komunikat ni mniej ni więcej mówi, że VS nie mogło odnaleźć wcześniejszego workspace'a. Powodem jest to z tego, że TFS cache'uje workspace'y. Jak zatem wymusić na żeby odświeżył je i zobaczył naszą zmianę?

Należy uruchomić Visual Studio Command Prompt (Start => Programy => Microsoft Visual Studio 2010 => Visual Studio Tools => Visual Studio Command Prompt (2010)) i wpisać w nim:

tf workspaces /s:URLDoTwojegoSerweraTFS

I już.