Как Agile IT може да трансформира ИТ индустрията?

Автор: Roger Morrison
Дата На Създаване: 20 Септември 2021
Дата На Актуализиране: 21 Юни 2024
Anonim
30 глупых вопросов Agile-коучу [Карьера в IT]
Видео: 30 глупых вопросов Agile-коучу [Карьера в IT]

Съдържание



Източник: Darkovujic / Dreamstime.com

За вкъщи:

За много от тях моделът на разработка на софтуер за разработка на софтуер е стандартът от десетилетия, но това сега е заменено от много по-гъвкавата методология Agile.

Agile методологията за разработка на софтуер може да повлияе положително на ИТ индустрията. Резултатите от приемането на методологията Agile могат да бъдат измерени по много начини. По-бързия обрат на заявките за промяна на софтуера, по-малко грешки, количественото измерване на ефективността на екипа и затрудненията са отражение на успешното внедряване на Agile. За да измерва успешно въздействието на Agile, една организация трябва да сравнява различни показатели, свързани с преди Agile и след Agile развитие. Реалното въздействие на Agile не може да бъде измерено само от увеличението на приходите или от увеличения брой отстранени грешки. За да се разбере реалното въздействие, трябва да се имат предвид няколко вътрешни параметри. (За повече информация за Agile разработката вижте Agile Software Development 101.)


Защо Agile IT?

ИТ индустрията е наклонена към Agile практики главно поради ограниченията на водопадния модел на разработка на софтуер. Като цяло се забелязва, че ИТ компаниите не са в състояние да отговорят на променящите се изисквания на клиентите или пазарните ситуации или да намалят разходите с модела на водопад при разработване на софтуер. Дори да противодействаме на този преобладаващ наклон към методологията на Agile и считаме, че някои от вълненията са просто свръх, има много емпирични отзиви срещу модела на водопада.

Просто казано, моделът на водопада е модел за разработка на софтуер, при който работата се извършва последователно - една фаза след друга. Има пет фази на този модел: изисквания, дизайн, изпълнение, проверка и поддръжка. Обикновено след приключване на една фаза е трудно, ако не и невъзможно, да се направят промени в по-ранна фаза. И така, предположението е, че изискванията са доста фиксирани. Основната разлика с модела Agile е в предположението, че няма да има промяна в изискванията. Agile предполага, че бизнес ситуациите ще се променят, както и изискванията. Така че софтуерът се доставя на по-малки парчета през ss, докато при модела на водопада първата доставка или освобождаване се извършва след дълго време. (За повече информация относно развитието вижте как Apache Spark помага за бързото развитие на приложения.)


Най-забележителната критика срещу модела на водопада е предположението, че няма да има промяна в изискванията. Самото предположение е недостатъчно и нереалистично. Например, през 2001 г. проучване на 1027 ИТ проекти в САЩ показа, че това предположение е единствената най-голяма причина за провала на ИТ проектите.

В друг пример, Крейг Ларман, авторът на книгата „Гъвкаво и итеративно развитие: Ръководство на мениджъра“, посочи как редица проекти, изпълнени от Министерството на отбраната (DoD), използвайки модела на водопада в САЩ, не успяха да постигат целите си. През 80-те и 90-те години на миналия век, DoD е трябвало да използва модела на водопада за своите проекти за разработка на софтуер съгласно стандартите, публикувани в DoD STD 2167. Шокираща статистика разкрива, че 75% от тези софтуерни проекти никога не са били използвани. След този доклад беше създадена работна група под ръководството на д-р Фредерик Брукс, известен експерт по софтуерно инженерство. Работната група излезе с доклад, който коментира, че „DoD STD 2167 също се нуждае от радикален ремонт, за да отразява най-добрите съвременни практики. Еволюционното развитие е най-доброто в техническо отношение, спестява време и пари. “

Следните четири предположения за модела на водопада са се провалили в реалните сценарии:

  • Дадените изисквания са достатъчно добре дефинирани и затова няма да се променят значително.
  • Дори и изискванията да се променят по време на фазата на разработване, те ще бъдат достатъчно малки, за да бъдат настанени в рамките на цикъла на развитие.
  • Системната интеграция, която се случва след доставката на софтуер, ще върви според плана.
  • Софтуерните иновации и усилията, необходими за иновации, ще вървят според планиран и предвидим график.

Как Agile Методология се справя с проблемите на модела на водопада?

