Piotr Skwarski, Maciej Prusko

1. MSF Piotr Skwarski, Maciej Prusko

2. Zagadnienia: • Przyczyny niepowodzeń projektówinformatycznych • Jakie problemy może rozwiązać MSF • Omówienie MSF v.3 • Jak wdrożyć MSF • MSF a MOF

3. Czym jest Framework? • Framework jest zestawem „dobrych praktyk” • Framework a metodologia • Łatwość wdrożenia • Restrykcyjność • Framework + metodologia (np. RUP)

4. MSF • Microsoft Solutions Framework • Utworzony w 1991, ostatnie duże zmianyw 1998 i 2003 (v3) • Związek z MOF, Microsoft Operational Framework • Koncentruje się na zarządzaniuinfrastrukturąinformatyczną

5. Cykl życiaprojektu IT Microsoft Solutions Framework Plan Operate Build Deploy Microsoft Operations Framework

6. Odsetek porażek w projektach IT Porażka Problemy Sukces 23% 49% 28% 2000 28% 46% 26% 1998 40% 33% 27% 1995 31% 53% 16% 1994 źródło:The Standish Group International, Extreme Chaos, The Standish Group International, Inc., 2000

7. Czy MSF się sprawdza? • Tak, jeśli wybierzesz odpowiednią dla twojego projektu cześć MSF • Duże projekty prowadzone zgodnie z MSF • www.nasdaq.com,www.marriott.com, www.ciber.co.uk • Visual Studio, Windows 2003, Windows XP

8. Dla kogo jest MSF? • Głównie wdrażany przy dużych projektach • Co to jest duży projekt? • 3-12 miesięcy (najczęściej 4-6) i zespół programistycznyprzynajmniej 3 osobowy (najczęściej 7-11 osób)

9. Models ProcessModel TeamModel Disciplines ReadinessManagementDiscipline RiskManagementDiscipline ProjectManagementDiscipline Komponenty MSF

10. Komponenty MSF

11. Model procesów w MSF Zakończeniewdrażania Gotowość do wdrożenia Zatwierdzeniedokumentuwymagań MSF Zatwierdzenieplanów projektu Wypuszczeniewersji beta

12. Faza wstępna • Utworzenie zespołu projektowego • Analiza dziedzinyproblemowej • Wstępne oszacowanie ryzyka

13. Planowanie • Wybór technologiii środowiska • Dokumenty: • Specyfikacja funkcjonalna • Główny plan projektu • Terminarz projektu

14. Koszty zmian w planie projektu 100 80 60 40 20 Koszt względny Implementacja Testowanie Wdrażanie Faza strategiczna Planowanie Faza projektu

15. Implementacja • Kod aplikacji • Dokumentacja • Proces wdrażania • Procedury operacyjne • Podręcznik użytkownika • Materiały marketingowe • Aktualizacja głównego planu

16. Budowanie kodu (kompilowalnego) w cyklu dobowym. Zalety: Wskaźnik, że zespół programistyczny funkcjonuje Uwidocznienie postępu prac Lepsza motywacja zespołu Daily Build

17. Wersjawewnetrzna n Wersjawewnętrzna n + 1 Implementacja Testowanie Daily Builds Wersje wewnętrzne (Internal Releases) • „Daily builds”kończą się wypuszczeniem działającej wersji alpha

18. Czy wypuszczanie kompilowalnej wersji oprogramowania każdego dnia jest możliwe? • W typowym 4 – 6 miesięcznym projekcie nie będzie to możliwe przez pierwsze 3 do 5 dni. • Potem jest to możliwe.

19. Porady odnośnie Daily Build • Używaj systemu zarządzania wersjami • Każdy pracownik pracuje lokalnie (kopie oprogramowania są na każdym komputerze) • Dzienny kod jest grupowany, kompilowany i każdego ranka publikowany • Zautomatyzuj co się da (batch files itp.)

20. Testowanie Release ReadinessApproved Project PlansApproved ScopeComplete

21. Faza stabilizacji • Wypuszczenie„pilota” • Kod źródłowy • Instrukcja instalacji • Dokumentacja • Raporty o błędach • Aktualizacja dokumentacji projektu

22. Wdrażanie • Instrukcje wdrażania • Repozytorium wszystkich wersji dokumentów, kodów źródłowych,konfiguracji • Raport zamknięcia projektu

