Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ АВТОНОМНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ

ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ

«НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ УНИВЕРСИТЕТ

«ВЫСШАЯ ШКОЛА ЭКОНОМИКИ»

Факультет бизнеса и делового администрирования

Выпускная квалификационная работа

по направлению подготовки

образовательная программа «Менеджмент»

Оценка эффективности использования гибких методологий управления проектом на примере разработки и запуска онлайн-платформы в области рекрутинга

Щугорев Семен Дмитриевич

Научный руководитель

Старший преподаватель

Кафедры управления проектами

Мария Викторовна Малинина

Москва 2019



Введение

Такие слова как «бизнес» и «предпринимательство» стали часто использоваться в нашей речи благодаря их активной популяризации со стороны нашего общества, в основном, вследствие глобализации и развития сети Интернет. С одной стороны, это полезно, так как предприниматели - это люди, не боящиеся рисковать ресурсами для создания чего-то нового, и философия предпринимательства является действительно двигателем прогресса и фактором развития экономики каждой страны. С другой стороны, людям, решившим построить собственное дело, не стоит питать иллюзий о быстром успехе, быстрых и огромных прибылях и месте в рейтинге журнала Чарльза Форбса (англ. Charles Forbes), так как создание бизнеса - это игра в долгую, во время которой её участников могут постигнуть как победы, так и поражения. Важно лишь, чтобы в конечном счете перевес был в сторону первых. Для обеспечения этого бизнесом необходимо эффективно управлять, активно используя различные менеджерские практики, которые были когда-то созданы предпринимателями, а сейчас переросли в целые научные области знаний со своими принципами и ограничениями. Одной из таких областей является управление проектами.

По своей сути создание собственного дела эквивалентно инициации проекта в какой-либо корпорации. Создание бизнеса с нуля имеет такую же тройственную ограниченность (стоимость, время, содержание), как и обычный проект, под стоимостью понимается цена тех ресурсов, которые будут использованы предпринимателем, время - это крайний срок достижения определенного содержания, т.е. результата деятельности. Единственным отличием проекта в корпорации от проекта предпринимателя является то, что ограничения во втором случае не задокументированы, а находятся зачастую в голове основателя. С одной стороны, это дает определенный уровень гибкости и свободы в действиях, а с другой, требует дисциплины т.к. все процессы и ответственность ложатся на плечи предпринимателя.

В современном мире есть разные виды создания и организации собственного дела. Традиционный подход предполагает выход на существующий рынок и использование проверенной бизнес-модели, которая дополняется уникальным конкурентным преимуществом. Другим подходом является создание совершенно нового продукта, для которого рынок еще недостаточно развит и только набирает обороты, в основном это инновационная сфера, связанная с разработкой информационно-технологических продуктов (далее ИТ-продуктов). Популярной разновидностью создания инновационного проекта является стартап (от англ. startup). В современном мире такая форма организации своего бизнеса как стартап обрела огромную популярность во многом благодаря успешным историям о том, как только открывшийся стартап в короткие сроки (менее чем за 4 года) смог достичь капитализации в 1 миллиард долларов и стать тяжеловесным игроком на своем рынке - например, социальная сеть Facebook.

Для того, чтобы иметь возможность достичь таких быстрых и значимых результатов в стартапе необходимо эффективно им управлять. Стартап во многом является проектной деятельностью, поэтому методологии применимые при управлении проектом актуальны и в этой сфере. Одной из таких методологий является «гибкий» подход (от англ. agile). На сегодняшний день в бизнесе гибкие методы управления проектами завоевали популярность при разработке высокотехнологичных продуктов. Согласно исследованию российского агентства ScrumTrek, в России гибкие подходы лишь набирают популярность и примечательно то, что 80% проектов, использующих гибкие методики, занимаются разработкой цифровых продуктов, но нужно учитывать, что исследования охватывает только проекты в крупных и средних компаниях, не обращая внимания на то, как можно применять данные методологии на начальных стадиях создания своего дела [19]. Из этого рождается интерес к тому, как российские компании, которые только создают свой продукт и выходят на рынок, интерпретируют и подстраивают под себя существующие гибкие методологии управления и действительно ли они полезны и приносят весомый результат.

Тема оценки эффективности использования гибких методологий в стартапах в России до сих пор не исследована. Целью настоящего исследования является формирование рекомендаций по наиболее эффективному использованию гибких методологий управления проектом при создании стартапа. Исследования в этой области позволят выявить новое видение для начинающих предпринимателей в нашей стране.

Объектом исследования являются собственный инновационный проект автора в сфере трудоустройства студентов и выпускников вузов России. Предметом исследования выступают практики и принципы гибких методологий управления, а также специальные модификации этих практик, которые используются при создании данного проекта на территории Российской Федерации.

Для достижения этой цели необходимо решить следующие задачи:

1. Изучить основные принципы и ценности гибкой методологии, условия и ограничения ее применения;

2. Определить основные достоинства и недостатки методологий;

3. Провести сравнительный анализ существующих концепций, основанных на гибких методологиях.

4. Изучить рынок ИТ стартапов в России и за рубежом: его структуру и особенности;

5. Проанализировать кейс по внедрению гибких методологиях и оценить его эффективность в российском стартапе в сфере трудоустройства студентов и выпускников;

6. Сформировать рекомендации по внедрению гибких методологий и на их основе описать улучшенную модель управления ИТ-стартапом.

В рамках этой цели будут рассмотрены следующие вопросы:

1. Каковы наиболее важные факторы успеха при создании стартапа?

2. Какие гибкие методологии используются для управления стартапом?

3. Как оценить эффективность этих методологий?

