Studia dzienne jednostopniowe magisterskie
Studia dzienne jednostopniowe magisterskie
2009-2010
Realizacja Projektu
Realizacja Projektu
Informatycznego
Informatycznego
Jakub Miler
Katedra In\
ynierii Oprogramowania
Wydział Elektroniki, Telekomunikacji i Informatyki
Politechnika Gdańska
[e-mail]
Materiały pomocnicze do wykładu na Wydziale ETI Politechniki Gdańskiej.
Wykorzystanie materiałów w innym celu i ich rozpowszechnianie bez zgody WETI PG zabronione.
- 1 - © J.Miler
Wykład 3
Wykład 3
Scrum:
Scrum:
Sprinty  organizacja pracy
Sprinty  organizacja pracy
i wytwarzanie produktu
i wytwarzanie produktu
- 2 - © J.Miler
Scrum
Scrum
Organizacja pracy w sprincie
Organizacja pracy w sprincie
- 3 - © J.Miler
Scrum  proces (przypomnienie)
Scrum  proces (przypomnienie)
1 dzień
Codzienne
spotkanie
Scrum
7
6
5
4
3 3
1
2 2 2
3
1 1
Product Sprint Częściowy
backlog backlog działający
produkt
Cechy
+ priorytety
Sprint
2 - 6 tygodni
U\
ytkownik
- 4 - © J.Miler
Punkt wyjścia - Product backlog
Punkt wyjścia - Product backlog
Priority
Zawiera jednostki
produktu (ang. items)
Jednostka mo\
e
reprezentować:
" wymaganie (cechÄ™)
" zadanie
" user story (XP)
" błąd do usunięcia
Jednostki sÄ…
posortowane po
priorytetach
Ka\
da jednostka ma
identyfikator,
oszacowanie (w story
points) i autora
Wartość dla klienta!
y
ródło: http://www.mountaingoatsoftware.com/product-backlog
- 5 - © J.Miler
Sprint backlog
Sprint backlog
Sprint backlog reprezentuje zakres produktu i pracy do wykonania w
ramach danego sprintu na podstawie oczekiwań Właściciela produktu
Sprint backlog odzwierciedla jednostki z produkt backlog (głównie te o
aktualnie najwy\
szym priorytecie) podjęte do wykonania przez zespół Scrum
Jednostki bardziej zło\
one
(np. user stories) rozbijane
sÄ… na zadania
Sprint backlog zawiera
konkretne zadania
Zadania szacowane sÄ…
ju\
w godzinach,
a nie w story points
Sprint backlog jest
dla zespołu!
y
ródło: Agile Software Development.com, http://agilesoftwaredevelopment.com/node/384
- 6 - © J.Miler
Product backlog vs. sprint backlog
Product backlog vs. sprint backlog
Product backlog - funkcjonalność
Interfejs
u\
ytkownika
Logika
aplikacji
Baza
danych
Product backlog  funkcje z punktu widzenia Właściciela produktu
Sprint backlog  wytwarzanie wybranych funkcji z punktu widzenia Zespołu
- 7 - © J.Miler
Scrum
SPRINT 2
SPRINT 3
SPRINT 1
backlog
backlog
backlog
Product backlog vs. sprint backlog (2)
Product backlog vs. sprint backlog (2)
Product backlog - funkcjonalność
Interfejs
u\
ytkownika
Logika
aplikacji
Baza
danych
Mo\
e się zdarzyć, \
e nie wszystkie zadania dla danej cechy/funkcji produktu
zostanÄ… zrealizowane w danym sprincie  przechodzÄ… wtedy do kolejnego
sprintu (je\
eli potwierdzi to Właściciel produktu)
- 8 - © J.Miler
SPRINT 2
SPRINT 3
SPRINT 1
backlog
backlog
backlog
Zasada przydziału pracy
Zasada przydziału pracy
Członkowie zespołu sami  pobierają zadania ze sprint backlog według
własnego uznania  nie ma odgórnego planowania i przydziału pracy!
Sprint backlog:
Zygmunt
Wacław
- 9 - © J.Miler
Codzienne spotkanie Scrum
Codzienne spotkanie Scrum
Po angielsku  Daily
scrum czyli
CODZIENNY MA
YN
- 10 - © J.Miler
Jak prowadzić codzienne spotkanie Scrum
Jak prowadzić codzienne spotkanie Scrum
Spotkanie jest na stojÄ…co
" trwa krócej
" stanie przypomina, \
e spotkanie słu\
y synchronizacji, a nie rozwiÄ…zywaniu
skomplikowanych problemów
Ma być krótkie, maks. 15 minut
" wzajemna informacja, co kto robi  rozwiązywanie problemów w podgrupach póz
niej
Stoimy przed tablicą zadań, product backlogiem lub sprint backlogiem
" widzimy o czym rozmawiamy, mo\
emy coś zmienić
Obecny jest cały zespół
" bezpośrednia komunikacja jest najskuteczniejsza
" mo\
na wyznaczyć  zastępstwo , je\
eli nie trzeba nadrobić wiedzę o stanie prac
y
ródło: http://agilesoftwaredevelopment.com/blog/artem/7-tips-daily-scrum
- 11 - © J.Miler
Jak prowadzić codzienne spotkanie Scrum (2)
Jak prowadzić codzienne spotkanie Scrum (2)
Nie notujemy na komputerze
" kto ma komputer ma władzę  wygląda jak kierownik, a nie chcemy kierownika
" notowanie przekręca słowa, notatki powinny być krótkie
Koncentrujemy siÄ™ na drugim i trzecim pytaniu, nie na pierwszym
" 1. Co robiłem wczoraj?
" 2. Co będę robił dzisiaj?
" 3. Czy sÄ… jakieÅ› przeszkody w mojej pracy?
" pierwsze pytanie to tylko kontekst dla drugiego i trzeciego
Nie  raportować Mistrzowi scruma
" je\
eli zespół zaczyna mówić do Mistrza, ten powinien udawać, \
e nie słyszy albo nawet
odejść nieco na bok
" spotkanie jest dla zespołu
y
ródło: http://agilesoftwaredevelopment.com/blog/artem/7-tips-daily-scrum
- 12 - © J.Miler
Praca nad produktem
Praca nad produktem
Uściślanie wymagań u\
ytkownika
Projektowanie
Programowanie
Testowanie
Praktyki
" jednostkowe
eXtreme
" funkcjonalne
Programming
Przeprojektowywanie
Poprawianie błędów
Integracja
Dokumentowanie
" wewnętrzne dokumenty robocze (mogą być nawet modele!)
" aktualizacja sprint backlog i burndown chart
- 13 - © J.Miler
Burndown chart dla sprintu
Burndown chart dla sprintu
y
ródło: Agile Software Development.com, http://agilesoftwaredevelopment.com/node/384
- 14 - © J.Miler
Produkt po sprincie
Produkt po sprincie
Product backlog - funkcjonalność
Interfejs
TO NIE JEST PRODUKT
u\
ytkownika
Logika
aplikacji
Baza
danych
Produkt udostępnia jakiś podzbiór funkcjonalności
Sam interfejs u\
ytkownika czy baza danych nie sÄ… produktem
- 15 - © J.Miler
SPRINT 1
wersja 1
backlog
Produkt
Informacje o wydaniu
Informacje o wydaniu
Angielskie  release notes
Zawartość dokumentu
" identyfikacja wersji produktu
" data wydania
" autorzy produktu
" krótki opis zakresu produktu
" zmiany w stosunku do poprzedniej wersji
" ograniczenia produktu (czego nie ma)
" znane błędy
" wymagania na środowisko (sprzętowe i programowe)
" sposób instalacji produktu
" sposób u\
ycia produktu
- 16 - © J.Miler
Przykłady pierwszej wersji produktu
Przykłady pierwszej wersji produktu
Biblioteka
" dodawanie i modyfikacja ksiÄ…\
ek
" przeglądanie księgozbioru
" wyszukiwanie ksiÄ…\
ek
" wypo\
yczanie ksiÄ…\
ek
" brak kont u\
ytkowników (brak autoryzacji)
" brak stanu księgozbioru
" brak zwrotów
mo\
liwe jest ju\
budowanie księgozbioru i wypo\
yczanie ksiÄ…\
ek
Rozpoznawanie tekstu z obrazka
" wczytywanie pliku do rozpoznania  funkcja zrealizowana częściowo (brak weryfikacji
formatu pliku)
" rozpoznawanie tekstu  funkcja zrealizowana częściowo (brak weryfikacji parametrów
obrazka, brak modyfikacji parametrów obrazka np. kontrast, podstawowa wersja
algorytmu rozpoznawania)
" prezentacja rozpoznanego tekstu
mo\
liwe jest ju\
rozpoznawanie tekstu dla prostych przypadków
- 17 - © J.Miler
Aktualizacja product backlog po sprincie
Aktualizacja product backlog po sprincie
Prezentacja wersji produktu na \
ywo Właścicielowi Produktu
Oczekiwania Właściciela Produktu:
" zmiana funkcji produktu
" rozszerzenie funkcji produktu
" dodanie nowej funkcji do produktu
Oczekiwania Właściciela zapisywane są jako nowe wpisy w product backlog
Funkcje całkowicie niezrealizowane w sprincie wracają do product backlog
Dla funkcji zrealizowanych częściowo w sprincie niezrealizowane zadania,
a zatem i część story points funkcji wracają do product backlog
- 18 - © J.Miler
Kolejny sprint (w skrócie)
Kolejny sprint (w skrócie)
Ponownie ustalamy z Właścicielem Produktu, które jednostki z product
backlog wejdÄ… z zakres sprintu
Zespół scrum przygotowuje dla siebie sprint backlog, gdzie rozpisuje ustalone
z Właścicielem Produktu jednostki na zadania
Członkowie zespołu w dniu pracy pobierają zadanie ze sprint backlog i je
wykonujÄ…
Wykonanie zadania oznaczajÄ… wpisujÄ…c 0 godzin jako oszacowanie
pracochłonności na kolejne dni sprintu
Wykonane zadania mo\
na oznaczyć kolorem (np. zielonym) w sprint backlog,
a na tablicy zadań przenieść do części  wykonane
Zadania sÄ… wykonywane a\
do zakończenia sprintu  decyduje czas a nie lista
zadań w sprint backlog
- 19 - © J.Miler
Scrum
Scrum
Wytwarzanie produktu
Wytwarzanie produktu
1
2
3
- 20 - © J.Miler
Wybrane praktyki eXtreme Programming
Wybrane praktyki eXtreme Programming
Testy przed kodem
Prosty projekt
Refaktoryzacja
Współwłasność kodu
Programowanie w parach
Standardy programowania
Ciągła integracja
- 21 - © J.Miler
Testy przed kodem
Testy przed kodem
Testy funkcjonalne
" przypadki testowe opisujÄ…ce zachowanie aplikacji z punktu widzenia u\
ytkownika
" stanowią doprecyzowanie wymagań na produkt
" trudne do automatyzacji
Testy jednostkowe
" testy zachowania poszczególnych klas
" specyfikujÄ… zachowanie klasy
" automatyzowane np. JUnit
Przypadki testowe dla testów funkcjonalnych pisane są przed rozpoczęciem
projektowania
Testy jednostkowe pisane są przez rozpoczęciem programowania klas
Klasa jest zatwierdzana do repozytorium kodu tylko gdy przejdzie wszystkie
testy jednostkowe
- 22 - © J.Miler
Testy przed kodem (2)
Testy przed kodem (2)
Przypadki testowe dla testów funkcjonalnych
Test Case ID JM.42
Author Jakub Miler
Feature being tested Execution of  Cut option in different contexts
Procedure Repeat steps for each node type and for empty and filled  Node Clipboard
1. Select a node
2. Display context menu
3. Execute  Cut
4. Display  Edit menu from main menu
5. Execute  Cut
Intended result After step 3 and step 5 for each node type  Node Clipboard window shows
correct data of node selected in step 1 (node type, node icon, node label and node
title). The tree remains intact.
Test Case ID JM.2.11
Author Jakub Miler
Feature being tested Cuting a node and pasting it under its own parent.
Procedure 1. Select a node
2. Display context menu
3. Execute  Cut option
4. Paste the node under its own parent.
Intended result Nothing happens. Command is ignored.
- 23 - © J.Miler
Testy przed kodem (3)
Testy przed kodem (3)
public class MathOps {
public static double average (List l)
{
Iterator iter = l.iterator();
Testowany kod:
double sum = 0;
while (iter.hasNext())
{
Integer num = (Integer) iter.next();
sum + = num.intValue();
}
return sum/l.size();
}
}
public class MathOpsTest extends public TestCase
{
public void test_average_multiple ()
{
Test jednostkowy JUnit:
Vector nums = new Vector();
nums.add(new Integer(3));
nums.add(new Integer(6));
assertTrue(MathOps.average(nums) == 4.5);
}
y
ródło: David Neary,
}
http://www.linux.ie/articles/tutorials/junit.php
- 24 - © J.Miler
Prosty projekt
Prosty projekt
Kod poprawnie przechodzi wszystkie testy jednostkowe
Kod zawiera wszystkie potrzebne klasy dla realizacji funkcjonalności
Nie ma powtórzeń kodu
Nie ma niepotrzebnych klas i metod
Nie wytwarzać kodu  na zapas  zasada YAGNI (You Aren t Gonna Need It)
Je\
eli projekt przestaje być prosty refaktoryzacja
- 25 - © J.Miler
Refaktoryzacja
Refaktoryzacja
Poszukiwanie w kodzie znamion  nieprostego lub po prostu złego projektu
 tak zwanych  złych zapachów (ang. bad smells lub code smells)
