Metodyka MSF: Różnice pomiędzy wersjami
m (Dodanie MetaData Description) |
m (cleanup bibliografii i rotten links) |
||
Linia 13: | Linia 13: | ||
</ul> | </ul> | ||
}} | }} | ||
'''[[Metodyka]] MSF''' ''(ang. Microsoft Solution Framework)'' to metodyka należąca do informatycznych metodyk wytwórczych, których [[produkt]] końcowy nie jest jednoznacznie określony dla jakiego odbiorcy został stworzony. Jest to zbiór zasad, modeli, wskazówek firmy Microsoft która usestymatyzowała podejście do projektów IT. Metodyka ta, zakłada cykliczność pewnych sekwencji działań, w odniesieniu do tych samych faz projektu, dzięki czemu można etapowo oceniać efekty prac projektowych i wprowadzać pewne zmiany zgodnie z życzeniami Sponsora bądź zmianą celów biznesowych projektu. Służy przede wszystkim do tworzenia oraz wdrażania systemów informatycznych oraz aplikacji tworzonych, gdy nie mamy wyraźnie zidentyfikowanego użytkownika końcowego. Koncentruje się przede wszystkim na fazie realizacji prac, nie zaś na zaspokojeniu oczekiwań klienta, ponieważ jest on w chwili tworzenia systemu nieznany. Tworzy [[system]] "uniwersalny”, który zostanie modyfikowany dopiero po wejściu na [[rynek]] i gdy jego funkcjonalność i celowość zostanie oceniona przez odbiorców. Oprogramowanie, system lub aplikacja, tworzona prze pomocy tej metodyki powinna spełniać oczekiwania klientów, które najpierw są definiowane w zespole projektowym, a następnie weryfikowane rynkowo. Dzieje się tak przede wszystkim dlatego, że najważniejsze jest zminimalizowanie czasu wytwarzania prototypu, co pozwala na sprawdzenie zainteresowania produktem oraz zebranie od testerów informacji oraz uwag, co pozwala na polepszenie funkcjonalności i użyteczności przy tworzeniu kolejnych wersji. | '''[[Metodyka]] MSF''' ''(ang. Microsoft Solution Framework)'' to metodyka należąca do informatycznych metodyk wytwórczych, których [[produkt]] końcowy nie jest jednoznacznie określony dla jakiego odbiorcy został stworzony. Jest to zbiór zasad, modeli, wskazówek firmy Microsoft która usestymatyzowała podejście do projektów IT. Metodyka ta, zakłada cykliczność pewnych sekwencji działań, w odniesieniu do tych samych faz projektu, dzięki czemu można etapowo oceniać efekty prac projektowych i wprowadzać pewne zmiany zgodnie z życzeniami Sponsora bądź zmianą celów biznesowych projektu. Służy przede wszystkim do tworzenia oraz wdrażania systemów informatycznych oraz aplikacji tworzonych, gdy nie mamy wyraźnie zidentyfikowanego użytkownika końcowego. Koncentruje się przede wszystkim na fazie realizacji prac, nie zaś na zaspokojeniu oczekiwań klienta, ponieważ jest on w chwili tworzenia systemu nieznany. Tworzy [[system]] "uniwersalny”, który zostanie modyfikowany dopiero po wejściu na [[rynek]] i gdy jego funkcjonalność i celowość zostanie oceniona przez odbiorców. Oprogramowanie, system lub aplikacja, tworzona prze pomocy tej metodyki powinna spełniać oczekiwania klientów, które najpierw są definiowane w zespole projektowym, a następnie weryfikowane rynkowo. Dzieje się tak przede wszystkim dlatego, że najważniejsze jest zminimalizowanie czasu wytwarzania prototypu, co pozwala na sprawdzenie zainteresowania produktem oraz zebranie od testerów informacji oraz uwag, co pozwala na polepszenie funkcjonalności i użyteczności przy tworzeniu kolejnych wersji. | ||
Linia 25: | Linia 24: | ||
==Ogólne założenia Metodyki MSF a MOP== | ==Ogólne założenia Metodyki MSF a MOP== | ||
Prócz MSF Microsoft uzupełnia swoje [[zarządzanie]] projektami o jeszcze jedną metodykę '''Microsoft Operation Framework (MOP)'''. Obie metodyki posiadają wspólne założenia, lecz różnią się ich zastosowania. Metodyka MSF reprezentuje podejście projektowe ''(ang. build it right)'', strukturę oraz czynności z w perspektywie dostarczania rozwiązań i tworzenia usług IT, natomiast MOP reprezentuje [[podejście procesowe]] ''(ang. run it right)'', a więc strukturę i czynności z perspektywy zarządzania usługami IT. | Prócz MSF Microsoft uzupełnia swoje [[zarządzanie]] projektami o jeszcze jedną metodykę '''Microsoft Operation Framework (MOP)'''. Obie metodyki posiadają wspólne założenia, lecz różnią się ich zastosowania. Metodyka MSF reprezentuje podejście projektowe ''(ang. build it right)'', strukturę oraz czynności z w perspektywie dostarczania rozwiązań i tworzenia usług IT, natomiast MOP reprezentuje [[podejście procesowe]] ''(ang. run it right)'', a więc strukturę i czynności z perspektywy zarządzania usługami IT. | ||
<google>ban728t</google> | <google>ban728t</google> | ||
==Cykl powstawania produktu wg Metodyki MSF== | ==Cykl powstawania produktu wg Metodyki MSF== | ||
Metodyka MSF podzielona jest na 5 faz, przedzielonych kamieniami milowymi. | Metodyka MSF podzielona jest na 5 faz, przedzielonych kamieniami milowymi. | ||
*'''Faza Przygotowania''' ''(ang. Envision)'' – w tej fazie definiowany jest [[zakres]] prac objętych projektem oraz planowaniem działań do wykonania na pierwszym etapie realizacji. | *'''Faza Przygotowania''' ''(ang. Envision)'' – w tej fazie definiowany jest [[zakres]] prac objętych projektem oraz planowaniem działań do wykonania na pierwszym etapie realizacji. | ||
*'''Faza Planowania''' ''(ang. Project Planning)'' – podczas tej fazy dokonuje się analizy ryzyka planowanych prac i ewentualnie modyfikuje się [[plan]] wykonawczy. Od tej pory aż do czasu wystąpienia przewidzianego [[zagrożenia]] jest to tzw. plan bazowy projektu, będący podstawą do kontroli postępów realizacji projektu. | *'''Faza Planowania''' ''(ang. Project Planning)'' – podczas tej fazy dokonuje się analizy ryzyka planowanych prac i ewentualnie modyfikuje się [[plan]] wykonawczy. Od tej pory aż do czasu wystąpienia przewidzianego [[zagrożenia]] jest to tzw. plan bazowy projektu, będący podstawą do kontroli postępów realizacji projektu. | ||
*'''Faza Wytwarzania''' ''(ang. Build)'' – w tej fazie produkt zostaje opracowany oraz dochodzi się w niej do ostatecznej wersji produktu. Jeśli faza ta jest wystarczająca, występuje ona w cyklu tworzenia produktu tylko raz, jednak na ogół tester/klient zgłasza jakieś uwagi co do funkcjonalności lub też zmiany są wywołane innymi czynnikami pochodzącymi z otoczenia organizacji. Z tego powodu przeważnie etap ten jest powtarzany wielokrotnie, dzięki czemu z wytworzonej bazy jest ulepszana kolejna wersja projektu. | *'''Faza Wytwarzania''' ''(ang. Build)'' – w tej fazie produkt zostaje opracowany oraz dochodzi się w niej do ostatecznej wersji produktu. Jeśli faza ta jest wystarczająca, występuje ona w cyklu tworzenia produktu tylko raz, jednak na ogół tester/klient zgłasza jakieś uwagi co do funkcjonalności lub też zmiany są wywołane innymi czynnikami pochodzącymi z otoczenia organizacji. Z tego powodu przeważnie etap ten jest powtarzany wielokrotnie, dzięki czemu z wytworzonej bazy jest ulepszana kolejna wersja projektu. | ||
*'''Faza Stabilizowania''' ''(ang. Stabilize'') – w tej fazie produkt końcowy oceniany jest pod względem funkcjonalności i użyteczności rynkowej przez testerów. | *'''Faza Stabilizowania''' ''(ang. Stabilize'') – w tej fazie produkt końcowy oceniany jest pod względem funkcjonalności i użyteczności rynkowej przez testerów. | ||
*'''Faza wdrażania''' ''(ang. Deploy)'' – w tej fazie produkt końcowy oceniany jest pod względem funkcjonalności i użyteczności rynkowej bezpośrednio przez użytkowników końcowych. | *'''Faza wdrażania''' ''(ang. Deploy)'' – w tej fazie produkt końcowy oceniany jest pod względem funkcjonalności i użyteczności rynkowej bezpośrednio przez użytkowników końcowych. | ||
Linia 45: | Linia 44: | ||
'''4. Wspólna i jasna odpowiedzialność za przydzielone do wykonywania zadania.''' Zasada ta oznacza, że każdy członek zespołu odpowiada za swoją część zarówno przed zespołem jak i przed interesariuszami projektu. Odpowiedzialność więc rozkłada się na cały [[zespół]], a nie na jedną osobę. Ponieważ wszyscy pracują na wspólne [[dobro]], członkowie zespołu mają świadomość, że bezpośrednio od nich zależy [[sukces]] projektu i panuje duże zaangażowanie w wykonywane obowiązki. | '''4. Wspólna i jasna odpowiedzialność za przydzielone do wykonywania zadania.''' Zasada ta oznacza, że każdy członek zespołu odpowiada za swoją część zarówno przed zespołem jak i przed interesariuszami projektu. Odpowiedzialność więc rozkłada się na cały [[zespół]], a nie na jedną osobę. Ponieważ wszyscy pracują na wspólne [[dobro]], członkowie zespołu mają świadomość, że bezpośrednio od nich zależy [[sukces]] projektu i panuje duże zaangażowanie w wykonywane obowiązki. | ||
'''5. Koncentracja na dostarczaniu wartości dodanej dla organizacji.''' Zasada ta pozwala na upewnienie się czy wszyscy członkowie zespołu projektowego w taki sam sposób jak [[lider]] rozumieją [[wartość]] i znaczenie danego projektu w kontekście całej organizacji. Tak samo istotne jest czy członkowie zespołu właściwie identyfikują oczekiwania strategicznych interesariuszy odnoście funkcjonalności produktów końcowych. | '''5. Koncentracja na dostarczaniu wartości dodanej dla organizacji.''' Zasada ta pozwala na upewnienie się czy wszyscy członkowie zespołu projektowego w taki sam sposób jak [[lider]] rozumieją [[wartość]] i znaczenie danego projektu w kontekście całej organizacji. Tak samo istotne jest czy członkowie zespołu właściwie identyfikują oczekiwania strategicznych interesariuszy odnoście funkcjonalności produktów końcowych. | ||
'''6. Otwartość na zmiany.''' Ponieważ specyfika projektów tworzonych przy pomocy Metodyki MSF jest złożona, zespół musi być otwarty na zmiany i [[ciągłe doskonalenie]] produktu końcowego. Członkowie powinni również opracować pewne standardy kontroli odchyleń od pożądanego kierunku, jak też prowadzić analizy, identyfikację i kontrolę wdrażanych zmian. | '''6. Otwartość na zmiany.''' Ponieważ specyfika projektów tworzonych przy pomocy Metodyki MSF jest złożona, zespół musi być otwarty na zmiany i [[ciągłe doskonalenie]] produktu końcowego. Członkowie powinni również opracować pewne standardy kontroli odchyleń od pożądanego kierunku, jak też prowadzić analizy, identyfikację i kontrolę wdrażanych zmian. | ||
'''7. [[Inwestowanie]] w [[jakość]].''' Według MSF nie istnieje stan najwyższej jakości projektu, który pozwolił by na zamknięcie i uznanie otrzymanego produktu za spełniony i gotowy. [[Proces]] dążenia do uzyskania najwyższej jakości nigdy się nie kończy, ponieważ nie istnieje pojęcia najwyższej jakości oprogramowania. Członkowie zespołu muszą trwale dbać o [[jakość produktu]] oraz zadowolenie interesariuszy ale także biorąc pod uwagę ograniczenia tj. [[harmonogram]], [[zasoby]], [[budżet]] i stosowaną technologię pracy. | '''7. [[Inwestowanie]] w [[jakość]].''' Według MSF nie istnieje stan najwyższej jakości projektu, który pozwolił by na zamknięcie i uznanie otrzymanego produktu za spełniony i gotowy. [[Proces]] dążenia do uzyskania najwyższej jakości nigdy się nie kończy, ponieważ nie istnieje pojęcia najwyższej jakości oprogramowania. Członkowie zespołu muszą trwale dbać o [[jakość produktu]] oraz zadowolenie interesariuszy ale także biorąc pod uwagę ograniczenia tj. [[harmonogram]], [[zasoby]], [[budżet]] i stosowaną technologię pracy. | ||
Linia 64: | Linia 63: | ||
==Bibliografia== | ==Bibliografia== | ||
* Giotis, T. C. (2007). ''How to deliver successful IT projects using MSF team model and MSF process model''. Paper presented at PMI® Global Congress 2007—EMEA, Budapest, Hungary. Newtown Square, PA: | <noautolinks> | ||
* Mastalerz M. (2015). ''[https://wneiz.pl/nauka_wneiz/studia_inf/36-2015/si-36-75.pdf Zwinne podejście w zarządzaniu przedsiębiorstwem]'', Zeszyty Naukowe Uniwersytetu Szczecińskiego, Studia Informatica nr 36 | * Giotis, T. C. (2007). ''How to deliver successful IT projects using MSF team model and MSF process model''. Paper presented at PMI® Global Congress 2007—EMEA, Budapest, Hungary. Newtown Square, PA: Project Management Institute | ||
* Sierzputowski M. ''[http://www.ee.pw.edu.pl/~sarwasg/PPIT/Projekt%20z%20wykorzystaniem%20Visual%20Studio%20Online%20TFS.pdf Zarządzanie projektem IT z wykorzystaniem usług Microsoft Visual Studio Team Foundation Server]'', Politechnika Warszawska, Wydział Elektryczny | * Mastalerz M. (2015). ''[https://wneiz.pl/nauka_wneiz/studia_inf/36-2015/si-36-75.pdf Zwinne podejście w zarządzaniu przedsiębiorstwem]'', Zeszyty Naukowe Uniwersytetu Szczecińskiego, Studia Informatica nr 36 | ||
* Sobestiańczyk T. (2013). '' | * Sierzputowski M. ''[http://www.ee.pw.edu.pl/~sarwasg/PPIT/Projekt%20z%20wykorzystaniem%20Visual%20Studio%20Online%20TFS.pdf Zarządzanie projektem IT z wykorzystaniem usług Microsoft Visual Studio Team Foundation Server]'', Politechnika Warszawska, Wydział Elektryczny | ||
* Trocki M. (2017). ''Metodyki i standardy zarządzania projektami''. Polskie Wydawnictwo Ekonomiczne | * Sobestiańczyk T. (2013). ''Standardy Microsoft Solution Framework w zarządzaniu projektami informatycznymi'', Zeszyty Naukowe Politechniki Śląskiej, Organizacja i Zarządzanie z. 67 | ||
* Trocki M. (2017). ''Metodyki i standardy zarządzania projektami''. Polskie Wydawnictwo Ekonomiczne | |||
</noautolinks> | |||
{{a|Martyna Żwak}} | {{a|Martyna Żwak}} |
Wersja z 09:58, 28 paź 2023
Metodyka MSF |
---|
Polecane artykuły |
Metodyka MSF (ang. Microsoft Solution Framework) to metodyka należąca do informatycznych metodyk wytwórczych, których produkt końcowy nie jest jednoznacznie określony dla jakiego odbiorcy został stworzony. Jest to zbiór zasad, modeli, wskazówek firmy Microsoft która usestymatyzowała podejście do projektów IT. Metodyka ta, zakłada cykliczność pewnych sekwencji działań, w odniesieniu do tych samych faz projektu, dzięki czemu można etapowo oceniać efekty prac projektowych i wprowadzać pewne zmiany zgodnie z życzeniami Sponsora bądź zmianą celów biznesowych projektu. Służy przede wszystkim do tworzenia oraz wdrażania systemów informatycznych oraz aplikacji tworzonych, gdy nie mamy wyraźnie zidentyfikowanego użytkownika końcowego. Koncentruje się przede wszystkim na fazie realizacji prac, nie zaś na zaspokojeniu oczekiwań klienta, ponieważ jest on w chwili tworzenia systemu nieznany. Tworzy system "uniwersalny”, który zostanie modyfikowany dopiero po wejściu na rynek i gdy jego funkcjonalność i celowość zostanie oceniona przez odbiorców. Oprogramowanie, system lub aplikacja, tworzona prze pomocy tej metodyki powinna spełniać oczekiwania klientów, które najpierw są definiowane w zespole projektowym, a następnie weryfikowane rynkowo. Dzieje się tak przede wszystkim dlatego, że najważniejsze jest zminimalizowanie czasu wytwarzania prototypu, co pozwala na sprawdzenie zainteresowania produktem oraz zebranie od testerów informacji oraz uwag, co pozwala na polepszenie funkcjonalności i użyteczności przy tworzeniu kolejnych wersji. Metodyka MSF może być stosowana do wszystkich rodzajów projektów, jednak ze względu na swój potencjał i podejście najczęściej stosuje się ją do dużych i złożonych projektach przeważnie w branży IT, ale także np. w przemyśle lotniczym.
Metodyka MSF została po raz pierwszy zaprezentowana w 1993 r. przez pracowników Microsoft Consulting Services. Od tego roku do roku 2005 MSF ewoluowało do wersji 4.0, gdy zostało zmienionych kilka istotnych elementów oraz model procesu wytwarzania oprogramowania (ang. The MSF Governance Model, MOP) oraz model zespołu projektowego (ang. The MSF Team Model, VSTS).
TL;DR
Metodyka MSF to zbiór zasad i modeli firmy Microsoft do zarządzania projektami IT. Koncentruje się na fazie realizacji prac i tworzeniu uniwersalnych systemów, które są modyfikowane po wejściu na rynek. Metodyka składa się z 5 faz: przygotowania, planowania, wytwarzania, stabilizowania i wdrażania. Wśród zasad MSF znajdują się otwarta komunikacja, wspólna wizja projektu, równość w zespole, wspólna odpowiedzialność, koncentracja na wartości dodanej, otwartość na zmiany, inwestowanie w jakość oraz uczenie się na doświadczeniach. Zaletami MSF są efektywne rozwiązania problemów projektu, jasne cele i skuteczne zarządzanie ryzykiem, a wadami brak uwzględnienia wzajemnie oddziaływających zagrożeń i brak globalnego mechanizmu ryzyka.
Ogólne założenia Metodyki MSF a MOP
Prócz MSF Microsoft uzupełnia swoje zarządzanie projektami o jeszcze jedną metodykę Microsoft Operation Framework (MOP). Obie metodyki posiadają wspólne założenia, lecz różnią się ich zastosowania. Metodyka MSF reprezentuje podejście projektowe (ang. build it right), strukturę oraz czynności z w perspektywie dostarczania rozwiązań i tworzenia usług IT, natomiast MOP reprezentuje podejście procesowe (ang. run it right), a więc strukturę i czynności z perspektywy zarządzania usługami IT.
Cykl powstawania produktu wg Metodyki MSF
Metodyka MSF podzielona jest na 5 faz, przedzielonych kamieniami milowymi.
- Faza Przygotowania (ang. Envision) – w tej fazie definiowany jest zakres prac objętych projektem oraz planowaniem działań do wykonania na pierwszym etapie realizacji.
- Faza Planowania (ang. Project Planning) – podczas tej fazy dokonuje się analizy ryzyka planowanych prac i ewentualnie modyfikuje się plan wykonawczy. Od tej pory aż do czasu wystąpienia przewidzianego zagrożenia jest to tzw. plan bazowy projektu, będący podstawą do kontroli postępów realizacji projektu.
- Faza Wytwarzania (ang. Build) – w tej fazie produkt zostaje opracowany oraz dochodzi się w niej do ostatecznej wersji produktu. Jeśli faza ta jest wystarczająca, występuje ona w cyklu tworzenia produktu tylko raz, jednak na ogół tester/klient zgłasza jakieś uwagi co do funkcjonalności lub też zmiany są wywołane innymi czynnikami pochodzącymi z otoczenia organizacji. Z tego powodu przeważnie etap ten jest powtarzany wielokrotnie, dzięki czemu z wytworzonej bazy jest ulepszana kolejna wersja projektu.
- Faza Stabilizowania (ang. Stabilize) – w tej fazie produkt końcowy oceniany jest pod względem funkcjonalności i użyteczności rynkowej przez testerów.
- Faza wdrażania (ang. Deploy) – w tej fazie produkt końcowy oceniany jest pod względem funkcjonalności i użyteczności rynkowej bezpośrednio przez użytkowników końcowych.
Podstawowe zasady Metodyki MSF
1. Sprzyjanie otwartej i czytelnej komunikacji w zespole projektowym. Wg Microsoft Corporation zasada ta pozwala na odpowiednio wczesne wykrycie pewnych odchyleń projektowych oraz przekazania informacji o powstających produktach projektu. Pozwala ona także na eliminowaniu konfliktów w zespole projektowym oraz na integrację członków zespołu.
2. Wspólna wizja projektu. Zasada ta pozwala na uświadomienie członkom zespołu istotę, cel i zakres realizowanego projektu, tak aby wszyscy łącznie z liderem rozumieli tak samo wizję projektu. Bez wspólnej wizji nie jest możliwe ulepszanie oprogramowania i dążenie do zaspokajania oczekiwań głównych klientów bez pojawiania się konfliktów w zespole.
3. Upełnomocnianie członków grupy. Wg modelu MSF w zespole projektowym panuje równość. Każdy z członków otrzymuje określone zadania z których jest rozliczany, a także posiada pełnomocnictwo w stopniu potrzebnym do modyfikacji swojej części. Zespoły projektowe łatwiej niż w innych w innych strukturach hierarchicznych akceptują nakładane na nich obowiązki i odpowiedzialność oraz znacznie efektywniej dążą do celu
4. Wspólna i jasna odpowiedzialność za przydzielone do wykonywania zadania. Zasada ta oznacza, że każdy członek zespołu odpowiada za swoją część zarówno przed zespołem jak i przed interesariuszami projektu. Odpowiedzialność więc rozkłada się na cały zespół, a nie na jedną osobę. Ponieważ wszyscy pracują na wspólne dobro, członkowie zespołu mają świadomość, że bezpośrednio od nich zależy sukces projektu i panuje duże zaangażowanie w wykonywane obowiązki.
5. Koncentracja na dostarczaniu wartości dodanej dla organizacji. Zasada ta pozwala na upewnienie się czy wszyscy członkowie zespołu projektowego w taki sam sposób jak lider rozumieją wartość i znaczenie danego projektu w kontekście całej organizacji. Tak samo istotne jest czy członkowie zespołu właściwie identyfikują oczekiwania strategicznych interesariuszy odnoście funkcjonalności produktów końcowych.
6. Otwartość na zmiany. Ponieważ specyfika projektów tworzonych przy pomocy Metodyki MSF jest złożona, zespół musi być otwarty na zmiany i ciągłe doskonalenie produktu końcowego. Członkowie powinni również opracować pewne standardy kontroli odchyleń od pożądanego kierunku, jak też prowadzić analizy, identyfikację i kontrolę wdrażanych zmian.
7. Inwestowanie w jakość. Według MSF nie istnieje stan najwyższej jakości projektu, który pozwolił by na zamknięcie i uznanie otrzymanego produktu za spełniony i gotowy. Proces dążenia do uzyskania najwyższej jakości nigdy się nie kończy, ponieważ nie istnieje pojęcia najwyższej jakości oprogramowania. Członkowie zespołu muszą trwale dbać o jakość produktu oraz zadowolenie interesariuszy ale także biorąc pod uwagę ograniczenia tj. harmonogram, zasoby, budżet i stosowaną technologię pracy.
8. Uczenie się na doświadczeniach zespołu i organizacji. Wg Metodyki MSF członkowie powinni ciągle udoskonalać swoje umiejętności oraz poszerzać wiedzę a także zdobywać doświadczenie w ramach realizacji podobnych projektów. Pozwala to na bardziej efektywną pracę i realizację ciągle stawianych przed sobą zadań w ramach projektu.
Zalety i wady metodyki MSF
Zalety:
- Efektywne rozwiązania problemów projektu
- Wyznaczanie jasnych i motywujących celów dla wszystkich członków zespołu projektowego
- Skuteczne zarządzanie głównymi czynnikami ryzyka oraz zmianami zakresu projektu
Wady:
- Brak uwzględniania wzajemnie oddziaływających zagrożeń
- Brak mechanizmu globalnego ryzyka dla całego projektu
Bibliografia
- Giotis, T. C. (2007). How to deliver successful IT projects using MSF team model and MSF process model. Paper presented at PMI® Global Congress 2007—EMEA, Budapest, Hungary. Newtown Square, PA: Project Management Institute
- Mastalerz M. (2015). Zwinne podejście w zarządzaniu przedsiębiorstwem, Zeszyty Naukowe Uniwersytetu Szczecińskiego, Studia Informatica nr 36
- Sierzputowski M. Zarządzanie projektem IT z wykorzystaniem usług Microsoft Visual Studio Team Foundation Server, Politechnika Warszawska, Wydział Elektryczny
- Sobestiańczyk T. (2013). Standardy Microsoft Solution Framework w zarządzaniu projektami informatycznymi, Zeszyty Naukowe Politechniki Śląskiej, Organizacja i Zarządzanie z. 67
- Trocki M. (2017). Metodyki i standardy zarządzania projektami. Polskie Wydawnictwo Ekonomiczne
Autor: Martyna Żwak