Posts tagged agile

Attended Agile Central Europe Conference

This was second conference I attended recently but my first one completely related to agile. I also think (but may be wrong) that it was biggest ever agile conference in Poland. After a bit disappointing 4developers conference in Poznań I still had quite big expectations about ACE in Kraków and was not disappointed. I could feel that people attending breathe agile and have a lot of interesting opnions to share. So here’s a short review of what I heard and find interesting from my perspective.

First things first – we (I travelled with my colleague Paweł) almost missed a train because of slight misunderstanding of train schedule, that I got a fine on railway station and finally we were late for conference… not a greatest start ever. First speech I attended was by Rachel Davies, author of Agile Coaching, talking about retrospectives. Some good stuff and stressing that you should not skip retrospectives. One of conclusion was that we are not the only ones who have problems with time-boxing and retrospectives take too long. Suprisingly there were also comments about teams who do not have anything to say and think that they are perfect. One new idea for me was using funny drawings to show the emotions during sprint with so called emotions timeline – definitely would like to try that.

Afterwards I attended Scrumfluenca by Jens Korte. Jens put a lot of effort to create a graph of works that had influence on Scrum and Agile thinking in general, reaching even zen buddhism. Quite interesting but actually I expected something else.

Next one was Monika Konieczny talking about communication problems in a project. A presentation was very interactive and one of it’s elements was cooking live a birthday cake showing problems in communication between client (a husband ordering cake for his wife), team leader (getting requirements from husband and taking care of process) and developer (cooking cake). Later Monika was telling about coping with problems and generally about idea of using games and simulations to show client some concepts in a funny way. Also need to check page about Fun Theory which states that you can change people behaviour with something as simple as fun. Shall we try it with our clients?

Following two talks (Mack Adams and Simon Roberts) were about agile coaching (very popular term recently) basically stressing importance of having an Agile Coach in your company and how the coach should work so that results and agile thinking stick to organisation and people.

I started next day of conference with very interesting talk about Agile Culture gave by Zuzana Sochova. She pointed main problems in adopting Agile in companies, showing that most difficult agile practices are TDD, pair programming and estimating in points. Zuzana was also convincing us that based on her experience Agile is also widely using in life-critical industries and projects and we should not believe in statements that waterfall is only choice there. Conclusion for me after her presentation was asking myself a question if Espeo is truly a company with agile culture – I think not yet, but hopefully know how to get there. Very interesting was result of some poll, where question: “would you rather work for change or complain?” was asked. 81% of people were not sure (!)

Quite interesting for me was Pawel Lipinski’s presentation about being agile nearshore team, especially because of similar to Espeo remote work process. Too bad Pawel did not give too many conclusions but basically showed how his team was organized. One thing for me to remember is about conducting demos and idea that client should actually be “clicking” application during demo by himself, otherwise if we do it, client gets bored.

Next Paweł Brodziński was talking about Kanban so process similar to Scrum, a subject that I had in my plans for quite a long time. Final conclusion for me is that it’s much less formalized than scrum therefore it requires higher level of discipline from team itself. Because of this reason I think we should keep using Scrum but it’s something interesting to use to organize own time – it’s called Personal Kanban and is a bit similar to Getting Things Done – a process that I’ve been trying to use for some time.

Last presentation I attended was given by guys from UK based company New Bamboo – this was the funniest one during whole conference. They were showing some small solution for problems in software development house, for instance having commit conflicts, how they are solving it you can see in a video.

[some problem with video will add it later...]

Summing up, it was a very nice experience, I met a lot of interesting people and have many new ideas for Espeo. New experience for me was also seeing that so many people nowadays use Mac computers, and Twitter – some part of attendees was all the time doing live commentary from conference. Maybe it’s also time to start using Mac and Twitter?

Zwinny projekt okiem programisty.

Czym jest Agile dla programisty? Co zmienia zastosowanie zwinnego podejścia w porównaniu z klasycznym waterfall?

Klasyka

Mam za sobą kilka większych lub mniejszych projektów realizowanych klasycznie. Obserwowałem pracę programistów z różnych perspektyw. Ciekawa jest tu obserwacja jak zmienia się nastawienie pojedynczych ludzi, jak i całych zespołów do realizacji projektu. Człowiek potrafi zaadaptować się niezwykle szybko do środowiska w jakim przebywa…