Zmiana struktury kodu poprzez kolejne  ściśle określone przekształcenia
Przykłady złych zapachów:
" Powtórzony kod  identyczny lub bardzo podobny kod w wielu miejscach
" Wielka metoda  metoda jest bardzo du\
a, powinna być rozbita na mniejsze
" Wielka klasa  klasa skupia zbyt wiele zachowania (powstaje  obiekt bóg )
" Zazdrość o funkcjonalność  klasa wykorzystuje bardzo mocno metody innej klasy
" Niepoprawna za\
yłość  klasa zale\
y od szczegółów wewnętrznych innej klasy
" Odrzucony spadek  klasa dziedziczÄ…ca nie zachowuje interfejsu klasy rodzica
" Leniwa klasa  klasa jest bardzo mała
" Klasa-dane  klasa przechowuje jedynie dane (ma jedynie atrybuty, getery i setery)
" A
ańcuchy komunikatów  klasa musi wywołać metodę innej klasy by otrzymać obiekt,
następnie wywołać metodę tego obiektu by otrzymać kolejny obiekt itd.
" Nieu\
ywany kod  kod (np. metoda), który nie jest u\
ywana przez pozostały kod
- 26 - © J.Miler
Refaktoryzacja (2)
Refaktoryzacja (2)
ZÅ‚y zapach: Odrzucony spadek
Przekształcenie: Zastąp dziedziczenie delegowaniem
Utwórz atrybut dla klasy rodzica, zmień metody by delegowały odpowiedzialność
do nadklasy i usuń dziedziczenie
y
ródło: Martin Fowler, www.refactoring.com
- 27 - © J.Miler
Refaktoryzacja (3)
Refaktoryzacja (3)
ZÅ‚y zapach: A
ańcuchy komunikatów
Przekształcenie: Ukrycie delegacji
Utwórz metodę w wywoływanej klasie by ukryć delegację
y
ródło: Martin Fowler, www.refactoring.com
- 28 - © J.Miler
Współwłasność kodu
Współwłasność kodu
Ka\
dy członek zespołu mo\
e modyfikować dowolny fragment kodu:
wprowadzać nową funkcjonalność, usuwać błędy, refaktoryzować
Kod ma autora (współautorów), a nie właściciela
Nie trzeba czekać na pierwszego autora, by wprowadził zmiany do  swojego
kodu
Ka\
dy kod ma testy jednostkowe, je\
eli zmiana kodu tego wymaga, trzeba
te\
zmienić kod testu (i go wykonać)
Pojedyncze osoby mogą odejść z zespołu, lecz wiedza na temat projektu i
kodu jest rozproszona w zespole i nie odchodzi wraz z człowiekiem
Osoba pracujÄ…ca z  cudzym kodem Å‚atwiej zauwa\
y mo\
liwości ulepszenia
kodu (podniesienia jakości) przez refaktoryzację
- 29 - © J.Miler
Programowanie w parach
Programowanie w parach
Programiści dobierają się w pary i pracują przy jednym komputerze
" jedna osoba pełni rolę programisty  pisze kod
" druga osoba pełni rolę projektanta, konsultanta, przeglądającego  siedzi obok i
rozmawia, podpowiada, wyszukuje błędy, pomaga projektować, podsuwa
mo\
liwości refaktoryzacji
" role mogą się zmieniać: klawiatura i myszka przechodzi z rąk do rąk
Zało\
enie: to się opłaca. Przecie\
dwa razy więcej osób pisze tę samą ilość
kodu w jednostce czasu. Ale lepszego kodu i zysk przychodzi póz
niej.
Rozmawianie umila pracę (bardzo wielu osobom, choć nie wszystkim)
Pary zmieniają się często, co pozwala szybko rozprowadzić i uspójnić wiedzę
na temat projektu w zespole
Praca w parach ma walor edukacyjny: nowych lub mniej doświadczonych
członków zespołu łączymy z bardziej doświadczonymi
- 30 - © J.Miler
Standardy programowania
Standardy programowania
Ustalone w zespole wspólne zasady pisania kodu obejmujące:
" formatowanie kodu
" komentarze
" nazewnictwo klas, metod, zmiennych, pakietów
" inne
 Mo\