Исследование в области применения гибких методологий управления ИТ- проектами актуально на сегодняшний день по нескольким причинам. Во-первых, отрасль информационных технологий очень динамична и подвержена резким изменением, что вынуждает сотрудников технологических компаний и предпринимателей уметь быстро реагировать на изменения и искать, как от позитивных, так и от негативных флуктуаций несомненную пользу. Во-вторых, в мае 2018 года Президентом Российской Федерации В.В. Путин был издан указ о цифровизации практически каждого сектора российской экономики до 2025 года, который несомненно будет способствовать увеличению спроса на новые технологические решения. Данный факт открывает большие возможности для предпринимателей и требует от них знаний и умений о том, как создать продукт, который будет востребован на рынке и принесет пользу клиента. [2]

Исследование будет иметь практическую значимость для начинающих предпринимателей и менеджеров, которые запускают инновационные проекты. Предприниматели могут использовать полученные результаты исследования, чтобы лучше понять процесс создания собственного предприятия и минимизации риска неудачи. Менеджеры могут использовать результаты этого исследования, чтобы улучшить процесс создания новых продуктов или услуг внутри компании.

Результаты исследования будут ограничены спецификой развития венчурного рынка в России. Основное внимание будет уделено авторскому кейсу, который посвящен созданию технологического стартапа в области рекрутинга.

Работа будет разделена на 5 глав. В первой главе будет кратко описана предметная область управления проектами, понятия проекта и основных его характеристик. В второй части, будет акцентировано внимание на конкретной области - гибких методологиях управления проектами, их понятие, история и описание. Далее, в третьей главе, будут разобраны три наиболее популярные гибкие методологии управления проектом. В четвертой части будет проанализирована концепция стартапа, его стадии развития и текущее состояние рынка стартапов в России. В заключительной главе данной работы будет описана наиболее популярная гибкая методика управления стартапом и оценена эффективность применения данной методики на примере собственного авторского проекта, также будет сформированы рекомендации по наиболее эффективному управления стартапом в России с применением гибких методологий управления.

В данной работе будут использованы следующие методы исследования: синтезирование собранного материала, индукция и дедукция, интерпретация данных, кейс-метод т.д

Основными источниками исследования являются доступные данные, такие как: интернет-ресурсы, учебные пособия, монографии и т.д.



1. Управление проектами основные понятия и концепции

масштабирование гибкий инновационный стартап

Для понимания сути работы необходимо начать с определения понятия проект и управления ими. Как и в любой прикладной науке в данной области знаний есть свои профессиональные ассоциации и стандарты, описывающие данную область более глубоко. Мы остановимся на одном институте в мире проектного управления, который известен своим популярным сводом знаний, который полностью посвящен проектному менеджменту - это Институт Управления Проектами (Project Management Institute) и их свод знаний PMBoK (Project Management Body of Knowledge).

Данный свод знаний дает следующие определения проекту и управлению проектами [4]:

«Проект -- это временное предприятие, предназначенное для создания уникальных продуктов, услуг или результатов. Временный характер проекта означает, что у любого проекта есть определенное начало и завершение»

«Управление проектами - область деятельности, в ходе которой определяются и достигаются четкие цели проекта при балансировании между объемом работ, ресурсами (такими как деньги, труд, материалы, энергия, пространство и др.), временем, качеством и рисками. Ключевым фактором успеха проектного управления является наличие четкого заранее определенного плана, минимизации рисков и отклонений от плана, эффективного управления изменениями (в отличие от процессного, функционального управления, управления уровнем услуг).

Помимо PMBOK в мире признаны и другие стандарты в области управления проектами, например, стандарт PRINCE2, которым на текущий момент владеет британская компания Axelos, дает следующие определения проекту [5]:

«Проект - ограниченная временем деятельность по созданию уникального продукта, услуги или результата. При этом слово «продукт» -- в единственном числе, хотя и допускается использование нескольких компонентов одного сложного продукта; термин «управленческие продукты» не используется»

Из этих двух определений проекта, мы видим, что ассоциации управления проектами смотрят на данный термин под одним углом и отмечают, что проект имеет ограничения и направлен на создание уникального продукта. Из этого исходит одно из свойств проекта- это ограниченность проекта, состоящая из 4 элементов: сроков, бюджета, содержания и качества. (см. Рис. №1).

Рисунок №1. «Ограниченность проекта»

Нельзя не отметить, что между всеми этими элементами есть прямые и обратные взаимосвязи. Например, снижение стоимости проекта (бюджета) может увеличить сроки проекта, а также понизить качество.

Согласно международному своду знаний по управлению проектами - PMBOK, проект может иметь 5 групп процессов [4]:

1. Инициализация. На данной стадии вырабатываются требования к продукту, который получиться по завершению проекта и определяется целесообразность его создания. Подготовка документации.

2. Планирование. Разрабатывается план выполнения проекта. Проводится декомпозиция всех процессов проекта. Определяется организационная структура, главные ответственные лица и ориентировочные сроки завершения проекта, а также формирование бюджета.

3. Выполнение. Реализаций задач, предусмотренных на предыдущем этапе.

4. Контроль и мониторинг. Данный этап проходит параллельно с Выполнением. На нем происходит отслеживание промежуточных результатов проекта и синхронизация графика выполнения с плановыми показателями.

5. Завершение. Все работы по проекту завершены. Проводится анализ результатов: сравнение достигнутых результатов с теми, которые были запланированы.

В настоящее время в мире существуют различные методы и подходы к управлению проектами, и их комплексность, в основном, зависит от отрасли, в которой внедряется система управления проектам. Например, в строительной отрасли подойдут подходы, которые в наибольшей степени гарантируют соблюдение изначальных требований и чёткое выполнение сроков проекта, а в индустрии информационных технологий необходима большая ориентация на работающий продукт и вовлеченность команды.

