On 02/01/2013 17:28, AK wrote:
> Użytkownik "Wojciech Muła" <w...@g...com> napisał :
>
>> Agile skupia się na tworzeniu działającego produktu, nie dostarcza
>> żadnych narzędzi dla zespołu w celu tworzenia utrzymywalnego programu
> ^^^^^^^^^^^^^^^
>
> To (i calosc posta Wojtka) to dla mnie sedno tzw. Agile.

Jest dokładnie przeciwnie - to Agile wprowadziło skuteczne narzędzia do
tworzenia utrzymywalnego programu. Przedtem było tak, że się tworzyło
program, a potem w ramach utrzymywania jego utrzymywalność się stopniowo
degradowała, aż dochodziło do tego, że taniej było zrobić rewrite niż
zmieniać istniejący kod.

Właśnie zakończyłem udział w projekcie, który był wdrażany przez dwa
lata zanim do niego przystąpiłem. Przez to, że projekt nie korzystał z
narzędzi Agile wyszło na to, że efektem dwóch lat pracy był
niedziałający nieutrzymywalny kod i ileś tam sron bezużytecznej
dokumentacji, plus bardzo wkurzony klient. Dopiero zastosowanie narzędzi
typowych dla Agile (jeden z wdrożeniowców wciągniętych do projektu ma w
tym spore doświadczenie) pozwoliło na to, że stopniowo zaczęliśmy
opanowywać sytuację.

Sam produkt, który był w tym projekcie wdrażany, jest również tworzony
metodami tradycyjnymi (nie Agile). Rezultatem jest nie tylko niska
niezawodnośc produktu (dużo bugów), ale też właśnie kod trudny w
utrzymaniu (niektóre moduły mają po kilkanaście tysięcy linii kodu,
niektóre funkcje po kilka tysięcy). Jedno z drugim oczywiście się ściśle
wiąże - niska czytelność kodu powoduje, że łatwo wprowadzić bugi, niski
test coverage powoduje bugi z jednej strony i ryzykowność refaktoryzacji
z drugiej.

Brak "agility" był również bezpośrednią przyczyną zawalenia się bardzzo
lukratywnego kontraktu na dostarczenie klientowi specjalnej wersji owego
produktu: klient widział żonglerkę wymaganiami, a nie widział
działającego oprogramowania, więc pomimo wpakowania w projekt milionów
dolarów wolał zrezygnować i zrobić sobie wszystko samemu, niż wpakować
kolejne miliony w coś co, jak uznał, nie ma wystarczająco dużej szansy
na satysfakcjonujące rezultaty.

Dla porównania miałem okazję zaobserwować zespół tworzący podobny
produkt w tej samej firmie (dlaczego ta samam firma produkuje dwa bardzo
podobne produkty to osobny temat) i ten zespół stosuje Scrum i praktyki
inżynieryjne Agile. Nie tylko mają przez to mniejsze problemy z
niezawodnością, ale też właśnie ich kod jest znacznie łatwiejszy w
utrzymaniu.

Na koniec jeszcze napiszę o małym projekciku, który przejąłem po innym
programiście. Teoretycznie utrzymywalność nie była taka istotna, bo z
założenia był to "throwaway code" do wykonania raz. Programista, od
którego przejąłem projekt pisał go od mniej-więcej roku i nie potrafił
doprowadzić go do postaci nadającej się do odpalenia w produkcji. Z
różnych względów pełny proces Agile nie miał zastosowania, przede
wszystkim dlatego, że był tylko jedcen programista, ale też np. uznałem,
że ze względu na specyfikę kodu pełny TDD byłby nieco overkill, ale
jednak udało mi się opanować i zakończyć projekt przed terminem dzięki
zastosowaniu narzędzi Agile, głównie związanych z komunikacją z
klientami, ale w ramach utrzymywalności kodu (która okazała się nie taka
jednak znowu nieistotna) bardzo przydatnym narzędziem był na przykład
"merciless refactoring" (co może się wydawać ryzykowne bez TDD, ale
dzięki specyfice kodu i narzędziom do automatycznej refaktoryzacji byłem
w stanie utrzymać ryzyko na akceptowalnym poziomie).