Embedded Files
Разработка программного обеспечения (далее ПО) включает в себя множество процессов, и эти процессы друг от друга зависят. Точно как в ресторане повара что-то режут, что-то жарят, что-то выкладывают на тарелки, и все эти процессы происходят в определенной последовательности - так же и в разработке ПО есть множество различных процессов, все они друг от друга зависят. Эта часть документа про то, как эти процессы могут быть организованы.
Вотерфол (Waterfall, Каскадная модель)
Вотерфол (Waterfall, Каскадная модель)
На заре разработки ПО мы не знали, как подойти к большим проектам, и мы решили перенять некоторые принципы из строительства. Например, когда хотят построить мост, сначала документируют требования, полностью проектируют проект, разрабатывают чертежи, до мелочей планируют, сколько нужно материалов, и сколько займёт каждая стадия постройки моста, и т.д., потом строят, потом проверяют на прочность, и когда все подписи получены - строительство считается законченным. Точно так же можно подойти к разработке софта. Эта модель называется вотерфол (водопад по-английски), потому что проект перетекает из одной стадии в другую, и это передвижение происходит только в одном направлении (см. график). Каждая стадия может занимать много месяцев, люди из разных стадий часто друг с другом не разговаривают, и все передается друг другу с помощью документации.
В каком-то плане этот подход сработал, лучше чем ничего. Но со временем люди начали видеть что разработка ПО отличается от постройки мостов в нескольких ключевых моментах.
Во-первых, не получалось все предусмотреть. В отличие от постройки мостов, в разработке ПО много переменных факторов, которые не очевидны на этапе планирования. Из-за этого, на этапе “реализации” становится известно, что изначальный план - невыполним. Но деньги уже заплачены, так что программисты вынуждены построить что-то похожее на план, чаще всего с помощью синей изоленты и бениной матери. В результате, в лучшем случае ПО выходит с задержкой в расписании, и затраты превосходят бюджет, в худшем - проект никогда не выходит в свет, или количество дефектов превосходит все нормы.
Второе отличие состоит в том, что демонтаж мостов - дорогостоящая затея, в то время как демонтаж софта ничего не стоит. И если для постройки мостов все должно быть спланировано, иначе нужны большие затраты чтобы убрать первую версию и построить вторую - это проблема менее чувствительна для разработки софта, а значит не так необходимо ее предотвращать
С развитием IT. многие компании перешли на разные версии модели разработки Аджайл.
Аджайл (Agile, Гибкая модель)
Аджайл (Agile, Гибкая модель)
Представьте, что вашему другу Васе нужно доехать до вас на машине. Вы смотрите на карту, записываете сколько ему ехать по каждой улице и когда повернуть, и присылаете все эти указания ему письмом, без адреса и карты. Вася садится в машину, и ему остается только надеяться что ваши указания написаны понятным языком, что вы не пропустили никакого поворота, и что по дороге ничего не будет перекрыто. С большой вероятностью, Вася до вас не доедет, или заблудится, или у него закончится бензин по дороге. Это Вотерфол.
Теперь представьте, что вы с Васей в одной машине, и вы едете к вам домой. Вася ведет машину, вы смотрите на карту и на знаки, и говорите когда и куда ему повернуть. Но если повернуть не получилось, или дорога перекрыта - вы смотрите на карту, и говорите ему другой вариант - никакие непредвиденные обстоятельства вам не гроза. Вдруг вы понимаете, что дома нет чая/пива/ананасов. Вы ищете продуктовый по дороге, и перенаправляете Васю туда. И так пока не доедете. Это Аджайл.
Agile переводится как “гибкий, подвижный”. Эта модель разработки получила распространение в 90-х как ответ вотерфолу, который оказался слишком “несгибаемым”.
В основе Аджайл лежат несколько принципов:
Сделать ПО которое работает как надо (доехать до вашего дома) важнее чем написать тонну исчерпывающих указаний
Адекватно реагировать на новые факторы (улица перекрыта, нужно в продуктовый) важнее чем дотошно следовать плану
Работать вместе с заказчиком (как Вася работал в вами в одной машине) важнее чем обговорить контракт до мелочей
Люди и взаимодействия между людьми важнее чем процессы и инструменты (например, проблема не решилась бы если бы вы отправили Васе инструкции по смс вместо письма)
В плане того как Agile выглядит в жизни:
Работа планируется небольшими кусками, которые можно закончить за 1-2 недели, эти промежутки времени называется “итерации”. Цель - минимизировать риск что что-то пойдет не по плану.
Эти куски работы разбиваются на еще более мелкие кусочки, которые называются юзер стори. Все юзер стори демонстрируются или на стене или в каком-нибудь онлайн приложении, например Джира (Jira). Статус каждой стори виден всем, начиная с “надо сделать”, “в процессе”, “тестируется”, “сделано”, и тд. Один из вариантов этого называется Канбан-доска (Kanban board).
Чтобы знать сколько работы поместится в итерацию, используют абстрактную метрику сложности. Программисты и/или менеджеры оценивают все стори в баллах/поинтах, например, простая стори - 1 балл, посложнее - 2 балла, большая и сложная стори - 3 балла. Со временем команда вырабатывает общее понимание сколько поинтов они могут сделать в итерацию.
Вся команда (программисты, дизайнеры, менеджеры, тестеры) сидит вместе, или постоянно общается между собой.
Каждый день команда собирается на короткое совещание, где все докладывают что они делали вчера, что собираются делать сегодня, и если они чем-то заблокированы. Называется или Скрам или Стендап митинг
Разные компании используют несколько разных вариантов Agile:
Всякого рода комбинации
Page updated
Google Sites
Report abuse