DevDay 2014 - relacja - dzień pierwszy (25.09.2014)

Za nami najpopularniejsza, a przynajmniej najbardziej oczekiwana konferencja związana ze środowiskiem programistów .NET w 2014 roku, czyli Devday 2014.

Organizowana przez ABB konferencja była od dawna oczekiwana w środowisku, a problemy z dostaniem wejściówki tylko to potwierdziły. Pierwsza tura darmowych biletów rozeszła się w 5 min, druga w 2 min., więc postanowiłem nie czekać i wykupiłem płatne warsztaty, dzięki czemu bilet na bądź co bądź darmową konferencję dostałem gratis.

W związku z powyższym pozwoliłem pokusić się o małą recenzję tego, bądź co bądź bardzo wyczekiwanego eventu.

Dzień 1, 25.09.2014 (czwartek)
W czwartek odbyły się dwa szkolenia. Jedno z Angular.Js z Tiberu Covaci, oraz drugie  "Accelerated Agile: from months to minute" z Dan'em North. Ja wybrałem się na szkolenie z Agile ponieważ zarówno temat jak i prowadzący wydawali mi się bardziej interesujący. Inna sprawa, iż uważam, że angulara dużo lepiej i taniej można się nauczyć z jakiś książek/tutoriali niż z jednodniowego szkolenia.

Szkolenie składało się z 5 części tematycznych, trwających 50-70 min. każda z przerwami na kawę, toaletę oraz obiad. Podczas szkolenia byliśmy podzieleni na 7 sześcioosobowych zespołów, wewnątrz których mieliśmy wykonywać mniej lub bardziej skomplikowane zadania w stosunkowo krótkich okresach czasu (2-3 min.). Idea była prosta -> jest x ludzi w zespole i bardzo ograniczony czas, a trzeba dojść do konsensusu i wystosować wspólne stanowisko grupy wobec podanego tematu. A tematy? Różne, od tego, jak ma się nazywać zespół, na czym ma się skupić prowadzący podczas zajęć, po różne elementy cyklu wytwarzania oprogramowania. Szkolenie odbywało się więc w formie mniej lub bardziej luźniej zabawy, za to z elementem "tykającego zegarka".

Ok. A gdzie w tym to całe "mięcho", po które przyszliśmy? Hmmm, pierwsze sesje były raczej takie "zapoznawcze" oraz mniej lub bardziej ogólnikowe np. tworzenie oprogramowania składa się z 3 faz: 
- badawcza (testujemy technologię, narzędzia, koncepcję itp.)
- działającego prototypu (jesteśmy w stanie pokazać klientowi coś co działa mniej lub bardziej zgodnie z założeniami)
- odtwarzalnej produkcji na masową skalę (cykl zmniejszania kosztów i zwiększania zysków, czyli ktoś inny może odtworzyć naszą pracę mniejszym nakładem sił)

Była też cała sesja poświęcona tworzeniom wersji "spike" oraz "prod". Znałem wcześniej pojęcie PoF, ale nie znałem pojęcia spike
Jedak największe wrażenie na mnie wywarły 2 ostatnie sesje. 

Pierwsza z nich, związana z ryzykiem utrzymywania aplikacji i związanymi z nią testami, próbowała odpowiedzieć na pytanie, czy "pokrycie kodu testami" to najlepszy sposób mierzenia oprogramowania? Zdaniem prowadzącego niekoniecznie. Zamiast bawić się w automat, powinniśmy rozdzielić naszą funkcjonalność, pod względem "skomplikowania" oraz "konsekwencji wystąpienia błędu (jak bardzo nas to zaboli)" w odniesieniu do "kontekstu" w jakim działamy (kontekst zazwyczaj zna tylko "biznes"). Idea, którą starał nam się przekazać Dan, polegała na tym, że nie każda część syst. musi być równo przetestowana (np. unit testami). Że czas, który poświęcili byśmy na pisanie testów dla mało znaczącego i stosunkowo prostego elementu, dużo lepiej jest spożytkować na dodatkowe testy tam, gdzie jak coś się wywali to nas (i nasz biznes) mocno zaboli. Dan wspomniał też, że zazwyczaj jak trafimy na element, który jest zarówno bardzo skomplikowany jak i bardzo istotny biznesowo, to... najczęściej da się go rozdzielić na kilka mniejszych elementów i... choćby testowanie jest wtedy łatwiejsze.