Далее, в данной работе будет уделено особое внимание управлению проектами именно в отрасли информационных технологий, так как данная сфера представляет наибольший интерес из-за её динамического развития и инновационной наклонности.

Одной из основополагающих моделей управления проектом по созданию цифрового продукта является каскадная модель управления (или водопадная), созданная и описанная Уинстоном Ройсом в своей работе «Managing the Development of Large Software Systems» в 1970 году. В ней Ройс рассматривает процесс реализации проекта как в виде потока, через который проект последовательно проходит этап за этапом. Важным требованием данной системы является последовательность процессов и невозможность начать следующий этап, если предыдущий еще не завершен.

Рисунок №2. «Каскадная модель управления проектом» [6].

Данная модель разработки цифрового продукта зарекомендовала свою эффективность при реализации проектов в больших корпорациях, где, как правило, сроки проекта и его требования заранее определены и неизменны на протяжении всего срока реализации. Естественно, у данной модели есть ряд недостатков:

§ Негибкость. Из-за заранее закрепленной последовательности этапов, в проект сложно внести изменения, необходимость которых может быть обнаружена уже в ходе выполнения, так как изменения могут привести к повторной реализации предыдущих этапов, что сильно отразится на бюджете и сроках проекта.

§ Излишняя формальность. Документирование процессов и реализация процедур согласования определенный действий могут негативно сказаться на сроках и бюджете проекта, а также на продуктивности работы команды. Тем не менее, при реализации больших проектов, данный уровень формальности обоснован и помогает нивелировать риски и сделать проект более прозрачным.

До конца ХХ века данная модель успешно применялась в управлении процессом разработки, но из-за бурного развития индустрии информационных технологий, в частности, сети Интернет, также стремительно начали изменятся и требования в ИТ-проектах, поэтому многие программисты начали разрабатывать свои собственные подходы к управлению проектами, которые учитывают динамически меняющиеся требования к функционалу продукта. Данные подходы стали толчком к созданию новой методологической базы в разработке программного обеспечения, которая объединила данный подходы в один большой пласт методов, который называются гибкими методами разработки (Agile software development).



2. Гибкий подход к управлению проектами

2.1 Ценности и принципы гибких методологий разработки

В 2001 году в городке Сноуберд в штате Юта, собрались 17 разработчиков программного обеспечения, которые также являлись изобретателями совершенно новых подходов в управлении ИТ-проектами. Каждый из них искал замену каскадной модели, которая стала слишком тяжеловесной и требовала много ресурсов для ее соблюдения, поэтому каждый из них смог создать свою собственную более легкую модель управления процессом разработки продукта и прибыл на встречу с другими разработчиками, для того чтобы рассказать о ней.

В результате данной встречи был сформирован Манифест гибкой методологии разработки программного обеспечения (Agile Manifesto), который закреплял основные ценности и принципы гибкой методологии разработки. С тех пор, любой подход к управлению процессом разработки программного обеспечения (далее ПО), который разделяет принципы и ценности манифеста, признается гибким. То есть. необходимо отметить, что гибкая методология не является конкретной методологией разработки программного обеспечения, а обозначает семейство подходов и практик, разделяющих «гибкие» принципы и ценности.

Согласно манифесту, основными ценностями гибких методологий являются следующие пункты. Как говорят создатели манифеста: «Несмотря, на то, что есть ценность в словах справа, мы ценим слова слева больше» [7].

· ЛЮДИ И ИХ ВЗАИМОДЕЙСТВИЕ важнее процессов и инструментов;

· РАБОТАЮЩИЙ ПРОДУКТ важнее исчерпывающей документации;

· СОТРУДНИЧЕСТВО С ЗАКАЗЧИКОМ важнее согласования условий контракта;

· ГОТОВНОСТЬ К ИЗМЕНЕНИЯМ важнее следования первоначальному плану.

На основе данных ценностей были сформулированы 12 принципов гибкого подхода к разработке [10]:

1. Удовлетворение клиента за счёт ранней и бесперебойной поставки ценного программного обеспечения;

2. Приветствие изменений требований даже в конце разработки (это может повысить конкурентоспособность полученного продукта);

3. Частая поставка рабочего программного обеспечения (каждый месяц или неделю или ещё чаще);

4. Тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта;

5. Проектом занимаются мотивированные личности, которые обеспечены нужными условиями работы, поддержкой и доверием;

6. Рекомендуемый метод передачи информации -- личный разговор (лицом к лицу);

7. Работающее программное обеспечение -- лучший измеритель прогресса;

8. Спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределённый срок;

9. Постоянное внимание улучшению технического мастерства и удобному дизайну;

10. Простота -- искусство не делать лишней работы;

11. Лучшие технические требования, дизайн и архитектура получаются у самоорганизованной команды;

12. Постоянная адаптация к изменяющимся обстоятельствам. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы

Указанные ценности и принципы показывают, что при создании или внедрении нового гибкого подхода для управления проектом важно сконцентрировать внимание на следующих сферах: работа команды, качество результата, отношение с заказчиком, адаптация при внесении изменений в процесс разработки продукта.

После того, как авторы вернулись из поездки в штат Юта, один из разработчиков, Уорд Каннингем, опубликовал Манифест гибкой методологии разработки онлайн на AgileManifesto.org, на котором все желающие могли подписать его, тем самым оказать свою поддержку.

Позже, теми же разработчиками в конце 2001 года был официально создан Agile Alliance, который стал местом, где все желающие могут делиться друг с другом своим опытом и знаниями о применении тех или иных практик, которые разделяют принципы и ценности гибких методологий.

