Agile Software Development 101

Съдържание

Кратко описание на жизнения цикъл на разработката на софтуер
Защо гъвкавите разработки са различни
Agile Practices
Защо да вървим пъргав?
Без грешки, без стрес - Вашето стъпка по стъпка ръководство за създаване на софтуер, променящ живота, без да разрушава живота ви

За вкъщи:

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

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

Кратко описание на жизнения цикъл на разработката на софтуер

Жизненият цикъл на разработката на софтуер (SDLC) е процес на създаване на софтуерни решения или модифициране на съществуващите структури, предназначени да се справят с определен проблем. Тя обхваща различни стъпки, които се следват в логичен ред. В традиционните SDLC модели това са стъпките, които се следват една след друга и обикновено се извършват изолирано:

Изисквания, събирани от клиентите
Анализ на системата и осъществимостта
Дизайн и моделиране
Кодиране или внедряване
Тестване
Разгръщане и доставка
Заявки за поддръжка и промяна

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

Защо гъвкавите разработки са различни

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

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

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

Agile Practices

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

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

Тестова разработка (TDD)
В идеалния случай разработчиците трябва първо да напишат тестови случаи за частта от функционалността, за която ще кодират. Това ще осигури добро качество на кода, който е по-малко вероятно да се счупи при изключителни условия. Този процес също помага да се гарантира, че потребителските спецификации са адресирани.
Програмиране на двойки
В развитието на Agile програмистите обикновено работят по един и същ проблем по двойки, при което един човек пише кода (драйвер), а другият преглежда кода и предоставя идеи и предложения (навигатор). Това повишава производителността и намалява времето, необходимо за преглед на кода.
Код Рефакторинг
Рефакторингът на кодове включва разбиване на кода на по-малки и опростени модули, които могат (и би трябвало) да съществуват независимо в идеалния сценарий. Това подобрява до голяма степен четливостта, тестируемостта и поддържането на кода.
Активно участие на реални заинтересовани страни
Следвайки редовни интервали от определен период от време (наричани "ss"), клиентите трябва да получат значим работещ прототип на софтуера. Това позволява на разработчиците да получават обратна информация за това, което изграждат, докато отиват.
Третирайте изискванията като приоритетен пакет
В Agile е от съществено значение да се категоризират изискванията въз основа на тяхната важност. Това може да включва както неявни, така и изрични очаквания на клиентите по отношение на софтуерния продукт, който се разработва. Екипът за разработка на софтуер трябва да прецени колективно времето и ресурсите, които ще инвестират в реализирането на функцията, и да ги преброи въз основа на потребителските изисквания и относителния ред, в който те ще се справят с всяка част от проекта.
Регресионно тестване
Тестът за регресия включва тестване на функционалността на цяло приложение след добавяне на нова функция или промяна на съществуващата функционалност в кода. Това помага да се гарантира, че промените не са нарушили съществуващия код.

Защо да вървим пъргав?

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