Методологии за разработка на софтуер

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

Водопад

Методологията на водопада е една от най-старите и включва строго последователно изпълнение: всеки етап трябва да бъде завършен, преди да започне следващият. С други думи, преминаването към следващия етап означава, че работата на предишния етап е 100% завършена. Картината показва How работи: първо анализираме проблема (documentираме задачи, обсъждаме предизвикателства), след това проектираме (структурата на проекта се оформя на този етап) и след това codeираме и тестваме. Връщане към предишни етапи не е разрешено. Този подход се препоръчва за малки проекти, където изискванията са известни предварително и е малко вероятно да се променят. Предимства:

• Пълна и последователна documentация на всеки етап
• Лекота на използване
• Стабилни изисквания
• Бюджетите и сроковете са предварително определени

Недостатъци:

• Голямо количество documentация
• Не е много гъвкав
• Клиентът не може да види демо version на продукта
• Няма опция за движение назад

Scrum

Scrum е методология за разработка на софтуер, която разделя целия процес на повторения. В края на всяко взаимодействие екипът е готов да предостави демо version на продукта. Картината показва, че екипът преминава през всички етапи на разработка паралелно, което прави възможно да имате завършена част от проекта в края на всяка итерация. Ще се опитам да обясня накратко същността на методологията с прости думи, но има много терминология. Мисля, че най-важното е да разберем същността. Ще запомните терминологията с опит. Цялото развитие е разделено на спринтове (често 2-3 седмици). Има изоставане(списък със задачи) за целия период на разработка и за всеки отделен спринт. Всяка задача има своя собствена история (оценка на трудност). Всеки участник в процеса има роля:

• Scrum екипът се състои от професионалисти (разработчици, тестери, дизайнери), работещи по даден проект.
• Scrum master е човекът, който гарантира, че принципите на scrum се спазват.
• Собственикът на продукта е клиентът.

Тази методология разчита на комуникацията, така че има голям брой срещи:

• Stand-up – Това е кратка среща, провеждана всеки ден, в която участват всички членове на екипа. Всеки участник отговаря на 3 въпроса: Какво направих? Какво ще правя? И Howви проблеми с блокирането има?
• Среща за планиране – Тази среща се провежда в началото на спринта. На тази среща се идентифицират задачите, които трябва да бъдат изпълнени в следващия спринт.
• Ретроспекция - Тази среща се провежда в края на спринта и целта й е да се определи Howво е напequalsо добре и Howво може да се подобри.

Предимства:

• Клиентът може да види резултатите по време на процеса на разработка
• Ежедневно наблюдение на процеса на разработка
• Възможност за корекции по време на разработката
• Установена комуникация с всички членове на екипа
• Малко количество documentация

Недостатъци:

• Трудно е да се оцени труд и други разходи, необходими за разработката
• Трудно е да се идентифицират тесните места преди да започне разработката
• Необходимостта от включване на всички в работата на останалите членове на екипа.

Канбан

Канбан е метод, базиран на визуализиране на постигнатия напредък при изпълнение на задачите на екипа. Основната идея е да се намали броят на задачите, които се изпълняват в момента (в колоната „В процес на изпълнение“). В схватката екипът е фокусиран върху успешното завършване на спринтове. В Kanban задачата заема водеща позиция. Това е добре за проекти в етап на поддръжка, където основната функционалност вече е внедрена и остават минимални подобрения и коригиране на грешки. В Kanban задачите се възлагат индивидуално. Една задача преминава през всички етапи на дъската, независимо от другите задачи, и след като бъде изпълнена, може да бъде показана на клиента. Канбан дъската се състои от колони, всяка от които представлява отделен процес на разработка. Някои колони (например „В ход“ ) ограничават броя на задачите, които могат да изпълняват. Това помага за бързото и лесно намиране на проблемни зони при разпределението на задачите. На снимката е показан пример точно за такава дъска. Броят на колоните и техните имена могат да варират. Ще представя най-често срещаните:

• To Do – Списък със задачи, които трябва да бъдат изпълнени
• В процес на изпълнение – задачи, по които се работи в момента
• Преглед на codeа – Задачи, които са изпълнени и са изпратени за преглед
• В тестване – Задачи, готови за тестване
• Готово – Завършени задачи

Предимства:

• Лекота на използване
• Видимост (помага за локализиране на тесните места, опростява разбирането)
• Висока ангажираност на екипа в самия процес
• Силно гъвкаво развитие

Недостатъци:

• Нестабилен списък със задачи
• Трудно се прилага при дългосрочни проекти
• Липса на твърди срокове

Последна дума за методологиите за разработка на софтуер

Хората, които заемат or се стремят към ръководни позиции, трябва да разбират напълно методологиите за разработка на софтуер, но всеки трябва да разбере поне основите. Методиките са неразделна част от процеса на разработка и се използват не само в IT сферата. Благодаря ви, че отделихте време да прочетете моята статия. Надявам се да ви е било полезно. Постарах се да опиша само ключовите точки възможно най-достъпно и кратко. В резултат на това тази статия не е изчерпателна. Ще се радвам да чуя вашето мнение по въпроса и да отговоря на вашите въпроси. Всичко най-хубаво!