Компютърната индустрия изобилства от двусмислен език, груб жаргон и сложни идеи, които са трудни за разбиране и могат да изпратят ума ви в лудост от изчислително буфериране.
Водопад? Scrum? Пъргав?
Ако тези фрази са ви напълно чужди, не се притеснявайте; вашият услужлив екип от технологични маниаци на HashDork е тук, за да ви помогне да разберете разликите между тези решаващи етапи от процеса на разработка, така че да придобиете знания.
Всички техники за гъвкавост, схватка и водопад ще бъдат разгледани в тази публикация в блога, заедно с това как всяка може да помогне на вашия екип като цяло.
Нека започнем с пъргавината и ще продължим с останалите.
Какво е Agile?
Разработката на гъвкав софтуер следва итеративен, постепенен подход. Вместо задълбочена подготовка в началото на проекта, Agile техниките са гъвкави към променящите се нужди с течение на времето и насърчават непрекъсната обратна връзка от крайните потребители.
Многофункционални екипи работят върху продуктови итерации с течение на времето и тази работа се категоризира като изоставане и се приоритизира въз основа на бизнес или клиентска стойност. Целта на всяка итерация е да създаде използваем продукт.
Лидерството насърчава сътрудничеството, отговорността и комуникацията лице в лице в Agile методологиите.
Бизнес заинтересованите страни и разработчиците трябва да си сътрудничат, за да гарантират, че продуктът отговаря на изискванията на потребителя и на целите на компанията.
Фразата „гъвкаво развитие“ се отнася до различни методи и рамки, които се основават на идеалите и принципите, очертани в Агилен манифест.
Експертите съветват да се придържате към гъвкавите принципи и ценности и да ги използвате като ръководство, за да решите кои са правилните действия, които да предприемете в конкретна среда, докато пристъпвате към разработката на софтуер.
Съвместният и самоорганизиращ се екип са основните области на фокус за общността за разработка на гъвкав софтуер.
На екипите е позволено самостоятелно да решават как ще се справят с конкретен проект, но това не означава, че надзорниците не съществуват. Следователно гъвкавите екипи са многофункционални.
В една гъвкава парадигма мениджърите все още са необходими. Те гарантират, че всеки член на екипа има или придобива необходимите способности за проекта.
Мениджърите в гъвкава рамка работят, като насърчават атмосфера, която извежда най-доброто в екипа. Но вместо да поемат водещата роля, те често остават на заден план и оставят екипа да реши как ще постигне нещата.
Мениджърите се включват само когато екипите многократно се опитват да разрешат проблеми без успех.
Гъвкав цикъл на разработка
Етапите на цикъла на разработка Agile са изброени по-долу. Важно е да запомните, че тези фази не трябва да се извършват по ред, защото са гъвкави и постоянно се променят. Много от тези етапи протичат едновременно.
- Планиране: След като екипът на проекта реши, че дадена идея е практична и работеща, те започват да търсят функции. Тази фаза има за цел да приоритизира всяка функция и да я присвои на итерация след разбиване на идеята на по-малки детайли (функциите).
- Анализ на изискванията: За да се определят бизнес изискванията, тази стъпка включва няколко дискусии с мениджъри, заинтересовани страни и потребители. Кой ще използва продукта и как ще го използва са сред подробностите, които екипът трябва да събере. Тези стандарти трябва да бъдат конкретни, приложими и количествени.
- Дизайн: Изискванията, открити в предишния етап, се използват за подготовка на дизайна на системата и софтуера. Съображенията за външния вид на продукта или решението трябва да бъдат направени от екипа. Стратегия или план за теста също се разработва от тестовия екип.
- Внедряване, кодиране или разработка: Фокусът на този етап е върху изграждането и оценката на характеристиките и планирането на внедряването на итерации (следвайки подхода за итеративно и постепенно развитие [IID]). Тъй като няма предоставени функции, започва итерация 0 от периода на разработка. Чрез завършване на дейности като сключване на договори, настройка на настройки и финансиране, тази итерация осигурява основата за бъдещ растеж.
- Тестване: След като кодът е създаден, той се тества спрямо изискванията, за да се гарантира, че продуктът наистина удовлетворява изискванията на потребителите и отговаря на бизнес целите. На този етап се извършват тестове за единица, интеграция, система и приемливост.
- внедряване: След тестване продуктът се изпраща на клиентите, за да могат да го използват. Проектът обаче не е завършен след внедряването. Клиентите могат да се сблъскат с допълнителни проблеми, след като започнат да използват продукта, за които екипът на проекта ще трябва да намери решение.
Предимства
- По-бърза доставка с по-високо качество: Чрез разделяне на проекта на повторения (управляеми единици), екипът може да се концентрира върху по-високо качество на сътрудничество, разработка и тестване. Когато тестването се извършва с всяка итерация, проблемите се откриват и коригират по-бързо. Освен това, с постоянни последващи ревизии, този висококачествен софтуер може да бъде доставен по-бързо.
- Промяната е добре дошла: Въпреки че циклите на планиране са по-кратки, е лесно да се приемат и приспособят промените във всяка точка на проекта. Неизпълнените задачи винаги могат да бъдат подобрени и приоритизирани отново, което позволява на екипите да направят промени в проекта след няколко седмици.
- Крайната цел може да не е известна: Agile е отличен за проекти, когато крайната цел не е ясно дефинирана. С напредването на проекта целите ще станат ясни и разработката ще може лесно да посрещне тези променящи се нужди.
- Непрекъснато усъвършенстване: Гъвкавите програми насърчават потребителския и екипния принос на всички етапи от проекта, позволявайки прилагането на наученото за по-добро следващо повторение.
- Мнението на клиентите се цени: Има няколко възможности за клиентите да наблюдават как работата е завършена, да предлагат обратна връзка и наистина да повлияят на крайния резултат. Взаимодействайки толкова тясно с екипа на проекта, те могат да развият чувство за собственост.
- Силна работа в екип: Agile подчертава значението на редовната комуникация и личните срещи. Хората могат да поемат отговорност и да притежават определени компоненти на проекта, когато работят в екипи.
Недостатъци
- Членовете на екипа трябва да имат познанияe: Agile екипите често са малки. По този начин членовете на екипа трябва да притежават широк набор от умения. Освен това те трябва да разбират и да се чувстват спокойни, използвайки избраната Agile техника.
- Планирането може да бъде по-малко прецизно: Понякога може да е предизвикателство да се определи точна дата на доставка. Agile е изграден върху ограничена във времето доставка и ръководителите на проекти често пренареждат приоритетите на задачите. По този начин е вероятно някои от доставките, които първоначално са били планирани за доставка, да не бъдат завършени навреме. Освен това може да се добавят повече спринтове във всеки момент от проекта, удължавайки целия график.
- Документацията може да бъде пренебрегната: Някои членове на екипа може да повярват, че концентрирането върху документацията е по-малко важно, тъй като Agile Manifesto предпочита работещия софтуер пред задълбочената документация. Гъвкавите екипи трябва да постигнат идеалния баланс между документация и диалог, дори докато изчерпателната документация не може сама по себе си да гарантира успех на проекта.
- Крайният резултат може да се различава значително: Може да не е имало ясна стратегия за първоначалния Agile проект и следователно крайният резултат може да се промени значително от това, което първоначално се очакваше. Съществено различен краен резултат може да бъде резултат от добавяне на нови итерации въз основа на промяна на входа на клиента, тъй като Agile е толкова адаптивен.
- Времеви ангажимент на разработчиците: Екипът за разработка трябва да бъде изцяло отдаден на проекта, за да бъде гъвкавият подход ефективен. Методът Agile, който отнема повече време от конвенционалния подход, изисква постоянно активно участие и сътрудничество. Освен това това означава, че разработчиците трябва да се ангажират с цялата продължителност на проекта.
Какво е водопад?
Най-популярната итерация на жизнения цикъл на разработка на системата (SDLC) за софтуерно инженерство и ИТ проекти е известна като „подход на водопад“, който следва последователна, линейна процедура.
Диаграмата на Гант, форма на стълбовидна диаграма, която показва началната и крайната дата на всяка работа, понякога се използва за нейното планиране.
Екипът за разработка преминава към следващото ниво след приключване на една от осемте фази. Екипът не може да се върне към предишен етап, без да се наложи да рестартира цялата процедура.
Освен това може да се наложи клиентът да оцени и приеме изискванията, преди екипът да премине на следващото ниво.
Моделът на водопада е разработен в силно организирани среди на производствения и строителния сектор, където корекциите може да са твърде скъпи или дори невъзможни.
Техниката на водопада е наречена така, защото е предназначена да тече само в една посока - надолу - точно като водопад. Неговите фази включват анализ, стартиране, тестване, проектиране, изграждане, внедряване, поддръжка и тестване.
Техниката на водопада има няколко предимства, както всяка друга стратегия. Едната е, че фазите на планиране и проектиране на проекта са по-добре установени.
Клиентите и екипът за разработка са по-съгласувани, когато става въпрос за резултати от проекта, докато използват каскадна разработка на софтуер. Тъй като сте наясно с обхвата на проекта от самото начало, разработката на каскада също улеснява наблюдението на напредъка.
Процесът на водопада използва специалисти, разработчици, анализатори и тестери, за да се концентрират върху работата си в проекта, вместо целият екип да набляга на една стъпка.
Етапи на водопада
Всички шест стъпки на водопада трябва да се появят една след друга:
- Изисквания за събиране и съхранение: Трябва да натрупате задълбочени познания относно това, което този проект изисква в момента. Има няколко техники за събиране на тези данни, включително интервюта, анкети и съвместна мозъчна атака. Нуждите на проекта трябва да станат очевидни, когато тази фаза приключи и вашият екип трябва да е получил копие от документа с изискванията.
- Дизайн на системата: Системата е проектирана от вашия екип с помощта на предварително определени спецификации. По време на този етап не се извършва кодиране, но екипът задава изисквания за хардуер или език за програмиране.
- изпълнение: Този етап включва кодиране. Данните от предходния етап се използват от програмистите за изграждане на използваем продукт. Кодът често се внедрява на малки парчета, които се комбинират в края на една фаза или в началото на друга.
- Тестване: Продуктът може да започне да се тества след завършване на кода. Всички проблеми се откриват щателно и докладват от тестери. Вашият проект може да се наложи да се върне към първа фаза за преоценка, ако се появят значителни проблеми.
- Доставка/разгръщане: Продуктът е завършен на този етап и вашият екип изпраща резултатите за внедряване или пускане.
- поддръжка: Клиентът е получил продукта и го използва. Вашият екип може да се наложи да разработи корекции и актуализации, когато се появят проблеми, за да ги коригира. Отново значителни проблеми могат да изискват връщане към първа стъпка.
Предимства
- Лесен за работа и управление: Подходът на водопада е лесен за използване и разбиране, тъй като всеки проект се обработва по същия последователен начин. Преди започване на проект Waterfall не се изисква екипът да има предварителен опит или обучение. Подходът на водопада е много строг; всеки етап има набор от резултати и преглед, което го прави лесен за администриране и поддръжка.
- Изисква се добре документирана методология: Документацията, която се изисква от методологията на водопада, помага да се изяснят мотивите зад тестовете и кода. Освен това създава хартиена следа, в случай че заинтересованите страни искат допълнителна информация за определена фаза или за бъдещи инициативи.
- Налагане на дисциплина: Всяка стъпка в проект за водопад има начало и край, което улеснява съобщаването на напредъка на заинтересованите страни и клиентите. Екипът може да намали възможността за пропускане на краен срок, като постави изискванията и дизайна на първо място, преди да създаде код.
Недостатъци
- Може да е трудно да се съберат точни изисквания: Разговорите с потребителите и заинтересованите страни, за да се определят техните нужди, е един от началните етапи на проекта Waterfall. На този ранен етап от проекта може да е предизвикателство да се установят техните конкретни изисквания. Клиентите често научават за техните изисквания, докато проектът се развива, вместо да ги изразяват предварително.
- Промените трудно се понасят: Екипажът не може да възобнови работа след приключване на фаза. Много е трудно и скъпо да се върнат и да го поправят, ако научат по време на фазата на тестване, че функционалността е липсвала по време на процеса на изискванията.
- Софтуерът се предоставя след крайния срок: Две до четири фази на проекта трябва да бъдат завършени, преди да започне истинското кодиране. В резултат на това заинтересованите страни няма да видят функционален софтуер до края на жизнения цикъл.
Какво е Scrum?
Една от най-харесваните рамки за процеси за прилагане на Agile на практика е Scrum, която е подгрупа на Agile.
Това е итеративна парадигма за управление на създаването на сложен софтуер и продукти. Спринтовете, които са итерации с фиксирана дължина, които продължават една до две седмици, позволяват на екипа да пуска софтуер по редовен график.
Заинтересованите страни и членовете на екипа се събират, за да обсъдят следващите стъпки след всеки спринт. Ролите, отговорностите и срещите в Scrum остават постоянни.
Например, Scrum определя планирането на спринта, ежедневното изправяне, демонстрацията на спринта и ретроспективата на спринта като четирите ритуала, които осигуряват всяка структура на спринта.
Екипът ще използва визуални артефакти като табла със задачи или диаграми за изгаряне по време на всеки спринт, за да демонстрира напредъка и да получи постепенна обратна връзка.
В scrum екипът и собственикът на продукта работят в тясно сътрудничество, за да идентифицират и приоритизират функционалността на системата. Те постигат това чрез създаване на продуктово изоставане, което съдържа всички задачи, необходими за създаване на софтуер, който функционира по предназначение.
Пачове за грешки, нефункционални изисквания и функции трябва да бъдат включени в опашката. Многофункционалните екипи трябва да направят оценка и да се регистрират, за да доставят софтуерни увеличения през непрекъснати спринтове, които обикновено продължават 30 дни, след като целите бъдат установени.
Само екипът може да добави функционалност към спринта след ангажиране на изоставането за този спринт.
Следващата доставка на спринт, изоставането на продукта се оценява и, ако е необходимо, се приоритизира отново, а следният комплект за доставка се избира да бъде част от следващия спринт.
Scrum процес
- Продуктов недостиг: За да поръчате артикулите в продуктовия нелог, Собственикът на продукта и екипът на Scrum се срещат (работата по продуктовия нелог идва от потребителски истории и изисквания). Продуктовото изоставане е списък с всички желани функции за продукта, а не списък със задачи, които трябва да бъдат завършени. След това екипът за разработка избира задачи от натрупания продукт, които да изпълнява по време на всеки спринт.
- Спринт планиране: Преди всеки спринт, собственикът на продукта доставя на екипа най-важните елементи в изоставането на среща за планиране на спринта. След това групата избира елементи от натрупания продукт, който може да завърши по време на спринта, и ги премества в натрупания списък на спринта (който е списък със задачи за изпълнение в спринта).
- Усъвършенстване/подстригване на изоставането: За да се гарантира, че изоставането е подготвено за следващия спринт, екипът и собственикът на продукта се срещат в края на един спринт. Екипът може да отхвърли потребителски истории, които вече не са уместни, да добави нови, да преразгледа реда, в който те трябва да бъдат разгледани, или да раздели потребителските истории на по-малки задачи. По време на тази среща за „подстригване“ ще се гарантира, че изоставането включва само неща, които са уместни, задълбочени и в съответствие с целите на проекта.
- Scrum срещи всеки ден: В 15-минутна среща, наречена Daily Scrum, всеки член на екипа обсъжда своите цели и всички възникнали проблеми. Всеки ден по време на спринта, екипът участва в Daily Scrum, което държи всички на ниво.
- Среща за оценка на спринтаt: Екипът представя работата си на среща за преглед на спринта в края на всеки спринт. Вместо доклад или PowerPoint презентация, тази среща трябва да включва истинска демонстрация.
- Ретроспективна спринт среща: Екипът обсъжда всички модификации, които трябва да бъдат направени в следващия спринт, както и колко добре работи Scrum за тях в края на всеки спринт. Екипът може да обсъди положителните аспекти на спринта, отрицателните аспекти и областите за подобрение.
Предимства
- Повече отговорност от екипа: Няма ръководител на проекта, който да инструктира екипа за скръм какво да прави и кога. Вместо това работата, която може да бъде свършена във всеки спринт, се решава от екипа като цяло. Всички те си сътрудничат и си помагат, като подобряват екипната работа и насърчават индивидуалността във всеки член на екипа.
- Подобрена видимост и прозрачност на проекта: Има по-малко недоразумения и несигурност, тъй като всеки в екипа е наясно със своите отговорности благодарение на честите срещи. Екипът може да се справи с проблемите, преди те да излязат извън контрол, тъй като проблемите се забелязват предварително.
- Подобрено намаляване на разходите: Постоянната комуникация държи екипа информиран за всички проблеми или промени веднага щом се случат, което помага за спестяване на разходи и подобряване на качеството. По-малките части от функции осигуряват постоянна обратна връзка и позволяват ранна корекция на грешки, преди по-големите грешки да станат твърде скъпи за отстраняване.
- Лесен за адаптиране към промените: По-лесно е да се справите и да се адаптирате към промените, когато има чести вериги за обратна връзка и кратки спринтове. Като илюстрация, ако екипът се натъкне на съвсем нова потребителска история по време на един спринт, той може бързо да добави тази функция към следващия спринт на срещата за уточняване на натрупаните задачи.
Недостатъци
- Опасност от пълзене на обхвата: Поради липсата на определена дата за завършване, някои Scrum проекти може да се сблъскат с пълзене на обхвата. Заинтересованите страни могат да бъдат подмамени да продължат да изискват повече функции, ако няма краен срок за завършване.
- Лошият Scrum Master може да провали всичко: Мениджърът на проекти не е същото като scrum master. Scrum Master трябва да се довери на екипа, който ръководи, и никога да не им дава инструкции. Scrum Master няма власт над екипа. Проектът ще се провали, ако scrum master се опита да управлява екипа.
- Проблеми с точността може да възникнат от лошо формулирани задачи: Ако задачите не са ясно посочени, разходите и графиците по проекта няма да бъдат точни. Планирането става предизвикателство и спринтовете може да отнемат повече време от очакваното, ако първоначалните цели не са определени.
- Опитът и отдадеността са необходими за един екип: За да бъде екипът успешен, ролите и задълженията трябва да бъдат ясно дефинирани. Scrum Team изисква членове на екипа с технически умения, защото няма ясно дефинирани роли (всеки прави всичко). Екипът трябва също така да се ангажира да участва в ежедневните Scrum сесии и да се държи заедно през целия живот на проекта.
Agile срещу Scrum
Въпреки че Agile и Scrum използват една и съща методология, има някои разлики между двете. Agile Manifesto очертава набор от принципи за създаване на софтуер чрез итеративна разработка.
Scrum, от друга страна, е набор от насоки, които трябва да се спазват, докато се прави разработка на Agile софтуер. Agile е концепция, докато Scrum е техника за прилагането й на практика.
Scrum е метод за прилагане на Agile, следователно и двата имат много общи неща. И двата подхода са итеративни, дават приоритет на ранното и често доставяне на софтуер и приемат промяна. Те също така подкрепят отвореността и непрекъснатото развитие.
Agile срещу водопад
Твърд срещу гъвкав най-добре описва разликите между процеса Waterfall и Agile. Докато Agile е течен и постоянно се променя, Waterfall е много по-строга и по-твърда методология.
Тези допълнителни разлики между тях са както следва:
- Agile не изисква линеен подход, докато Waterfall е последователен.
- Въпреки че нуждите често са предварително дефинирани в проектите на Waterfall, се очаква те да се променят и адаптират в Agile инициативите.
- За разлика от Agile, проектите на Waterfall не позволяват да се правят модификации на работа, която е била завършена на предишен етап.
- Водопадът е организирана процедура, в която трябва да завършите всяка стъпка, преди да преминете към следващата. Agile обаче е гъвкава методология, която ви позволява да продължите с проекта със собствено темпо.
Agile Vs Waterfall Vs Scrum
- Водопадът повишава доверието в това, което ще бъде предоставено много скоро след като е планирано. Agile разчита на най-добрите практики на средата за разработка. Тук редица рискове на проекта могат да бъдат управлявани добре, тъй като резултатите се оценяват непрекъснато.
- Waterfall не предвижда екипът и проектът да бъдат базирани на едно и също място. Докато scrum и agile имат нужда от съвместно разполагане на служители.
- Agile се фокусира върху намаляването на преработката на проекти и насърчава промените да бъдат включени много по-рано. За разлика от водопада, който реагира по различен начин, scrum също позволява ранно откриване на промените.
- По-компактен план за крайния продукт се осигурява от agile и scrum. Това създава проблем с обещанията, дадени на купувача. За разлика от това, графиката на водопада дава на клиентите и разработчиците по-добро впечатление за крайния резултат.
- Всяка от тези техники има набор от инструменти за организиране и симулиране на задачите, включени в тяхното създаване.
Заключение
Ако сте следвали досега и сте уверени в знанията си за разликите между процесите Waterfall, Agile и Scrum, вече трябва да знаете коя стратегия ще работи най-добре за вас и вашия екип.
Техниката Waterfall, която е за проекти с определен обхват, времева рамка и бюджет, може да бъде най-добрият вариант, ако харесвате твърдите правила и процедури и установите, че те внасят яснота.
От друга страна, ако свободата и адаптивността, предлагани от Agile, ви вдъхновяват, може да е мястото, където трябва да насочите вниманието си.
Scrum обаче е правилният начин, ако желаете малко дисциплина в гъвкава рамка.
Трябва обаче да обмислите тези подходи в светлината на проекта, върху който работите, и крайния ви резултат.
Оставете коментар