Temat: Scrum to koszmar programisty...

Scrum to koszmar programisty...

Scrum to koszmar dla prac programistycznych. Dostarczanie efektu w ciągu 2 tygodni oraz zapewnienie braku długu technologicznego. Czy to w ogóle możliwe? Sama idea tworzenia polega na tworzeniu fundamentów a następnie dopracowywania szczegółów. Znane są metafory budowania samolotu w trakcie lotu albo dobudowywanie piętra w budynku pośrodku innych. Model kaskadowy programowania z roku 1970 jest nadal aktualny - tu nie ma żadnych zmian.




https://en.wikipedia.org/wiki/Winston_W._Royce
Decyzja, aby zespół programistyczny pracował zgodnie z zasadami Scrum nie jest łatwa. Proces ten jest wręcz sprzeczny z ideą programowania, kiedy następują po sobie kolejne etapy weryfikacji pracy. Osoby na stanowiskach architekt oprogramowania mają za zadanie ustalić jakie są ramy tworzonego oprogramowania, lecz jak to zrobić w sytuacji ciągłej zmiany wymagań? W takiej sytuacji może to wyglądać wręcz jak wróżenie i przepowiadanie a nie ustalanie.

Co robimy w Scrum?
Abyśmy w pełni zrozumieli, dlaczego ta praca tak wygląda musimy zdefiniować co w niej robimy. Jest to “Przyrost”, oznacza, że coś co ciągle rośnie i ciągle jest gotowe do użytku. Od samego początku skupiamy się nad działającym oprogramowaniem, z którego jest wartość dla Interesariuszy - osób korzystających z efektu prac. Praca taka ma pewne trudności - raz stworzone rozwiązanie powinno być w odpowiedniej jakości, takiej samej jak wszystkie poprzednie.

Jakość jest strzeżona przez Definition of Done - czyli reguły stanowiące wymogi każdego zadania, np.: testy przeglądarkowe, pokrycie testami, brak wpływu na wydajność, odpowiednia jakość kodu. Dzięki temu w trakcie weryfikacji zadania nie patrzy się tylko na kryteria oddania, ale również na ogólny poziom jakości

Dlaczego tak jest?
W Scrum po każdym Sprincie powinno być stworzone coś co działa, spełnia wszystkie wymogi formalne i funkcjonalne. Oznacza to brak wydzielonego etapu tworzenia architektury, struktury - to się dzieje od razu. Łatwo sobie wyobrazić, że to powoduje sytuacje, kiedy bardzo łatwo można podjąć złą decyzję a efekty pozostają na długo. Bardzo łatwo jest stworzyć dług technologiczny.




...
https://www.linkedin.com/pulse/scrum-koszmar-programist...