W klasycznym podejściu rola programisty ogranicza się w zasadzie do ‘klepania kodu’. Powszechnie przy tym narzeka się na analityków, projektantów, a także testerów. Często nie dostrzega się klienta, czy nawet celów projektu, poza należną premią oczywiście :)

Jak wygląda (w uproszczeniu oczywiście) klasyczny warterfall

Jak wygląda (w uproszczeniu oczywiście) klasyczny warterfall

Miejsce programisty jest w zasadzie tylko przy etapie ‘kodowanie’. Jego rolą jest naklepanie treści do tego co wymyślił projektant… i przekazanie następnie do testera – z nadzieją aby ten nie wykrył tych drobnych obejść, które często wynikały z nieścisłego gdzieniegdzie projektu. W końcu po co zawracać sobie tym głowę – projektant widocznie tak chciał to ma.

Do takiej roli bardzo dobrze przygotowują wszelkie uczelnie. Po prostu trzeba doskonale znać narzędzia i język w którym się koduje. Działamy jak algorytm – na wejściu analiza, na wyjście dajemy działający kod. Nie ma znaczenia co gdzieś daleko za nami chciał klient, ani czego oczekuje po wdrożeniu. Jesteśmy tylko połączeniem projektanta z testerem.

Czasami rzeczywistość zaskakuje nas jak drogowców zimą :) Faza analizy się przedłuża i nie ma czasu na projekt :) Wówczas implementujemy często wynik analizy bez projektu… Jeśli przedłużyła się analiza – znaczy, że dziedzina jest trudna, pewnie implementacja też się przedłuży, więc może faza testów też jest niepotrzebna? Najważniejsze jest przecież wdrożenie… Tego chce klient (a może nie?).

W takich projektach Project Manager ma niełatwe zadanie. Ślęczy nocami nad znienawidzonym M$ Projectem, aby zgrać wszystkie etapy. Każdy próbuje zwalić winę na innego… To już temat na zupełnie osobny artykuł…
Programista podejmuje decyzje jedynie na temat tego czy użyć pętli while czy może lepiej for. Całą resztę zrzuca na projektanta lub PMa.

Agile

Jak wygląda zwinny proces rozwoju oprogramowania z punktu widzenia programisty?

Uproszczony schemat Agile

Uproszczony schemat Agile

Tutaj idziemy przez całość zagadnień małymi kroczkami. Za każdym razem wykonujemy analizę, projekt implementację i integrację z całością. Za każdym razem dostajemy informację zwrotną od klienta czy to co zrobiliśmy to jest to czego oczekuje. Klient dostaje gotowe fragmenty, które może używać. Sam decyduje które fragmenty chce najszybciej.
A co robi teraz programista? Otóż niestety ma sporo więcej pracy. Przejmuje po części role analityka, projektanta, testera i wdrożeniowca… Niestety ma więcej pracy i odpowiedzialności. Ale myślę że praca ta jest dużo ciekawsza i posiada dużo większe możliwości rozwoju.

Niestety jednak, tutaj napotykamy problem. Większość absolwentów kierunków informatycznych nie jest dobrze przygotowana do przejęcia tych wszystkich ról. Nie wystarczy więc powiedzieć – od dziś pracujemy w agile. Trzeba nieustannie podnosić kwalifikacje pracowników.

Poszczególne fazy, z racji tego że nie są one w pełni formalnie osadzone, różnią się też sporo od tych znanych z podejścia klasycznego. Nie powstaje zwykle jakiś spójny dokument zwany analizą, czy projektem, który jest normalnie akceptowany i odbierany przez klienta. Za to klient akceptuje gotowa działające kawałki. Wydaje się, że ma to głębszy sens – za abstrakcyjnym dokumentem projektu nie widać zwykle gotowego systemu.

Uczelnie wypuszczają całą masę programistów. To samo w sobie nie jest złe, są oni zwykle doskonali w programowaniu… Jednak spotyka się takich którzy nie słyszeli nigdy akronimu SOLID. Podczas studiów wykonuje się niezliczone ‘projekty’ programistyczne. Niewiele z nich jednak przechodzi przez fazy analizy, projektowania, czy nawet testowania! A te umiejętności wśród programistów są niezbędne aby swobodnie realizować zwinny projekt.

Jest to jedna z trudności (i wyzwań) dla zwinnych zespołów – w klasycznym podejściu każdy ma swoją działkę w której nabywa umiejętności; w agile każdy jest specjalistą od wszystkiego :) Postaram się dalej pokazać, że to nie taki diabeł straszny jak go malują.