TFS 2012 w chmurze obliczeniowej

Niesamowite. Zwykle warsztaty oparte o Team Foundation Server związane były z przygotowaniem serwera, który musiałem ze sobą zabrać (w tym na Litwę, Łotwę, czy do Estonii).

29-30 sierpnia 2012, dwa tygodnie po oficjalnej premierze VS 2012, przeprowadziłem (w Polsce) warsztat „Efektywne zarządzanie projektami w … z wykorzystaniem metodyki SCRUM i narzędzi wspomagających”. Tym razem z TFS 2012 w chmurze obliczeniowej. Wykorzystałem szablom MSF Agile 6.0, choć uczestnicy mieli dostęp również do projektu wygenerowanego na podstawie metodyki VS SCRUM 2.0. Logowanie uczestników  warsztatu za pomocą Live ID. Koniec problemów z brakiem domeny! Wystarczyło hotelowe WiFi (pewnie Neostrada 2MB).

Działa fantastycznie.  Od 6 lat nie miałem tak dobrej infrastruktury i tak dobrego narzędzia.  Brawo Microsoft!

 

 

Efektyvaus programavimo projektu valdymo seminaras

W tytule litewska nazwa seminarium - premiery Team Foundation Server 2010. Seminarium przeprowadziłem w Wilnie - 5 dni, po udostępnieniu wersji beta 2 społeczności informatycznej – 26 października 2009. Składało się z czterech modułów:
1. Quick Start – configure your environment, define your project, build your team, choose the right tools for each person .
2. Working with code repository and builds - developers' and project managers' needs and expectations during Software Development Life Cycle.
3. Effective project management with work items and Microsoft Solutions Framework 5.0 methodologies.
4. Testing and improving code quality. Reporting and analyzing the result of work done. How to extend Team Foundation Server 2010 methodology template? Case study: How Microsoft Team System’s Division use Team System 2010?
Wzięło w nim udział ponad 120 (zadowolonych) uczestników. Jego organizatorem był Microsoft Litwa.

50 spotkanie Krakowskiej Grupy Deweloperów .NET

Już 6 rok działa Krakowska Grupa Deweloperów .NET. Grupa, którą udało mi się stworzyć wspólnie z Joanną Grzywną, Piotrem Dobrowolskim i Pawłem Rzadkowskim.

Moja prezentacja to: Świat zmienia się. Efektywne zarządzanie projektami też!
Oto krótkie streszczenie: Zmieniają się zespoły. Te duże dzielą się na kilkuosobowe załogi, te małe jeszcze mocnej ze sobą współpracują. W ciszy i spokoju. To też załogi (wspólny sukces, czy porażka). Kamienie milowe zamieniają się bramy (gates) do kolejnych etapów. Czasem jakaś załoga nie przejdzie przez bramę. I nie ma usprawiedliwienia. Tonie.

Nie zależnie od tego, jakie metody pracy wybrano pojawia się porządek, czy porządkowanie metod pracy. Polskie firmy dążą do tego, by znaleźć się na poziomie CMMI 1,5, czy 2,5 (o dziwo nie 2). Oczywiście ma to nieformalny charakter. O dziwo można uporządkować nakładanie się na siebie procesów sprzedaży i życia projektu, a projekt nie zaczyna się po podpisaniu kontraktu … W przypadku projektów wewnętrznych (wewnątrz dużych organizacji) zarządzanie interesariuszami (stakeholders management) nabiera wymiaru praktycznego. Jeżeli do tego dołożyć mapy drogowe dla różnego typu projektów, to można by powiedzieć, że jesteśmy świadkami rewolucji.
O dziwo Microsoft wyczuwa to, co się dzieje. Nie teoretyzuje, nie przywiązuje się do tego, co było dobre w przeszłości. Odważnie idzie do przodu. Wystarczy popatrzyć na MSF 5, czy Sure Step 2.5.

W przerwie był tort!

Drugą sesją była prezentacja Szymona Pobiegi nt. usług zdalnych. Wysłuchałem z dużym zainteresowaniem.

Trzymam kciuki za kolejne 5 lat i deklaruję przygotowanie sesji na 100 spotkanie!

Zarządzanie projektem z wykorzystaniem Team Foundation Server 2008 jednak bez Visual Studio i Team Explorera