Команды и организации начали внедрять гибкие методологии, во главе с людьми, занимающимися разработкой в командах. Постепенно руководители этих команд также начали внедрять гибкие подходы в своих организациях.

По мере того, как гибкие методики стали широко известны, сформировалась экосистема, в которую вошли люди, которые занимались улучшением процесса разработки программного обеспечения, а также люди и организации, которые помогли им с помощью консалтинга, обучения, структур и инструментов

В дополнение, если еще раз взглянуть на принципы и ценности гибкой методологии разработки, указанные выше, можно отметить, что они образуют определенную иерархию в виде пирамиды, где на вершине находятся 4 основополагающих ценности, а под ними базируются 12 принципов. Затем основываясь на идеях, описанных на верхних уровнях пирамиды, в самом низу располагаются отдельные гибкие практики (cм. Схему №3), о которых подробнее будет сказано далее.



Рисунок №3 «Пирамида гибких методологий» Иллюстрация, созданная автором данной работы

2.2 Структуры методологий и направления развития

После ознакомления с основными ценностями и принципами гибких методологий управления необходимо понять, что же стоит за этими постулатами и какие конкретно практики отражают суть гибких методологий.

На сайте альянса гибких методологий разработки - Agile Alliance находится специальная схема (см. Рис. №4), очень напоминающую карту метрополитена, на которой располагаются все известные agile-практики, сгруппированные по направлениям развития Agile (цветные линии на схеме).



Рисунок №4 «Agile-практики»

Также данная схема показывает то, как различные направления связаны между собой, так как находятся на стыке «течений» в Agile. Ниже представлена краткая характеристик основных наиболее популярных практик и фреймворков гибких методологий разработки ПО, о некоторых из них будет подробнее сказано в следующей главе данной работы:

1. SCRUM - набор подходов, фреймворков, инструментов к разработке программного обеспечения, которые позволяют в жестко фиксированные и короткие сроки (спринты) предоставить заказчику или конечному пользователю функционирующий продукт в соответствии с требованиями, которые были заявлены в начале спринта.

2. Lean Software Development - концепция гибкой методологии разработки, созданная на основе принципов бережливого производства. Практика пропагандирует безжалостное избавление от всего, что не прибавляет дополнительной ценности к итоговому продукту (бесполезные собрания, задачи, документация) и закрепляет принципы о том, как правильно управлять командой разработчиков и выстроить систему постоянного обучения на рабочем месте.

3. Kanban - подход к управлению разработкой, суть которого заключается в грамотном распределении трудозатрат всех членов команды разработки. Kanban позволяет сделать процесс создания продукта максимально прозрачным для каждого из разработчиков путем сбора всех задач по проекту в единый список, из которого каждый разработчик может брать задачи на выполнение.

4. Extreme Programming (XP) - одна из наиболее популярных гибких методологий разработки, основной фокус которой направлен на эффективность взаимодействия разработчиков с кодом. Смысл заключается в том, чтобы поднять традиционные методы написания и проверки написанного кода на новый, «экстремальный» уровень. Например, при выполнении ревизии кода, которая выполняется одним программистом, который изучает и исправляет код своего коллеги, в экстремальном варианте это представлено в парном программировании, когда одновременно с написанием кода одним программистом, другой в это же время находится рядом и проверяет код на его корректность.

5. Test Driven Development - подход к разработке программного обеспечения, в основе которого лежит работа в очень сжатых циклах разработки: сначала пишется тест, который будет проверять последующий код на правильность написания, затем пишется сам код, и под конец проводится рефакторинг написанного кода, который проверяет его соответствие стандартам.

В рамках данной работы будут рассмотрены более детально лишь несколько практик, которые, на наш взгляд, могут иметь значимость при создании инновационного стартапа.



2.3 Преимущества и недостатки гибких методологий

Как и любая методология, применяемая к какому-либо процессу гибкие подходы к разработке ПО и управлению данным процессом, имеют как очевидные преимущества, так и недостатки [9].

Преимущества гибкой методологии

§ Высокая скорость. За счет четкой ориентации на продукт и требования заказчика, а также поддержании работоспособной атмосферы в команде продукт поставляется намного быстрее чем, например, при каскадной модели разработки.

§ Предельное качество. Встроенные тестирования кода и подходы позволяющие объединить усилия нескольких программистов (парное программирование) позволяет достаточно детально и своевременно взглянуть на все возникающие недостатки в пользовательском опыте и устранить их, тем самым делаю продукт более совершенным.

§ Прозрачность процесса. Гибкость обязывает вовлекать в процесс разработки пользователей конечного продукта наравне с его заказчиками, что дает возможность получить обратную связь и сделать проект более открытым.

§ Минимальный риск неудачи. Процесс гибкой разработки сфокусирован на итерационном анализе проделанной работы и устранение всех неполадок на ранних стадиях проекта, что автоматически снижает риск возникновения серьезных проблем при поставке финальной версии продукта.

Недостатки гибких методологий

§ Уменьшение предсказуемости. В некоторых случаях команда разработки, которая до этого не работала по гибкой системе, не может количественно оценить требуемые трудовые ресурсы, необходимые для выполнения задач по проекту, особенно если конечный продукт достаточно комплексный.

§ Повышенные требования к команде. Обычно для того, чтобы сделать качественный продукт в короткие сроки необходима достаточно квалифицированная и мотивированная команда разработчиков, которая также должна быть самоорганизованной и уметь повышать эффективность своей собственной работы. Не всегда проект имеет достаточный бюджет, чтобы привлечь такую команду.

