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… Read more »
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… Read more »
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… Read more »
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.