W piątego 6-go i sobotę 7-go czerwca, po raz drugi przeprowadziłem eksperymentalny warsztat w Krakowskiej Szkole Biznesu z zarządzania projektem informatycznym z wykorzystaniem jednostek roboczych Team Foundation Server 2008. W zajęciach uczestniczyło 30 osób, 10 zespołów (z rolami kierownik projektu, analityk biznesowy, tester) – co oznaczało 10 projektów TFS. Celem warsztatu było poznanie różnic pomiędzy klasycznym zarządzaniem projektem z wykorzystaniem MS Project, a nowoczesnym z wykorzystaniem jednostek roboczych.
Wykorzystywane przez członków zespołu narzędzia to przeglądarka internetowa (w jednej zakładce Team System Web Access, w drugiej dostęp do portalu projektu – SharePoint Services 3.0), MS Excel, MS Word i MS Project. To był warsztat dla kierowników projektów – korzystaliśmy ani z Visual Studio 2008, a nie z Team Explorera.
Wszystkie projekty przeprowadzono w oparciu o metodykę Microsoft Solutions Framework for Agile System Development, jednak z własnymi szablonami dokumentów będącymi punktem wyjścia do moich polskich i międzynarodowych wdrożeń. W trakcie warsztatu każdy zespół zarejestrował kilkadziesiąt jednostek roboczych (sceanrios, QoS, tasks, bugs), zmieniając ich stany i powody przejścia zgodnie z workflow przyjętym w metodyce.
Eksperyment pokazał przydatność Team Foundation Server do nowoczesnego zarządzania projektem również wtedy, kiedy narzędziem pracy deweloperów nie jest Visual Studio.

Scrum pokonał MSF 4.2 Agile (Scrum beats MSF 4.2 Agile)

W piątek i sobotę – 16-17 maja, w dużej polskiej firmie IT prowadziłem warsztat „Efektywne zarządzanie projektem informatycznym z wykorzystaniem metodyk zwinnych – SCRUM i Microsoft Solutions Framework v4.2 for Agile System Development oraz Team Foundation Server 2008”. W grupie 13 osób, w tym 10 deweloperów. Tworzą oni rozwiązania IT (package business solutions) od wielu lat (czasem i ponad 10). I Odnoszą sukces rynkowy. Znaczący.
Wspaniała atmosfera twórczej pracy. Płaska struktura, „agailowe” myślenie …
W trakcie warsztatu porównaliśmy zarówno proces jak i model zespołu w obu metodykach (Scrum i Microsoft Solutions Framework v4.2 for Agile Software Development). Zapytałem, która metodyka jest im bliższa?
10:3 zwyciężył Scrum. Nie należy tego uogólniać.
Dlaczego Scrum? Systematyczność (bardzo dobrze zdefiniowane spotkania na początku i na końcu sprintu, dailly scrum), transparentność tego, co w projekcie się dzieje, mało biurokracji (tworzonych dokumentów), dużo kodowania, zarządzanie funkcjonalnością (i wartością biznesową) budowanego rozwiązania poza zespołem, mocne relacje pomiędzy członkami zespołu.
W trakcie dyskusji podkreślano, że Scrum nie jest uniwersalną receptą dla każdego zespołu, ale do ich zespołów bardzo pasuje …
Warsztat będzie miał swoje cdn. Praktyczne laboratorium ..

O zarządzaniu projektami z Team Foundation Server na żywo (My, You Tube interview about working with TFS 2008)

Poproszony o komentarz, na ile narzędzia i metody pracy oferowane przez Microsoft sprzyjają zarządzaniu projektami opowiedziałem dziennikarzowi webhosting.pl, czym jest Team Foundation Server i Microsoft Solution Framework. Możecie zobaczyć na You Tube.
Nic się nie zmieniło. Nie jestem pracownikiem Microsoft. To, co zostało podane w tytule, to skrót od mojej honorowej działalności jako Microsoft Regional Director in Poland.

Łotysze polubili Visual Studio 2008 Team System i Microsoft Solutions Framework (Great adoption of ... in Latvia)

Łotewski warsztat „Effectively Managing innovative IT project using Microsoft Solutions Framework for Agile System Development methodology and Visual Studio 2008 Team System (a dynamic and innovative approach to successful management of projects and teams)” niestety już za mną, a właściwie za nami (przed 3 dni pracowałem razem z Marcinem) …
Wydawało nam się, że po warsztacie na Litwie nic nie jest w stanie nas zaskoczyć. A jednak?


