- \n",
+ "
- techne: sztuka, umiejętność \n", + "
- logia: nauka (czegoś) \n", + "
\n",
+ "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "# Metodyki adaptacyjne w programowaniu (Agile Software Development)"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "Systemy informatyczne analizy danych
\n", + ".6 Metodyki adaptacyjne w programowaniu[wykład]
\n", + "Krzysztof Jassem (2023)
\n", + "\n",
+ "\n",
+ " Agile (zwinny) to pojęcie odnoszące się do szybkości i sprawności w działaniu i myśleniu.\n",
+ " \n",
+ "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "## Manifest Agile\n",
+ " * opublikowany w roku 2001\n",
+ " * autorzy: 17 teoretyków i praktyków programowania\n",
+ " * 4 wartości\n",
+ " * 12 zasad (pryncypiów)\n",
+ " \n",
+ " ### 4 wartości manifestu Agile\n",
+ " 1. Ludzie i interakcje ponad procesy i narzędzia.\n",
+ " 2. Działające oprogramowanie ponad szczegółową dokumentację.\n",
+ " 3. Współpraca z klientem ponad negocjację umów.\n",
+ " 4. Reagowanie na zmiany ponad podążaniem za planem.\n",
+ " \n",
+ " ### 12 pryncypiów manifestu Agile \n",
+ " [12 pryncypiów](https://www.agilealliance.org/agile101/12-principles-behind-the-agile-manifesto/)"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "## 10 pryncypiów wg Kelly Watersa (All About Agile: Agile Management Made Easy!, 2012)"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "1. Active User Involvement Is Imperative."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "\n",
+ "\n",
+ "Nic dobrego nie wynika
\n", + "Bez udziału użytkownika.\n", + " \n", + "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "2. Agile Development Teams Must Be Empowered."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "\n", + "Bez udziału użytkownika.\n", + " \n", + "
\n",
+ "\n",
+ "Nie warta praca mozołu,
\n", + "Gdy władza nie w rękach zespołu.\n", + " \n", + "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "3. Time waits for no man."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "\n", + "Gdy władza nie w rękach zespołu.\n", + " \n", + "
\n",
+ "\n",
+ "Czas płynie wartko jak rzeka,
\n", + "I na nikogo nie czeka.\n", + " \n", + "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "4. Agile Requirements Are Barely Sufficient."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "\n", + "I na nikogo nie czeka.\n", + " \n", + "
\n",
+ "\n",
+ "Dosłownie w kilku dziś zdaniach
\n", + "Streścimy swe wymagania.\n", + " \n", + "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "5. How do you eat an elephant? One bite at a time."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "\n", + "Streścimy swe wymagania.\n", + " \n", + "
\n",
+ "\n",
+ "Sekretów uchylam wieczko:
\n", + "Jedz słonia małą łyżeczką.\n", + " \n", + "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "6. Fast but not so furious."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "\n", + "Jedz słonia małą łyżeczką.\n", + " \n", + "
\n",
+ "\n",
+ "Byli szybcy, lecz nie wściekli,
\n", + "I na czas produkt dowlekli.\n", + " \n", + "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "7. Done Means DONE!"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "\n", + "I na czas produkt dowlekli.\n", + " \n", + "
\n",
+ "\n",
+ "Praca była \"wykonana\",
\n", + "I działało... aż do rana.\n", + " \n", + "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "8. Enough is enough."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "\n", + "I działało... aż do rana.\n", + " \n", + "
\n",
+ " \n",
+ "Projekt ciągle się rozrasta,
\n", + "Trzeba krzyknąć: \"Stop i Basta!\"\n", + " \n", + "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "9. Agile Testing Is Not For Dummies."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "\n", + "Trzeba krzyknąć: \"Stop i Basta!\"\n", + " \n", + "
\n",
+ " \n",
+ "Wiedz, by dobrze móc testować,
\n", + "Twa głowa ma być pomysłowa.\n", + " \n", + "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "10. No place for snipers."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "\n", + "Twa głowa ma być pomysłowa.\n", + " \n", + "
\n",
+ " \n",
+ "Choć mocno znów cierpi Twe ego,
\n", + "Nie strzelaj - do siebie samego.\n", + " \n", + "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "## Przykład manifestu zespołu ludzi (PWN AI)\n",
+ "> 1. Biznes stawia **cele**, IT daje **rozwiązania**.\n",
+ "> 2. Wszystko da się zrobić.\n",
+ "> 3. Biznes wyjaśnia **potrzeby**, IT wyjaśnia **możliwości**.\n",
+ "> 4. **Komunikacja i zaangażowanie** – albo wyrzucanie pieniędzy w błoto.\n",
+ "> 5. Wszyscy jesteśmy **elastyczni**."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "## Metodyka SCRUM"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "\n", + "Nie strzelaj - do siebie samego.\n", + " \n", + "
\n",
+ " \n",
+ "Scrum jest metodyką, 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.\n",
+ " \n",
+ "
\n"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "Struktura metodyki Scrum opiera się na trzech filarach:\n",
+ "* Artefakty\n",
+ "* Role\n",
+ "* Cykl Pracy"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "## Artefakty w metodyce Scrum"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "\n",
+ " \n",
+ "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "Rejestr Produktu (Product Backlog)
\n", + "\n", + " Rejestr Produktu to lista zadań do wykonania w projekcie ułożona według priorytetu wykonania.\n", + "\n", + "- \n",
+ "
- Rejestr produktu utrzymywany jest przez Właściciela Produktu. \n", + "
- Zadania, których efekt widoczny jest dla użytkownika mają często postać User Story . \n", + "
- Zadania o najniższym priorytecie mogą być usuwane z Rejestru Produktu. \n", + "
\n",
+ " \n",
+ " chcę wykonać aby\n",
+ "\n",
+ "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "User Story
\n", + "\n", + "> User story to krótki opis wybranej funkcjonalności, napisany z punktu widzenia docelowego użytkownika danego produktu (Encyklopedia Zarządzania).\n", + "\n", + "User Story ma zwykle postać: \n", + "> JakoPrzykład User Story
\n", + " \n", + "> Jako klient sklepu chcę dodać produkt do koszyka aby go później kupić .\n", + "\n",
+ " \n",
+ "
\n"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "Rejestr Sprintu (Sprint Backlog)
\n", + "\n", + " Rejestr Sprintu to lista Zadań do wykonania podczas Sprintu:\n", + "\n", + "- \n",
+ "
- utrzymywana przez Zespół Deweloperski, \n", + "
- tworzona na początku każdego Sprintu przez Zespół Deweloperski na podstawie priorytetowego zadania z Rejestru Produktu. \n", + "
\n",
+ " \n",
+ "
\n"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "### Role w metodyce Scrum"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "Zadanie (Task)
\n", + "\n", + " Zadanie w Rejestrze Sprintu zawiera następujące informacje:\n", + "\n", + "- \n",
+ "
- opis zadania, \n", + "
- szacowany czas wykonania zadania, \n", + "
- członek zespołu odpowiedzialnego za wykonanie zadania, \n", + "
- status danego zadania (np. jeden z trzech: oczekuje na realizację/w trakcie realizacji/wykonane). \n", + "
\n",
+ " \n",
+ "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "Udziałowcy (stakeholders)
\n", + "Udziałowcy to ludzie, którzy finansują projekt:\n", + "- \n",
+ "
- właściciele firmy realizującej projekt, \n", + "
- klienci, \n", + "
- przyszli użytkownicy. \n", + "
\n",
+ " \n",
+ "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "Właściciel Produktu (Product Owner)
\n", + "\n", + " Właściciel Produktu to rola, która reprezentuje interesy biznesu.\n", + "\n", + "Zadania Właściciela Produktu:
\n", + "\n", + "- \n",
+ "
- nadzoruje pisanie User Stories, \n", + "
- analizuje na bieżąco potrzeby biznesu i na tej podstawie... \n", + "
- ustala priorytet User Stories w Rejestrze Produktu, \n", + "
- decyduje, co jest WYKONANE. \n", + "
\n",
+ "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "Zespół Deweloperski (Development Team)
\n", + " \n", + "Zespół Deweloperski to zespół wykonawców oprogramowania, zazwyczaj składający się z kilku osób (3-9), o równych prawach.\n", + " \n", + "Zadania Zespołu Deweloperskiego:
\n", + "\n", + "- \n",
+ "
- jest odpowiedzialny za implementację, \n", + "
- na podstawie priorytetów Właściciela produktu określa zadania na kolejny sprint, \n", + "
- wykonuje cały proces: analiza, programowanie, testowanie (dzienniku produktu), \n", + "
- sam decyduje o sposobie realizacji zadań. \n", + "
\n",
+ "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "## Cykl pracy w metodyce Scrum"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "Scrum Master
\n", + "\n", + "Scrum Master to członek zespołu deweloperskiego, mający dobre zrozumienie ideologii SCRUM.\n", + "\n", + "Zadania Scrum Mastera:
\n", + "- \n",
+ "
- prowadzi Daily (spotkanie zespołu), \n", + "
- prowadzi Retrospektywę, \n", + "
- buduje relacje w zespole, \n", + "
- pomaga rozwiązywać konflikty, \n", + "
- pośredniczy w rozmowach z Właścicielem produktu. \n", + "
\n",
+ "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "Sprint
\n", + "\n", + " Sprint to okres, podczas którego tworzy się przyrost projektu, skutkujący prototypem gotowym do użycia. Sprint zazwyczaj trwa nie krócej niż tydzień i nie dłuzej niż miesiąc.\n", + "W skład Sprintu wchodzą:\n", + "- \n",
+ "
- Planowanie Sprintu, \n", + "
- Implementacja, \n", + "
- Codzienne spotkania, \n", + "
- Przegląd Sprintu, \n", + "
- Retrospektywa. \n", + "
\n",
+ "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "Planowanie Sprintu (Sprint Planning)
\n", + "\n", + " Planowanie sprintu jest pierwszym spotkaniem podczas każdego sprintu. \n", + "\n", + "- \n",
+ "
- Planowanie Sprintu bierze udział Zespół Deweloperski oraz opcjonalnie Właściciel Produktu. \n", + "
- Planowanie Sprintu prowadzone jest przez Scrum Mastera. \n", + "
Standardowy przebieg Planowania Sprintu:
\n", + "- \n",
+ "
- Analizy Rejestru Produktu - wybór wymagań do realizacji, \n", + "
- Określenie celu sprintu - na podstawie wybranych wymagań, \n", + "
- Określenie pełnego zakresu prac: jak będzie działał system po Sprincie, \n", + "
- Stworzenie Rejestru Sprintu: podział zakresu prac na zadania i przydzielenie członków zespołu do zadań, \n", + "
- Estymacja pracochłonności zadań. \n", + "
\n",
+ "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "Codzienne Spotkania (Daily Scrum)
\n", + "\n", + " Codzienne Spotkanie (stosowana nazwa w j. polskim - Daily ) to codzienne zdarzenie, które trwa do piętnastu minut w stałym miejscu i o stałej porze. \n", + "\n", + "- \n",
+ "
- W Daily bierze udział Zespół Deweloperski. \n", + "
- Daily prowadzone jest przez Scrum Mastera. \n", + "
Standardowy plan Daily:
\n", + "\n", + "- \n",
+ "
- Przegląd prac w ciągu ostatniego dnia, \n", + "
- Omówienie pojawiających się problemów, \n", + "
- Omówienie planu na kolejny dzień. \n", + "
\n",
+ "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "Przegląd Sprintu
\n", + "\n", + " Przegląd Sprintu jest spotkaniem organizowanym na zakończenie Sprintu w celu zweryfikowania wykonania zadań w Sprincie i dostosowania Rejestru Produktu. \n", + "\n", + "- \n",
+ "
- W Przeglądzie Sprintu bierze udział Zespół Deweloperski, Właściciel Produktu oraz Udziałowcy zaproszenieni przez Właściciela Produktu. \n", + "
- Przegląd Sprintu prowadzony jest przez Właściciela Produktu. \n", + "
Standardowy plan Przeglądu Sprintu:
\n", + "\n", + "- \n",
+ "
- Właściciel Produktu wyjaśnia Udziałowcom, które funkcjonalności zostały \"Wykonane”, a które nie. \n", + "
- Zespół Deweloperski omawia zadania w Sprincie, jakie były problemy oraz jak je rozwiązano. \n", + "
- Zespół Deweloperski prezentuje \"Wykonaną” pracę; dyskusja. \n", + "
- Właściciel Produktu omawia obecny Rejestr Produktu. \n", + "
- Uczestnicy omawiają kolejne kroki pracy pod kątem potrzeb biznesu.\n", + "
- Właściciel produktu aktualizuje Rejestr Produktu.\n", + "
\n",
+ "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "## Wniosek\n",
+ "Nie zrobi informatyk \n",
+ "Złotego interesu, \n",
+ "Gdy nie będzie co tydzień \n",
+ "Słuchał potrzeb biznesu."
+ ]
+ }
+ ],
+ "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": "05. Metodologia Prince2Agile[wykład]",
+ "title": "Przygotowanie do projektu badawczo-rozwojowego",
+ "year": "2021"
+ },
+ "nbformat": 4,
+ "nbformat_minor": 4
+}
diff --git a/materiały na wykład/02_prototypowanie_systemy_kontroli_wersji.ipynb b/materiały na wykład/02_prototypowanie_systemy_kontroli_wersji.ipynb
new file mode 100644
index 0000000..d988517
--- /dev/null
+++ b/materiały na wykład/02_prototypowanie_systemy_kontroli_wersji.ipynb
@@ -0,0 +1,234 @@
+{
+ "cells": [
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "Retrospektywa Sprintu
\n", + "\n", + " Retrospektywa Sprintu to spotkanie po Przeglądzie Sprintu w celu opracowania usprawnień na następny Sprint. \n", + "\n", + "- \n",
+ "
- W Retrospektywie udział bierze Zespół Deweloperski. \n", + "
- Retrospektywę prowadzi Scrum Master. \n", + "
Standardowy plan Retrospektywy:
\n", + "\n", + "- \n",
+ "
- Sprawdzenie, co działo się w ostatnim Sprincie, \n", + "
- Zidentyfikowanie elementów, które sprawdziły się w działaniu, \n", + "
- Zidentyfikowanie elementów, które kwalifikują się do usprawnienia, \n", + "
- Stworzenie planu wprowadzania w życie usprawnień. \n", + "
\n",
+ "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "Systemy informatyczne analizy danych
\n", + "2. Prototypowanie, systemy kontroli wersji[wykład]
\n", + "Filip Graliński, Krzysztof Jassem (2023)
\n", + "\n",
+ " \n",
+ "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "## Cele prototypowania\n",
+ " * Zademonstrowanie umiejętności wykonania produktu końcowego\n",
+ " * Określenie realistycznych wymagań końcowych\n",
+ " * Przekonanie się o wpływie innych systemów, środowisk na produkt. \n",
+ " * Sprawdzenie implementacji kluczowych funkcji\n",
+ "\n",
+ "## Potencjalne efekty prototypowania\n",
+ "* Wykrycie nieporozumień między klientem i wykonawcą \n",
+ "* Określenie brakujących funkcji \n",
+ "* Wykrycie błędów w specyfikacji\n",
+ "* Przewidywanie przyszłych trudności "
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "## Prototyp poziomy a pionowy\n",
+ "### Prototyp poziomy (Horizontal Prototype)\n",
+ "\n",
+ "**Prototyp poziomy** obrazuje całość systemu, podkreślając interakcję z użytkownikiem, a nie wnikając w funkcjonalności.\n",
+ "\n",
+ "Przykłady prototypów poziomych w informatyce:\n",
+ " * Prototyp papierowy\n",
+ " * Makieta statyczna\n",
+ " * Makieta dynamiczna\n",
+ " * Graficzny interfejs użytkownika"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "Prototyp
\n", + "Prototyp to wynik częściowej implementacji, posiadający wybrane cechy produktu końcowego.\n", + "\n", + "\n",
+ " \n",
+ "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "Prototyp papierowy
\n", + " \n", + "Prototyp papierowy to sposób reprezentacji produktu cyfrowego za pomocą wycinanek z papieru. \n", + " \n", + "* Służy do zrozumienia koncepcji produktu cyfrowego przez użytkownika. \n", + "* Dla autora koncepcji prototyp taki służy do prześledzenia reakcji użytkowników na przyszłe działanie systemu przed jego realizacją.\n", + "\n", + "Prototypowanie papierowe - etapy :\n", + "\n", + "- \n",
+ "
- Naszkicowanie wstępnej koncepcji ekranów z wyróżnieniem głównych funkcjonalności. \n", + "
- Symulowanie interakcji poprzez podmienianie papierowych ekranów i wyciętych elementów. \n", + "
\n",
+ " \n",
+ "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "Makieta statyczna
\n", + " \n", + " \n", + "Makieta statyczna to cyfrowy projekt aplikacji, który zawiera pewne elementy docelowej konstrukcji, ale nie jest funkcjonalny. \n", + "\n", + "- \n",
+ "
- Obrazuje wybrane widoki bez połączeń między nimi. \n", + "
\n",
+ " \n",
+ "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "Makieta dynamiczna
\n", + " \n", + " \n", + "Makieta dynamiczna to cyfrowy projekt aplikacji, który zawiera pewne elementy docelowej konstrukcji i wskazuje interakcje z użytkownikiem. \n", + "\n", + "- \n",
+ "
- Widoki są \"klikalne\" - po kliknięciu użytkowniki kierowany jest do nowego widoku. \n", + "
\n",
+ " \n",
+ "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "### Prototyp pionowy (Vertical Prototype)\n",
+ "**Prototyp pionowy** to pełna realizacja kluczowej (kluczowych) funkcji systemu.\n",
+ "\n",
+ "Cele prototypowania pionowego:\n",
+ "* sprawdzenie wyboru technologii\n",
+ "* pomiary wydajności\n",
+ "* sprawdzenie poprawności algorytmów i struktur danych\n",
+ "\n",
+ "Realizacja prototypów pionowych jest polecana w sytuacji, gdy wykonanie kluczowych funkcji systemu obarczone jest wysokim ryzykiem."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "## Prototypowanie z porzuceniem a prototypowanie ewolucyjne"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "### Prototypowanie z porzuceniem (Thow-away Prototyping)\n",
+ "\n",
+ "W **prototypowaniu z porzuceniem** budowane są kolejne wersje prototypów, a niektóre z nich są porzucane.\n",
+ "\n",
+ "Cele prototypowania z porzuceniem:\n",
+ "* minimalizacja ryzyka,\n",
+ "* głębokie zrozumienie problemów technicznych\n",
+ "\n",
+ "Koszty:\n",
+ " * Koszty prototypowania z porzuceniem są wysokie."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "### Prototypowanie ewolucyjne (Ewolutionary Prototyping)\n",
+ "\n",
+ "**Prototypowanie ewolucyjne** polega na stopniowym rozszerzaniu prototypu, aż spełnia on wszystkie wymagania... \n",
+ "\n",
+ "...Wtedy prototyp staje się produktem.\n",
+ "\n",
+ "Prototyp ewolucyjny powinien być budowany:\n",
+ " * w środowisku zbliżonym do produkcyjnego, \n",
+ " * z dużą dbałością o jakość."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "## Prototypowanie - podsumowanie\n",
+ "\n",
+ "* Prototypy tworzy się w celu zminimalizowania ryzyka niepowodzenia produktu. \n",
+ "* W prototypach poziomych chodzi o zobrazowanie wszystkich funkcji. \n",
+ "* W prototypach pionowych chodzi o szczegóły techniczne.\n",
+ "* Prototypowanie z porzuceniem oywa się z reguły wszerz (prototypy poziome); \n",
+ " * jest bardziej kosztowne, ale minimalizuje ryzyko.\n",
+ "* Prototypowanie ewolucyjne odbywa się z reguły w głąb (prototypy pionowe); \n",
+ " * jest mniej kosztowne, ale bardziej ryzykowne."
+ ]
+ }
+ ],
+ "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": "06. Prototypowanie i ciągła integracja[wykład]",
+ "title": "Przygotowanie do projektu badawczo-rozwojowego",
+ "year": "2021"
+ },
+ "nbformat": 4,
+ "nbformat_minor": 4
+}
diff --git a/materiały na wykład/03_ciągła_integracja_ewaluacja.ipynb b/materiały na wykład/03_ciągła_integracja_ewaluacja.ipynb
new file mode 100644
index 0000000..3ef4c63
--- /dev/null
+++ b/materiały na wykład/03_ciągła_integracja_ewaluacja.ipynb
@@ -0,0 +1,284 @@
+{
+ "cells": [
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "Graficzny interfejs użytkownika (GUI)
\n", + "\n", + " Graficzny interfejs użytkownika to sposób komunikacji użytkownika z komputerem za pomocą elementów graficznych.\n", + " \n", + "Prototypem poziomym nazwiemy GUI, który: \n", + "- \n",
+ "
- Pokazuje menu. \n", + "
- Pozwala na nawigację. \n", + "
- Akceptuje input. \n", + "
- Wyświetla losowy output. \n", + "
- NIE wspiera logiki aplikacji. \n", + "
\n",
+ "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "Systemy informatyczne analizy danych
\n", + "3. Ciągła integracja i ciągła ewaluacja[wykład]
\n", + "Filip Graliński, Krzysztof Jassem (2023)
\n", + "\n",
+ " \n",
+ "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "Ciągła integracja
\n", + " \n", + "Ciągła integracja (CI) to praktyka rozwoju oprogramowania, w której:\n", + "- \n",
+ "
- zmiany w kodzie są regularnie przesyłane do centralnego repozytorium, \n", + "
- po każdym dołączeniu nowego kodu wykonywane są (automatycznie): kompilacja kodu i testy. \n", + "
\n",
+ " \n",
+ "
\n",
+ "\n",
+ " \n",
+ "\n"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "![Schemat CI/CD](obrazy/cicd.drawio.png \"Schemat CI/CD\")"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "## Przebieg pracy w Ciągłej Integracji\n",
+ "1. **Take Integrated Code**\n",
+ " * Pobieram kod z repozytorium.\n",
+ " * Instaluję kopię na swojej stacji roboczej. \n",
+ " \n",
+ "2. **Do Your Part**\n",
+ " * Opracowuję nowy kod.\n",
+ " * Opracowuję nowe testy jednostkowe.\n",
+ " \n",
+ "3. **Build on your machine**\n",
+ "\n",
+ " * **Repeat** \n",
+ " * Kompiluję swój kod i buduję wersję wykonywalną,\n",
+ " * Przeprowadzam testy jednostkowe,\n",
+ " * **Until**\n",
+ " * Kod się skompilował poprawnie oraz\n",
+ " * Testy zakończyły się powodzeniem.\n",
+ " \n",
+ "4. **Integrate with Repository**\n",
+ "\n",
+ " * Przesyłam kod do repozytorium centralnego, skąd przesyłany jest do kompilacji i testów.\n",
+ " * Przypadek 1. W międzyczasie ktoś dodał swój kod do repozytorium. Kompilacja lub testy się nie powodzą.\n",
+ " * **Go back to: Take Integrated Code**\n",
+ " * Przypadek 2. Tetsy się powodzą\n",
+ " * **Continue**\n",
+ " \n",
+ "5. **End Session**\n",
+ " * Gdy powiodły się wszystkie testy, mogę zakończyć sesję."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "## Dobre praktyki Ciągłej Integracji\n",
+ "(wg https://www.martinfowler.com/articles/continuousIntegration.html)"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "### Maintain a Single Source Repository\n",
+ " * Załóż mainline (linię główną): \n",
+ " * Deweloperzy powinni większość pracy składać na mainline.\n",
+ " * Nie nadużywaj odgalęzień (branchów). Jeśli już, to tylko w celu:\n",
+ " * naprawy błędów,\n",
+ " * tymczasowych eksperymentów,\n",
+ " * oznaczania wersji publikowalnych.\n"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "### Automate the Build\n",
+ " * Wersja wykonywalna powinna być tworzona jednym poleceniem.\n",
+ " * Dotyczy to zarówno repozytorium centralnego, jak i maszyn lokalnych."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "### Test Yourself\n",
+ " * Pisz testy jednostkowe.\n",
+ " * Uruchamiaj testy po każdej kompilacji."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "### Everyone Commits Everyday\n",
+ " * Każdy powinien \"codziennie\" wypychać swój kod do linii głównej.\n",
+ " * Umożliwia to wczesne wykrywanie konfliktów, gdyż...\n",
+ " * Im wcześniej wykryje się konflikt, tym łatwiej go naprawić.\n",
+ " * Postulat wymaga rozbicia projektu na małe kawałki."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "### Every Commit Should Build the Mainline\n",
+ " * Nie odchodzisz od pracy z repozytorium, aż Twój kod nie przeszedł pełnych testów.\n",
+ " * Korzystaj z systemów ciągłej integracji (Cruise Control, Jenkins)."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "### Fix the Broken Builds Immediately\n",
+ "Co zrobić, jeśli jednak kod na \"mainline\" się nie buduje? \n",
+ "Znalezienie i poprawienie blędu jest priorytetem, ale:\n",
+ " * Nie debugguj kodu na centralnym repozytorium. \n",
+ " * Przywróć wersję wykonywalną na \"mainline\".\n",
+ " * Debugguj kod na maszynie lokalnej."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "### Make it Easy to Run the Latest Executable\n",
+ "* Każdy członek zespołu (nie tylko deweloper) powinien mieć możliwość łatwego uruchomienia ostatniej wersji stabilnej.\n",
+ "* Jest to niezbędne do:\n",
+ " * testowania integracyjnego (tester),\n",
+ " * rozmów z klientem (zarząd lub sprzedawca),\n",
+ " * prowadzenia projektu (kierownik zespołu).\n",
+ "* W specjalnej lokalizacji przetrzymuj wersje stabilne - \"do pokazania\"."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "### Keep the Build Fast\n",
+ "\n",
+ " * Maximum 10 minut na build + testy.\n",
+ " * A jeśli testy trwają dłużej?\n",
+ " * Testy dwuetapowe:\n",
+ " * kompilacja + testy jednostkowe przy każdym commicie,\n",
+ " * testy integracyjne co pewien czas (np. po commicie wszystkich deweloperów)."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "### Clone the Environment\n",
+ " * Przygotuj klon środowiska produkcyjnego:\n",
+ " * ta sama wersja systemu operacyjnego\n",
+ " * ta sama baza danych\n",
+ " * te same biblioteki (nawet jak ich nie potrzebujesz) \n",
+ " * Wszystkie testy przeprowadzaj na przygotowanym środowisku."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "### Everyone Can See What's Happening\n",
+ "System powinien informować użytkowników o swoim statusie."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "### Automate Deployment\n",
+ " * Zautomatyzowanie wdrożenia polega na napisaniu skryptów, które instalują system w docelowym środowisku.\n",
+ " * Pozwala to na szybką reakcję, gdy \"coś się dzieje\". "
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "## Narzędzia Ciągłej Integracji\n",
+ "\n",
+ "https://www.katalon.com/resources-center/blog/ci-cd-tools/\n",
+ "\n",
+ "1. Jenkins\n",
+ "2. Circle CI\n",
+ "3. Team City\n",
+ "4. Bamboo\n",
+ "5. GitLab"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "## Korzyści z Ciągłej Integracji\n",
+ " * Minimalizacja ryzyka\n",
+ " * Łatwiejsze szacowanie terminu zakończenia prac\n",
+ " * Szybsza lokalizacja i naprawa błędów\n",
+ " * Świadomość stanu prac u całego zespołu\n",
+ " * Możliwość kontynuowania prac w przypadku odejścia dewelopera\n",
+ " * Możliwość pracy w środowisku rozproszonym\n",
+ " * Możliwość usunięcia bariery między wykonawcą i klientem"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "## Przykład - Jenkins\n",
+ "\n",
+ "https://git.wmi.amu.edu.pl/filipg/paper-cutter/src/branch/master/Jenkinsfile\n",
+ "\n"
+ ]
+ }
+ ],
+ "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": "06. Prototypowanie i ciągła integracja[wykład]",
+ "title": "Przygotowanie do projektu badawczo-rozwojowego",
+ "year": "2021"
+ },
+ "nbformat": 4,
+ "nbformat_minor": 4
+}
diff --git a/materiały na wykład/04_systemy_analizy_danych.ipynb b/materiały na wykład/04_systemy_analizy_danych.ipynb
new file mode 100644
index 0000000..be37c87
--- /dev/null
+++ b/materiały na wykład/04_systemy_analizy_danych.ipynb
@@ -0,0 +1,49 @@
+{
+ "cells": [
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "Główne przesłanki CI
\n", + " \n", + "Ciągła integracja (CI) to praktyka rozwoju oprogramowania, w której:\n", + "- \n",
+ "
- szybsze lokalizowanie błędów w kodzie, \n", + "
- ciągły wzrost jakości oporgramowania, \n", + "
- szybkie wydawanie nowych wersji. \n", + "
\n",
+ "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "Do tego wykładu materiały w formie Jupyter Notebook nie zostaną podane."
+ ]
+ }
+ ],
+ "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": "03. Prezentacja koncepcji projektu B+R[wykład]",
+ "title": "Przygotowanie do projektu badawczo-rozwojowego",
+ "year": "2021"
+ },
+ "nbformat": 4,
+ "nbformat_minor": 4
+}
diff --git a/materiały na wykład/05_innowacyjny_projekt_informatyczny.ipynb b/materiały na wykład/05_innowacyjny_projekt_informatyczny.ipynb
new file mode 100644
index 0000000..04bdf9a
--- /dev/null
+++ b/materiały na wykład/05_innowacyjny_projekt_informatyczny.ipynb
@@ -0,0 +1,296 @@
+{
+ "cells": [
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "Systemy informatyczne
\n", + "4. Przykłady systemów analizy danych w Żabce[wykład]
\n", + "autor: Tomasz Głowacki[wykład 2023]
\n", + "\n",
+ "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "## Definicja projektu\n",
+ "Projekt to system działań składający się z: \n",
+ "- zakresu działań, \n",
+ "- terminu realizacji, \n",
+ "- zasobów potrzebnych do realizacji projektu (ludzie, kapitał, wiedza, technologia).\n",
+ "\n",
+ "Projekt innowacyjny charakteryzuje się następującymi cechami: \n",
+ " - niepowtarzalność,\n",
+ " - złożoność,\n",
+ " - identyfikowalność."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "## Przykład projektu badawczo-rozwojowego: AI Searcher\n",
+ "\n",
+ "### Definicja projektu:\n",
+ "System działań mających na celu stworzenie systemu informatycznego wspomagającego pracowników Polskiej Straży Granicznej. \n",
+ "\n",
+ "\n",
+ "### Zakres projektu: \n",
+ "System informatyczny wdrożony w siedzibie Straży Granicznej, który ma pomagać w znajdowaniu treści przestępczych w Internecie. \n",
+ "System realizuje następujący scenariusz działania:\n",
+ " 1. Pracownik Straży Granicznej wpisuje zapytanie.\n",
+ " 2. Moduł Rozszerzania Zapytań rozszerza zapytanie na zestaw kwerned do wyszukiwarek internetowych.\n",
+ " 3. Translator tłumaczy kwerendy na języki: rosyjski, ukraiński i białoruski.\n",
+ " 4. Crawler wyszukuje dokumentów w trzech językach przygranicznych i języku polskim.\n",
+ " 5. Translator tłumaczy znalezione teksty na język polski. \n",
+ " 6. Klasyfikator wybiera teksty potencjalnie przestępcze.\n",
+ " 7. Analizator Lingwistyczny oznacza informację dodatkową w dokumentach:\n",
+ " \n",
+ "### Termin realizacji: \n",
+ "grudzień 2018 - grudzień 2021\n",
+ "\n",
+ "### Zasoby:\n",
+ " * Ludzie: Wojskowa Akademia Techniczna, UAM, Ken-Bit https://www.kenbit.pl/\n",
+ " * Kapitał: dotacja z NCBR\n",
+ " * Wiedza: Najnowsze badania z klasyfikacji tekstu, uczenia automatycznego itp.\n",
+ " * Technologia: Framework do tworzenia interfejsu użytkownika, algorytmy do klasyfikacji tekstu, modele języka"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "### Poglądowy widok systemu AI Searcher\n",
+ "Systemy Informatyczne
\n", + "5. Innowacyjny projekt informatyczny[wykład]
\n", + "Krzysztof Jassem (2023)
\n", + "![\"Zrzut](\"obrazy/AISearcher.png\")
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "## Poziomy gotowości technologicznej\n",
+ "\n",
+ "### Poziom 1.\n",
+ "Rozpoczęto badania naukowe (np. zdefiniowano tematu pracy mgr).\n",
+ "### Poziom 2.\n",
+ "Znaleziono zastosowania badań naukowych (np. określono, na czym będzie polegał projekt mgr).\n",
+ "### Poziom 3.\n",
+ "Przeprowadzono pierwsze eksperymenty na krytycznych technologiach (np. wykonano proof-of-concept).\n",
+ "\n",
+ "### Poziom 4.\n",
+ "Zintegrowano podstawowe komponenty prototypu w warunkach laboratoryjnych (np. zrealizowano \"user-stories\" na komputerze dewelopera).\n",
+ "### Poziom 5.\n",
+ "Zweryfikowano działanie w warunkach zbliżónych do rzeczywistego (np. przeprowadzono testowanie prototypu wdrożónego na serwerze WMI).\n",
+ "### Poziom 6.\n",
+ "Dokonano demonstracji działania w warunkach zbliżónych do rzeczywistych (np. zademonstrowano wdrożony prototyp z interakcją użytkowników).\n",
+ "\n",
+ "### Poziom 7.\n",
+ "Dokonano demonstracji systemu w warunkach operacyjnych (np. zademonstrowano prototyp wdrożony u użytkownika / klienta).\n",
+ "\n",
+ "### Poziom 8.\n",
+ "Potwierdzono zamierzony poziom technologii w warunkach operacyjnych (np. pomyślnie zakończono testowanie akceptacyjne).\n",
+ "\n",
+ "### Poziom 9.\n",
+ "Stwierdzono, że wypracowana technologia odniosła zamierzony efekt (np. stwierdzono, że stosowanie rozwiązania przynosi wymierne korzyści). \n",
+ "\n",
+ "[Formalny opis poziomów gotowości technologicznej](https://archiwum.ncbr.gov.pl/fileadmin/zalewska/5_1_1_1_2018/13_poziomy_gotowosci_technologicznej.pdf)\n",
+ "\n"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "# Produkt High-Tech\n",
+ "Oczekuje się, że wynikiem innowacyjnego projektu badawczo-rozwojowego w informatyce jest produkt High-Tech.\n",
+ "\n",
+ "## Czym jest produkt High-Tech?\n",
+ "\n",
+ "### Definicja produktu\n",
+ "Produkt = \n",
+ "Zawartość + \n",
+ "Funkcjonalność + \n",
+ "Konstrukcja + \n",
+ "Monetyzacja \n",
+ "Oczekuje się zatem, że z produkt posiada jakąś zawartość (Zawartość), z której kożna korzystać (Funkcjonalność), gdyż został odpowiednio skonstruowany (Konstrukcja), ale trzeba za to płacić (Monetyzacja)."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "\n",
+ " \n",
+ "Wyraz \"technologia\" pochodzi z języka greckiego:\n",
+ "
- \n",
+ "
- techne: sztuka, umiejętność \n", + "
- logia: nauka (czegoś) \n", + "
\n",
+ "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "# Metodyki adaptacyjne w programowaniu (Agile Software Development)"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "Systemy informatyczne analizy danych
\n", + ".6 Metodyki adaptacyjne w programowaniu[wykład]
\n", + "Krzysztof Jassem (2023)
\n", + "\n",
+ "\n",
+ " Agile (zwinny) to pojęcie odnoszące się do szybkości i sprawności w działaniu i myśleniu.\n",
+ " \n",
+ "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "## Manifest Agile\n",
+ " * opublikowany w roku 2001\n",
+ " * autorzy: 17 teoretyków i praktyków programowania\n",
+ " * 4 wartości\n",
+ " * 12 zasad (pryncypiów)\n",
+ " \n",
+ " ### 4 wartości manifestu Agile\n",
+ " 1. Ludzie i interakcje ponad procesy i narzędzia.\n",
+ " 2. Działające oprogramowanie ponad szczegółową dokumentację.\n",
+ " 3. Współpraca z klientem ponad negocjację umów.\n",
+ " 4. Reagowanie na zmiany ponad podążaniem za planem.\n",
+ " \n",
+ " ### 12 pryncypiów manifestu Agile \n",
+ " [12 pryncypiów](https://www.agilealliance.org/agile101/12-principles-behind-the-agile-manifesto/)"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "## 10 pryncypiów wg Kelly Watersa (All About Agile: Agile Management Made Easy!, 2012)"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "1. Active User Involvement Is Imperative."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "\n",
+ "\n",
+ "Nic dobrego nie wynika
\n", + "Bez udziału użytkownika.\n", + " \n", + "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "2. Agile Development Teams Must Be Empowered."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "\n", + "Bez udziału użytkownika.\n", + " \n", + "
\n",
+ "\n",
+ "Nie warta praca mozołu,
\n", + "Gdy władza nie w rękach zespołu.\n", + " \n", + "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "3. Time waits for no man."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "\n", + "Gdy władza nie w rękach zespołu.\n", + " \n", + "
\n",
+ "\n",
+ "Czas płynie wartko jak rzeka,
\n", + "I na nikogo nie czeka.\n", + " \n", + "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "4. Agile Requirements Are Barely Sufficient."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "\n", + "I na nikogo nie czeka.\n", + " \n", + "
\n",
+ "\n",
+ "Dosłownie w kilku dziś zdaniach
\n", + "Streścimy swe wymagania.\n", + " \n", + "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "5. How do you eat an elephant? One bite at a time."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "\n", + "Streścimy swe wymagania.\n", + " \n", + "
\n",
+ "\n",
+ "Sekretów uchylam wieczko:
\n", + "Jedz słonia małą łyżeczką.\n", + " \n", + "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "6. Fast but not so furious."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "\n", + "Jedz słonia małą łyżeczką.\n", + " \n", + "
\n",
+ "\n",
+ "Byli szybcy, lecz nie wściekli,
\n", + "I na czas produkt dowlekli.\n", + " \n", + "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "7. Done Means DONE!"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "\n", + "I na czas produkt dowlekli.\n", + " \n", + "
\n",
+ "\n",
+ "Praca była \"wykonana\",
\n", + "I działało... aż do rana.\n", + " \n", + "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "8. Enough is enough."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "\n", + "I działało... aż do rana.\n", + " \n", + "
\n",
+ " \n",
+ "Projekt ciągle się rozrasta,
\n", + "Trzeba krzyknąć: \"Stop i Basta!\"\n", + " \n", + "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "9. Agile Testing Is Not For Dummies."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "\n", + "Trzeba krzyknąć: \"Stop i Basta!\"\n", + " \n", + "
\n",
+ " \n",
+ "Wiedz, by dobrze móc testować,
\n", + "Twa głowa ma być pomysłowa.\n", + " \n", + "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "10. No place for snipers."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "\n", + "Twa głowa ma być pomysłowa.\n", + " \n", + "
\n",
+ " \n",
+ "Choć mocno znów cierpi Twe ego,
\n", + "Nie strzelaj - do siebie samego.\n", + " \n", + "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "## Przykład manifestu zespołu ludzi (PWN AI)\n",
+ "> 1. Biznes stawia **cele**, IT daje **rozwiązania**.\n",
+ "> 2. Wszystko da się zrobić.\n",
+ "> 3. Biznes wyjaśnia **potrzeby**, IT wyjaśnia **możliwości**.\n",
+ "> 4. **Komunikacja i zaangażowanie** – albo wyrzucanie pieniędzy w błoto.\n",
+ "> 5. Wszyscy jesteśmy **elastyczni**."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "## Metodyka SCRUM"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "\n", + "Nie strzelaj - do siebie samego.\n", + " \n", + "
\n",
+ " \n",
+ "Scrum jest metodyką, 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.\n",
+ " \n",
+ "
\n"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "Struktura metodyki Scrum opiera się na trzech filarach:\n",
+ "* Artefakty\n",
+ "* Role\n",
+ "* Cykl Pracy"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "## Artefakty w metodyce Scrum"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "\n",
+ " \n",
+ "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "Rejestr Produktu (Product Backlog)
\n", + "\n", + " Rejestr Produktu to lista zadań do wykonania w projekcie ułożona według priorytetu wykonania.\n", + "\n", + "- \n",
+ "
- Rejestr produktu utrzymywany jest przez Właściciela Produktu. \n", + "
- Zadania, których efekt widoczny jest dla użytkownika mają często postać User Story . \n", + "
- Zadania o najniższym priorytecie mogą być usuwane z Rejestru Produktu. \n", + "
\n",
+ " \n",
+ " chcę wykonać aby\n",
+ "\n",
+ "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "User Story
\n", + "\n", + "> User story to krótki opis wybranej funkcjonalności, napisany z punktu widzenia docelowego użytkownika danego produktu (Encyklopedia Zarządzania).\n", + "\n", + "User Story ma zwykle postać: \n", + "> JakoPrzykład User Story
\n", + " \n", + "> Jako klient sklepu chcę dodać produkt do koszyka aby go później kupić .\n", + "\n",
+ " \n",
+ "
\n"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "Rejestr Sprintu (Sprint Backlog)
\n", + "\n", + " Rejestr Sprintu to lista Zadań do wykonania podczas Sprintu:\n", + "\n", + "- \n",
+ "
- utrzymywana przez Zespół Deweloperski, \n", + "
- tworzona na początku każdego Sprintu przez Zespół Deweloperski na podstawie priorytetowego zadania z Rejestru Produktu. \n", + "
\n",
+ " \n",
+ "
\n"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "### Role w metodyce Scrum"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "Zadanie (Task)
\n", + "\n", + " Zadanie w Rejestrze Sprintu zawiera następujące informacje:\n", + "\n", + "- \n",
+ "
- opis zadania, \n", + "
- szacowany czas wykonania zadania, \n", + "
- członek zespołu odpowiedzialnego za wykonanie zadania, \n", + "
- status danego zadania (np. jeden z trzech: oczekuje na realizację/w trakcie realizacji/wykonane). \n", + "
\n",
+ " \n",
+ "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "Udziałowcy (stakeholders)
\n", + "Udziałowcy to ludzie, którzy finansują projekt:\n", + "- \n",
+ "
- właściciele firmy realizującej projekt, \n", + "
- klienci, \n", + "
- przyszli użytkownicy. \n", + "
\n",
+ " \n",
+ "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "Właściciel Produktu (Product Owner)
\n", + "\n", + " Właściciel Produktu to rola, która reprezentuje interesy biznesu.\n", + "\n", + "Zadania Właściciela Produktu:
\n", + "\n", + "- \n",
+ "
- nadzoruje pisanie User Stories, \n", + "
- analizuje na bieżąco potrzeby biznesu i na tej podstawie... \n", + "
- ustala priorytet User Stories w Rejestrze Produktu, \n", + "
- decyduje, co jest WYKONANE. \n", + "
\n",
+ "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "Zespół Deweloperski (Development Team)
\n", + " \n", + "Zespół Deweloperski to zespół wykonawców oprogramowania, zazwyczaj składający się z kilku osób (3-9), o równych prawach.\n", + " \n", + "Zadania Zespołu Deweloperskiego:
\n", + "\n", + "- \n",
+ "
- jest odpowiedzialny za implementację, \n", + "
- na podstawie priorytetów Właściciela produktu określa zadania na kolejny sprint, \n", + "
- wykonuje cały proces: analiza, programowanie, testowanie (dzienniku produktu), \n", + "
- sam decyduje o sposobie realizacji zadań. \n", + "
\n",
+ "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "## Cykl pracy w metodyce Scrum"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "Scrum Master
\n", + "\n", + "Scrum Master to członek zespołu deweloperskiego, mający dobre zrozumienie ideologii SCRUM.\n", + "\n", + "Zadania Scrum Mastera:
\n", + "- \n",
+ "
- prowadzi Daily (spotkanie zespołu), \n", + "
- prowadzi Retrospektywę, \n", + "
- buduje relacje w zespole, \n", + "
- pomaga rozwiązywać konflikty, \n", + "
- pośredniczy w rozmowach z Właścicielem produktu. \n", + "
\n",
+ "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "Sprint
\n", + "\n", + " Sprint to okres, podczas którego tworzy się przyrost projektu, skutkujący prototypem gotowym do użycia. Sprint zazwyczaj trwa nie krócej niż tydzień i nie dłuzej niż miesiąc.\n", + "W skład Sprintu wchodzą:\n", + "- \n",
+ "
- Planowanie Sprintu, \n", + "
- Implementacja, \n", + "
- Codzienne spotkania, \n", + "
- Przegląd Sprintu, \n", + "
- Retrospektywa. \n", + "
\n",
+ "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "Planowanie Sprintu (Sprint Planning)
\n", + "\n", + " Planowanie sprintu jest pierwszym spotkaniem podczas każdego sprintu. \n", + "\n", + "- \n",
+ "
- Planowanie Sprintu bierze udział Zespół Deweloperski oraz opcjonalnie Właściciel Produktu. \n", + "
- Planowanie Sprintu prowadzone jest przez Scrum Mastera. \n", + "
Standardowy przebieg Planowania Sprintu:
\n", + "- \n",
+ "
- Analizy Rejestru Produktu - wybór wymagań do realizacji, \n", + "
- Określenie celu sprintu - na podstawie wybranych wymagań, \n", + "
- Określenie pełnego zakresu prac: jak będzie działał system po Sprincie, \n", + "
- Stworzenie Rejestru Sprintu: podział zakresu prac na zadania i przydzielenie członków zespołu do zadań, \n", + "
- Estymacja pracochłonności zadań. \n", + "
\n",
+ "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "Codzienne Spotkania (Daily Scrum)
\n", + "\n", + " Codzienne Spotkanie (stosowana nazwa w j. polskim - Daily ) to codzienne zdarzenie, które trwa do piętnastu minut w stałym miejscu i o stałej porze. \n", + "\n", + "- \n",
+ "
- W Daily bierze udział Zespół Deweloperski. \n", + "
- Daily prowadzone jest przez Scrum Mastera. \n", + "
Standardowy plan Daily:
\n", + "\n", + "- \n",
+ "
- Przegląd prac w ciągu ostatniego dnia, \n", + "
- Omówienie pojawiających się problemów, \n", + "
- Omówienie planu na kolejny dzień. \n", + "
\n",
+ "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "Przegląd Sprintu
\n", + "\n", + " Przegląd Sprintu jest spotkaniem organizowanym na zakończenie Sprintu w celu zweryfikowania wykonania zadań w Sprincie i dostosowania Rejestru Produktu. \n", + "\n", + "- \n",
+ "
- W Przeglądzie Sprintu bierze udział Zespół Deweloperski, Właściciel Produktu oraz Udziałowcy zaproszenieni przez Właściciela Produktu. \n", + "
- Przegląd Sprintu prowadzony jest przez Właściciela Produktu. \n", + "
Standardowy plan Przeglądu Sprintu:
\n", + "\n", + "- \n",
+ "
- Właściciel Produktu wyjaśnia Udziałowcom, które funkcjonalności zostały \"Wykonane”, a które nie. \n", + "
- Zespół Deweloperski omawia zadania w Sprincie, jakie były problemy oraz jak je rozwiązano. \n", + "
- Zespół Deweloperski prezentuje \"Wykonaną” pracę; dyskusja. \n", + "
- Właściciel Produktu omawia obecny Rejestr Produktu. \n", + "
- Uczestnicy omawiają kolejne kroki pracy pod kątem potrzeb biznesu.\n", + "
- Właściciel produktu aktualizuje Rejestr Produktu.\n", + "
\n",
+ "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "## Wniosek\n",
+ "Nie zrobi informatyk \n",
+ "Złotego interesu, \n",
+ "Gdy nie będzie co tydzień \n",
+ "Słuchał potrzeb biznesu."
+ ]
+ }
+ ],
+ "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": "05. Metodologia Prince2Agile[wykład]",
+ "title": "Przygotowanie do projektu badawczo-rozwojowego",
+ "year": "2021"
+ },
+ "nbformat": 4,
+ "nbformat_minor": 4
+}
Retrospektywa Sprintu
\n", + "\n", + " Retrospektywa Sprintu to spotkanie po Przeglądzie Sprintu w celu opracowania usprawnień na następny Sprint. \n", + "\n", + "- \n",
+ "
- W Retrospektywie udział bierze Zespół Deweloperski. \n", + "
- Retrospektywę prowadzi Scrum Master. \n", + "
Standardowy plan Retrospektywy:
\n", + "\n", + "- \n",
+ "
- Sprawdzenie, co działo się w ostatnim Sprincie, \n", + "
- Zidentyfikowanie elementów, które sprawdziły się w działaniu, \n", + "
- Zidentyfikowanie elementów, które kwalifikują się do usprawnienia, \n", + "
- Stworzenie planu wprowadzania w życie usprawnień. \n", + "