Możesz zacząć nowy projekt, kompletnie od zera zamiast utrzymywać stary kod? Szczęściar(a/z)! Chciałbym podzielić się swoim doświadczeniem i opowiedzieć, jak z punktu widzenia programisty powinien wyglądać dobrze poprowadzony projekt. Na potrzeby tej prezentacji załóżmy jedno wymaganie odnośnie dobrego projektu: kilka lat po wdrożeniu i utrzymywywaniu aplikacji, nowo dołączająca osoba nie ma ochoty uciec z krzykiem. Opowiem o tym, jak wygląda przeprowadzenie projektu od analizy do wdrożenia, z całą masą rzeczy o których trzeba pamiętać po drodze. Odpowiem na pytanie "co każdy projekt powinien mieć? Jak powinien funkcjonować". Wytłumaczę które rzeczy da się nadrobić, a wprowadzenie których na zbyt późnym etapie będzie bardzo kosztowne. Przy odrobinie szczęścia, wiedza wyniesiona z tej prezentacji pozwoli uniknąć tzw. kodu "legacy".

"Jeden prosty trik, by rozwiązać wszystkie Twoje projektowe problemy!". No może nie wszystkie, ale na pewno jakąś ich część. I może nie do końca rozwiązać, ale z pewnością lepiej je zrozumieć. 

W czasie prezentacji opowiem o tym, dlaczego warto pytać "dlaczego". Szczególnie kiedy sytuacja wydaje się beznadziejna, a kolejne "action pointy" z retrospektywy niczego nie zmieniają. Przeanalizujemy możliwe motywacje Klienta, który często zmienia wymagania biznesowe i zastanowimy się, jak można sobie z tym w projekcie poradzić. 

Chcę też pokazać uniwersalność pytania "dlaczego" i to jak sprawdza się w codziennej komunikacji z Klientem - nie tylko przy zmianie wymagań. Przedstawię przypadki z życia wzięte, gdzie proste zapytanie Klienta o jego intencje pozwoliło dobrać skuteczne rozwiązanie, tak by wszyscy byli zadowoleni. 

So where is your documentation? It should has been done yesterday! – There is no documentation in Agile – replied a lazy developer. – “Working software over comprehensive documentation” – explained another agile one. – Let’s create a change request – PM rubbed his hands – you may generate a Javadoc! – Isn’t our code self-documenting, Uncle? – asked an XP developer. – No document unless it's need is immediate and significant – confirmed Bob. How many times have you heard such conversation? Probably you are not surprised with a common reluctance concerning software and code documentation. However, do you feel comfortable with Github projects having poor readme.md? This topic is addressed to developers who want to forget about documentation and return to the code. It may also interest people who feel that the time of docx files faded away. I will talk about modern and diverse methods or documentation replacements. I will show among others how to: create living documentation which won’t be outdated tomorrow; replace user stories and executable specifications with tests (still clear to business people); generate documentation elements without waffle; create graphs and diagrams without legacy UML; document API without Swagger’s hell of annotations.