Reagowanie na zmiany vs. realizacja planu
W końcu ostatni postulat manifestu zwinności. Od razu uspokajam, że nie chodzi o to żeby pracować bez planu.
Programiści powinni pracować według jakiegoś planu – po zrealizowaniu jednego zadania, wiadomo co robić dalej. Ale czasem istnieje potrzeba zmiany harmonogramu pracy, dodania nowego zadania czy rezygnacji z innego.
Przykład 1
Firma zamawia stronę i sklep internetowy. Ponieważ jakaś wizytówka przedsiębiorstwa już istnieje, priorytetem staje się działający sklep.
Po tygodniu klient stwierdza, że niedługo musi dokonać poważnych zmian na stronie i do tego przyda mu się CMS. Programiści mogą albo trzymać się przyjętego planu i utrudnić życie klientowi, albo zamienić kolejność zadań w harmonogramie, nic przy tym nie tracąc.
Przykład 2
Programiści przygotowują aplikację wspomagającą zarządzanie w pewnej jednoosobowej firmie cateringowej.
Po pewnym czasie właściciel przedsiębiorstwa rezygnuje z utrzymywania własnej chłodni. Z kolei obroty za ostatni rok sugerują, że będzie musiał stać się płatnikiem VAT.
W takiej sytuacji programiści powinni zrezygnować z pisania modułu magazynowego i skupić się na dodaniu stawek VAT. W przeciwnym wypadku wykonają produkt zupełnie mijający się z potrzebami klienta.
Podsumowanie
Reagowanie na zmiany nie jest dużym problemem, a może pozytywnie wpłynąć na jakość produktu końcowego. Zauważyłem też, że większość zespołów programistycznych nie wzbrania się przed zmianami planu.
Oczywiście dużo łatwiej jest w porę zareagować na zmiany, jeżeli na bieżąco współpracuje się z klientem.