1. 3 osoby (na 12) miały doświadczenia – do 2 lat w wykorzystaniu technologii opartej o TFS. O wzorcowym wdrożeniu w Exigen Services DATI pisałem uprzednio. Lauris Riskov, menedżer tej firmy, który zarządza grupą ponad 50 osób, a jego zespół od dwóch lat używa TFS wystawił nam oceny (w sakli 1-9) - 6 – za treść (nie do Laurisa adresowany był warsztat), 9 – za kompetencje i 9 – za sposób przeprowadzenia warsztatu. Napisał: „ As I mentioned before, I’m not sure if this course will be useful for me in future, but the course itself is great”. Zadbaliśmy o wszystkich.

2. Uczestnikom warsztatu bardzo przydał do gustu Visual Studio Team System Web Access dla serwera TFS 2008 (VSTS Web Access). Praca z jednostkami roboczymi najczęściej obywała się z wykorzystaniem VSTS Web Access.


3. Ostatni dzień warsztatu – „Współpraca z narzędziami z narzędziami zewnętrznymi (MS Excel, MS Project, VSTS Web Access)” i „Modyfikacja szablonu metodyki dla TFS 2008” wyzwolił wiele emocji. Przeprowadziliśmy go w formie rywalizacji pomiędzy sześcioma, dwuosobowymi zespołami. 15 możliwych do uzyskania punktów uzyskały aż 3 zespoły, a ten ostatni szósty może pochwalić się rezultatem 13,45 pkt.

4. Wszystkie zespoły stworzyły i opublikowały na portalu projektu po dwa raporty (z wykorzystaniem Reporting Services). I zajęło im to nie więcej niż 20 minut.

5. Dużym wyzwaniem okazała się współpraca 64 bitowych stacji roboczych z Windows XP 64-bit z serwerem TFS. Konfiguracja naszego laboratorium „rozgrzewała” się przez 2,5 dnia (na 3 dni). Dopiero końcówka była perfekcyjna. Jak na razie nie „pałam miłością” do 64-bitów. Nie stawiajcie nam proszę więcej 64 bitowych systemów operacyjnych i komputerów!



Oceny? Były bardzo dobre, choć niższe niż na Litwie. To moja wizyta tutaj. Znam temperament Łotyszy. Dlatego uśrednione oceny (w skali 1-9), to 7,92 za treść warsztatu, 8,58 za kompetencje trenerów, 8,08 za sposób prezentacji to nasz sukces.

Ryga wiosną jest inna niż ta latem. Ale również urokliwa.

Czy „ergonomista” jest potrzebny w zespole projektowym? (Do we need user experience role inside the project team?)