§ Зацикленность. Необходимость постоянного отслеживания и удовлетворения изменений в функционал итогового продукта может привести весь проект к тому, что он займет неопределенное кол-во времени, постоянно дорабатывая возникающие снова и снова функции.

В итоге можно сделать вывод, что внедрение гибких методологий разработки зависит, в первую очередь, от условий, в которых будет функционировать проект, если бюджет проекта достаточно гибок, а заказчики готовы постоянно контактировать с командой разработки, то здесь определенно подойдет гибкая методология. В том случае, если границы проекта четко прописаны, например, бюджет фиксирован, сроки жесткие, заказчик с большой периодичностью отслеживает результат, а также в случае законодательный ограничений, то в данном случае, скорее всего, больше подойдет каскадная модель управления проектом.



3. Популярные гибкие методологии управления ИТ-проектом

В данном разделе будут детально описаны основные гибкие методологии управления проектами в сфере разработки программного обеспечения, которые доказали свою эффективность не только при реализации ИТ-проектов в крупных компаниях, но и при создании инновационных продуктов группой энтузиастов.

3.1 Концепция Lean Software Development

Термин Lean (c англ. «бережливый») первоначально начал использоваться для описания практик эффективного процесса управления производством в автомобильной отрасли, а конкретно при создании автомобилей марки Toyota. Данные практики были широко показаны миру в книге Джеймса П. Уомака, Дэниела Т. Джонса и Дэниела Рооса - «Машина, которая изменила мир». Авторы назвали термином «lean» любые методы эффективного управления производством, которые способствовали минимизации потерь при создании изделий, а также при их проектировании, что позволило японцам почти на треть сократить сроки поставки продукции и вдвое уменьшить время на проектирования продуктов.

Вскоре инженеры и ученые в области менеджмента стали осознавать схожесть бережливого японского производства и процесса разработки программного обеспечения, что в конечном счете, уже после публикации манифеста о гибких методология разработки, вылилось в создание книги Мэри и Тома Поппендик «Lean Software Development» в 2003 году, как и предыдущие исследователи в данной области их фокус был направлен на устранении потерь, уменьшении бюрократии, построении работы на основе коротких итерационных циклов, а также на использование метода «вытягивания» в время разработки, когда доработки продукта обусловлены отзывами, полученными от пользователей после использования. Данный метод противопоставляется методу «выталкивания», при использовании которого разработка продукта идет согласно техническому заданию и фиксированным срокам.

Тем не менее, оставалось непонятным, можно ли перенести успешный опыт использования методологий бережливого производства в сферу разработки программного обеспечения. Если под «бережливостью» понимать конкретные практики управления процессом производства, то их применение в разработке выглядит маловероятным, но если под этим понятием подразумевать принципы и ценности, а не практические методы, то их применение уже выглядит оптимальным, которое способно существенно повысить эффективность процесса разработки. В статье «Challenging the Fundamental Notions of Software Development» Николас Шаретт, профессор Массачусетского Технологического Института, подчеркивал, что смысл бережливой разработки не в процессе, а в том, что с помощью современных технологий приносить выгоду клиенту. Следовательно, бережливая разработка - целая система, состоящая из принципов, практических методов, а также основных ценностях создания программных продуктов для клиента [10].

Мери и Том Поппендик выделяют 7 принципов бережливой разработки программного обеспечения:

1. Оптимизация целого

2. Устранение потерь

3. Забота об интеграции

4. Постоянное обучение

5. Быстрая доставка

6. Вовлечение всех участников

7. Непрерывное совершенствование

Оптимизация целого

Концепция базируется на вовлечении и глубоком понимании бизнес-задачи, которая стоит перед клиентом, однако зачастую выяснить, что именно нужно клиенту бывает достаточно сложно, учитывая тот факт, что ПО, решающее узкую бизнес-задачу само по себе не является отдельным получаемым продуктом, оно приобретает его в составе более крупных систем, например, программа автопилота в бортовой компьютерной системе автомобиля. Следовательно, разработчикам необходимо принимать во внимание все аспекты, в которых будет функционировать их программный продукт, поэтому особое внимание должно уделяться формированию ценности не только на стадии разработки, но и на этапах проектирования и развертывания в системе, а также возможности изменять базу кода с течением времени. [12]

Устранение потерь

Потери - это все те компоненты ПО и элементы процесса разработки, которые не приносят клиенту никакой ценности, но на их создание расходуются ресурсы команды, например, это могут быть ненужные функции, незаконченная работ, многозадачность и, самое главное, время, потраченное на поиск и устранение дефектов в продукте, которое обычно составляет 40% от времени все разработки. Для оптимизации процесса разработки необходимо ликвидировать данные потери, например, с помощью контроля за цепочкой создания итоговой ценности, в этом случае отслеживать и устранять потери будет в разы проще.

Забота об интеграции

Традиционно при разработке отдельных программных модулей для комплексной системы, их взаимодействие и интеграция в систему происходили на самом последнем этапе, что, зачастую, выливалось в лишние трудности при интеграции, и продукт необходимо было дорабатывать. В данном случае оптимальным методом, который позволяет избежать интеграционные трудности является «программирование сверху вниз» - методика, при которой модули, по мере их создания, сразу же интегрируются в итоговую систему.

Постоянное обучение

Процесс разработки ПО - это непрекращающийся процесс обучения, при котором полученные знания используются для дальнейшего создания продукта. Принципы «бережливости» рекомендуют, в зависимости от ситуации, два метода по получению знаний.

§ Первый - метода на основе принципа приоритета обучения. В данном случае рассматривается множество вариантов достаточно ресурсоемких решений, например, изменение архитектуры, выбор языка и концепции пользовательского интерфейса. В процессе рассмотрения данных вариантов формируются новые знания касательно возможной реализации альтернатив, на основе которых легче принять критически важные решения относительно наиболее подходящего варианта, который лучшим образом будет оптимизировать работу системы.