Методиката Agile е коренно различна от модела на водопада и това е ясно от неговите предположения:

  • Никой, дори и клиентът, не може напълно да знае или да разбере изискванията. Няма гаранция, че изискванията няма да се променят.
  • Промените в изискванията може да не са малки и управляеми. Всъщност те ще се предлагат в различни размери и ще продължават да идват. Така че софтуерът ще се доставя на малки стъпки, за да следи промените.

Как Agile повлия на ИТ индустрията?

Agile се приема на много места, докато много компании правят планове да приемат Agile. Въпреки че Agile определено направи фундаментални промени в ИТ индустрията, факти и цифри все още са малко трудни за получаване. Но въздействието на Agile може да бъде разбрано с казуса на British Telecom (BT), даден по-долу.

Без грешки, без стрес - Вашето стъпка по стъпка ръководство за създаване на софтуер, променящ живота, без да разрушава живота ви


Не можете да подобрите уменията си за програмиране, когато никой не се интересува от качеството на софтуера.

Причини BT се насочи към Agile практики

BT започна да среща редица проблеми с практиките си за разработка на софтуер през 2004 г. BT разработи редица софтуерни проекти, както прости, така и сложни. Много софтуерни проекти не успяха да разработят качествена продукция в рамките на договорените срокове. BT установи, че проблемите дължат корените си на модела на водопада. Така че укрепването на модела на водопада нямаше да помогне. Основните причини за проблемите са дадени по-долу:

Лошо управление на изискванията

  • Бяха зададени твърде много изисквания, за да бъдат изпълнени в твърде ограничен срок.
  • Много изисквания бяха без значение за нуждите на бизнеса.
  • Почти всички, ако не всички изисквания са били присвоени с висок приоритет.
  • Изискванията представляват текущите нужди на бизнеса, без да се обръща внимание на бъдещите сценарии. Това остави отворена възможност за бъдещи промени в софтуера.

Лош софтуер за дизайн

  • Предвид огромния брой изисквания, дизайнерите изразходваха твърде много време, само опитвайки се да разберат какво означават изискванията. Остана малко време за действителния дизайн.
  • Анализаторите на изискванията преминаха към други задачи, като взеха със себе си неписани, мълчаливи знания.
  • Горните два фактора доведоха до лош дизайн. Дизайнерите все още трябваше да доставят в съответствие с оригиналната времева линия.

Ограничения за развитие

Кодирането беше прибързано и с лошо качество поради недостатъчен дизайн на софтуера. Разработчиците биха разбрали, че лошият софтуерен дизайн би довел до лош код, но въпреки това трябваше да се изпълни по договорения график. Много грешки ще бъдат докладвани по време на интеграцията, тъй като единичните тестове и регресионните тестове не са били изпълнени.

По време на внедряването на софтуера клиентът отбелязва, че изискванията вече са променени, както и бизнес сценарият. Софтуерът също има много проблеми. Ефективно, цялото усилие за разработка на софтуер сега се счита за загуба.

Какво направи BT за справяне с горепосочените проблеми?

BT разбра, че укрепването на модела на водопада не е отговорът на проблемите. Трябваше нов подход. И така, той реши да приложи подхода Agile. Съгласно новия подход бяха решени следните неща:

  • Вместо 12-месечния цикъл на разработка, BT вече ще доставя работещи части от софтуера в 90-дневен цикъл. Идеята беше да се съсредоточим върху един или два бизнес проблема и да се насочим към доставяне на софтуерно решение в рамките на 90 дни. Началото на този цикъл бе белязано от интензивна дискусия между различни заинтересовани страни, така че изискванията да бъдат ясно идентифицирани, анализирани и приоритизирани.
  • Целта беше да се осигурят ясни и осезаеми бизнес стойности. Вътрешният клиент беше под напрежение, за да осигури ясни изисквания. Така вместо неясни цели бяха дадени потребителски истории с ясни критерии за приемане.
  • Софтуерът, който ще бъде доставен, ще бъде напълно тестван и документиран. Софтуерът ще преминава през чести интеграционни тестове, за да идентифицира проблемите предварително.

С Agile подхода BT може да се адаптира към променящите се изисквания или бизнес ситуации по-лесно. Качеството на кода се подобри и бяха адресирани основните грешки в последната минута.

заключение

Agile, за всичките си предимства и свръх около него, все още е на етап, в който потенциалът му не е напълно реализиран. Това е така, защото много организации персонализират подхода до степен на изменение на първоначалните му принципи. В резултат моделът на водопада в някои случаи се завръща. Въпреки че персонализирането ще продължи, важно е да се запазят основните принципи на Agiles. Много организации твърдят, че са напълно Agile, но те все още имат някакъв път, за да станат наистина Agile компания.