23. MSF – model zespołu Cechy: • Zespoły są małe • Współzależne i współpracujące role • Każdy członek ma jasne cele i zadania • Współdzielone zarządzanie projektem • „Zespół rówieśników” – nieograniczona komunikacja

24. Integracja i motywacja zespołu Członek zespołu musi : • Być świadomy wpływu podejmowanych przez siebie decyzji • Być przygotowany na uzależnienia od innych • Jasno określać swoje zaangażowanie • Informować o zagrożeniach Zespół z czasem wypracowuje zaufanie pomiędzy członkami zespołu.

25. Wspólny cel – różne wizje • Każdy członek zespołu ma własną wizję realizacji celu • Jedna narzucona wizja może być przyczyną współzawodnictwa w zespole

26. Łączenie ról

27. Product Management • Identyfikacjai zrozumienieklienta • Analiza wymagań Development Program Management Testing Release Management Product Management User Experience

28. Program Management • Ustalenie budżetu • Harmonogram projektu • Projektowanie całkowitegorozwiązania • Zapewnienie jakości • Zapewnie usług administracyjnych Development Program Management Testing Release Management Product Management User Experience

29. Development • Zbudowanie rozwiązania zgodnego z oczekiwaniami klienta i specyfikacją Development Program Management Testing Release Management Product Management User Experience

30. Testing • Zidentyfikowaniewad i poprawieniebłędów • Testowanie planu i podejścia • Poprawieniejakości • Rozwój specyfikacji testu Development Program Management Testing Release Management Product Management User Experience

31. Release Management • Planowanie wdrożenia Development Program Management Testing Release Management Product Management User Experience

32. User Experience • Poprawa jakości • Rozwój dokumentacji dla systemów wykonawczych • Interfejs użytkownika Development Program Management Testing Release Management Product Management User Experience

33. Podsumowanie • Model zespołu nie jest gwarancją sukcesu projektu • Struktura jest podstawą dla efektywniejszej i pomyślnej pracy • Więcej info na: • Microsoft Solutions Framework: http://www.microsoft.com/msf • Microsoft Operations Framework: http://www.microsoft.com/mof

34. Zarządzanie ryzykiem to: • Ciągłe identyfikowanie ryzyka w projekcie • Ustalanie priorytetów • Implementowanie strategii w cyklu oprogramowania

35. Charakterystyka zarządzania ryzykiem • Obszerna – dotyczy Ludzi, Procesów i Elementów Technologicznych • Stosowana podczas całego cyklu budowy oprogramowania • Łatwe do przystosowania

36. Identyfikacja ryzyka • Identyfikacja ryzykadla rozwijania świadomościzespołu Identify Analyze andPrioritize Learn Plan andSchedule Control Trackand Report

37. Analiza i priorytezacja • Przekształceniedanych dot. ryzyka do formy która umożliwi zespołowiokreśleniapriorytetówi przydzielenie zasobów Identify Analyze andPrioritize Learn Plan andSchedule Control Trackand Report

38. Planowanie • Formułowaniestrategii, planów,działań • Zatwierdzanieplanów • Harmonogram ryzyka łączy się z harmonogramem projektu Identify Analyze andPrioritize Learn Plan andSchedule Control Trackand Report

39. Raportowanie • Monitorowanie stanui postępu • Zbieranie danychdo ewentualnychzmianw planach Identify Analyze andPrioritize Learn Plan andSchedule Control Trackand Report

40. Kontrola • Nanoszenie zmiando projektu jeżeli zmiany planuzarządzaniaryzykiem sąznaczące Identify Analyze andPrioritize Learn Plan andSchedule Control Trackand Report

41. Nauka • Zebranie doświadczeniai nadanie jej formyponownego użycia Identify Analyze andPrioritize Learn Plan andSchedule Control Trackand Report

42. Podsumowanie • Projekty kończą się niepowodzeniem z powodów nietechnologicznych • Framework taki jak MSF zwiększa szanse powodzenia projektu • Nie musisz używać całego MSF

43. Dodatkowe informacje • www.microsoft.com/msf • Kurs Microsoftu: “MSF Essentials” MOC #1846 • Książka: • “Dynamics of Software Development” by Jim McCarthy, Microsoft Press