esz pisać kod jak tylko chcesz, lecz nie w zespole [Kent Beck]
Kod słu\
y (równie\
) komunikacji w zespole na temat systemu
Kod jest nośnikiem informacji o projekcie systemu, musi być zrozumiały dla
wszystkich w zespole
Standardy programowania są konieczne przy współwłasności kodu,
programowaniu w parach i refaktoryzacji
Standard komentowania pozwala automatycznie wygenerować
dokumentacjÄ™ np. Javadoc
- 31 - © J.Miler
Standardy programowania (2)
Standardy programowania (2)
Przykłady
Przykłady
Standardowy nagłówek klasy
//************************************************************************//
// Copyright (c) 2007
// Gdansk University of Technology
// All Rights Reserved
// Project: TCT  Trust Case Toolbox
// Description: DetailsPanel class for managing panel for node details
// Development history:
// Jan 2007: Jakub Miler - original code author
//************************************************************************//
Formatowanie kodu, nazewnictwo metod
},
_activateTab : function(tab) {
this._activeTab = tab;
tab.activate();
},
_onTabActivateSuccess : function(emptyContext, tab) {
y
ródło: TCT Editor 3.0 source code, DetailsPanel.js
- 32 - © J.Miler
Standardy programowania (3)
Standardy programowania (3)
Komentarz Javadoc
Komentarz Javadoc
/**
* Returns an Image object that can then be painted on the screen.
* The url argument must specify an absolute {@link URL}. The name
* argument is a specifier that is relative to the url argument.
*

* This method always returns immediately, whether or not the
* image exists. When this applet attempts to draw the image on
* the screen, the data will be loaded. The graphics primitives
* that draw the image will incrementally paint on the screen.
*
* @param url an absolute URL giving the base location of the image
* @param name the location of the image, relative to the url argument
* @return the image at the specified URL
* @see Image
*/
public Image getImage(URL url, String name) {
try {
return getImage(new URL(url, name));
} catch (MalformedURLException e) {
return null;
}
}
y
ródło: How to Write Doc Comments for the Javadoc Tool, http://java.sun.com/j2se/javadoc/writingdoccomments/
- 33 - © J.Miler
Ciągła integracja
Ciągła integracja
Przekazywanie kodu do repozytorium jak najczęściej i synchronizowanie
lokalnej kopii roboczej z repozytorium
Automatyczna integracja kodu  skrypty integracyjne
Po ka\
dej integracji uruchamiane sÄ… testy
Je\
eli jakiś test przestał działać poprawnie, wiadomo, w której wersji kodu
wprowadzono błąd
Pozwala uniknąć  piekła integracji , gdy próbujemy zintegrować kod
wytwarzany niezale\
nie na końcu projektu
Narzędzia wspomagające ciągłą integrację, np. Apache Ant, CruiseControl
- 34 - © J.Miler


Wyszukiwarka