Redakcja
Zacznijmy od wyjaśnienia.
WCZESNE ZAANGAŻOWANIE
Wczesne zaangażowanie odnosi się do wczesnej dbałości o jakość w projektach informatycznych, a w ostatnich latach ukuł i rozpowszechnił termin przesunięcie w lewo (ang. shift left). Jest to nic innego jak wczesne testowanie wymagań czy też kodu. Od samego początku projektu powinniśmy postawić na kontrolę jakości jako ważnej zasady pomagającej uniknąć długu technologicznego czy problemów przy wdrożeniu. Dodatkowo koncept wczesnego testowania zakłada, że większy wysiłek kontrolny wkładany jest we wczesne fazy wytwarzania. Podejście to jest jednak „nieinżynieryjne”, ponieważ „większy” nie jest tu zdefiniowane. Warto podkreślić, że wczesne zaangażowanie nie przekreśla ciągłego zaangażowania, ale zakłada ono, że to późniejsze może być zredukowane. Poniżej wyobrażenie wczesnego zaangażowania na wykresie:
POWSTRZYMANIE FAZOWE
Powstrzymanie fazowe jest dużo mniej znane, ale ma znacznie szerszą perspektywę niż wczesne zaangażowanie. Kiedy o nim mówimy, mamy na myśli próbę zatrzymania defektu w ramach pojedynczej fazy wytwórczej. Chodzi o sytuację, w której ktoś wprowadził defekt do produktu w ramach wytwarzania oprogramowania, a my w ramach tej samej fazy ten defekt znajdziemy i usuniemy. Takie działanie ma wiele zalet, bo oprócz tego, że szybko eliminujemy defekty, to jeszcze jesteśmy w stanie ukrócić ich propagowanie się czy namnażanie. Powstrzymanie fazowe jest więc przypisaniem czynności kontroli jakości do każdej czynności wytwórczej w procesie tworzenia oprogramowania. Oczywiście jest to również przypisanie do czynności wczesnych jak definiowanie wymagań czy tworzenie kodu źródłowego.
Przykładem stosowania powstrzymania fazowego jest model W.
Czynności takie, jak przegląd wymagań czy metoda TDD należą do zbioru praktyk shift left. Są one rekomendowane również w ramach powstrzymania fazowego. Na tym nie kończy się jednak lista sugerowanych praktyk, bo także późniejsze czynności, jak integrowanie kolejnych modułów czy systemów, wytwarza pewien produkt, który może być weryfikowany. Każdy półprodukt i produkt cyklu rozwoju oprogramowania może być sprawdzony. To znaczy, że każda faza wytwórcza od początku do końca procesu ma mieć zbiór praktyk kontrolnych i w każdej może nastąpić powstrzymanie fazowe.
Oba podejścia zarówno wczesnego zaangażowania, jak i powstrzymania fazowego rekomendują ciągłą kontrolę jakości, ale shift left wskazuje, że powinno być go „więcej” na początku. Brzmi to jak kolejna z wielu najlepszych praktyk, która kompletnie nie uwzględnia kontekstu projektowego. Lepiej jest oprzeć się na podejściu powstrzymania fazowego i uznać ciągłą kontrolę jakości od początku do końca procesu z założeniem dopasowania obciążenia pracą (workload) do kontekstu.
Jeśli więc następnym razem staniesz przed zadaniem lepszego zadbania o jakość i ktoś zaproponuje shift left, możesz rozszerzyć to na powstrzymanie fazowe.
Grafika artykułu jest przeróbką grafiki z https://en.wikipedia.org/wiki/Shift-left_testing#/media/File:Model-Shift-Left.jpg