§ Второй - получение знаний через постоянные обновления продукта. Для этого команда разработки создает минимально работоспособный продукт, который передается клиенту, и уже в процессе пользования продукт обновляется на основе отзывов со стороны клиента. Это позволяет свести к минимуму затраты на функции, которые не несут ценности для клиента.

Бережливая разработка говорит нам о том, что эти два метода получения знаний можно использовать вместе. Критически важные решения нужно принимать исходя из рассмотренных и проанализированных альтернатив, но при этом учитывать, что продукт будет постоянно меняться с течением времени.

Быстрая поставка

В рамках принципов бережливой разработки программный продукт должен выпускаться итерационно, например, еженедельно, так как это позволяет более качественно отслеживать дефекты в кодовой базе. В случае, когда продукт выпускается в короткие сроки, то следует рассматривать весь проект не как поэтапный процесс, а как поток, в котором программный продукт проектируется, разрабатывается и выпускается беспрерывно через череду небольших обновлений после каждой итерации.

Вовлечение всех сотрудников

Основой для бережливого процесса разработки, как и для любой гибкой методологии, должно быть характерно наделение участников широкими полномочиями, поощрение командного взаимодействия и делегирования принятия решений на самый низкий возможный уровень.

Непрерывное совершенствование

Как и на бережливом производстве Toyota, все процессы в бережливой разработке должны совершенствоваться по научно обоснованному методу, под контролем опытного руководителя и на самом низком уровня по иерархии. Согласно leanконцепции достичь непрерывного совершенствования процесса разработки достаточно трудно, так как не всегда бережливые практики, которые показали свою эффективность в той или иной ситуации, можно применить для решения каждой проблемы. Поэтому организациям рекомендуют начать с более простых гибких методологий, таких как Scrum, и постепенно совершенствовать процесс разработки.

3.2 Фреймворк Kanban

Фреймворк Канбан, в переводе с японского - «визуальный сигнал», достаточно популярен среди современных гибких методологий разработки ПО, но история канбана насчитывает уже более 50 лет. В конце 1940-х годов Toyota начала оптимизировать свои процессы на производстве на основе той же модели, которую супермаркеты использовали для складирования своих полок. Супермаркеты снабжали товар достаточным количеством, чтобы удовлетворить потребительский спрос. Данная практика оптимизировала поток между супермаркетом и потребителем. Поскольку уровни запасов должны соответствовать моделям потребления, супермаркет получал значительную эффективность в управлении запасами, уменьшая количество избыточных запасов, которые необходимо хранить в любой момент времени. Тем не менее, супермаркет все еще мог гарантировать, что продукт, в котором нуждается потребитель, всегда есть в наличии.

Когда Toyota применила эту же систему к своим заводским цехам, цель заключалась в лучшем согласовании огромных запасов с фактическим потреблением материалов. Для того, чтобы сообщать уровни производительности в режиме реального времени на производственном предприятии, рабочие передавали карточку, или «канбан», между командами. Когда контейнер с материалами, использованными на производственной линии, был опустошен, на склад передавался канбан с описанием того, какой материал необходим, точное количество этого материала и другие требования. На складе ожидала новая корзина с этим материалом, которая затем отправлялась на фабрику, а также к поставщику. Поставщик, в то же время, имел контейнер с этим материалом, которая отправляюсь на склад. Весь процесс «сигнализации» в управлении запасами был построен на принципе JIT («just in time» - в переводе с англ. «вовремя»), которые актуален до сих пор и активно используется в процессе разработки программного обеспечения. [11]

Канбан разделяет ценности и принципы манифеста Agile, поэтому считается гибкой методологией разработки ПО. Фреймворк Канбан считается одной из самых легких в плане имплементации методологий. Отчасти это обусловлено тем, что для внедрения не требуется практически никаких дополнительных затрат -- нужно просто изучить основные принципы методики. Например, если применять канбан на производстве, необходимо изменить физические процессы и приобрести дополнительные материалы, а командам разработчиков ПО потребуются только доска и карточки, да и те могут быть виртуальными.

Весь фреймворк построен на использование канбан-доски, которая необходима для наглядности и оптимизации всего процесса разработки. Некоторые разработчики предпочитают использовать реальные доски, но практически в любой команде разработки, которая действует по гибким методологиям канбан, доски находится в виртуальном виде на компьютере, что является более эффективным, чем в физическом виде, так как цифровые канбан доски позволяют проще отслеживать процессы, координировать работу команды, а также иметь доступ из разных точек нашей планеты.

Методология Канбан основывается на прозрачности процесса разработки для каждого члена команды, а также на быстром обмене информацией внутри команды. Следовательно, канбан доска является главным источником информации о работе всей команды разработки. Зачастую стандартный процесс на доске состоит из трёх шагов, через которые проходят задачи проекта: «Запланировано», «В процессе», «Сделано». Ниже мы рассмотрим пример структуры виртуальной канбан доски. [20]

Рисунок №5 «Виртуальная канбан доска» [20]

На рис. №5 представлен интерфейс канбан доски, на которой процесс разделен на 4 группы:

1. To do (в переводе с англ. «сделать»). В данную группы относятся задачи, которые необходимо сделать для достижения целей проекта.

2. In progress (в переводе с англ. «выполняется»). Здесь собираются задачи, выполнение которых уже началось.