Druga, sesja, która mi się bardzo podobała, to była sesja związana z wycenianiem czasu trwania projektów. Coś, z czym często programiści mają problem. Jak się okazało, z ok ~40 os. na sali, tylko 4-5 czuły się w tym w miarę mocne. Dan podszedł do tematu nieco inaczej. Nie pokazywał nam jakiś "magicznych" metodologii przepowiadania przyszłości, a posłużył się metaforą przewidywania pogody. O ile w przypadku prognoz pogody, mamy do czynienia z 4 zmiennymi i... nikt nie wymaga od prognoz specjalnej dokładności, o tyle w przypadku tworzenia oprogramowania tych zmiennych jest znacznie więcej (często od 8 w górę), a... wszyscy wymagają od nas dokładnego przewidywania, nawet na kilka mieś. do przodu.
Zamiast tradycyjnego wróżenia z fusów nt. pracochłonności, Dan zaproponował odwrócenie procesu, tzn. biznes powinien się zadeklarować, ile jest w stanie na dany projekt wydać oraz ile planuje na nim zarobić. Podając pewne widełki, np. 50-150 tyś. dolarów, można przyjąć pewien okres prac programistycznych, np. 3-9 mieś., i na tej podstawie prognozować, czy skończenie projektu jest prawdopodobne. Nast. wraz z upływem czasu i wzrostem wydanych kosztów, śledzić na bieżąco i doprecyzowywać szacowanie np. po wydaniu 40 tyś. dol. spróbować oszacować, czy już mamy połowę, czy dopiero 1/3. I później, wraz z biegiem czasu i coraz lepszym poznawaniem tematu prognozować, czy dany projekt w ogóle ma sens.
Może i nie jest to super opis tego, o czym mówił Dan, ale jest to mniej więcej pogląd na wycenianie, jaki warto jest zacząć rozważać, skoro wcześniejsze próby wyceniania zwyczajnie się nie sprawdzają.

Ogólnie warsztaty z Danem były całkiem miłe i przyjemne. Gdybym miał je ocenić to? Hmmm, z całą pewnością były inspirujące i coś z nich wyniosłem, a pewne przemyślenia będę się starał włączyć do rzeczywistych projektów. Czego zabrakło? Z całą pewnością narzędzi, SCRUM-u, i innych "sformalizowanych" specyfik. Ale czy na pewno zabrakło? Hmmm.
A ocena? Pocz. myślałem o 7/10, ale obecnie, po powrocie do domu bardziej skłaniał bym się do 8/10.

Po warsztatach, poszedłem wziąć prysznic i nieco odpocząć, ponieważ tego samego dnia swoje spotkanie miała również Krakowska grupa .NET.

Do siedziby ABB dotarłem tuż przed rozpoczęciem prelekcji przez Maćka Aniserowicza i nie żałuję, bo wcześniejszą prezentację Michała o F# miałem okazję już wcześniej zobaczyć na spotkaniu Warszawskiej grupy .NET.
Maciek mówił o Dependency Injection i jak ktoś czyta jego bloga to w sumie niczego zaskakującego się podczas tej prezentacji nie dowiedział, za to to, co było miłe podczas tego spotkania, to ilość ludzi, jaka się zebrała (były problemy z miejscami stojącymi na sali), a także darmowe piwo i pizza (na koszt tretton37) podczas spotkania o losowaniu licencji na R# nie wspomnę ;)

Po spotkaniu większość devów udała się na miasto w celu dalszej dyskusji mniej lub bardziej palących nas spraw. Fajnie było znowu pobyć w wśród większej ilości, często bardziej doświadczonych devów i powymieniać się własnymi, często jakże różnymi doświadczeniami.