pobierz wyniki ankiety w postaci pdf

Liczba ankietowanych: 49
Ankieta zostala opublikowana na Polish Agile User Group, pl.comp.java i
pl.comp.programming
1. Stand-up/ SCRUM
Codziennie robimy stand-up/SCRUM.
Stand-up jest krotki i zawsze o tej samej porze.
Klient uczestniczy w stand-up.
27
28
9
55%
57%
18%
Iteracje sa ustalonej dlugosci.
Nigdy nie zmieniamy terminu iteracji.
Wymagania sa zamrozone po rozpoczeciu iteracji.
Kazda iteracja rozpoczyna sie spotkaniem, na ktorym planujemy zadania
do wykonania.
Klient jest obecny przy planowaniu iteracji.
Planujemy iteracje przy uzyciu "user stories".
34
24
16
69%
49%
33%
35
18
18
71%
37%
37%
Szacujemy i notujemy planowany czas wykonania kazdego zadania.
Zadania maja "acceptance criteria".
32
14
65%
29%
6
16
5
7
5
Response
Percent
15%
41%
13%
18%
13%
16
16
32
34
33%
33%
65%
69%
6
12%
17
35%
2. Iteracje i planowanie
Response
Count
3. Jak dluga jest iteracja?
Response
Count
1 tydzien
2 tygodnie
3 tygodnie
4 tygodnie
Inna
4. Zarzadzanie iteracja
Response
Count
Uzywamy "Index cards" i "Status Board".
Mierzymy wydajnosc (Velocity).
Uzywamy listy zadan (Task Backlog).
Uzywamy systemu do rejestracji bledow.
5. Praca nad kodem
Response
Count
Pracujemy w parach (pair-programming) wiecej niz 3 godziny dziennie,
codziennie
Kazdy programista jest w stanie zmodyfikowac dowolny modul systemu
bez obawy o wprowadzenie bledu do systemu.
Wszyscy programiści w zespole stosują refactoring.
28
57%
Regularnie omawiamy co mozna zrobic by poprawic prace zespolu.
Robimy regularnie "Code reviews"
Piszemy niewiele dokumentacji, nasz kod dokumentuje sie sam.
Uzywamy czasem narzedzi do mierzenia jakosci kodu ( test coverage,
duplicates, inspections)
Narzedzia do mierzenia jakosci kodu sa zintegrowane z "continuous
integration".
Robimy check-in wszystkich zmian przynajmniej raz dziennie.
Check-iny sa male - srednio 5 plikow.
Mozemy rozmawiac o kodzie napisanym przez innych programistow bez
obawy, ze ci poczuja sie zagrozeni/urazeni.
29
22
24
59%
45%
49%
25
51%
11
27
22
22%
55%
45%
31
63%
18
5
37%
10%
24
9
49%
18%
Mamy tzw. "one-click" build
Uzywamy "continuous integration" (przy kazdym check-in do
repozytorium).
Wszyscy wiemy od razu jesli build jest zepsuty.
22
45%
15
21
31%
43%
Naprawiamy build jesli jest zepsuty zanim wolno zrobic "check-in".
Hot-fix releases tylko przy uzyciu "hot-fix branch".
13
5
27%
10%
6. Unit-testy
Response
Count
Uzywamy Test Driven Development
Uzywamy Test First Development
Kazdy moze uruchomic unit-testy na swojej maszynie bez dodatkowej
konfiguracji.
Unit-testy trwaja mniej niz 60 sekund.
7. Continuous Integration
Response
Count