Najważniejsze w transformacji jest zrozumienie, że nic nie może być robione na siłę i musi wynikać z konkretnej potrzeby optymalizacji. Dzięki wsłuchiwaniu się w swojego wewnętrznego marudę, ale również w narzekania Twoich projektowych kolegów i przełożonych możesz stać się siłą napędową zmiany. Zdiagnozujesz konieczne zmiany.
Przejście do eksploracji nigdy nie będzie nagłe i skokowe. Musisz wyjść od swojej obecnej koncepcji weryfikacji jakości i ewoluować w kierunku na eksplorację. Z biegiem czasu coraz więcej weryfikatorów będzie wykonywanych przez eksperymenty, a coraz mniej uwagi poświęcisz na formalną specyfikację.
Eksploracja jest uproszeniem codziennych czynności i formą ograniczenia niepotrzebnej pracy przy maksymalizacji efektu końcowego. W swoim obecnym projekcie i procesie musisz zdiagnozować:
- Co jest zbędne? - można to zredukować
- Co jest niezbędne, ale nudne, męczące i powtarzalne? - trzeba to zmienić
- Co jest konieczne? - musi zostać.
Może okazać się, że znany i stosowany przez Ciebie proces nagle zredukuje się do niezbędnych, ale też przynoszących realne korzyści elementów.
Nie twierdzę jednak, że eksploracja jest jedynym i ostatecznym rozwiązaniem. Opcji jest naprawdę wiele, ale eksploracja będzie prawdopodobnie najlepszym punktem startowym przy pierwszym kontakcie z softwarem. Potem możesz podejmować wiele decyzji od pozostania przy eksploracji przez automatyzację po wdrożenie testów opartych na uczeniu maszynowym. Wszystko zależy od kontekstu projektu, produktu czy całej organizacji rozwoju i utrzymania oprogramowania.
O swojej transformacji opowiem podczas konferencji PTaQ Day One – 30.03.2019, 10:45 - 11:30. Pokój: CW8, 1p. >> http://dayone.ptaq.org/
Serdecznie zapraszam
Radek Smilgin