W trakcie trzeciego z prowadzonych przez mnie kursów „Efektywne zarządzanie innowacyjnym projektem informatycznym z wykorzystaniem metodyki Microsoft Solutions Framework v4.2 for Agile System Development i Team Foundation Server 2008” (pierwszy, drugi), w Warszawie – poniedziałek i we wtorek 11-12 lutego wywiązała się dyskusja na temat roli określanej przeze mnie jako „ergonomista” (ang. user experience). Dla mnie to bardzo ważna rola, bo końcowy użytkownik i płatnik (ktoś, kiedyś musi zapłacić za software, który budujemy) ocenia nas poprzez jakość („Czy tą aplikację da się używać?”) jak i prostotę używania (Na ile korzystanie z aplikacji jest intuicyjne?). „Ergonomista” to rola, która pojawiła się w tzw. starej Microsoft Solutions Framework (do wersji 3.2) i jest obecna w metodyce Microsoft Solutions Framework for CMMI Process Improvement v4.x. W metodyce Microsoft Solutions Framework v4.x for Agile System Development rola ta (w sensie operacyjnym) nie występuje, choć jeden z analityków biznesowych musi lobbować na rzecz ergonomii rozwiązania.
Czym zajmuje się "ergonomista"?
Najważniejszy zakres odpowiedzialności dotyczy:
- interfejsu aplikacji (na ile łatwo, intuicyjnie można z rozwiązania korzystać?)
- przygotowania instrukcji użytkownika i pomocy (ang. help) – wsparcia w sytuacjach trudnych.
Dyskusja (w trakcie kursu dotyczyła) odpowiedzi na pytanie, kiedy pisać podręcznik użytkownika? W trakcie implementacji, czy stabilizacji? Ja (intuicyjnie wypracowałem podobne metody działania jak Microsoft) uważam, że w trackie implementacji, uczestnicy kursu uważali (mam nadzieję, że już nie), że w tracie stabilizacji - kiedy pełna funkcjonalność została zaimplementowana.
Dlaczego musimy zacząć pisać podręcznik użytkownika w trackie fazy implementacji?
1. Rolą "ergonomisty" jest również zarządzanie używalnością aplikacji – musi być aktywny w tracie implementacji i podejmować decyzje na bieżąco. Opisując pracę budowane rozwiązania weryfikuje swoje koncepcje. Deweloperzy poprawiają błędy na bieżąco. To działa! To nie jest zarządzanie zmianą.
2. Przygotowując podręcznik w trakcie stabilizacji i natrafiając na ewidentne pomyłki w zakresie ergonomii użytkowania, błędy zgłaszane przez ergonomistę mają najniższy priorytet (pol. musztarda po obiedzie). Rzadko, kiedy dochodzi do ich poprawy.
3. Pisanie podręcznika i pomocy (zwykle ten sam plik przetwarzany do innej formy wynikowej) to sztuka, często zajmuje więcej czasu niż pisanie kodu.
4. Kiepski podręcznik (i help) to ogromne obciążenie dla call center zajmującego się wsparciem użytkownika końcowego (ang. help-desk) – niezależnie od tego, czy dotyczy to klienta biznesowego, czy prywatnego. Było to (i jest) problemem dla wielu polskich firm IT. Tych sprzedających setki, czy tysiące licencji rocznie.
5. Dobry „ergonomista” nie tylko przygotuje dobrze zrozumiały podręcznik, ale przede wszystkim tak zaprojektuje aplikację, że korzystanie z podręcznika, helpu, help-desk będzie minimalne.
Czy piszę o wyimagowanym problemie? Próbowaliście kiedyś zmontować meble IKEA na podstawie instrukcji? Zamontować, korzystając z instrukcji bagażnik dachowy na samochodzie KIA? Uruchomić radio po odłączeniu akumulatora na podstawie instrukcji dostarczonej przez firmę OPEL? To przykłady z mojego prywatnego help-desk za ostatnie 3 dni. Instrukcje, które wręczyli mi znajomi były „tak dobre” jak wielu aplikacji komputerowych. Nie, miały pewną przewagę. Wiele aplikacji ma jedynie coś, co „markuje” podręcznik użytkownika.
Raz na tydzień dostaje email w stylu „help desk Microsoft mnie ignoruje, czy mogę prosić o …”. Nie reaguję! Nigdy nie reaguję. Mam zasadę, że nie otwieram Puszki Pandory.

Wdrażać, czy nie Team Foundation Server? (10 pros for Team Foundation Server)

Joanna, kierownik projektu w dużej, polskiej „fabryce oprogramowania” była uczestnikiem kolejnego, z cyklu trzech podobnych warsztatów „Efektywne zarządzanie innowacyjnym projektem informatycznym z wykorzystaniem metodyki Microsoft Solutions Framework v4.2 for Agile System Development i Team Foundation Server 2008” w poniedziałek i wtorek. Pierwszy (z cyklu warsztaów) odbył się w Poznaniu, ten drugi w Warszawie. Trzeci za tydzień przewidziany jest również w Warszawie …
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.

SCRUM czy MSF Agile? (What to choose – SCRUM or MSF Agile?)

Prawie 4 dni spędziłem w poprzednim tygodniu w Poznaniu. Powodem był warsztat „Efektywne zarządzanie innowacyjnym projektem informatycznym z wykorzystaniem metodyki Microsoft Solutions Framework v4.2 for Agile System Development i Team Foundation Server 2008”. Warsztat dla sympatycznej grupy pracowników firmy X.
SCRUM czy Microsoft Solutions Framework v4.2 for Agile System Development (MSF Agile)? To pytanie przejawiało się często.
Obie metodyki spisują się doskonale, o ile wspiera je jeszcze Team Foundation Server (TSF), do tego w wersji 2008.
Jeżeli jako zespół chcecie zarządzać „wartością biznesową” budowanego rozwiązania to bardziej MSF Agile, jeżeli Wasz Product Manager jest poza zespołem (w SRUM nazywamy go SCRUM Owner), a Waszą rolą jest jedynie zbudowanie rozwiązania to raczej SCRUM. Pytanie to temat na poważny artykuł. W tym na blogu. Przyjdzie czas i napiszę
Poznań to bardzo urokliwe miasto. Mnie tym razem urzekła ta część nazywana Wildą, z pięknym Rynkiem Wildeckim. Szkoda, że nie zrobiłem żadnego zdjęcia. Może będzie okazja. Może mnie znowu poproszą o …?