Szczęśliwy, trzynasty, odcinek to chwilowy odpoczynek od technikaliów. Tym razem wraz z Grzegorzem Rycajem serwujemy Wam dywagacje na popularny temat: agile. Grzegorz od wielu lat programuje i kieruje zespołami programistów. Prawdopodobnie wielu z Was niejednokrotnie miało okazję oglądać go na scenie, gdyż regularnie występuje na różnych eventach. MVP w kategorii Visual Studio ALM.
40-minutową rozmowę rozpoczynamy od historii agile. Nie zagłębiamy się jednak w teorię – tę pewnie ogromna większość Was zna (jeśli nie – zapraszam do sekcji z linkami). Zastanawiamy się czym różni się agile w zależności od modelu pracy zespołu: “wewnętrzne zasoby” vs “dostawcy oprogramowania”. Jaki wpływ na projekt ma typ klienta: bank czy startup? Bardzo ważna część konwersacji to przestrogi: na co uważać stosując agile, jakie są najczęściej popełniane błędy w tym zakresie? Grzesiek dzieli się też swoimi spostrzeżeniami odnośnie radzenia sobie z “wrzutkami z produkcji” skutecznie demolującymi plany na dany sprint, czyli: jak radzić sobie z utrzymaniem systemów? Albo: jak dbać o dokumentację projektową? Rozmawiamy też o bardziej niskopoziomowych praktykach, takich jak code review, daily standup meeting, retrospekcje czy wreszcie continuous integration.
Konkurs: rozdajemy egzemplarz polecanej przez Grześka książki “Agile Project Management with Scrum“. Pewnie już wiecie kto ją dostanie, prawda?:) Tak, autor jednego z komentarzy pod niniejszym postem! Gorąco zapraszam zatem do dyskusji na temat zarówno tego odcinka, jak i DevTalka w ogóle.
Montaż odcinka: Krzysztof Śmigiel.Ważne adresy:
- zapisz się na newsletter
- zasubskrybuj w iTunes, Spotify lub przez RSS
- ściągnij odcinek w mp3
Linki:
- Manifesto for Agile Software Development (http://agilemanifesto.org)
- blog Rafała Barszczewskiego (gościa piątego odcinka DevTalk) (http://blog.rafalb.com)
- wystąpienie Erik Meijer “One Hacker Way” (http://vimeo.com/110554082)
- PaSkol na temat tej prezentacji (http://paskol.robi.to/?p=2062)
- Future Processing blog: “The Scrum Planning Meeting – doing it right” (http://www.future-processing.pl/blog/the-scrum-planning-meeting-doing-it-right/)
Muzyka wykorzystana w intro:
“Misuse” Kevin MacLeod (incompetech.com)
Licensed under Creative Commons: By Attribution 3.0
http://creativecommons.org/licenses/by/3.0/
13 – O agile z Grzegorzem Rycajem | DevTalk
Dziękujemy za dodanie artykułu – Trackback z dotnetomaniak.pl
Myślę, że właśnie w pracy freelancera agile może okazać się bardzo pomocny. Freelancerzy raczej nie pracują przy dużych projektach, więc elastyczność jest spora. Jeśli uświadomimy dobrze klienta, korzyści są obustronne. Jak wszyscy wiemy, klient nigdy nie wie czego chce, nawet jeśli myśli, że wie. :) Z tego powodu o wiele łatwiej robić z nim sprinty tygodniowe i planować tylko najbliższe zajęcia. Wtedy klient będzie zadowolony, bo na bieżąco moźe kierować do nas swoją wizję. My będziemy zadowoleni, bo unikniemy sytuacji, gdzie narobimy się nad czymś przez miesiąc, co później okaże się do kompletnego zaorania, bo klient wymyślił nowy feature.
Paweł,
Z jednej strony: tak. Z drugiej strony: klient chce od razu wiedzieć ile go będzie kosztował projekt. Więc jak to widzisz: umawiamy się na konkretną kasę a potem w trakcie dopiero uzgadniamy co ma być zrobione? :)
Generalnie Agile jest fajny. TFS (jak ja go nie lubię) daje fajne możliwości robienia review, choć fajniej jeszcze robi się je na githubie.
Faktycznie jedna z ważniejszych elementów a strasznie zaniedbywanych to retrospekcja. Sam nawet nie wiem czy nie najważniejsza. Nie oszukujmy się, chodzi o to by robić to co robimy z każdym sprintem lepiej.
Problem z Agile jest niestety IMHO taki, że każdy wyciera sobie nim buzię. W końcu w tej chwili każda prawie firma jest Agile. Nawet ja pracuję w firmie Agile. To Agile to nawet koło Agile czy tam Scruma nie stało :) Ale jest i jak coś to jesteśmy Agile.
@Maciej – ja to widzę raczej tak. Umawiamy się na kwotę za to co jest w ustaleniach, Zmiana ustaleń to ew. zmiana kwoty. Wiadomo jakieś drobne zmiany to ok. Najfajniej jest zrobić stories usera i on za te konkretne stories ma zapłacić. Zmiana zrobionych stories, dodanie nowego story – ++$.
pawelek,
No agile agilowi nierówny i każdy wie najlepiej jak to zrobić u siebie, często ignorując to czym agile powinien być:).
Co do freelancera i jego klienta – często nie ma możliwości manewru. Przychodzi koleś z własnymi oszczędnościami, których więcej po prostu nie ma, i chce system. W tym systemie musi być X, Y i Z, a dodatkowo fajnie by było gdyby znalazło się również A, B i C. Umawiam się że za taką kasę dostanie wszystko bez B i C. Jeśli się zgadza – to jedziemy. Jeśli nagle wymyśli coś super świetnego, a kasy na to nie ma (a w tym przykładzie – nie ma), to mu tego nie zrobię, niezależnie od tego jak bardzo agile jesteśmy. Rozliczanie się per user story nie ma sensu ponieważ system musi mieć pewne elementy i klient chce to co sobie wymyślił, a nie jakieś poszczególne scenariusze.
Agile agilem, ale kasa musi się zgadzać. Raz jeden w życiu poszedłem na układ “mamy X tys pln i jazda, jakoś to będzie, w trakcie się zobaczy”. Z tego projektu nie był zadowolony nikt.
Czuję niedosyt. Olbrzymi niedosyt. Chciałoby się powymieniać doświadczeniami, porozpatrywać różnorodne przypadki. Oczywiście rozumiem i w pełni popieram, że czas rozmowy musi być rozsądny, bo byśmy człowieka zamęczyli. Niemniej zacząłbym się zastanawiać na słuchowiskiem czy to spolszając “Przez chwilę z Agile” czy trzymając angielskiego brzmienia “Jedynie miedza dzieli od Edżajl” ;). Tak na marginesie, z tego samego powodu – zbyt krótkiego czasu – zawsze po prelekcjach mam wrażenie, jakby ktoś brutalnie przerwał mi grę wstępną ;).
Przechodząc do meritum, to chciałbym uzupełnić, że TDD należy także traktować jako … dokumentację. Pisał o tym bodajże Robert C. Martin (tzw. Uncle Ben, dla niezorientowanych, a czytających ten komentarz). I to jest potwierdzony fakt, bo osobiście patrząc na test (o ile jest to test jednostkowy, a nie test jakiśtam, gdzie odstępy pomiędzy Arrange, Act i Assert liczą co najmniej jeden ekran) jestem w stanie bardzo szybko zrozumieć jak testowany kod ma być używany. Co więcej – test jest w konkretnym miejscu, więc od razu mogę poznać sposób wywoływania metod klasy, w innym wypadku muszę szukać przykładow w kodzie (nawet jeśli ma Resharpera, to i tak napotkany kod będzie miał szerszy kontekst niż jedynie użycie konkretnej klasy).
Potwierdzam też naginanie manifestu Agile, moje osobiste doświadczenia, to olewanie specyfikacji projektowej, siadanie z programistą i opowiadanie mu jak ma coś działać. I gdybyż za tym mimo wszystko szedł koniec końców opis, ale nie. Potem jedynym, który rzekomo wie jak to działa jest programista (ha, ha, on już niczego nie pamięta). Inni więc muszą odczytywać logikę z kodu, a to i tak bez pewności, że autor tego kodu w pełni zrozumiał, jak to ma być zaprogramowane. Ale to temat, który bez wątpienia wkrótce zagości na moim blogu. Przeżyłem Scruma w wersji Resident Evil – to trzeba opisać.
Na koniec – zajebisty pomysł, ale dorzucę trochę krytycznych uwag:
1. Muzyka na końcu, choć może wydawać się warta zaprezentowania w większym fragmencie, nie powinna jednak zaczynać się jeszcze w momencie konwersacji, mnie to np. rozproszyło, ale ja w ogóle mam problemy, kiedy jest kilka źródeł dźwięku (stąd w pubach z głośną muzyką moja komunikatywność spada drastycznie). Można ją wrzucić w podsumowaniu prowadzącego. I nie robić tak głośnej gdy już prowadzący podsumuje (mało mi głowy z szyi nie wyrwało :D).
2. Rozmiar i typ czcionki użytej w komentarzu świadczy, żę to nie jest serwis dla starych ludzi ;). Ona jest za mała. Oraz polskie literki są zupełnie inną czcionką (test na Win XP i Win 7).
P.S. Czuję się zaszczycony podlinkowaniem mojej polemiki z Erikiem. Poczytam to sobie jako miernik jej trafności :D.
3. Szlak trafił formatowanie (#jak_żyć???).
wygram książkę?
Do prezentacji Erika Meijera dorzuciłbym jeszcze http://www.thoughtworks.com/talks/the-death-of-agile – w sumie sam nie wiem, która lepsza, ale obie to dla mnie “must see” :)
PaSkol,
No niestety czas nagrania oscyluje i zawsze będzie oscylował wokół 40 minut a to za mało na dogłębne obgadanie jakiegokolwiek tematu.
Co do testów – same testy nie wystarczą jeśli trzeba w projekt wdrożyć nowego developera. Jak najbardziej pełnią rolę dokumentacji, ale nie zapewniają “overview”.
A wygląd strony – no jest jaki jest :). Jak znajdę trochę czasu to poszukam kogoś kto mi napisze dedykowany worpress theme bo ten jest w porządku, ale nie jest idealny. Formatowanie jest OK, znika tylko autorom komentarzy – refresh załatwia sprawę :).
Książka wędruje to PaSkola, a Łukasz i pawelek dostaną po kubeczku, maile z prośbą o adres juz poszły.
Paweł Michna juz kubek dostał z innej okazji ;).
@sokald – nie :)
Niniejszym dziękuję ;)
A tak przy okazji – jak się okazuje – szukając ostatnio pracy, miałem też ofertę od Billennium ;). Świat jest mały :D.
Jeszcze uzupełnię, bo dopiero teraz zauważyłem Twoje odniesienie do dokumentacji. Jako “dokumentację” rozumiałem w tym wypadku jedynie tę techniczną i to też w sensie użycia metody/klasy. W żadnym zaś przypadku nie twierdzę, że testy zastąpią _całą_ dokumentację (albo że nie są potrzebne , itd.)
Oprócz uzupełnienia także autokorekta. Nie piszę się “szlak trafił”, ale “szlag trafił”, a dlaczego, to już ewentualnych zainteresowanych odsyłam do słownika.