Для того чтобы создавать программные продукты, которые будут отвечать всем требованиям заказчика и притом не тратить дополнительное время на исправление ошибок и новых требований заказчика, нужно использовать специальные методологии разработки.
Оригинал статьи на моем сайте- http://www.mikenin.com/blog/metodologii-dlya-razrabotki-programmnyh-produktov
В современном мире IT-компании, которые не хотят меняться умирают. В связи с постоянными инновациями, однажды, одна группа разработчиков собралась и придумала правила, которые должны упростить разработку программных продуктов и повысить общую управляемость компанией. Так на свет появился «Agile манифест». Суть которого сделать процессы более прозрачными и дать каждому сотруднику реализоваться, технология применима в любой сфере деятельности, но мы коснемся только IT направления.
Agile это свод правил, которым должна следовать компания или группа людей для повышения продуктивности. Далее о некоторых из них:
- Люди и взаимодействие важнее процессов и инструментов – данное правило говорит о том, что мы должны дать людям сотрудничать друг с другом, тогда они смогут делать лучшие вещи, но не загонять людей в рамки стандартов и правил,
- Работающий продукт важнее исчерпывающей документации – под этим понимается, что главенствующая роль отводится реализации и что главное, сделать что-то, чем впустую описывать процессы на бумаге,
- Сотрудничество с заказчиком важнее согласования условий контракта – данный шаг направлен на налаживание контакта между двумя сторонами исполнителем и заказчиком,
- Готовность к изменениям важнее следования первоначальному плану – это главное правило в планировании. Вас постоянно будет что-то отвлекать и будут появляться более важные задачи, которые не учтены в плане, нужно быстро перестраиваться и решать новые задачи, тогда Ваш продукт будет всегда актуален и вы не будете удаляться от цели.
Внедрение данной методологии в текущие процессы будет очень сложным, т.к. люди привыкли работать в старом режиме и по натуре своей не приемлют изменений. Поэтому для успешного внедрения Agile были созданы три реализации методологии: Kanban, Scrum, Extreme Programming (XP).
Для начала начнем с самой простой и понятной – это Kanban. Он создан как переходный период от текущих процессов разработки к передовым. Kanban помогает устранить текущий хаос в задачах и навести порядок в делах. Реализация носит следующий характер, в помещении ставит большая доска, которая делится на три колонки: «Задачи», «В процессе», «Выполнено».
В первую колонку «Задачи» клеятся стикеры с задачами, далее исполнитель (любой человек в команде) берет стикер и перемещает его в колонку «В процессе» и выполняет его, после выполнения стикер перемещается в раздел «Выполнено». Из преимуществ такого подхода хочется отметить структурированность задач, все видят, что нужно выполнить и берут те задания, которые им нравятся или которые они могут выполнить.
Есть контроль за текущим состоянием дел, в процессе разработки проекта. Но есть и отрицательная сторона, люди могут выбирать только легкие задания, тяжело проконтролировать кто взял задание и ответственен за его исполнение.
Для новичков в Agile данная методология будет наиболее оптимальна, она еще не перегружена терминологией, позволяет привыкнуть к новому ведения дел, она своего рода «супчик для больного», помогает «организму» компании перестроиться и «выздороветь» для более успешного ведения дел.
Следующей успешной методологией можно считать Extreme Programming (XP). Она создана специально для разработчиков и носит полностью прикладной характер.
Основа методологии это планирование, Заказчик и Исполнители проводят сессию, в течении которой обсуждают функционал программного продукта, а разработчики решают, кто будет какую задачу выполнять. При согласовании стороны договариваются о следующей сессии, когда они смогут обсудить достигнутые результаты и назначить следующие задачи.
Далее разработчики внутри команды назначают итерации, своего рода демо-дни, когда они договариваются по срокам работы над задачей и показывают текущие результаты.
Между итерациями могут проходить собрания, на которых обсуждаются важные вопросы по реализации, обмен мнениями и советами, такие собрания принято проводить стоя, т.к. по идее они длятся не более 15 минут и по идее должны отвечать на «горячие» вопросы, а то что оно проходит стоя не дает людям «закиснуть» и заставляет оперативно решать проблему.
Еще одним правилом является простота, в методологии главное написать простой и понятный код, чем писать сложный, т.к. требуется постоянно показывать результаты и проще доработать простой код, чем заменить сложный.
Как было сказано ранее, рекомендуется, если Заказчик будет участвовать в работе над продуктом, желательно, чтобы он мог периодически приходить к разработчиком и обсуждать функционал продукта, оперативно договариваться об изменениях. Далее интересным требованием идет парное программирование, это когда два разработчика работают за одним компьютером.
Один в это время пишет код, другой описывает стратегию и принципы функционирования программы. Такой шаг позволит разработчикам писать более точный код, меньше допускать ошибок, также они всегда будут в курсе кода и будут знать, где дорабатывать, если возникнет нужда. А чтобы не было застоя, разработчиком нужно постоянно меняться партнерами, т.о. достигается баланс.
Каждый разработчик в курсе решаемых задач, он всегда знает как функционирует тот или иной код и способен заменить предыдущего разработчика на любом участке.
Из положительных влияний методологии хочется отметить, высокое качество продукции в результате, большую вовлеченность разработчиков. Из отрицательных моментов, это совмещение встреч Заказчика и разработчиков, постоянно возрастающее количество задач, на которые придется постоянно переключаться.
И в завершении о самой лучшей методике, которая наиболее продуктивна - это Scrum. Принцип постановки задач и их выполнения похож на метод Kanban, когда используется доска и стикеры. Для начала дадим определения, которые необходимы для понимания функционирования методологии:
- Продукт – то что мы хотим разработать,
- MVP – минимальный жизнеспособный продукт, демо-версия продукта,
- Product Owner – ответственный за разработку,
- Стейкхолдер – специалист, который контролирует результат работы, не входит в команду разработки,
- Бэклог (Backlog) – список задач, которые необходимо решить,
- Бэклог-груминг – совещание между Product Owner и Стейкхолдером по дальнейшему развитию разработки.
Также немного о специалистах, которые должны быть задействованы в создании продукта. Разработчики, они должны быть универсальными в любой момент заменить друг друга. Scrum-мастер, человек ответственный за реализацию методологии, контролирующий процесс выполнения задач.
Теперь о контроле и ведение дел. Каждое утро рабочего дня должны проводиться планерки, на которых определяются задачи на день, в начале каждой недели проводится планинг (Planing), на котором обсуждаются прошедшие этапы и ставятся задачи на неделю. Период работы над группой задач до показа стейкхолдеру называется спринт, он длится две недели или один месяц.
Во избежание ошибок при использовании методологии, не рекомендуем отменять утренние планерки, т.к. на них задаются задачи на день и на них легче проконтролировать результаты предыдущего дня. Также не надо отменять обсуждений по улучшению продукта в начале недели, т.к. это уменьшит творческий настрой команды и в будущем может лишить продукт полезного функционала.
Именно такая гибкость методологии сделала ее популярной среди всех сфер деятельности. Чтобы начать применять Scrum в работающем деле нужно преодолеть тяжелое первичное отторжение среди людей, т.к. для работы по этой методологии нужно полностью изменить свой подход к работе и решению задач.
Подведем итог, чтобы создавать успешные программные продукты быстро, с минимальными временными затратами, с уменьшением простоя сотрудников, нужно использовать Agile подход. Новичкам будет полезно начать с Kanban, а затем решать на какой из вариантов методологии перейти: XP или Scrum.