CC BY
11ISSN 2223-4047
Вестник магистратуры. 2015. № 11 (50). Т. 1.
УДК 004
А.В. Кокшаров
ОСОБЕННОСТИ ВЕДЕНИЯ ПРОЕКТОВ ПО РАЗРАБОТКЕ ПО С ИСПОЛЬЗОВАНИЕМ ГИБКОЙ МЕТОДОЛОГИИ РАЗРАБОТКИ
В статье рассматриваются особенности гибкой методологии разработки программного обеспечения. Описание процесса разработки при использовании методологии, на основе двух наиболее популярных методологий: Scrum и Canban.
Ключевые слова: Agile, гибкая методология разработки, фичи, продукт, разработка ПО.
Еще несколько лет назад срок разработки программных продуктов занимал довольно продолжительное время. Сейчас же на выполнение подобного проекта будет затрачено в разы меньше.
Задача бизнеса - вывести продукт на рынок как можно быстрее, при этом продукт должен максимально отвечать потребностям заказчиков, а именно быть качественным и выполнять все возложенные на него функции. Отсюда возникает закономерные вопросы: как работать качественно и быстро? Как постоянно тестировать и улучшать продукт? На эти вопросы позволяет ответить Agile.
Agile (или Agile Software Development) - серия подходов к разработке программного обеспечения, ориентированных на использование интерактивной разработки, динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля [3].
Существует манифест гибкой методологии разработки программного обеспечения, принятый в 2001 году в США. Манифест гласит следующее: «Мы постоянно открываем для себя более совершенные методы разработки программного обеспечения, занимаясь разработкой непосредственно и помогая в этом другим» [1].
Основополагающие принципы манифеста следующие:
- люди и взаимодействие важнее процессов и инструментов.
- работающий продукт важнее исчерпывающей документации.
- сотрудничество с заказчиком важнее согласования условий контракта.
- готовность к изменениям важнее следования первоначальному плану.
И другие двенадцать важнейших принципов гибкой методологии разработки программного обеспечения.
Необходимо разобраться в чем заключаются особенности гибкой методологии и для этого необходимо для начала понять, что такое продукт в области разработки. У владельца продукта есть свое видение продукта, которым он действительно увлечен. Он может точно не знать детали того, что его продукт делает, но точно знает почему он делает этот продукт и какие проблемы он будет решать для клиента. Есть заинтересованные лица или клиенты, которые пользуются продуктом и периодически выставляют пожелания по улучшению этого продукта. Есть команда разработчиков продукта, которая использует гибкую методология, при которой она не копит различные фичи, о которых сказано ранее, вместо этого она старается выпускать их с самого начала и делать это максимально часто. Проблема заключается в том, что заинтересованных лиц много и они все хотят все больше и больше нового функционала. Естественно такой подход приведет к тому, что команда разработчиков повысит скорость выпуска фич, но тем не менее не сможет удовлетворить всех заинтересованных лиц их количеством выпущенных изменений, вместе с этим понизится качество того, что успеет сделать команда, а задачи будут продолжать копиться. На помощь в данной ситуации приходит две наиболее популярных методологии гибкой разработки: Scrum и Canban.
Scrum подразумевает собой использование метода так называемой «вчерашней погоды». Это подход, при котором команда при выпуске фич ориентируется на их количество. К примеру, за прошлую неделю было выпущено 5 обновлений, значит и на текущий момент стоит браться за работу за такое же количество задач. Таким образом задача владельца продукта заключается в том, выбрать из всех заявок на изменение наиболее важные с его точки зрения [2].
Canban же в свою очередь решает проблему с количеством выпускаемых фич, ограничивая время одновременной работы над несколькими задачами. Таким образом, команда, выбрав оптимальное коли-
© Кокшаров А.В., 2015.
Вестник магистратуры. 2015. № 11 (50). Т. 1.
ISSN 2223-4047
чество задач, над которыми она будет работать одновременно, не будет перегружена и в то же время все члены команды будут заняты. Как только будет закончена одна задача, команда готова взять следующую, убедившись, что не будет нарушен лимит по количеству задач в неделю.
В результате использования таких подходов будет сформирован пул задач, который носит название backlog продукта. Ясно, что со временем этот пул задач будет становиться все больше и больше. И еще одной главной задачей владельца продукта является научиться оценивать задачи по их стоимости и продолжительности выполнения и отдавать соответствующие приоритеты. На мой взгляд важным вопросом является определение этой самой стоимости задач и здесь, как не странно, включается чутье и опыт владельца продукта, благодаря которым и определяется эта стоимость. В отличии от стоимости продолжительность работ можно обсудить с командой разработки.
Также стоит отметить, что в проекте с использованием гибкой методологии очень большую роль играет коммуникации между владельцем продукта, или исполнителем проекта, и клиентом. При коммуникации нужно обсуждать и согласовывать конкретные сроки по определенным задачам. Управление продуктом это построение качественных коммуникаций. Исходя из первого положения манифеста, главным звеном в любом проекте являются люди и их взаимодействие вне процессов и инструментов. Поэтому задачей владельца продукта является не бездумно раздавать задачи группе разработчиков, это скучно и неэффективно, а вместо этого необходимо убедиться, что все понимают видение продукта, что команда может напрямую взаимодействовать с заинтересованными сторонами и что цикл обратной связи достаточно короткий, в терминах поставок продуктов реальным пользователям.
При таком подходе команда обучается и может принимать оперативные решения сама, а владелец продукта может сосредоточиться на картине в целом.
Важно также ответить на следующий вопрос: какие решения должен принять владелец продукта и команда? В начале проекта самыми проблемными местами является неопределенность и риск. С точки зрения бизнеса, риск заключается в том, правильную ли вещь мы делаем. Социальный риск - смогут ли эти люди сделать проект. Технический риск - будет ли продукт эффективно работать на нашей платформе и сможем ли мы его масштабировать. И, конечно же, есть риски, связанные со стоимостью и сроками проекта - сможем ли мы поставить продукт в разумные сроки и за разумное количество денег.
Знания - это противоположность риску - когда неопределенность большая, мы фокусируемся на приобретение знаний.
Особенностью гибкой методологии также является решение конфликта связанным с краткосрочным-долгосрочным решением. Нужно решить, что делать следующим, исправить срочный баг или делать новую фичу или же стоит сделать упор на улучшение программной платформы, что позволит в будущем ускорить разработку. Необходимо постоянно балансировать между реактивной и проактивной работой.
Из этого приходим к еще одной важной особенности это выбор между тем что: делать вещи правильно или делать правильные вещи или делать быстро. В идеале, конечно же, хотелось бы иметь все три варианта одновременно, но найти правильный баланс очень сложно. Как правило в гибкой методологии ключевые фигуры сосредоточены на своем: владелец продукта сосредоточен на построении правильных вещей, команда сосредоточена на том чтобы делать вещи правильно, а клиент хочет быстрее.
Стоит сказать еще пару слов про бэклог продукта. Бэклог подразумевает, что проект рано или поздно закончится, на самом деле, как правило, проект никогда не является законченным, потому что всегда есть улучшение, которое можно сделать, до конца существования продукта.
В заключение хотелось бы подытожить, что применение гибкой методологии разработки, например, Scrum в проектах по разработке программного обеспечения уже показало свой преимущества в настоящее время. Большинство лидирующих компаний и вообще любых компаний, которые заинтересованы в повышении продуктивности своего бизнеса уже давно занялось внедрением этих методологий, в идеале нанимаются даже специалисты-консультанты, которые специализируются на внедрении Agile.
Список литературы
1. Agile-манифест разработки программного обеспечения // [Электронный ресурс]. бесплат. электрон. // Режим доступа: http: // www.agilemanifesto.org/iso/ru/
2. Scrum: гибкая разработка ПО.: Пер. с англ. - М.: ООО "И.Д. Вильямс", 2011. - 576 с.: ил. - Парал. тит.
англ.
3. Википедия // [Электронный ресурс]. бесплат. электрон. Интернет- библиотека - Электрон. дан. (34362 док.) // Режим доступа: https: // ru.wikipedia.org/wiki/Scrum
КОКШАРОВ АНТОН ВЛАДИМИРОВИЧ - магистрант, Российский экономический университет им. Плеханова, Россия.
