forked from AITech/aitech-ppb-pbr
407 lines
15 KiB
Plaintext
407 lines
15 KiB
Plaintext
|
{
|
||
|
"cells": [
|
||
|
{
|
||
|
"cell_type": "markdown",
|
||
|
"metadata": {},
|
||
|
"source": [
|
||
|
"![Logo 1](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech1.jpg)\n",
|
||
|
"<div class=\"alert alert-block alert-info\">\n",
|
||
|
"<h1> Przygotowanie do projektu badawczo-rozwojowego</h1>\n",
|
||
|
"<h2> 4. <i>Metodologia Prince2</i>[wykład]</h2> \n",
|
||
|
"<h3>Krzysztof Jassem (2021)</h3>\n",
|
||
|
"</div>\n",
|
||
|
"\n",
|
||
|
"![Logo 2](https://git.wmi.amu.edu.pl/AITech/Szablon/raw/branch/master/Logotyp_AITech2.jpg)"
|
||
|
]
|
||
|
},
|
||
|
{
|
||
|
"cell_type": "markdown",
|
||
|
"metadata": {},
|
||
|
"source": [
|
||
|
"## Metodologia Prince2\n",
|
||
|
"Prince2 (PRojects IN Controlled Environments) to metoda **zarządzania** *projektami*\n",
|
||
|
"niezależna od zmiennych projektu, takich jak: środowisko, skala, typ, organizacjakultura, położenie geograficzne."
|
||
|
]
|
||
|
},
|
||
|
{
|
||
|
"cell_type": "markdown",
|
||
|
"metadata": {},
|
||
|
"source": [
|
||
|
"<div class=\"alert alert-block alert-success\">\n",
|
||
|
" \n",
|
||
|
"<h3>Projekt</h3> \n",
|
||
|
"Projekt to organizacja założona:\n",
|
||
|
" \n",
|
||
|
"<p> na <b>określony czas</b> </p>\n",
|
||
|
"<p> w celu dostarczenia <b>rozwiązania</b></p>\n",
|
||
|
" <p> dla określonej <b>potrzeby</b> biznesowej </p> \n",
|
||
|
"</div>"
|
||
|
]
|
||
|
},
|
||
|
{
|
||
|
"cell_type": "markdown",
|
||
|
"metadata": {},
|
||
|
"source": [
|
||
|
"<div class=\"alert alert-info alert-success\">\n",
|
||
|
" \n",
|
||
|
"<h3>Przykład projektu</h3> \n",
|
||
|
" \n",
|
||
|
"<p><b>Potrzeba biznesowa:</b> Oszczędzenie 70% czasu biura obsługi klienta.</p>\n",
|
||
|
"<p><b>Rozwiązanie:</b> System automatycznego obiegu dokumentów. </p>\n",
|
||
|
"<p><b>Czas:</b> 6 miesięcy </p> \n",
|
||
|
"<p><b>Projekt:</b> Zespół ludzi wydelegowanych na 6 miesięcy dla dostarczenia systemu automatycznego obiegu dokumentów w celu zaoszczędzenia 70\\% czasu biura obsługi klienta. </p> \n",
|
||
|
"</div>\n"
|
||
|
]
|
||
|
},
|
||
|
{
|
||
|
"cell_type": "markdown",
|
||
|
"metadata": {},
|
||
|
"source": [
|
||
|
"### Cechy charakterystyczne projektu\n",
|
||
|
"Projekt jest przeciwieństwiem pojęcia \"buiseness as usual\" (działanie rutynowe). Projekt od rutyny odróżniają następujące cechy\n",
|
||
|
"\n",
|
||
|
" * Zmiana - projekt to środek do przeprowadzenia zmiany.\n",
|
||
|
" * Tymczasowość - projekt ma swoją datę początku i końca.\n",
|
||
|
" * Wielofukcyjność - przy projektach zaangażowani są ludzie o różnych kompetencjach.\n",
|
||
|
" * Wyjątkowość - każdy projekt jest wyjątkowy (nawet jak jest jakiś wzorzec projektu, to każdy projekt się czymś wyróżnia: albo zespołem, albo klientem, albo położeniem geograficznym, itp.\n",
|
||
|
" * Niepewność - projekty ze swojej natury są ryzykowne, bo mają wprowadzić zmianę.\n",
|
||
|
" ### Zarządzanie projektem\n",
|
||
|
" Zarządzanie projektem to:\n",
|
||
|
" - planowanie zadań\n",
|
||
|
" - delegowanie ludzi do zadań\n",
|
||
|
" - monitorowanie wykonywania zadań\n",
|
||
|
" - kontrolowanie\n",
|
||
|
" aby:\n",
|
||
|
" - osiągnąć cel projektu\n",
|
||
|
" - w wyznaczonym czasie\n",
|
||
|
" - przy zachowaniu przeznaczonych kosztów\n",
|
||
|
" \n",
|
||
|
" ### Aspekty kontroli w zarządzaniu projektem\n",
|
||
|
" Projekt należy kontrolować pod następującymi apektami:\n",
|
||
|
" - koszty (czy przestrzegamy kosztów projektu?)\n",
|
||
|
" - czas (kiedy skończymy?)\n",
|
||
|
" - jakość (czy produkt działa zgodnie z oczekiwaniami?)\n",
|
||
|
" - zakres (czy zakres działania projektu będzie pokrywa się z oczekiwaniami?)\n",
|
||
|
" - korzyści dla klienta (czy użytkownik naszego produktu uzyskuje planowaną korzyść?)\n",
|
||
|
" - ryzyko (jakie jest ryzyko niepowodzenia lub niepożądanych skutków projektu i czy potrafimy to ryzyko zminimalizować?)"
|
||
|
]
|
||
|
},
|
||
|
{
|
||
|
"cell_type": "markdown",
|
||
|
"metadata": {},
|
||
|
"source": [
|
||
|
"## Metodologie zarządzania projektem \n",
|
||
|
"(por. https://startnearshoring.com/knowledge/it-project-management-a-quick-guide-to-tools-and-methodologies/)"
|
||
|
]
|
||
|
},
|
||
|
{
|
||
|
"cell_type": "markdown",
|
||
|
"metadata": {},
|
||
|
"source": [
|
||
|
"### Metodologie tradycyjne\n",
|
||
|
"Metodologie tradycyjne charakteryzują się działaniem \"krok po kroku\". Kładą nacisk na:\n",
|
||
|
" * skrupulatne zbieranie wymagań\n",
|
||
|
" * dokładną analizę\n",
|
||
|
" * istotność dokumentacji.\n",
|
||
|
"Sprawdzają się w projektach z dobrze określonymi wymaganiami już od początku. \n",
|
||
|
"Produkt ma być realizowany i dostarczony zgodnie z określonym planem. W planowaniu nie analizuje się szczegółowo, w jaki sposób produkt ma być wykonany. "
|
||
|
]
|
||
|
},
|
||
|
{
|
||
|
"cell_type": "markdown",
|
||
|
"metadata": {},
|
||
|
"source": [
|
||
|
"#### Waterfall (model kaskadowy) (wg Wikipedia)\n",
|
||
|
"> Model polega on na wykonywaniu podstawowych czynności jako odrębnych faz projektowych, kolejno po sobie. Jeśli któraś z faz nie powodzi się, to następuje nawrót do poprzedniej fazy. Każda czynność to schodek (kaskady):\n",
|
||
|
"> * Planowanie systemu (w tym specyfikacja wymagań).\n",
|
||
|
"> * Analiza systemu (w tym analiza wymagań i studium wykonalności).\n",
|
||
|
"> * Projekt systemu (poszczególnych struktur itp.).\n",
|
||
|
"> * Implementacja (wytworzenie kodu).\n",
|
||
|
"> * Testowanie (poszczególnych elementów systemu oraz elementów połączonych w całość).\n",
|
||
|
"> * Wdrożenie i pielęgnacja powstałego systemu.\n",
|
||
|
"\n",
|
||
|
"Model kaskadowy sprawdza się dla małych, krótkich projektów z ustalonymi wymaganiami, które nie mogą zmienić się w trakcie realizacji projektu."
|
||
|
]
|
||
|
},
|
||
|
{
|
||
|
"cell_type": "markdown",
|
||
|
"metadata": {},
|
||
|
"source": [
|
||
|
"<div class=\"alert alert-block alert-success\">\n",
|
||
|
" \n",
|
||
|
"<h5>Plusy modelu kaskadowego</h5> \n",
|
||
|
"<ol>\n",
|
||
|
" <li> Projekty są dobrze określone, a zatem łatwe w zarządzaniu. </li>\n",
|
||
|
" <li> Przebieg projektu opisany jest liniowo (sekwencyjnie), przez co łatwiej go zrozumieć.</li>\n",
|
||
|
" </ol>"
|
||
|
]
|
||
|
},
|
||
|
{
|
||
|
"cell_type": "markdown",
|
||
|
"metadata": {},
|
||
|
"source": [
|
||
|
"<div class=\"alert alert-info alert-success\">\n",
|
||
|
" \n",
|
||
|
"<h5>Minusy modelu kaskadowego</h5> \n",
|
||
|
"<ol>\n",
|
||
|
" <li> Dokonanie wszelkich zmian w projekcie jest kosztowne.</li>\n",
|
||
|
" <li> Jakikolwiek namacalny efekt działań jest wdoczny dopiero po dłuższym czasie.</li>\n",
|
||
|
"</ol>"
|
||
|
]
|
||
|
},
|
||
|
{
|
||
|
"cell_type": "markdown",
|
||
|
"metadata": {},
|
||
|
"source": [
|
||
|
"#### Prince 2\n",
|
||
|
"W metodyce Prince2 projekt dzielony jest na etapy. Po każdym etapie następuje uszczegółowienie planu najbliższych etapów.\n",
|
||
|
"\n",
|
||
|
"W Prince 2 nacisk kładzie się na osiągnięcie założonych produktów biznesowych. \n",
|
||
|
"Struktura organizacyjna jest precyzyjnie określona - każdy członek teamu ma przypisaną rolę. \n",
|
||
|
"Ważną rolę odgrywają procedury raportowania."
|
||
|
]
|
||
|
},
|
||
|
{
|
||
|
"cell_type": "markdown",
|
||
|
"metadata": {},
|
||
|
"source": [
|
||
|
"<div class=\"alert alert-block alert-success\">\n",
|
||
|
" \n",
|
||
|
"<h5>Plusy modelu Prince2</h5> \n",
|
||
|
"<ol>\n",
|
||
|
" <li> Podział projektu na etapy ułatwia kontrolę nad projektem (sprawdzamy, czy na końcu etapu mamy planowany rezultat).</li>\n",
|
||
|
" <li> Dobrze dokumentuje przebieg projektu.</li>\n",
|
||
|
" </ol>"
|
||
|
]
|
||
|
},
|
||
|
{
|
||
|
"cell_type": "markdown",
|
||
|
"metadata": {},
|
||
|
"source": [
|
||
|
"<div class=\"alert alert-info alert-success\">\n",
|
||
|
" \n",
|
||
|
"<h5>Minusy modelu Prince2</h5> \n",
|
||
|
"<ol>\n",
|
||
|
" <li> Każda zmiana wymaga \"łańcucha akceptacji\" i wymusza zmiany w dokumentacji. </li>\n",
|
||
|
" <li> Tworzenie obszernej dokumentacji jest pracochłonne. </li>\n",
|
||
|
"</ol>"
|
||
|
]
|
||
|
},
|
||
|
{
|
||
|
"cell_type": "markdown",
|
||
|
"metadata": {},
|
||
|
"source": [
|
||
|
"#### PMBOX (wg Wikipedia)\n",
|
||
|
"Projekt składa się z ciągu etapów lub faz w których od inicjacji do zamknięcia.\n",
|
||
|
"Grupy procesów\n",
|
||
|
"* procesy rozpoczęcia (inicjowania) - zdefiniowanie nowego projektu (lub nowej fazy w istniejącym projekcie)\n",
|
||
|
"* procesy planowania - \n",
|
||
|
" * określenie zakresu i celu projektu \n",
|
||
|
" * zdefiniowanie akcji prowadzących do realizacji celu,\n",
|
||
|
" * procesy realizacji - realizacja wymagań projektowych\n",
|
||
|
" * procesy monitorowania i kontroli - śledzenie, przeglądanie postępu oraz wydajności prac projektowych; ewentualnie inicjacja zmian w planie,\n",
|
||
|
" * procesy zakończenia (zamknięcia) - formalne zakończenie projektu.\n",
|
||
|
"\n",
|
||
|
"Procesy połączone są ze sobą wkładami i rezultatami. Rezultaty z jednego procesu mogą być wkładem do następnych. \n",
|
||
|
"\n",
|
||
|
"PMBOX oferuje wiele różnych procesów do wyboru. Zadaniem menadżera projektu jest wybór procesów odpowiednich do projektu. "
|
||
|
]
|
||
|
},
|
||
|
{
|
||
|
"cell_type": "markdown",
|
||
|
"metadata": {},
|
||
|
"source": [
|
||
|
"<div class=\"alert alert-block alert-success\">\n",
|
||
|
" \n",
|
||
|
"<h5>Plusy modelu PMBOX</h5> \n",
|
||
|
"<ol>\n",
|
||
|
" <li> Podczas trwania projektu można dodawać nowe narzędzia i techniki działania (ze względu na różnorodność dostępnych procesów) </li>\n",
|
||
|
" <li> Kierownik projektu ma dostęp do pełnej informacji o zachodzących procesach.</li>\n",
|
||
|
" </ol>"
|
||
|
]
|
||
|
},
|
||
|
{
|
||
|
"cell_type": "markdown",
|
||
|
"metadata": {},
|
||
|
"source": [
|
||
|
"<div class=\"alert alert-info alert-success\">\n",
|
||
|
" \n",
|
||
|
"<h5>Minusy modelu PMBOX</h5> \n",
|
||
|
"<ol>\n",
|
||
|
" <li> Mała elastyczność </li>\n",
|
||
|
" <li> Centralizacja władzy </li>\n",
|
||
|
"</ol>"
|
||
|
]
|
||
|
},
|
||
|
{
|
||
|
"cell_type": "markdown",
|
||
|
"metadata": {},
|
||
|
"source": [
|
||
|
"### Metodologie zwinne\n",
|
||
|
"Metodologie zwinne przeciwstawiają się metodologiom tradycyjnym w czterech płaszczyznach:\n",
|
||
|
" * Inteakcje między ludźmi podczas pracy są ważniejsze niż procesy i narzędzia.\n",
|
||
|
" * Działające oprogramowanie (choćby prototyp) jest ważniejsze niż rozbudowana dokumentacja.\n",
|
||
|
" * Współpraca z klientem / uzytkownikiem podczas pracy jest ważniejsza niż negocjowanie umowy.\n",
|
||
|
" * Reakcja na zmiany jest ważniejsza niż stosowanie się do planu."
|
||
|
]
|
||
|
},
|
||
|
{
|
||
|
"cell_type": "markdown",
|
||
|
"metadata": {},
|
||
|
"source": [
|
||
|
"#### Scrum\n",
|
||
|
"Scrum jest moetodologią, w której kluczowym elementem jest **sprint** - faza, która kończy się działającym prototypem. Po każdym sprincie następuje planowanie działań w kolejnym sprincie - biorące pod uwagę dotychczasowe doświadczenia."
|
||
|
]
|
||
|
},
|
||
|
{
|
||
|
"cell_type": "markdown",
|
||
|
"metadata": {},
|
||
|
"source": [
|
||
|
"<div class=\"alert alert-block alert-success\">\n",
|
||
|
" \n",
|
||
|
"<h5>Plusy modelu Scrum</h5> \n",
|
||
|
"<ol>\n",
|
||
|
" <li> Szybkie dostarczanie działającego systemu - również w wersji końcowej (na rynek).</li>\n",
|
||
|
" <li> Elastyczne dostosowywanie się do zmieniających się potrzeb biznesowych.</li>\n",
|
||
|
" </ol>"
|
||
|
]
|
||
|
},
|
||
|
{
|
||
|
"cell_type": "markdown",
|
||
|
"metadata": {},
|
||
|
"source": [
|
||
|
"<div class=\"alert alert-info alert-success\"> \n",
|
||
|
"<h5>Minusy modelu Scrum</h5> \n",
|
||
|
"<ol>\n",
|
||
|
" <li> Wymagana jest współpraca ze strony klienta (użytkownika) - a o to niełatwo! </li>\n",
|
||
|
" <li> Konieczne jest zaangażowanie i zrozumienie koncepcji ze strony całego zespołu wykonawców. </li>\n",
|
||
|
"</ol>"
|
||
|
]
|
||
|
},
|
||
|
{
|
||
|
"cell_type": "markdown",
|
||
|
"metadata": {},
|
||
|
"source": [
|
||
|
"#### Kanban\n",
|
||
|
"Kanban jest metodologią, w której kluczowym elementem jest **wizualizacja** przebiegu projektu - najczęściej za pomocą tablicy, na której przesuwane są zadania wraz z postępem ich wykonania (od początku do zakończenia)."
|
||
|
]
|
||
|
},
|
||
|
{
|
||
|
"cell_type": "markdown",
|
||
|
"metadata": {},
|
||
|
"source": [
|
||
|
"<div class=\"alert alert-block alert-success\">\n",
|
||
|
" \n",
|
||
|
"<h5>Plusy modelu Kanban</h5> \n",
|
||
|
"<ol>\n",
|
||
|
" <li> Motywujący wpływ na pracę zespołową </li>\n",
|
||
|
" <li> Wysoka wydajność poprzez zapobieganie zatorom w pracy</li>\n",
|
||
|
" </ol>"
|
||
|
]
|
||
|
},
|
||
|
{
|
||
|
"cell_type": "markdown",
|
||
|
"metadata": {},
|
||
|
"source": [
|
||
|
"<div class=\"alert alert-info alert-success\"> \n",
|
||
|
"<h5>Minusy modelu Kanban</h5> \n",
|
||
|
"<ol>\n",
|
||
|
" <li> Wysoko wskazane jest doświadczenie przynajmniej jednego członka zespołu. </li>\n",
|
||
|
" <li> Istotne dla sukcesu jest ustawienie zadań w odpowiedniej kolejności. </li>\n",
|
||
|
"</ol>"
|
||
|
]
|
||
|
},
|
||
|
{
|
||
|
"cell_type": "markdown",
|
||
|
"metadata": {},
|
||
|
"source": [
|
||
|
"## Zasady Prince2\n",
|
||
|
"### Ciągłe uzasadnienie biznesowe\n",
|
||
|
"* Musi istnieć jakiś biznesowy (przeliczalny na pieniądze) powód do rozpoczęcia projektu. \n",
|
||
|
"* Uzasadnienie biznesowe musi mieć miejsce podczas całego projektu - trzeba to cały czas sprawdzać.\n",
|
||
|
"\n",
|
||
|
"### Nauka przez doświadczenie\n",
|
||
|
"* Podczas wykonywania projektu należy wyciągać wnioski - uczyć się lekcji.\n",
|
||
|
"* Lekcje te powinny być zapisywane.\n",
|
||
|
"\n",
|
||
|
"### Określone role i odpowiedzialności\n",
|
||
|
"W projekcie wykonawcy mają określone role i określone zakresy odpowiedzialności. Dotyczy to również przedstawicieli klienta.\n",
|
||
|
"\n",
|
||
|
"### Praca etapami\n",
|
||
|
"Projekt jest planowany i monitorowany etap po etapie.\n",
|
||
|
"\n",
|
||
|
"### Zarządzanie wyjątkami\n",
|
||
|
"Jeśli przebieg projektu mieści się w granicach tolerancji (czas, pieniądze itp.), to nie ma potrzeby alarmować przełożonych. W przypadku **wyjątku** (wyjście poza granicę tolerancji), trzeba powiadomić przełożonych.\n",
|
||
|
"\n",
|
||
|
"### Koncentracja na produkcie\n",
|
||
|
"Najważniejsza w projekcie jest jakość dostarczanego produktu.\n",
|
||
|
"\n",
|
||
|
"### Dostrajanie\n",
|
||
|
"Metodyka zarządzania powinna być dostrojona do specyfiki projektu: środowisko, złożoność, zespół, ryzyko itp."
|
||
|
]
|
||
|
},
|
||
|
{
|
||
|
"cell_type": "code",
|
||
|
"execution_count": null,
|
||
|
"metadata": {},
|
||
|
"outputs": [],
|
||
|
"source": []
|
||
|
},
|
||
|
{
|
||
|
"cell_type": "markdown",
|
||
|
"metadata": {},
|
||
|
"source": [
|
||
|
"## Motywy przewodnie Prince2 (themes)"
|
||
|
]
|
||
|
},
|
||
|
{
|
||
|
"cell_type": "markdown",
|
||
|
"metadata": {},
|
||
|
"source": [
|
||
|
"## Procesy Prince2"
|
||
|
]
|
||
|
},
|
||
|
{
|
||
|
"cell_type": "markdown",
|
||
|
"metadata": {},
|
||
|
"source": [
|
||
|
"## Artefakty w Prince2"
|
||
|
]
|
||
|
},
|
||
|
{
|
||
|
"cell_type": "markdown",
|
||
|
"metadata": {},
|
||
|
"source": [
|
||
|
"## Role w Prince2"
|
||
|
]
|
||
|
}
|
||
|
],
|
||
|
"metadata": {
|
||
|
"author": "Krzysztof Jassem",
|
||
|
"email": "jassem@amu.edu.pl",
|
||
|
"kernelspec": {
|
||
|
"display_name": "Python 3",
|
||
|
"language": "python",
|
||
|
"name": "python3"
|
||
|
},
|
||
|
"lang": "pl",
|
||
|
"language_info": {
|
||
|
"codemirror_mode": {
|
||
|
"name": "ipython",
|
||
|
"version": 3
|
||
|
},
|
||
|
"file_extension": ".py",
|
||
|
"mimetype": "text/x-python",
|
||
|
"name": "python",
|
||
|
"nbconvert_exporter": "python",
|
||
|
"pygments_lexer": "ipython3",
|
||
|
"version": "3.8.5"
|
||
|
},
|
||
|
"subtitle": "04. Metodologia Prince 2[wykład]",
|
||
|
"title": "Przygotowanie do projektu badawczo-rozwojowego",
|
||
|
"year": "2021"
|
||
|
},
|
||
|
"nbformat": 4,
|
||
|
"nbformat_minor": 4
|
||
|
}
|