3. Code review (в переводе с англ. «проверка кода»). Специальная группа задач, которая есть во всех командах разработки ПО, которые используют методологию Канбан. Здесь аккумулируются задачи, результатом выполнения которых является написанный код. Каждый написанный код проверяется на наличие ошибок, при этом проверяющим является программист, отличный от того, который создавал данный код. Тем самым, устраняются ошибки в коде, что способствует созданию лучшего результата.

4. Done (в переводе с англ. «завершено»). Задачи, которые были завершены. По ним также измеряют общую эффективность команды разработки по разным метрикам (среднее время выполнения задачи, объем задач и так далее) для дальнейшего улучшения процесса разработки.

Рабочие задачи на канбан доске представлены в виде специальных канбан карточек. Такая наглядность помогает членам команды делать процесс разработки проще и удобнее, а также отслеживать жизненный цикл задач. На канбан карточке есть необходимые сведения о задаче, которые доступны всем участникам проекта: имя ответственное лицо, прогресс работы над задачей, оставшееся время до завершения и т. д. На цифровых досках в карточки прикрепляются снимки экрана с кодом и остальные важные для разработчика технические детали. Если вся команда может видеть текущую ситуация на проекте в любое время и следить за ходом выполнения всех задач, а также всю связанную с ними информацию, повышается концентрация, обеспечивается полная прозрачность, быстрее выявляются ошибки и зависимости.

Преимущества методологии Канбан

1. Гибкое планирование. Команда канбан сосредоточена только на работе, которая похожа на состояние потока. Как только команда завершает работу над функцией или элементом ПО, она сразу же берет следующую канбан карточку из блока «Сделать» и начинает ее выполнение, перенося саму карточку в блок «Выполняется». Владелец продукта может перераспределить очередность выполнения задач, не нарушая процесс работы команды, потому что любые изменения за пределами процесса разработки не влияют на команду. Когда владелец продукта переносит важные задачи в блок «Сделать» команда разработчиков уверена, что они, решая эти задачи приносят бизнесу максимальную отдачу. Таким образом, нет необходимости в итерациях фиксированной длины, которые использует Scrum. [20]

2. Короткие временные циклы. Длительность цикла является ключевым показателем для команд. Цикл -- это количество времени, которое занимает выполнение конкретной части работы с момента начала до момента ее завершения. Оптимизируя время цикла, команда может уверенно прогнозировать выполнение будущей работы. Если навыки специалистов в команде пересекаются, то продолжительность цикла сокращается, но, если определенный навык необходимый для выполнения задачи есть только у одного специалиста, вероятно растяжение цикла. Именно поэтому команды делятся знаниями и внедряют такие практики, как проверка кода и наставничество. Благодаря обмену знаниями члены команды могут выполнять разнообразные задачи, что еще больше оптимизирует продолжительность цикла. Это также означает, что в случае скопления работы вся команда сможет взяться за нее и восстановить нормальное течение процесса. К примеру, тестирование не всегда выполняют только инженеры по тестированию. Разработчики тоже могут поучаствовать.

3. Снижение количества узких мест. Многозадачность убивает эффективность. Чем больше задач находятся в работе в любой момент времени, тем больше времени уходит на переключение между ними, что препятствует их скорому завершению. Потому ключевым принципом канбана является ограничение объема незавершенных работ. Данный порог ограничивает узкие места и резервные копии в процессе работы команды из-за нехватки внимания, людей или навыков. Например, типичная команда разработчиков программного обеспечения может иметь четыре состояния рабочего процесса: «Сделать», «Выполняется», «Проверка кода» и «Готово». Они могут установить ограничение в 2 задачи, которые могут находится на стадии проверки кода. Это может показаться низким пределом, но для этого есть веская причина: разработчики часто предпочитают писать новый код, а не тратить время на просмотр чужой работы. Низкий предел побуждает команду уделять особое внимание проблемам в состоянии проверки и проверять работу других, прежде чем приниматься за написание своего кода. Это в итоге уменьшает общее время цикла.

4. Непрерывная интеграция. Известно, что непрерывная интеграция практика автоматического построения и постепенного тестирования кода в течение дня - крайне важна для поддержания качества работы Канбан также рекомендует использовать практику «реактивной» поставки продукта. Реактивная поставка -- это практика предоставления промежуточных результатов работы клиентам очень часто - даже ежедневно или ежечасно. Канбан и реактивная поставка прекрасно дополняют друг друга, потому что оба метода фокусируются на своевременной (и единовременной) доставке ценности. Чем быстрее команда сможет доставить инновации на рынок, тем более конкурентоспособным будет их продукт на рынке. И канбан команды сосредоточены именно на этом: оптимизировать поток работы для клиентов

3.3 Методология Scrum

