Този сайт използва бисквитки (cookies). Ако желаете можете да научите повече тук. Разбрах

Новини Технологии и концепции
бр. 4, 2018

Как да задобреете в Agile разработките

Трябва да обогатите познанията си с набор от дисциплини и технологии, за да овладеете Agile методологията.

от , 24 април 2018 0 663 прочитания,

Исаак Саколик, IDG, САЩ

Ако ръководите или сте част от екип за Agile разработки, с избран модел, например Scrum, разполагате с основен процес, чрез който да синхронизирате доставчиците на приложения с набелязаните цели. Задачите са разпределени, графикът и дневният ред на срещите са уточнение, както и Agile инструментите за управление на backlog-а.

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

Достатъчен ли е тогава Agile процесът сам по себе си за постигането на добър работещ софтуер?

Отговорът е „не“. Нужно е още да обогатите познанията си с набор от дисциплини, често поддържани от технологии, за да овладеете Agile методологията.

Въпросите, на които трябва да си отговорите, са:

  • Какви технически аспекти трябва да се вземат предвид, за да се гарантира, че инструментите за сътрудничество могат да поддържат жизнения цикъл на разработката?

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

  • Как да се дефинира и третира техническия дълг в Agile разработките?

Как да задобреете в Agile разработките

Често се изискват много компромиси, за да се осъществят заложените потребителски истории. Още при съставянето ми, започва обсъждането на вариантите на функционалностите, особено ако екипите използват Agile при оценка на ключовите моменти или други измерители.

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

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

Важна отговорност на разработчиците в Agile екипа е да записват техническия дълг. При малките проблеми, това може да се направи в кода с коментари на задачи, когато следващият разработчик работи над него. По-големи проблеми в кода, които налагат рефакторинг, трябва да се категоризират в backlog-а.

Дисциплинираните Agile екипи ще намерят начин да приоретизират техническия дълг и ще помолят собствениците на продукта да заделят поне 30% от своя backlog за справяне с него. Този процент е определен въз основа на средна стойност от 20-30%, които софтуерните доставчици залагат в договорите си за поддръжка, но той може да бъде по-нисък за нови приложения и доста по-висок за стари.

Може да се справите с техническия дълг на няколко нива:

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

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

  • В една потребителска история, екипът може да препоръча мерки, с които да се третира основният технически дълг.

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

Контрол на качеството при Agile разработките

Един от най-честите проблеми на лидерите на Agile екипи е как да приложат практиките за контрол на качеството (Quality Assurance или QA) в процеса разработване, особено ако се прилага Scrum методологията. Идеята да си „свършил работата“ в края на спринта означава, че QA може да направят всеки функционален или регресионен тест в рамките на спринта. Това обаче не е лесно, когато продължителността на спринта е кратка и ако разработчиците искат да кодират през цялото време до пускането на демо версията.

Включването на качествения контрол не е лесно и когато не е ясно кой отговаря за контрола и кой за разработките. А практиките за тестване на раздели, автоматизацията при разработване, както и на нивото на тестовете създава още затруднения. Освен това, има много практики при тестването в т.ч. тестване на програмни интерфейси, функционалност, данни, мобилни интерфейси, сигурност на приложенията, работата и мащабируемостта. Всички тези тестове може да са трудно осъществими или дори оправдани, когато се очаква новите функционалности да се пуснат по-бързо на пазара.

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

За да се синхронизира тестването и разработването, трябва да се види кога то може да се интегрира в процеса на разработване. Например, при Scrum методология това става така:

  • Първоначалното тестване на потребителските истории започва в началото на разработката им. Важно е обаче софтуерните специалисти да се опитат да приключат високорисковите истории и онези, които изискват повече тестове в по-ранните етапи на спринта.

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

  • Тестове на сигурността, анализа на кода и тестове на работата могат да се планират и да бъдат извършени върху кода, приключен при предходния спринт. Финални тестове трябва да се насрочат, преди разработката да бъде пусната в реална среда.

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

Как да задобреете в Agile разработките

Идентифициране на стандарт при разклоняването на кода

Основополагаща практика при Agile разработването е способността то да се разбие в множество пътеки и да се подготви кода за пускане в експлоатация в отделни тестови и производствени среди.

Инструментите са се развили значително през последните няколко години и много екипи са се научили да използват такива като Git за нещо, което някога се смяташе за напреднали практики за управление на сорс код. Високо производителните Agile екипи знаят как да използват тези инструменти, за да повишават производителността и да вкарат гъвкави процеси на разработване за различните видове дейности.

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

  • Функционалност в собствен клон, която след завършване се слива с останалия код.

  • Пачове за решаване на проблеми по пускането в експлоатация, без да се използва код, който все още се разработва.

  • Ъпгрейди на компоненти или архитектури, изискващи значителни промени в кода, при положение че тестването може да се извърши в отделни клонове, докато не станат готови за пускане в експлоатация.

Прилагане на преглед на кода с цел подобряване на качеството и сътрудничеството между разработчиците

Друго приложение на инструменти като Git за управление на сорс кода е за формализиране на прегледите на кода. В Git разработчиците обикновено ползват един клон или функционалност и доставят код в зависимост от нуждите, или на базата на политики. Когато е завършен, разработчикът пуска заявка за преместване на промените от клона за разработване в този за тестване. След това втори разработчик слива тази заявка в тестовете.

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

Прилагане на непрекъсната интеграция и непрекъсната доставка

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

Исторически погледнато, много приложения са изградени и доставени на ръчни етапи: разработчиците извършват стъпка в интегрирана среда(integrated development environment или IDE), след което пакетират резултата чрез скриптове. Изпращат файла по FTP на място, където някой от екипа по операциите, след получаване на одобрена заявка за промяна, предприема множество стъпки за доставянето на кода в предвидената реална среда. Този ръчен процес може да генерира много грешки и е неефективен за бизнес и технологичните екипи, които искат да внедряват чести промени в реална среда.

Решението е стъпките да се автоматизират. Когато екипите по разработките и операциите си сътрудничат в подобряването на гъвкавостта и стабилността на работа, се появяват devops практиките. Ключовите devops практики включват:

  • Непрекъсната интеграция (Continuous integration или CI), където клоновете се сливат често и процесът на изграждане на приложенията е автоматизиран.

  • Непрекъснатата доставка (Continuous delivery или CD), където софтуерът се пуска в избрана реална среда с натискането на един бутон.

Непрекъсната интеграция и доставка (CI/CD) изискват автоматизация на тестовете. Те са част от стратегията за управление на версиите, която всяка организация трябва да има като част от своя Agile процес на разработване. Най-напредналите софтуерни компании, които искат да пускат код по-често (ежедневно и дори по-често), предприемат и последната стъпка към непрекъснато внедряване.

Agile методологията позволява повече автоматизация и подобрява процесите

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

Най-добре е да започнете с решенията, която влияят на поведението на клиентите. Формулирайте нуждите от автоматизация и сътрудничество като потребителски истории и ги направете приоритет в backlog-а, сякаш са софтуерен проект. След това започнете да ги внедрявате и подгответе стратегия за бъдещи подобрения.

КОМЕНТАРИ ОТ  

Полезни страници
    За нас | Аудитория | Реклама | Контакти | Общи условия |
    Действителни собственици на настоящото издание са Иво Георгиев Прокопиев и Теодор Иванов Захов