Всичко, което трябва да знаете за методологиите за разработка на софтуер: тенденции, принципи и клопки за начинаещи

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

Внимание, начинаещи! Модели, методологии и общо объркване

Като начало трябва да направим важно пояснение: моделите за разработка на софтуер и методологиите за разработка на софтуер са отделни и различни. Моделите предвиждат How ще се държи системата. Необходими са методологии, за да работи системата Howто трябва. Объркването на модели и методологии за разработка на софтуер е стандартна оперативна proceduresа за всеки ИТ начинаещ, така че това не се счита за голяма грешка. Пример за модел е класическият водопаден модел с неговата линейна прогресия, ясно дефиниране на целите за всеки етап и строг контрол върху крайните срокове. Друг модел е моделът със спирала, с фокус върху ранното откриване и смекчаване на рисковете по проекта. Спираловидното развитие започва с малко, като първо решава местни проблеми и след това напредва към по-сложни. И накрая, друг модел е итеративна и поетапна разработка (IID) , при която жизненият цикъл на проекта е разбит на поредица от итерации, всяка от които прorча на „мини-проект“. Като цяло, моделът е описание на процеса на разработка на софтуер . Но методологиите са системи за контрол, оценка и наблюдение на работата по възложените задачи. Методологиите са тоягата и моркова на модерната епоха, необходими за контрол на всяка стъпка в процеса на развитие. Те се избират въз основа на посоката на проекта, неговия бюджет и сроковете за изпълнение на крайния продукт. Нещо повече, методологиите могат да бъдат избрани въз основа на темперамента на ръководителя на проекта и неговия or нейния екип. Дори въз основа на философията на компанията or клиента. Нека да разгледаме най-популярните методики.

1. Scrum

Scrum е гъвкав метод за управление на проекти. Базира се на „спринтове“, or кратки итерации, строго ограничени във времето (обикновено 2-4 седмици). Това минимизира продължителността на срещите, но увеличава тяхната честота. Всеки спринт се състои от списък със задачи, които трябва да бъдат изпълнени до края на итерацията, като всяка от тях има своя собствена „тежест“. По време на срещите екипът обсъжда Howво са направor членовете на екипа, Howво планират да направят и Howви проблеми има. Scrum използва изоставане за планиране. При този подход екипите обикновено имат scrum master. Този човек помага на екипа да работи без прекъсване и създава комфортна среда за екипа. Проектът ще има и някой в ​​ролята на собственик на продукта. Този човек е ръководител на разработката, наблюдава продукта и действа като основна връзка между това, което клиентът иска, и това, което екипът произвежда.

Професионалисти:

• възможност за бързо стартиране на проект с възможно най-нисък бюджет;
• ежедневно наблюдение на напредъка, чести демонстрации на проекти;
• възможност за извършване на корекции по време на проекта.

Минуси:

• трудности при сключване на договори поради липса на фиксиран бюджет;
• не работи за неопитен екип or при занижени срокове or бюджет;
• способността постоянно да се правят промени между спринтовете може да създаде объркване.

За кого е?

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

2. Канбан

Най-важната характеристика на Kanban е визуализацията на жизнения цикъл на проекта. Създават се колони за изпълнение на работни позиции. Работните елементи се обработват индивидуално. Колоните са маркирани със състояния като: За изпълнение, В ход, Преглед на codeа, В тестване, Готово (разбира се, имената на колоните може да варират). Целта на всеки член на екипа е да намали броя на работните елементи в първата колона. Подходът на Kanban е интуитивен и ви помага да разберете къде се крият проблемите. Структурата на Kanban не е окончателно и безвъзвратно фиксирана: в зависимост от спецификата на проекта можете да добавите импровизирани колони. Например, някои екипи използват система, в която трябва да дефинирате готови правила за работен елемент, преди да го изпълните. В този случай се добавят две колони: Specify (посочете параметрите) и Implement (захванете се за работа).

Професионалисти:

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

Минуси:

• не работи с екипи от повече от пет човека;
• не е предназначен за дългосрочно планиране;
• не е подходящ за немотивиран отбор. Kanban няма крайни срокове за всеки работен елемент. Методиката също не предвижда санкции за забавяне.

За кого е?

Kanban работи чудесно в компании, където екипът е мотивиран да расте и да постига резултати. Вече трябва да е очевидно - това е за малък екип. Може би дори отряд or част от екип.

3. Рационален унифициран процес (RUP)

RUP методологията използва итеративен модел на развитие. В края на всяка итерация (която отнема от 2 до 6 седмици) екипът трябва да постигне планираните цели и да получи работеща, макар и временна version на проекта. RUP предвижда разделяне на проекта на четири фази . Във всяка фаза се извършва работа по следващото поколение на продукта: създаване, разработване, изграждане и преход. В края на една фаза се постига крайъгълен камък на проекта. Моментът, в който екипът оценява своите резултати, може да се счита за крайъгълен камък на проекта. Това означава, че методологията предполага, че основните функции се пускат в първата фаза, а допълненията се добавят в следващите фази.

Професионалисти:

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

Минуси:

• Тази методология е доста сложна и трудна за прилагане в малък екип or компания;
• зависи от способността на експертите да поставят задачи;
• се нуждае от прекомерна documentация на изискванията.

За кого е?

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

Има много методологии, но една тенденция

В допълнение към scrum и Kanban, които са безспорно популярни и се основават на гъвкави принципи , Howто и устойчивата, итеративна RUP методология, компаниите използват много вариации на методологии. Една компания може да е по-близо до екстремното програмиране и вземането на най-бързите и прости решения. Друг може да е по-близо до разработката, управлявана от тестове. Друг все още може да предпочете бърза разработка на applications (RAD). Въпреки това, има силна, безспорна тенденция към използване на множество методологии едновременно. Или дори комбиниране на модели и методологии в уникална система за управление. Днешните компании се стремят да премахнат бюрократичните бариери и да създадат атмосфера на единна екипна работа в организацията, без да прехвърлят отговорността между отдели и организационни звена. Според Scrum Alliance, 70% от ИТ компаниите използват scrum. Сред тях са такива гиганти като Google, Amazon, Salesforce, Microsoft и Adobe. Стартъпите и младите проекти са по-склонни към Kanban, но Toyota и например геймърите от Wargaming също го използват. Scrum е инструмент за планиране, докато Kanban е за наблюдение на напредъка. Що се отнася до RUP, той се използва най-често от западни компании с 50-200 служители и приходи от $1-10 мorона. IBM обаче модифицира RUP, за да се доближи до гъвкавите принципи, пускайки OpenUP методологията (RUP, но гъвкав). Тази прехвалена гъвкава методология сега движи ИТ света . Това не е просто мимолетна мода - все още е иновативно и всъщност се използва в много големи компании. Agile се използва в Сorконовата долина. Facebook и Uber го използват.

Долния ред

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