Методология Scrum в нынешнем виде была создана двумя разработчиками программного обеспечения Кенам Швабером и Джефом Сазерлендом в 1991 году. Для популяризации методологии авторами был запущен специальный Интернет-ресурс (http://www.scrumguides.org), с помощью которого любой желающий может ознакомиться с принципами, компонентами данной гибкой методологии. Швабер и Сазерленд приводят следующее определение методологии Scrum:

«Scrum -- это методология, которая используется для управления работой над сложными продуктами с начала 1990-х годов. Scrum не является процессом, техникой или окончательным методом. Это больше похоже на рамки, в которых вы можете применять разные процессы и практики. Scrum обеспечивает эффективность управления разработкой продуктом, при этом постоянно совершенствую окружающую вас среду: сам продукт, команду, коммуникацию и др.» [8]

В основе методологии Scrum лежит итеративно-инкрементальная модель управления проектом, смысл которой заключается в разбиении жизненного цикла проекта на итерации, которые циклично повторяются. В конце каждого из этих циклов-итераций должен быть достигнут определенный результат (инкремент), и далее, с каждой последующей итерацией команда, учитывая предыдущие результаты дорабатывает и улучшает конечный продукт.

Scrum имеет 5 главных ценностей, в соответствии с которыми должна функционировать Scrum-команда:

1. Преданность

2. Смелость

3. Концентрация на результате

4. Открытость

5. Уважение

Все члены Scrum-команды исследуют и постигают эти ценности по мере работы с событиями, ролями и артефактами.

Успешность использования Scrum напрямую зависит от того, насколько хорошо люди придерживаются этих ценностей. Каждый участник предан целям Scrum-команды. Все обладают смелостью действовать правильно и работать над решением сложных задач. Каждый участник сфокусирован на целях Scrum-команды и на их достижении в рамках Спринта. Заинтересованные лица и Scrum-команда соглашаются быть открытыми друг с другом в работе, несмотря на возникающие трудности. Участники команды уважают профессионализм и самостоятельность друг друга.

Методология Scrum состоит из компонентов, которые условно делятся на три группы (см. таблицу №2).

Таблица №1 «Компоненты Scrum»

1. Scrum-команда, это люди от которых зависит успех проекта, имеет несколько ролей:

a. Владелец продукта. Человек, который несет главную ответственность за реализацию проекта, создание максимально возможной ценности, а также контроль за деятельностью команды специалистов. Важно, чтобы владельцем являлся один человек, а не группа людей. В обязанности владельца также входит управление бэклогом продукта.

b. Scrum-мастер. Человек, который несет ответственность за соблюдение ценностей и правил гибкой методологии Scrum. Помогает команде и владельцу продукта работать с максимальной эффективностью, обучая и контролируя весть процесс работы на проекте.

c. Команда специалистов. Или команда разработки. Основная движущая сила всего проекта. Команда разработки состоит из специалистов из разных областей, например, Java и iOS разработчиков, которые работают вместе. Кроме этого, команда специалистов является саморганизующей и несет коллективную ответственность за каждый инкремент продукта.

2. Артефакты. Одни из важнейших элементов всей методологии Scrum, артефакты позволяют каждому участнику проекта получать информацию о текущем состоянии проекта и отслеживать его прогресс.

a. Бэклог продукта. Содержит описание полного функционала, которым должен обладать финальный продукт. Бэклог не является фиксированным во времени списком требований, он постоянно должен меняться, в соответствии с обратной связью, которую получает конечный пользователь продукта.

b. Бэклог спринта. В нем представлены функции продукта, выбранные из бэклога, которые должны быть реализованы в течение спринта и войти в инкремент.

c. Инкремент. Результат работы команды в конце каждого из спринтов, которые представляет собой продукт, обладающий всеми функциями, которые были заложены в бэклоге спринта.

d. Доски задач. Это канбан доска, которая интегрирована в методологию Scrum, и имеет те же самые функции, которые были описаны в п.3.2

3. События.

a. Спринт. Временной промежуток (от 2 недель до 1 месяца) в течение которого Scrum-команда реализует функции заявленные в бэклоге спринта. Механик работы спринта представлена на рисунке №6.



Рисунок №6 «Механика работы спринта» [25]

b. Оценка задач. Scrum рекомендует командам для измерения прогресса проекта использовать не временную оценку выполнения задач, а относительную. Например, в команде у всех участников есть понимание того, сколько займет время выполнения определенной по сложности задачи, эту задачу выбирают как меру для оценки длительности других задач. На практике команды могут создавать собственные системы оценки задач, главное, чтобы они были относительные. На рисунке №7 такой оценкой являются стори-поинты (от англ. «story points», и они отображаются на диаграмме сгорания (от англ. «burndown chart»). Многие команды разработки используют другие модификации данной диаграммы, но основной принцип построения базового варианта достаточно прост. По оси абсцисс отмечается длительность текущего спринта (на рисунке 10 рабочих дней). По оси ординат слева отображаются относительные оценки (стори-поинты), а справа задачи бэклога, на языке гибких методологий разработки их называют пользовательскими историями (от англ. «user story»).



График №1 «Диаграмма сгорания в конце спринта» [25]

Во время спринта стори-поинты и истории пользователей уменьшаются, к концу спринта, для достижения поставленных целей в начале спринта, кол-во историй пользователей должно равняться нулю - это означает, что все задачи были выполнены.

Также пунктиром на данной диаграмме отображается идеальная траектория выполнения задач во время спринта, если линия историй пользователей идет выше идеала, то проект идеи с опозданием, если ниже, то с опережением.

c. Ретроспектива. Синонимом названия этого события может выступать рефлексия. Основной целью этого события в Scrum является совершенствование процесса разработки продукта. Ретроспектива представляет собой общее собрание команды проекта, на котором выносятся на обсуждение проблемы и трудности, которые возникли в течение прошедшего спринта. Основным результатом ретроспективы являются рекомендации, которые были выработаны коллективно, и будут применены во время следующего спринта. Это позволяет совершенствовать процесс разработки и приводит к экономии ресурсов.

d. Обзор спринта. Данное событие также является собранием всех участников команды проекта, но ее основной целью, в отличие от ретроспективы является не оптимизация процесса разработки, а демонстрация инкремента, которые был создан в прошедшем спринте. Владелец продукта координирует процесс получения обратной связи от конечного пользователя, и на основе ее формирует новые задачи, которые заносятся в бэклог продукта.



4. Стартап как форма создания и масштабирования бизнеса

В данной главе мы опишем основные пункты, связанные с понятием стартапа и экосистемой, в которой он существует, а также посмотрим на жизненный цикл типичного проекта. Кроме этого, рассмотрим то, как развиваются стартапы России и какие возможности для этого есть.

...