Jak sprawne IT może przekształcić przemysł IT?

Zawartość

• Dlaczego Agile IT?
• Jak metodologia zwinna rozwiązuje problemy modelu wodospadu?
• Jak Agile wpłynęło na branżę IT?
• Bez błędów, bez stresu - Twój przewodnik krok po kroku do tworzenia oprogramowania zmieniającego życie bez niszczenia życia
• Powody przejścia BT na praktyki zwinne
• Słabe zarządzanie wymaganiami
  
• Zły projekt oprogramowania
• Ograniczenia rozwojowe
• Co zrobił BT, aby rozwiązać powyższe problemy?
• Wniosek

Źródło: Darkovujic / Dreamstime.com

Na wynos:

Dla wielu model tworzenia oprogramowania typu wodospad był od dziesięcioleci standardem, ale obecnie jest on zastępowany przez znacznie bardziej elastyczną metodologię Agile.

Zwinna metodologia tworzenia oprogramowania może pozytywnie wpłynąć na branżę IT. Wyniki przyjęcia metodologii Agile można mierzyć na wiele sposobów. Szybsze przetwarzanie żądań zmiany oprogramowania, mniej błędów, ilościowy pomiar wydajności zespołu i wąskie gardła są odzwierciedleniem udanego wdrożenia Agile. Aby skutecznie zmierzyć wpływ Agile, organizacja musi porównać różne wskaźniki związane z rozwojem Agile i Agile. Rzeczywistego wpływu Agile nie można zmierzyć jedynie wzrostem przychodów lub większą liczbą naprawionych błędów. Aby zrozumieć rzeczywisty wpływ, należy wziąć pod uwagę kilka parametrów wewnętrznych. (Aby uzyskać więcej informacji na temat programowania Agile, zobacz Agile Software Development 101.)

Dlaczego Agile IT?

Branża IT skłania się ku praktykom zwinnym głównie ze względu na ograniczenia modelu tworzenia oprogramowania typu kaskadowego. Zasadniczo zaobserwowano, że firmy IT nie są w stanie reagować na zmieniające się wymagania klientów lub sytuacje rynkowe ani obniżać kosztów za pomocą wodospadowego modelu rozwoju oprogramowania. Nawet jeśli przeciwstawimy się temu przeważającemu przechyleniu w kierunku metodologii Agile i uznamy, że niektóre emocje są po prostu szumem, istnieje wiele empirycznych opinii na temat modelu wodospadu.

Mówiąc najprościej, model kaskadowy to model programistyczny, w którym prace są wykonywane sekwencyjnie - jedna faza po drugiej. Istnieje pięć faz tego modelu: wymagania, projekt, wdrożenie, weryfikacja i utrzymanie. Zwykle po zakończeniu jednej fazy wprowadzanie zmian do wcześniejszej fazy jest trudne, jeśli nie niemożliwe. Tak więc założeniem jest, że wymagania są właściwie ustalone. Główną różnicą w przypadku modelu Agile jest założenie, że wymagania nie ulegną zmianie. Zwinny zakłada, że ​​sytuacja biznesowa ulegnie zmianie, podobnie jak wymagania. Tak więc oprogramowanie jest dostarczane w mniejszych porcjach przez ss, podczas gdy w modelu kaskadowym pierwsza dostawa lub wydanie następuje po długim czasie. (Aby uzyskać więcej informacji na temat programowania, zobacz Jak Apache Spark pomaga w szybkim rozwoju aplikacji).

Najbardziej zauważalną krytyką modelu wodospadu było jego założenie, że wymagania nie ulegną zmianie. Samo założenie jest błędne i nierealne. Na przykład w 2001 r. Badanie dotyczące 1027 projektów informatycznych w Wielkiej Brytanii wykazało, że założenie to było jednym z największych powodów niepowodzenia projektów informatycznych.

W innym przykładzie Craig Larman, autor książki „Agile and Iterative Development: A Manager's Guide”, wskazał na to, jak wiele projektów realizowanych przez Departament Obrony (DoD) przy użyciu modelu wodospadu w USA nie udało się osiągnąć swoje cele. W latach 80. i 90. XX wieku DoD było zobowiązane do korzystania z modelu kaskadowego w swoich projektach programistycznych zgodnie ze standardami opublikowanymi w DoD STD 2167. Szokujące statystyki ujawniły, że 75% tych projektów nigdy nie było używanych. Po tym raporcie utworzono grupę zadaniową pod kierunkiem dr Fredericka Brooksa, znanego eksperta w dziedzinie inżynierii oprogramowania. Grupa zadaniowa wyszła z raportem, w którym skomentował: „DoD STD 2167 również wymaga radykalnego przeglądu, aby odzwierciedlić nowoczesne najlepsze praktyki. Ewolucyjny rozwój jest najlepszy technicznie, oszczędza czas i pieniądze. ”

Następujące cztery założenia modelu wodospadu zawiodły w rzeczywistych scenariuszach:

• Podane wymagania są dość dobrze określone, więc nie zmienią się znacząco.
• Nawet jeśli wymagania zmienią się na etapie opracowywania, będą wystarczająco małe, aby można je było uwzględnić w cyklu opracowywania.
• Integracja systemu, która nastąpi po dostarczeniu oprogramowania, przebiegnie zgodnie z planem.
• Innowacje w oprogramowaniu i wysiłek wymagany do wprowadzenia innowacji pójdą zgodnie z zaplanowanym i przewidywalnym harmonogramem.

Jak metodologia zwinna rozwiązuje problemy modelu wodospadu?

Metodologia Agile zasadniczo różni się od modelu kaskadowego i wynika to z jego założeń:

• Nikt, nawet klient, nie może w pełni poznać ani zrozumieć wymagań. Nie ma gwarancji, że wymagania się nie zmienią.
• Zmiany wymagań mogą nie być małe i możliwe do zarządzania. W rzeczywistości będą w różnych rozmiarach i będą przychodzić. Tak więc oprogramowanie będzie dostarczane w małych krokach, aby śledzić zmiany.

Jak Agile wpłynęło na branżę IT?

Agile jest adoptowane w wielu miejscach, podczas gdy wiele firm planuje adopcję Agile. Chociaż Agile zdecydowanie dokonało fundamentalnych zmian w branży IT, fakty i liczby są nadal nieco trudne do uzyskania. Ale wpływ Agile można zrozumieć na podstawie studium przypadku British Telecom (BT) podanego poniżej.

Bez błędów, bez stresu - Twój przewodnik krok po kroku do tworzenia oprogramowania zmieniającego życie bez niszczenia życia

Nie możesz poprawić swoich umiejętności programistycznych, gdy nikt nie dba o jakość oprogramowania.

Powody przejścia BT na praktyki zwinne

BT zaczęło napotykać wiele problemów z praktykami tworzenia oprogramowania w 2004 roku. BT opracowało szereg projektów oprogramowania, zarówno prostych, jak i złożonych. Wiele projektów oprogramowania nie było w stanie opracować wysokiej jakości wyników w ustalonych ramach czasowych. BT stwierdził, że problemy wynikały z modelu wodospadu. Wzmocnienie modelu wodospadu nie pomoże. Główne przyczyny problemów podano poniżej:

Słabe zarządzanie wymaganiami

• Podano zbyt wiele wymagań, aby je spełnić w zbyt krótkim czasie.
• Wiele wymagań było nieistotnych dla potrzeb biznesowych.
• Niemal wszystkie, jeśli nie wszystkie wymagania, mają status wysokiego priorytetu.
• Wymagania reprezentowały bieżące potrzeby biznesowe, nie zwracając uwagi na przyszłe scenariusze. To pozostawiło otwartą możliwość przyszłych zmian oprogramowania.

Zły projekt oprogramowania

• Biorąc pod uwagę ogromną liczbę wymagań, projektanci spędzili zbyt dużo czasu, próbując dowiedzieć się, co oznaczają wymagania. Na faktyczny projekt pozostało niewiele czasu.
• Analitycy wymagań przeszli na inne zadania, zabierając ze sobą niepisaną, milczącą wiedzę.
• Powyższe dwa czynniki spowodowały zły projekt. Projektanci wciąż musieli dostarczać zgodnie z pierwotną ramą czasową.

Ograniczenia rozwojowe

Kodowanie było szybkie i niskiej jakości z powodu wadliwego projektu oprogramowania. Deweloperzy zdawali sobie sprawę, że zły projekt oprogramowania spowodowałby zły kod, ale mimo to musiał dostarczyć zgodnie z ustalonym harmonogramem. Podczas integracji zgłoszonych zostanie wiele błędów, ponieważ testy jednostkowe i regresyjne nie zostały uruchomione.

Do czasu wdrożenia oprogramowania klient zauważa, że ​​wymagania już się zmieniły, podobnie jak scenariusz biznesowy. Oprogramowanie ma również wiele problemów. W efekcie cały wysiłek związany z tworzeniem oprogramowania jest obecnie uważany za marnotrawstwo.

Co zrobił BT, aby rozwiązać powyższe problemy?

BT zdało sobie sprawę, że wzmocnienie modelu wodospadu nie było odpowiedzią na problemy. Potrzebowało nowego podejścia. Postanowił więc wdrożyć podejście zwinne. Zgodnie z nowym podejściem podjęto następujące decyzje:

• Zamiast 12-miesięcznego cyklu programistycznego BT dostarczyłoby działające oprogramowanie w cyklu 90-dniowym. Pomysł polegał na skoncentrowaniu się na jednym lub dwóch problemach biznesowych i dostarczeniu rozwiązania programowego w ciągu 90 dni. Początek tego cyklu upłynął pod znakiem intensywnej dyskusji między różnymi zainteresowanymi stronami, dzięki czemu wymagania zostały jasno określone, przeanalizowane i uszeregowane pod względem ważności.
• Celem było dostarczenie jasnych, namacalnych wartości biznesowych. Klient wewnętrzny był pod presją zapewnienia jasnych wymagań. Dlatego zamiast niejasnych celów historie użytkowników zostały podane z jasnymi kryteriami akceptacji.
• Dostarczone oprogramowanie zostanie w pełni przetestowane i udokumentowane. Oprogramowanie przechodziłoby często testy integracyjne w celu wcześniejszego zidentyfikowania problemów.

Dzięki podejściu zwinnemu BT może łatwiej dostosować się do zmieniających się wymagań lub sytuacji biznesowych. Poprawiono jakość kodu i naprawiono podstawowe błędy z ostatniej chwili.

Wniosek

Zwinny, pomimo wszystkich swoich zalet i szumu wokół niego, wciąż znajduje się na etapie, w którym jego potencjał nie jest w pełni wykorzystany. Wynika to z faktu, że wiele organizacji dostosowuje podejście do zakresu modyfikacji jego pierwotnych zasad. W rezultacie model wodospadu powraca w niektórych przypadkach. Podczas gdy dostosowanie będzie kontynuowane, ważne jest, aby zachować podstawowe zasady Agile. Wiele organizacji twierdzi, że jest w pełni zwinnych, ale wciąż jest jeszcze wiele do zrobienia, aby stać się naprawdę zwinną firmą.