Uzasadnione i potrzebne
Wynika z rozpoznanej potrzeby, celu, reguły albo ograniczenia.
02 · Nasze podejście
Właściwe rozwiązanie zaczyna się przed pierwszą linią kodu.
Wysokiej jakości system powstaje wtedy, gdy jego cel, użytkownicy, warunki działania i oczekiwane rezultaty są dobrze zrozumiane. Wymagania stają się wspólnym punktem odniesienia dla architektury, zakresu, jakości, zmian, odbioru i eksploatacji.
Requirements First
Requirements First - Great Solutions to Follow
Jakość systemu zaczyna się od rygorystycznego zrozumienia celu, użytkowników, kontekstu otoczenia, a następnie uwzględnienia ich od początku w architekturze, zakresie funkcjonalnym, wskaźnikach jakościowych i wydajnościowych oraz kryteriach odbioru. W Code Can Fly stosujemy podejście Requirements First - Great Solutions to Follow. Efekt? Mniej iteracji, niższe koszty utrzymania i szybsze osiągnięcie zamierzonej wartości. A Ty — od czego zaczynasz projekt IT?
Praktyka CCF
Nasze podejście wyrasta z doświadczenia.
W Code Can Fly zaczynamy od organizacji — jej procesów, ludzi, ograniczeń i celów, a nie od technologii poszukującej zastosowania. Nasza fundamentalna zasada brzmi: zanim zaprojektujemy system, wspólnie ustalamy, co ma umożliwić, jakie procesy i stanowiska wesprzeć, w jakim otoczeniu będzie działać, jakimi ograniczeniami będzie się mierzyć oraz po czym poznamy, że właściwie pełni swoją rolę. To eliminuje ryzyko budowania rozwiązań technicznie poprawnych, a biznesowo obcych.
Nasza przewaga konkurencyjna tkwi w połączeniu dwóch obszarów, które zbyt często rozdzielają tradycyjne software house’y: świetnie zarządzane wymagania wyłonione z architektury biznesowej oraz dobór architektury IT pod ich adekwatną realizację. Działamy w oparciu o branżowe wzorce: ramy architektury korporacyjnej wyznacza TOGAF, proces zarządzania wymaganiami opieramy na praktykach IREB oraz wytycznych normy ISO/IEC/IEEE 29148; BPMN i UML uspójniają narzędzie komunikacji pomiędzy interesariuszami projektu. Dzięki temu wymagania są nie tylko kompletne i spójne, ale realnie powiązane z procesami biznesowymi organizacji, a architektura służy realizacji tych wymagań, a nie odwrotnie.
Dobre wymagania to nie koszt na starcie, lecz inwestycja w decyzje, które nie okażą się później kosztownym błędem. Umożliwiają lepszą architekturę (dobór technologii i wzorców, które służą celom, a nie modzie), przewidywalność realizacji (świadome planowanie zakresu, wczesne ujawnianie zależności i ryzyk) oraz sprawiedliwe miary sukcesu (jasne kryteria odbioru łączące prace zespołu z rezultatem istotnym dla organizacji, a nie tylko „wykonaniem zadań”). To przekłada się na mniejszą liczbę iteracji, niższe koszty utrzymania i szybsze osiągnięcie zamierzonej wartości.
Wymagania same nie budują systemu, ale stanowią punkt odniesienia dla wszystkich innych dziedzin inżynierii oprogramowania — dzięki czemu analiza, architektura, implementacja, testy i utrzymanie dostarczają wartość na rzecz realizacji tego samego celu. Wymagania żyją i ewoluują razem z wiedzą o systemie, rynkiem i użytkownikami. Kluczem jest świadome zarządzanie tą zmianą: każda modyfikacja wymaga uzasadnienia, analizy wpływu i powiązania z decyzjami, na które wpływa. Dzięki temu elastyczność nie oznacza chaosu, a iteracje prowadzą w stronę lepszego rozwiązania.
Bazując na takim fundamencie, dostarczamy rozwiązania o najwyższej jakości, wykorzystując do tego celu technologie i procesy wytwórcze dobrane do jak najszybszego osiągnięcia celu projektu.
Potrafimy mierzyć to, co wytwarzamy — m.in. z wykorzystaniem metod punktów funkcyjnych (COSMIC, IFPUG) — co pozwala nam z dużą precyzją szacować i kontrolować terminy oraz koszty wytwarzania.
Doświadczenie przekładamy na uporządkowany proces.
Nasza metoda nie powstała w prezentacjach ani w ramach jednorazowych wdrożeń. Została ukształtowana przez doświadczenie z analizą, architekturą, budową, testowaniem, wdrażaniem i utrzymaniem dużych systemów, w których największe problemy niemal zawsze miały swoje źródło w nieuzgodnionych celach, ukrytych założeniach, niedoskonale rozpoznanych zależnościach lub w wymaganiach, których nie dało się jednoznacznie zweryfikować. W Code Can Fly traktujemy te doświadczenia jako strategiczny atut: dzięki nim wiemy, gdzie i kiedy pojawiają się realne ryzyka, a przede wszystkim — jak je eliminować, zanim staną się kosztownym problemem.
Dlatego stosujemy własny, uporządkowany proces analizy, w którym łączymy świat biznesu z inżynierią w sposób, który jest zarówno rygorystyczny, jak i praktyczny. Pozyskujemy wiedzę od wszystkich kluczowych interesariuszy, porządkujemy ją i transformujemy we wspólną platformę wiedzy opisanej w jednolity sposób dla naszych klientów oraz zespołu realizacyjnego.
Dbamy o wspólne pojęcia, identyfikujemy założenia i uwidaczniamy zależności — dzięki czemu decyzje są podejmowane na podstawie faktów, a nie domysłów. Weryfikujemy i uzgadniamy wymagania z osobami posiadającymi wiedzę domenową oraz z zespołem odpowiedzialnym za architekturę, implementację, testy i późniejsze działanie rozwiązania, aby sprzeczności, luki i ryzyka można było rozwiązywać wtedy, gdy ich korekta jest jeszcze stosunkowo łatwa i tania.
Uznane standardy i metodyki, będące fundamentem naszych standardów pracy, potrafimy elastycznie dostosowywać do realiów przedsięwzięcia. Zamiast wdrażać je „na siłę”, dobieramy sposób pracy i poziom formalizacji do skali, ryzyka, etapu życia oraz otoczenia systemu — tak, aby wspierały proces oceny i decyzji, a nie zastępowały wiedzy domenowej, odpowiedzialności ani wyborów wynikających z faktycznej sytuacji organizacji. W Code Can Fly metodyka jest narzędziem do osiągania celu, nie celem samym w sobie; jej wartość mierzymy skutecznością, przewidywalnością i realnym wpływem na jakość dostarczanego rozwiązania.
Jakość wymagań
Co oznacza, że wymagania są dobrej jakości?
Nie chodzi o długość dokumentu ani liczbę zapisanych punktów. Dobre wymagania pozwalają uczestnikom przedsięwzięcia rozumieć tę samą potrzebę, podejmować spójne decyzje i potwierdzić, czy rozwiązanie spełnia uzgodniony cel. Konkretne kryteria oraz poziom ich rygoru dobieramy do kontekstu systemu.
Dobre pojedyncze wymaganie jest:
Jednoznaczne i zrozumiałe
Osoby zaangażowane w realizację interpretują je w ten sam sposób.
Pojedyncze i na właściwym poziomie
Opisuje jeden istotny aspekt rozwiązania z poziomem szczegółowości odpowiednim dla danej decyzji.
Kompletne w swoim kontekście
Zawiera informacje konieczne do jego zrozumienia, zaprojektowania i sprawdzenia.
Wykonalne
Uwzględnia realne ograniczenia techniczne, organizacyjne, prawne, czasowe i ekonomiczne.
Weryfikowalne
Pozwala ustalić jednoznaczny sposób potwierdzenia, że rozwiązanie je spełnia.
Dobry zbiór wymagań jest:
Kompletny na danym etapie
Obejmuje znane i istotne wymagania funkcjonalne, jakościowe, integracyjne, regulacyjne i eksploatacyjne potrzebne do podejmowanych decyzji.
Spójny
Nie zawiera sprzeczności, niekontrolowanych powtórzeń ani rozbieżnej terminologii.
Zwalidowany względem celów
Jako całość opisuje rozwiązanie odpowiadające rzeczywistym potrzebom organizacji i użytkowników.
Śledzalny
Pozwala przejść od źródła i celu przez decyzje architektoniczne oraz realizację aż do testów i odbioru.
Możliwy do zarządzania
Wymagania mają ustalone znaczenie, priorytety, właścicieli, wersje i kontrolowaną historię zmian.
Możliwy do rozwijania
Można go modyfikować bez utraty spójności, kontekstu i wiedzy o wpływie zmiany.
Cykl życia
Wymagania prowadzą system przez cały cykl życia.
Wymaganie nie kończy swojej roli z chwilą zaakceptowania analizy. Łączymy je z decyzjami architektonicznymi, zakresem realizacji, kryteriami jakości i scenariuszami testowymi. Zachowane zależności pozwalają zespołowi rozumieć, dlaczego dany element rozwiązania powstał i jakie konsekwencje może mieć jego zmiana.
Podczas wdrożenia i odbioru wymagania pomagają potwierdzić, czy system realizuje uzgodnione cele. Po uruchomieniu pozostają kontekstem dla utrzymania, obsługi incydentów, dalszego rozwoju oraz kolejnych zmian biznesowych i technologicznych.
Wiedza zgromadzona na początku nie ginie więc na granicy pomiędzy analizą, architekturą, budową, testami i eksploatacją. Kolejne kompetencje pracują na wspólnym fundamencie, a odpowiedzialność za rezultat zachowuje ciągłość.
- 01
Potrzeba organizacji
Cel, interesariusze, kontekst i oczekiwany rezultat.
- 02
Wymaganie
Pozyskanie, uzgodnienie, zapis i walidacja.
- 03
Architektura
Decyzje projektowe powiązane z wymaganiami i ryzykiem.
- 04
Realizacja
Zakres prac, implementacja, integracje i kontrola konfiguracji.
- 05
Test i odbiór
Dowody spełnienia uzgodnionych kryteriów.
- 06
Eksploatacja i zmiana
Utrzymanie kontekstu, analiza wpływu i kontrolowany rozwój.
Kontrolowana zmiana
Zmiana pozostaje decyzją, nie przypadkiem.
Stabilność rozwiązania nie bierze się z zakazu zmian. Bierze się z wiedzy, dlaczego wymagania istnieją, z jakimi celami są powiązane i na jakie części systemu wpływają.
Kiedy pojawia się nowa potrzeba, oceniamy jej konsekwencje dla zakresu, architektury, bezpieczeństwa, jakości, zależności, terminu, kosztu i kryteriów odbioru. Zmiana pozostaje wtedy świadomą decyzją, a nie przypadkową ingerencją w system.
Taki fundament pozwala budować rozwiązania, które są dobre nie tylko w dniu wdrożenia, ale również możliwe do bezpiecznego utrzymania i rozwoju przez kolejne lata.
Wielu wykonawców
Jasna odpowiedzialność także w środowisku wielu wykonawców.
W złożonych przedsięwzięciach wymagania tworzą wspólny język pomiędzy organizacją, CCF i pozostałymi wykonawcami. Porządkujemy granice zakresów, zależności oraz przepływ informacji i decyzji.
Partnerzy mogą uzupełniać specjalistyczne kompetencje, ale nie mogą rozmywać odpowiedzialności CCF za uzgodniony rezultat.
Zacznijmy od tego, co system ma umożliwić Twojej organizacji.
Porozmawiajmy o celu, warunkach działania i wymaganiach, które powinny stać się fundamentem rozwiązania.
Porozmawiajmy