Основы разработки ПО

Роли в команде

Менеджер проекта (Project manager)

Проект – это временное предприятие, направленное на создание уникального продукта, услуги или результата.

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

Менеджер релизов – в реалиях российских Enterprise-компаний так называются руководители команд, управляющие процессом, когда IT-продукт из проекта уже превратился в сервис, но находится на доработке согласно запросам на изменения (ЗИ).

Менеджер продукта (Product manager)

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

Эти роли различаются тем, что product manager придумывает новые функции, которые можно добавить в продукт, а project manager ставит задачу подчиненным реализовать эти новые функции и сообщает о сроках, когда они будут готовы. Product manager решает, что сделать, project manager – когда и как.

Архитектор (Architect)

Архитектура ИС – это набор структурных элементов, организованных определенными способами для взаимодействия друг с другом, которые складываются в единый программно-аппаратный комплекс. Он выстроен для достижения конкретных бизнес-целей.

Архитектура – понятие глобальное, его можно разделить на несколько частей, переходя от общего к частному. В работе аналитика встречаются следующие виды «архитектур».

Архитектура предприятия / корпоративная архитектура (Enterprise Architecture) – высокоуровневая архитектура всего предприятия, покрывающая бизнес-потребности IT-способностями. Корпоративная архитектура фокусируется на определении потоков и бизнес-процессов, действий, функций, информации, данных и технологий предприятия, а также на вызовах, стоящих перед IT и необходимых для того, чтобы эффективно применить технологию в ответ на изменение бизнес-потребностей.

Бизнес-архитектура (Business Architecture) описывает все бизнес-процессы, бизнес-акторы, бизнес-сущности и бизнес-правила с точки зрения бизнеса. Бизнес-архитектура не зависит от применяемых в разработке технологий.

Информационная архитектура (Information Architecture) определяет структуры данных и описывает все потоки данных, которые используются для поддержки бизнес-архитектуры. Такие операции, как идентификация, систематизация, категоризация, хранение данных, относятся к информационной архитектуре. Может представляться в виде модели данных (Data Model).

Архитектура решения (Solution Architecture) – архитектура программного обеспечения (ПО), которое реализует функции бизнес-архитектуры.

Технологическая архитектура (Technology Architecture) описывает архитектуру IT-окружения, которое используется для поддержки информационной архитектуры и архитектуры решения.

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

Архитектура ПО (Application Architecture) – составная часть системной архитектуры. Описывает организацию системы с точки зрения программных компонентов, из которых она состоит, и связи между компонентами.

Архитектура данных (Data Architecture) – составная часть системной архитектуры. Описывает структуры данных и логические связи между ними.

Каждым из видов архитектуры занимается соответствующий архитектор.

Бизнес-архитектор (Enterprise Architect) отвечает за то, чтобы бизнес-стратегия компании использовала правильную архитектуру технологических систем для достижения своих целей. EA несут огромную ответственность и, как правило, подчиняются непосредственно директору по информационным технологиям (CIO). Они должны идти в ногу с последними тенденциями в технологиях и определять, подходят ли технологии для компании. EA берет бизнес-стратегию компании и описывает архитектуру технологических систем, которая будет необходима для поддержания этой стратегии. Архитекторы уровня enterprise ориентируются на бизнес-потребности, придумывают, как решить какую-либо бизнес-задачу, разрабатывают глобальный план работы приложения и алгоритм его взаимодействия с другими. EA должен представлять, как все приложения работают вместе, иметь всю информацию. Он принимает концептуальные решения.

Архитектор решений (Solution Architect). Если EA решает, что делать, то SA – как делать.

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

• как технологии могут быть использованы для решения бизнес-проблемы;

• какую платформу или стек технологий можно использовать для создания решения;

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

• как вещи будут масштабироваться и поддерживаться.

Архитектор решений часто работает под методическим руководством бизнес-архитектора.

Technical (software) Architect – техлид в обычных реалиях. Это технический эксперт, который пытается решать проблемы, поставленные SA-архитектором. TA ставит задачи разработчикам и занимается уровнем реализации конкретной системы. На уровне конкретной информационной системы определяет стек технологий этой системы, сервисы, подходы к разработке, выбирает БД и интерфейсы для взаимодействий с другими системами.

Аналитик (Analyst)

Бизнес-аналитик (Business Analyst) описывает бизнес-процессы, как они есть (as is), и, общаясь с заказчиком и заинтересованными сторонами, составляет предложение, какими они должны быть (to be), чтобы решить задачи бизнеса (достичь целей).

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

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

Продуктовый аналитик (Product Analyst) – мостик между бизнесом и данными. Он работает рука об руку с менеджером продукта и помогает продуктовой команде принимать верные решения.

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

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

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

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

Дизайнер (Designer)

User Experience (UX) – это путь клиента от точки входа до точки выхода. То, насколько клиенту удобно, например, заполнить на сайте заявку на кредит. Отвечает за функциональность.

User Interface (UI) – это вид интерфейса. Отвечает за статику.

UX-дизайнер – это проектировщик, который изучает потребности пользователей, строит логические схемы работы интерфейса, тестирует прототипы на целевой аудитории и составляет ТЗ для UI-дизайнера.

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

Специалист по информационной безопасности (Application security)

Анализирует приложение с точки зрения информационной безопасности: определяет требования к приложениям и проверяет реализацию на соответствие этим требованиям. Занимается поиском и анализом уязвимостей.

Разработчик (Developer)

Если говорить о веб-приложении, frontend-разработчик занимается клиентской стороной интерфейса, отвечает за вывод информации для пользователя. Backend-разработчик занят серверной разработкой – тем, чего не видит пользователь, реализацией бизнес-логики приложения. Fullstack – человек, который объединяет в себе обязанности front и back (они тесно связаны).

Пример

Вы выбираете рейс из Нью-Йорка в Гонконг. Вы находитесь в зоне frontend. Нажмите клавишу поиска, и вы переместитесь в зону backend, чтобы вам могли правильно вернуть лучший, самый короткий и дешевый рейс в мгновение ока. Как только отобразятся результаты, вы снова окажетесь в зоне frontend.

Отдельно выделены gamedev-разработчики (разработчики игр) и iOS/Android-разработчики – группы разработчиков под эти ОС.

1С/SAP-разработчики и так далее – разработчики на определенном коробочном решении. Такие решения закупаются фирмой и дорабатываются под ее нужды, здесь имеются специализированный язык и свои инструменты.

Тестировщик (QA Engineer)

Есть несколько видов тестирования. Соответственно, разные его виды выполняют разные тестировщики.

➤ По отношению к объекту тестирования.

1. Функциональное. Тестирование конкретной функциональности, которая была разработана в соответствии с требованиями.

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

3. Производительности. Стресс-тестирование, тестирование нагрузки, стабильности.

➤ По доступу к коду.

1. Тестирование черного ящика в том случае, когда мы не знаем алгоритмы.

2. Тестирование белого ящика в том случае, когда учитываются механизмы системы внутри.

3. Тестирование серого ящика – комбинация первого и второго.

➤ По степени автоматизации.

1. Ручное – тест-кейсы.

2. Автотестирование – специально написанный код для автоматизации проверки определенного кейса.

➤ По степени изолированности компонента

1. Модульное – тестирование определенных модулей системы (компонентов).

2. Интеграционное – тестирование взаимодействия модулей.

3. Тестирование системы в целом (полной системы).

Техническая поддержка (Tech Support)

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

Level 1/2/3 support – несколько уровней поддержки приложения по степени знания системы.

На этом этапе обеспечивается общая техническая поддержка, в рамках которой обрабатываются типовые обращения. Цель создания такой службы – обеспечение постоянной поддержки пользователей на определенном уровне. Значительное число входящих вопросов решается на первой линии.

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

Level 2 support – это технические специалисты с более продвинутыми навыками общего или специализированного назначения. Тут происходит систематизация, анализ и решение проблем.

Обязанности специалистов второго уровня:

• контакт с персоналом первой линии и помощь ему;

• фиксация и последующий анализ инцидента;

• решение проблемы;

• передача данных по решенной проблеме на первый уровень.

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

Level 3 support – это обычно команда разработки, которая лучше всех знает продукт и может помочь в решении проблемы.

Жизненный цикл ПО

Жизненный цикл ПО (SDLC, Software Development Life Cycle) – период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации.

SDLC – это основные этапы, через которые проходит любой программный продукт. Плюс-минус всегда имеют место следующие этапы.

1. Фаза планирования.

2. Фаза сбора требований/анализа.

3. Фаза дизайна/проектирования.

4. Фаза разработки.

5. Фаза тестирования.

6. Фаза внедрения.

7. Фаза поддержки.

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

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

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

Поэтому хотелось бы отметить, что для продукта и проекта этапы ЖЦ могут отличаться. Это стоит понимать и учитывать.

Жизненный цикл проекта

Любой ЖЦ проекта включает в себя четыре фазы.

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

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

3. Выполнение работ. Это фаза создания проекта. Именно на этом этапе создается продукт. Менеджер проекта получает отчеты о ходе выполнения проекта и контролирует процесс. Далее происходит финальное одобрение продукта перед подписанием акта приема работ.

4. Финальная стадия. Основная суть этой фазы – подвести итоги после завершения проекта, подписать акт приема-передачи и передать продукт в операционную деятельность.

На графике показано, как в зависимости от стадии проекта меняются такие показатели, как:

• стоимость проекта и численность персоналом – вовлеченность ресурсов (кривая 1);

• влияние заинтересованных сторон, неопределенность проекта, возможность рисков (кривая 2);

• стоимость изменений по проекту (кривая 3).

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

Пример

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

2. Максимальные затраты ресурсов в проекте наблюдаются в период его выполнения (ближе к концу). Это связано с тем, что к этому времени большинство спорных моментов проекта уже прояснилось, команда знает, что делать, и активно работает. Также именно на этих этапах во многих проектах возникает понимание того, что команда опаздывает, и подключаются все возможные ресурсы для работы.

Этап планирования

На этой стадии нужно максимально снизить неопределенность.

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

• определить проблемы, цели, задачи и ресурсы (такие, как персонал и издержки – важно заранее найти людей, которые в дальнейшем будут работать с проектом, и включить их в проектную команду; инфраструктурные ресурсы);

• рассмотреть варианты альтернативных решений на встречах с клиентами, поставщиками, консультантами и сотрудниками;

• понять, как сделать ваш продукт лучше, чем у конкурентов;

• провести анализ осуществимости (feasibility study), направленный на изучение возможности создания продукта в соответствии с заданными требованиями заказчика и выделенными ресурсами.

Ведущую роль в разработке концепции играет бизнес-аналитик (или Product Manager), занимающийся этим продуктом. Для определения потребностей заказчика/рынка в течение всего срока разработки концепции проводится интенсивная работа с инвестором проекта, чтобы выработать единое ви´дение будущего продукта. Если это заказной продукт, то инвестор – конечный заказчик. Если продукт предназначен для открытого рынка, то ответственны за него учредители компании или совет директоров. Далее на основе изученных и систематизированных требований аналитик вместе с командой экспертов создает образ будущего продукта. В конце аналитик и экспертная команда определяют границы проекта, которые должны содержать ориентировочные сроки реализации и бюджет продукта.

Результатом разработки концепции является Product Vision Document (если продукт разрабатывается под заказ) или Marketing Requirement Document (если продукт предназначен для открытого рынка). Эти документы содержат подробную информацию о требованиях заказчика, возможностях продукта, которые должны удовлетворять эти требования, а также ориентировочные сроки его реализации и бюджет. Различие между PVD и MRD состоит в том, что в MRD обычно более детально описаны целевые сегменты рынка и сделан детальный обзор конкурентов.

После разработки концепции продукта делается вывод о целесообразности создания продукта. Если принято положительное решение, пишется устав проекта по разработке продукта. PVD/MRD – входной документ устава проекта, описывающий содержание работ.

Входы: идея, концепция, экономическое обоснование.

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

Этап анализа требований

На этом этапе нужно четко определить и задокументировать требования к продукту и утвердить их.

Входы: реестр заинтересованных лиц, дорожная карта.

Выходы: техническое задание.

Этап проектирования

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

Входы: техническое задание.

Выходы: архитектурное решение, спецификация требований к ПО, дизайн-макеты, тест-кейсы.

Этап разработки

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

Входы: архитектурное решение, спецификация требований к ПО, дизайн-макеты, тест-кейсы.

Выходы: работающая версия ПО, готовая к тестам.

Этап тестирования

На этом этапе проверяется работоспособность системы.

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

Входы: тест-кейсы, версия ПО.

Выходы: отчет о тестировании, баг-репорты.

Этап внедрения и поддержки

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

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

Входы:

• консультирование пользователей;

• исправление дефектов;

• доработка в соответствии с новыми требованиями.

Выходы:

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

• пользовательская документация.

Стандарты жизненного цикла ПО

ГОСТ Р ИСО/МЭК 12207–2010

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

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

➤ Процессы соглашения

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

➤ Процессы организационного обеспечения проекта

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

Процессы организационного обеспечения проекта:

• процесс менеджмента модели жизненного цикла;

• процесс менеджмента инфраструктуры;

• процесс менеджмента портфеля проектов;

• процесс менеджмента людских ресурсов;

• процесс менеджмента качества.

➤ Процессы проекта

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

Существуют две категории процессов проекта.

• Процессы менеджмента проекта используются для планирования, выполнения, оценки продвижения проекта и управления им.

• Процессы поддержки проекта обеспечивают выполнение специализированных целей менеджмента.

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

• планирование проекта;

• управление проектом и его оценка.

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

• менеджмент решений;

• менеджмент рисков;

• менеджмент конфигурации;

• менеджмент информации;

• измерения.

➤ Технические процессы

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

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

Технические процессы:

• определение требований правообладателей;

• анализ системных требований;

• проектирование архитектуры системы;

• реализация;

• комплексирование системы;

• квалификационное тестирование системы;

• инсталляция программных средств;

• поддержка приемки программных средств;

• функционирование программных средств;

• сопровождение программных средств;

• изъятие программных средств из обращения.

➤ Процессы реализации программных средств

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

➤ Процессы поддержки программных средств

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

➤ Процессы повторного применения программных средств

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

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

Ограничения

• Не детализирует процессы жизненного цикла в разрезе методов и процедур.

• Не устанавливает требований к документации.

• Не предписывает четких и однозначных схем построения жизненного цикла ПО.

• Не предписывает использование конкретной модели жизненного цикла, методологии, методов, моделей или технических приемов.

Каждая организация сама несет ответственность за выбор!

ГОСТ 34.601–90

Стандарт предусматривает следующие стадии и этапы создания автоматизированной системы (АС):

1. Формирование требований к АС:

a. Обследование объекта и обоснование необходимости создания АС;

b. Формирование требований пользователя к АС;

c. Оформление отчета о выполнении работ и заявки на разработку АС.

2. Разработка концепции АС:

a. Изучение объекта;

b. Проведение необходимых научно-исследовательских работ;

c. Разработка вариантов концепции АС и выбор варианта, удовлетворяющего требованиям пользователей;

d. Оформление отчета о проделанной работе.

3. Техническое задание:

a. Разработка и утверждение технического задания на создание АС.

4. Эскизный проект:

a. Разработка предварительных проектных решений по системе и ее частям;

b. Разработка документации на АС и ее части.

5. Технический проект:

a. Разработка проектных решений по системе и ее частям;

b. Разработка документации на АС и ее части;

c. Разработка и оформление документации на поставку комплектующих изделий;

d. Разработка заданий на проектирование в смежных частях проекта.

6. Рабочая документация:

a. Разработка рабочей документации на АС и ее части;

b. Разработка и адаптация программ.

7. Ввод в действие:

a. Подготовка объекта автоматизации;

b. Подготовка персонала;

c. Комплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями);

d. Строительно-монтажные работы;

e. Пусконаладочные работы;

f. Проведение предварительных испытаний;

g. Проведение опытной эксплуатации;

h. Проведение приемочных испытаний.

8. Тестирование АС.

9. Сопровождение АС:

a. Выполнение работ в соответствии с гарантийными обязательствами;

b. Послегарантийное обслуживание.

Эскизный, технический проекты и рабочая документация – это последовательное построение все более точных проектных решений. Допускается исключать стадию «Эскизный проект» и отдельные этапы работ на всех стадиях, объединять стадии «Технический проект» и «Рабочая документация» в «Технорабочий проект», параллельно выполнять различные этапы и работы, включать дополнительные.

Модели разработки ПО

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

Классические модели разработки

Модель кодирования и устранения ошибок

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

1. Постановка задачи.

2. Создание программы.

3. Тестирование.

4. Анализ результатов тестирования и возможный переход к шагу 1.

Эта модель совсем не актуальна для профессиональной разработки ПО. По таким алгоритмам программисты работали 50–60 лет назад. Излишняя простота в этом случае не позволяет конкурировать с другими моделями.

Каскадная модель или Waterfall

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

В конце каждого этапа создается документация, которая служит входными данными для следующего этапа.

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

2. Анализ требований. Требования анализируются, детализируются, уточняются, обсуждаются, документируются (формируем требования к ПО).

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

4. Разработка. Реализация.

5. Тестирование. Проверка.

6. Внедрение, поддержка. Вывод в промышленную эксплуатацию и перевод на поддержку.

Когда можно использовать каскадную модель:

• для средних и больших проектов, в которых задействованы десятки программистов и несколько разных команд проекта;

• для проектов, в которых требования и границы прозрачны и точно известны в начале жизненного цикла проекта. То есть когда проект понятен и прост.

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

Любая стройка – это пример использования «Водопада» (кейс – проект – стройка – приемка). Также в качестве примера подходит автомобильный конвейер.

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

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

Каскадная модель с обратной связью

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

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

Каскадная модель с промежуточным контролем

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

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

Модель обладает следующими характеристиками взаимодействия этапов:

• модель состоит из последовательно расположенных этапов (точно так же, как и «Водопад»);

• каждый этап имеет обратную связь с предыдущими;

• исправление ошибок происходит на каждом из этапов сразу при выявлении проблемы – производится промежуточный контроль;

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

• результат появляется только в конце разработки, как и в модели «Водопад».

Инкрементная (инкрементальная) модель разработки

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

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

Мы получаем несколько циклов разработки – своеобразный «мультиводопад». Каждый цикл делится на модули, а каждый модуль – на фазы: определение требований, проектирование, написание кода, внедрение, тестирование.

Когда можно использовать инкрементную модель:

• для проектов, в которых точное техническое задание прописано уже на старте, а продукт должен быстро выйти на рынок.

Итеративная модель разработки

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

В этом случае создание начинается с реализации части функционала и становится базой для определения дальнейших требований, иными словами, мы получаем так называемый минимально жизнеспособный продукт (Minimum Viable Product). Этот процесс повторяется снова и снова. Версия может быть неидеальной, главное, чтобы она работала. Понимая конечную цель, мы стремимся идти к ней так, чтобы каждый шаг был результативным, а каждая версия – работоспособной.

Когда можно использовать итеративную модель:

• когда важен анализ рисков и затрат;

• в крупных долгосрочных проектах с отсутствием четких требований или вероятностью их динамического изменения;

• при разработке новой линейки продуктов.

На рисунке показана итерационная «разработка» Моны Лизы. Как видно, в первой итерации есть лишь набросок Джоконды, во второй появляются цвета, в третьей добавляются детали и насыщенность, и процесс завершается. В инкрементной же модели функционал продукта наращивается по кусочкам, и продукт составляется из частей. В отличие от итерационной модели, здесь каждый кусочек – целостный элемент.

V-модель разработки

Еще она называется Verification and Validation model – модель верификации и валидации. Это усовершенствованная каскадная модель, в которой заказчик и команда программистов одновременно составляют требования к системе и описывают, как будут тестировать ее на каждом этапе. V-модель разработки унаследовала структуру «шаг за шагом» от каскадной модели.

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

Спиральная модель

Ее начали использовать в 1988 году. Спиральная модель воплощает в себе преимущества каскадной модели. При этом в нее включен анализ рисков и предусмотрена разработка проекта посредством прототипирования.

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

Главные фазы:

1. определение целей, альтернатив, ограничений;

2. анализ, определение и разрешение рисков;

3. фаза разработки и тестирования;

4. планирование новой итерации.

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

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

Главная особенность спиральной модели – концентрация на возможных рисках. Для их оценки даже выделена соответствующая стадия. Эта модель часто используется в исследовательских проектах и проектах с высокими рисками.

RUP (Rational Unified Process)

Это уже не модель, а методология разработки.

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

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

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

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

Цели каждой фазы:

• Inception (начальная стадия) – понимание того, что мы создаем. Фаза сбора информации и анализа требований, определение образа проекта в целом;

• Elaboration (Уточнение) – понимание того, как мы это создаем. Фаза анализа требований и проектирования системы, планирование необходимых действий и ресурсов, спецификация функций и особенностей дизайна;

• Construction (конструирование) – создание бета-версии продукта. Основная фаза разработки и кодирования, построение продукта как восходящей последовательности итераций (версий кода);

• Transition (внедрение) – создание конечной версии продукта. Фаза внедрения продукта, поставка продукта конкретному пользователю.

Это фазы управления развитием продукта – итерациями жизненного цикла. И в отличие от «водопада» каждая из фаз может повторяться по несколько раз, отражая изменение требований заказчика продукта.

Методология RUP основана на девяти основных потоках (workflow) – элементах итерации жизненного цикла ПО.

1. Business modeling (бизнес-анализ) – анализ требований на данной итерации жизненного цикла, определение желаемых параметров системы и нужд пользователей.

2. Requirements (требования) – формализация образа системы. Предполагает сбор требований и управление требованиями, перевод требований в функциональные спецификации. Здесь начинается анализ прецедентов и построение use cases, формально отображающих требования пользователя в UML. В результате мы получаем документы уровня менеджмента.

3. Analysis and design (анализ и моделирование) – перевод собранных требований в формализованную программную модель. Результат – описание системы на этапе реализации (технический проект); эти документы относятся к уровню разработчиков системы. Язык формализации – Unified Modelling Language (UML). В процессе итеративной разработки эволюционировать будет продукт именно этого потока – модель проекта. Все изменения привязываются в RUP непосредственно к моделям, а средства автоматизации и довольно гибкий язык моделирования позволяют управлять данным процессом более или менее безболезненно в плане затрат времени и ресурсов.

4. Implementation (реализация, кодирование) – собственно написание кода.

5. Test (тестирование) – тестирование продукта на данной итерации.

6. Deployment (внедрение) – установка продукта на полигоне заказчика, подготовка персонала, запуск системы и приемо-сдаточные испытания, подготовка стандартов упаковки и распространения продукта, передача материалов отделу продаж (действия опциональны в зависимости от специфики продукта).

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

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

Также здесь есть элементы, касающиеся поддержки продукта, – core supporting workflows.

1. Management (управление проектом) – набор административных действий по управлению проектом согласно идеологии RUP. Использует средства управления проектом (см. ниже список продуктов Rational).

2. Configuration management (управление конфигурацией и изменениями) – мощный слой административных действий, направленных на управление версиями продукта. Предполагает контроль исходного кода (модели, исполняемых модулей, тестов, документации), контроль версий продукта, использование корпоративных стандартов разработки кода и документации, отслеживание изменений и ошибок (bug tracking). Тесно связан с тестированием и поддержкой пользователей (customers support).

3. Environment (окружение) – создание и поддержка средств анализа, проектирования, разработки, тестирования (как программное, так и аппаратное обеспечение).

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

Гибкие модели управления командой Agile и Kanban

Что такое Agile

С английского agile переводится как «подвижный, быстрый, проворный». В русской IT-лексике за этой группой методологий закрепилось определение «гибкие».

В Agile-подходе проект постоянно адаптируется к новым обстоятельствам и требованиям. Вспомним, как устроена разработка по методологии Waterfall.

1. Выдвигаются требования к ПО, разрабатывается техническое задание (ТЗ).

2. Поставленные задачи воплощаются в коде.

3. Выполняется тестирование.

4. Готовое ПО внедряется в работу.

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

Для Agile в приоритете не исходные установки, а актуальные потребности пользователя. Постоянно вносить изменения в ТЗ, даже в самый разгар разработки, для Agile нормально. В гибкой методологии не предусмотрен предварительный генеральный план – напротив, программный продукт пишется практически экспромтом.

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

Идеи и принципы

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

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

1. Люди и взаимодействие между ними важнее, чем процессы и инструменты.

2. Работающее ПО важнее, чем исчерпывающая документация.

3. Сотрудничество с заказчиком важнее, чем согласование условий контракта.

4. Готовность к изменениям важнее, чем следование первоначальному плану.

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

Это неверное понимание. Идеи Agile говорят нам, что в первую очередь мы должны фокусироваться на левой части утверждения, но при этом необходимо все равно уделить внимание правой части. Она тоже важна, просто чуть менее приоритетна.

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

• приоритет людей и общения над инструментами и процессами;

• приоритет работающего продукта над полной документацией;

• приоритет сотрудничества с заказчиком над утверждением контракта;

• приоритет готовности меняться над следованием первоначально созданному плану.

12 принципов Agile

1. Наивысший приоритет для нас – удовлетворение потребностей клиента благодаря регулярной и ранней поставке ценного ПО.

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

2. Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.

Чем чаще, тем лучше. Это позволит планировать и внедрять любые изменения.

3. Изменение требований приветствуется даже на поздних стадиях разработки.

Учитывается, что требования могут измениться на любом этапе разработки. Если изменения вносятся в проект быстро, заказчик может получить конкурентные преимущества.

4. Разработчики и представители бизнеса должны ежедневно работать вместе.

Можно оперативно задавать вопросы и получать ответы.

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

Разделение ответственности и понимание своего вклада в дело помогает работать лучше.

6. Личное общение – наиболее практичный и эффективный способ обмена информацией как с самой командой, так и внутри нее.

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

7. Работающий продукт – основной показатель прогресса.

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

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

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

9. Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость.

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

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

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

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

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

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

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

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

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

Что показывает эта картинка? Есть философия Agile, которая базируется на ценностях (на верхнем уровне) и принципах (более подробно), которые мы только что рассматривали. Далее на этих принципах строится много практик и моделей разработки и управления проектом. Один набор практик на рисунке – это Scrum, другой – XP (экстремальное программирование) и т. д.

Применимость Agile к проекту

На рисунке представлена матрица Стейси.

Эта матрица, похожая на модель Кеневин, была создана профессором менеджмента Ральфом Стейси. Она называется матрицей согласованности и определенности. Модель применяется для оценки проекта с точки зрения неопределенности. Так можно оценить применимость Agile к проекту.

Выделенные на рисунке области соответствуют доменам из теории запутанности, известной как Cynefin Framework. Эта теория делит все системы на четыре домена по степени неопределенности: простые, сложные (упорядоченные), комплексные (запутанные) и хаотичные.

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

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

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

• Хаотичные системы – это запутанные в кубе. Количество факторов в них еще больше, причинно-следственные связи в основном неизвестны.

Модель имеет две оси, соответствующие степеням определенности в отношении технологий и в отношении требований.

• Горизонтальная ось демонстрирует уровень технической неопределенности проекта и показывает, насколько понятен способ достижения цели проекта (знаем ли мы, КАК делать?)

• Вертикальная ось показывает уровень неопределенности требований к проекту – степень согласия по поводу того, что должно быть сделано в результате проекта (знаем ли мы, ЧТО делать?)

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

Минутка истории

Систему канбан придумали японцы. Она сформировалась к 1950-м годам на производстве автомобилей «Тойота». Топ-менеджеры компании во главе с ее президентом Тайити Оно поставили цель: выпускать автомобили с максимальной скоростью, а складские запасы свести к минимуму.

Тайити Оно вместе с соратниками обратил внимание на работу американских супермаркетов, где покупатель сам выбирал необходимые товары. Роль «супермаркета» в корпорации Toyota выполнил склад.

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

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

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

Само слово «канбан» с японского переводится как «сигнальная карточка» / «бирка» / «знак».

Карточки (бирки) крепились к таре с деталями. На таких бирках указывалась информация о номере и количестве деталей, а также о том, какой отдел их отправляет и куда они должны прибыть.

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

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

Система канбан, продолжая приносить пользу на производственных конвейерах, проникла и в сферу IT. Карточки стали использоваться иначе, но сохранился основной принцип фиксирования на них производственных задач – визуализация.

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

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

Что же такое Kanban?

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

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

Ценности Kanban

Kanban базируется на определенных ценностях.

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

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

3. Сотрудничество. Совместная работа и ее совершенствование: члены команды сотрудничают друг с другом и с заказчиком.

4. Клиентоориентированность. На протяжении всего срока работы стремитесь вовремя завершать задачи и плавно наращивать ценность вашего труда для клиента.

5. Поток. Необходимо понимать, что работа – поток создания ценности. Поток в Kanban – это последовательность этапов, через которые проходит каждая задача. Важно сохранять эту последовательность и управлять потоком: находить и анализировать слабые места в процессе, исправлять их.

6. Лидерство. Нужно поощрять инициативу на всех уровнях организации: от каждого работника до высшего руководителя. Лидер должен вдохновлять окружающих своим примером. Хорошее лидерство помогает укрепить все прочие ценности, а плохое лидерство может быстро уничтожить их. Хорошее руководство создает хорошие системы работы (или ищет помощи в их создании) и сильную культуру.

7. Понимание. В Kanban эта ценность проявляется в понимании текущих ролей, процессов и того, почему все устроено таким образом.

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

9. Уважение. Тут вроде все понятно: уважение к коллегам и совместной работе необходимо для комфортной и продуктивной деятельности.

Принципы Kanban

Существует шесть основополагающих принципов Kanban, которые можно разделить на две группы:

• принципы управления изменениями;

• принципы предоставления сервисов.

Основная трудность заключается в сопротивлении команд новому. Kanban признает существование этого человеческого фактора и руководствуется тремя принципами управления изменениями.

1. Начните с того, что есть сейчас. Мы не начинаем резко менять структуру организации, процессы и роли. Kanban – это последовательные и плавные улучшения.

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

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

2. Договоритесь об эволюционном развитии. Команда должна прийти к единому мнению, что постоянные изменения – это способ улучшить процесс разработки. Глобальные перемены несут большой риск, поэтому Kanban поощряет небольшие эволюционные изменения.

Как работает эволюционный подход.

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

Таким образом, мы эволюционно улучшаем наши процессы и продукт.

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

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

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

1. Выясните потребности и ожидания заказчика. Постарайтесь понять потребности и ожидания клиентов и сосредоточьтесь на них

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

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

Практики Kanban

1. Визуализируйте.

2. Ограничивайте количество незавершенной работы.

3. Управляйте потоком работы.

4. Используйте явные правила работы.

5. Вводите циклы обратной связи (каденции).

6. Улучшайтесь и эволюционируйте.

Эти практические приемы мы используем для улучшения работы и повышения качества сервиса.

➤ Визуализация

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

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

Kanban не дает указаний в отношении конструкции канбан-досок.

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

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

➤ Работа с доской

1. Все задачи, которые поступают от заказчика, записываются на стикерах и размещаются в графе «В ожидании». На примере это графа «Сделать». Им можно назначать приоритет: более важные размещают выше и принимают в работу в первую очередь, а второстепенные выполняются после завершения приоритетных.

2. Как только команда приступает к работе над очередной задачей, соответствующий листок переносится в графу «В работе». На примере это графа «Выбрано».

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

4. Вторая точка – точка поставки – принятие выполненного рабочего элемента (после колонки «Приемка»), когда заказчик принимает работу команды.

5. После выполнения задачи стикер отправляется в последнюю графу. В нашем примере – «Готово».

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

➤ Ограничение количества незавершенной работы

Еще одна значимая практика в Kanban – ограничение количества незавершенной работы. Незавершенная работа находится между двумя точками: «обязательство» и «поставка». На доске количество задач-листков, находящихся в работе на одной стадии, должно быть ограничено. Стабильно выполнять небольшое количество задач лучше, чем взяться за множество задач и толком не закончить ни одной. Для такого ограничения в Kanban вводится понятие work in progress (wip) – количество задач в работе. Точный максимум определяют, исходя из возможностей коллектива. Взяться за следующую задачу разработчик сможет не раньше, чем закончит работу с предыдущей.

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

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

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

➤ Управление потоком работы

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

Kanban помогает вам в этом с помощью kanban-досок. Когда мы выносим всю работу на видное место, нам становится проще понять, где именно возникают проблемы, а это позволяет оперативнее отреагировать и найти решение. Таким образом, работа быстрее движется к завершению.

Пожалуй, именно поэтому у данной практики есть более развернутая формулировка: «Управляйте потоком работы, а не людьми. Дайте людям самим организоваться вокруг нее».

➤ Используйте явные правила

Следующая практика говорит о важности использования явных правил в работе. Цель – сделать прозрачными договоренности, снизить зависимость от человеческого фактора. Другими словами, нужно определить правила игры.

Одно из правил – это подсчет wip. Самый частый пример явных правил – критерии готовности (definition of done) для вытягивания работы на следующий этап (то, что команда подразумевает под словом «готово» применительно к задаче). Например, сначала задача должна быть сформулирована в виде пользовательской истории с критериями приемки. И только после этого ее можно будет перенести в «ожидает разработки». Или реализованная задача должна пройти нагрузочное тестирование, чтобы ее можно было перенести в «приемка», и т. п.

➤ Используйте петли обратной связи

Практика больше известна как «встречи в Kanban». Цель – получить информацию о показателях системы и результатах совершенных ранее действий, спланировать следующие эксперименты и замкнуть петлю обратной связи.

➤ Улучшайтесь и эволюционируйте

Цель этой практики – научиться управлять изменениями команды или организации. Мы не рисуем большое красивое будущее в виде точки «Б» и не строим грандиозный план, как туда попасть.

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

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

Классы обслуживания

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

Стоимость задержки – это недополученная прибыль или понесенные издержки из-за не вовремя оказанных услуг. Рассмотрим влияние стоимости задержки и соответствующие классы обслуживания на примерах.

1. Ускоренный класс – неотложная скорая помощь, реанимация. Едет по выделенной полосе. Нет времени откладывать решение проблемы, необходимо все сделать как можно скорее. Пример: блокирующие дефекты.

2. Класс с фиксированной датой – стоимость задержки резко возрастает после определенного периода. Пример: проект в виде ФЗ с фиксированной датой начала действия. Не успеем вовремя – есть риск потерять лицензию.

3. Стандартный класс – стоимость задержки растет пропорционально времени. Если делаем сразу, то и прибыль получаем сразу. Если делаем долго, то и прибыль получаем нескоро.

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

Каденции

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

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

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

1. Канбан-митинг (ежедневная). Обсуждаем статус задач. Канбан-митинг чем-то напоминает стендап: сначала каждый делится проблемами и планами на день, а потом все вместе обсуждаем, как решить проблему. Уделяем внимание заблокированным задачам.

2. Встреча по наполнению очереди (обычно раз в одну-две недели). Берем на себя обязательства за то, что будет делать предоставляемый сервис, то есть планируем, какой продукт будем реализовывать.

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

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

5. Операционная встреча (обычно раз в месяц). Обсуждаем качество взаимодействия связанных сервисов. Если мы взаимодействуем с кем-то еще, например с техподдержкой, то собираемся вместе и проводим обзор предоставляемых сервисов/продуктов для максимизации ценности сервиса для заказчика, то есть пересматриваем качество, ищем возможность улучшить результат.

6. Встреча по обзору рисков (обычно раз в месяц). Изучаем риски, обсуждаем попытки минимизировать их. Обсуждаем риски, связанные с блокировками выполнения задач и их влиянием на работу сервиса. К примеру, результатом встречи может быть изменение класса обслуживания/приоритета задачи.

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

Частоту встреч можно отрегулировать под себя. От некоторых допустимо вообще отказаться, если они не несут для вас никакой ценности. Например, 1–4 встречи – основные. А три последние вводятся на уровне организации и нескольких связанных сервисов. Но важно помнить, что обмен информацией между всеми уровнями управления принесет организации максимальную гибкость.

Роли

В Kanban выделяют три роли.

1. Менеджер сервиса запросов (Service Request Manager, менеджер продукта, владелец продукта) отвечает за изучение потребностей и ожиданий заказчиков, содействует выбору и приоритизации рабочих элементов на собраниях по пополнению очереди.

2. Менеджер сервиса поставки (Service Delivery Manager, менеджер потока, менеджер поставок) отвечает за поток работы, в ходе которого выбранные рабочие элементы поставляются заказчикам. Проводит Kanban-митинги и собрания планирования поставки.

3. Команда разработки.

S.T.A.T.I.K

Расшифровывается как System Thinking Approach for Introducing Kanban и переводится как «системный подход к внедрению Kanban». То есть вы проходите определенные шаги, оцениваете задачи, проблемы и ожидания. И из этих элементов получаете взгляд на систему в целом. Здесь будут видны все недостатки процессов и пути по их исправлению.

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

1. Определить потребителей сервиса.

2. Выявить источники неудовлетворенности.

3. Проанализировать спрос.

4. Проанализировать возможности.

5. Построить модель рабочего процесса.

6. Определить классы сервиса.

7. Создать проект визуализации Kanban-системы.

8. Представить систему.

0/1. Сервис и менеджер

Пожалуй, один из самых важных разделов инструмента. Расскажите о вашем сервисе поставки и о том, кто является его менеджером.

Вспомогательные вопросы: какой сервис вы предоставляете? кто отвечает за то, что сервис будет предоставлен вовремя и в надлежащем качестве?

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

1/2. Источники неудовлетворенности

В этом разделе нужно отразить внутренние и внешние (с точки зрения клиента) источники неудовлетворенности и изменчивости.

Внутренние источники неудовлетворенности – то, чем недовольна сама команда сервиса.

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

Внешние источники неудовлетворенности – это то, чем недовольны заказчики сервиса или смежные сервисы.

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

2/3. Анализ запросов

Этот раздел содержит шаблон анализа запросов. Какие задачи вам поступают? Истории, собранные в этом разделе, часто содержат слова, которые раскрывают типы рабочих элементов, скрытую информацию о рисках, неудовлетворенные ожидания, внешние и специфичные зависимости (раздел «Отображение рабочих процессов»), неявные классы обслуживания.

Для каждого типа рабочего элемента соберите следующую информацию.

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

• Место назначения – куда поставляются результаты работы сервиса. Пример: они могут возвращаться заказчику или передаваться ниже по течению: в маркетинг, соседнему сервису, а могут оставаться в вашем сервисе.

• Частота возникновения – количество запросов на единицу времени. Плохой пример: «У нас 300 элементов в бэклоге». Если вам дадут такой ответ, спросите, откуда взялись эти элементы и как они попали в бэклог. Хороший пример: «Два раза в неделю».

• Характер (или природа) запроса – внимание к любым закономерностям. Пример: прибегает в последнюю минуту; ссылается на генерального директора; спокойный, можно договориться.

• Ожидания клиента – представления заказчика о времени поставки элемента. Могут быть необоснованными. Пример: через неделю, через два дня, сегодня, по готовности.

3. Отображение рабочих процессов

Нарисуйте рабочий процесс для нескольких типов рабочих элементов (3–4 шт.). Есть ли между ними сходства и различия? Осуществляется ли одновременная и неупорядоченная деятельность?

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

4. Классы обслуживания

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

Всего существует четыре архетипа классов обслуживания. Они основаны на стоимости задержки. Задайте вопрос для каждого типового элемента из раздела 2: «Какую сумму денег мы потеряем, если не начнем делать эту работу прямо сейчас?» Варианты ответов:

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

2. Ничего не потеряем до тех пор, пока не наступит дедлайн. Нужно сделать работу к определенной дате. Это класс обслуживания для задач с дедлайном.

3. Будем терять постепенно, если не сделаем эту работу. Это стандартный класс обслуживания.

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

5. Каденции по пополнению и поставке

Укажите для каждого типа рабочего элемента входную и выходную каденцию – частоту наполнения и поставки типового элемента сервисом.

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

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

6. Визуализация канбан-системы

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

Гибкие модели управления командой Scrum

Что такое Scrum

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

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

Создатели Scrum Джефф Сазерленд и Кен Швабер, наблюдая за игрой в регби, поняли, что как раз командной работы, слаженности не хватает и разработчикам ПО. Так появился Scrum.

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

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

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

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

Принципы Scrum

В основе Scrum лежат три принципа: прозрачность, инспекция и адаптация.

➤ Прозрачность

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

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

Прозрачность процессов в Scrum – не просто рекомендация, а именно принцип работы.

Примеры

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

2. Те, кто выполняют работу и принимают рабочий продукт, должны иметь общие критерии готовности (definition of done).

➤ Инспекция

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

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

Участники Scrum-процесса должны сами инспектировать его артефакты и прогресс на пути к цели спринта.

Пример

Ежедневные сборы для выявления блокеров и сообщения важной информации участникам команды.

➤ Адаптация

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

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

Пример

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

Три базовых принципа Scrum – это «три кита», которые позволяют Scrum как фреймворку максимально полно реализовывать гибкий подход к разработке.

Ценности Scrum

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

➤ Сфокусированность (Focus)

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

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

➤ Смелость (Courage)

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

➤ Открытость (Openness)

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

➤ Обязательство (Commitment)

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

➤ Уважение (Respect)

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

Роли в Scrum

Scrum – это командный процесс, который включает в себя три роли.

1. Владелец продукта (Scrum Product Owner).

2. Scrum-мастер.

3. Scrum-команда (команда разработки).

➤ Владелец продукта

Это выделенная роль. На самом базовом уровне владелец продукта – лидер, ответственный за максимизацию ценности продуктов, которые создает команда Scrum.

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

1. Говоря о команде, мы упоминали такую роль, как владелец продукта (Product Owner). Это человек, который представляет продукт, управляет им и формирует его ви´дение. Анализируя рынок и целевую аудиторию, он определяет, как будет развиваться продукт и как максимально удовлетворить всех заинтересованных лиц.

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

2. Все идеи и пожелания владелец продукта складывает в Product Backlog. Бэклог продукта – это упорядоченный перечень всех пожеланий и идей, над которыми будет работать Scrum-команда. Владелец продукта единолично управляет этим бэклогом, описывает его задачи для команды, определяет приоритеты этих задач, обеспечивает прозрачность для всех участников процесса.

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

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

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

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

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

➤ Scrum-мастер

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

Scrum-мастер – это коуч и защитник Scrum-команды, который устраняет препятствия и контролирует рабочие процессы. Его задача – убедиться, что проект работает без сбоев, и у каждого члена команды есть инструменты для эффективного выполнения своей работы.

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

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

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

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

2. Scrum-мастер может фасилитировать встречи. Он помогает Scrum-команде стать самоорганизующейся, не сбиться с пути, а также остаться продуктивной и нарастить свои возможности.

3. Scrum-мастер работает вместе с владельцем продукта, помогая ему понимать, создавать и поддерживать бэклог продукта.

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

5. Scrum-мастер помогает людям вне команды понять процесс и видит, какие взаимодействия с командой идут им на пользу, а какие нет.

➤ Scrum-команда

Сердце Scrum – Scrum-команда. Это небольшая группа людей, работающая над продуктом.

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

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

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

4. В Scrum-команде обычно не так много людей – 7 ± 2 человека. Оптимальная по численности команда разработки достаточно мала для того, чтобы оставаться простой в управлении, и в то же время достаточно велика, чтобы выполнять значительный объем работы в течение спринта.

Мероприятия в Scrum

Scrum включает в себя пять видов активностей/мероприятий.

1. Спринт.

2. Планирование спринта.

3. Daily Scrum (ежедневный).

4. Обзор спринта.

5. Ретроспектива спринта.

Мероприятия используются в Scrum для поддержания принципов инспекции и адаптации, а также для создания регулярности.

➤ Спринт

Спринт – контейнер для всех событий Scrum, временной отрезок неизменной длины, за который команда разработки должна подготовить инкремент.

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

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

Следующий спринт начинается сразу же по окончании предыдущего.

Спринты состоят из планирования, ежедневных Scrum (стендапов), разработки, обзора спринта (или демо), а также ретроспективы спринта.

➤ Планирование спринта

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

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

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

Задачи, которые команда взяла в работу в спринт, называют бэклогом спринта.

Рекомендуемая длительность встречи – не более четырех часов для двухнедельного спринта.

➤ Ежедневный Scrum (стендап)

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

Эти встречи проводятся в одном и том же месте, в одно и то же время для уменьшения путаницы.

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

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

➤ Обзор спринта

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

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

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

Для спринта длиной в месяц обзор – четырехчасовое мероприятие. На короткие спринты обычно тратят меньше времени.

➤ Ретроспектива спринта

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

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

Цели ретроспективы спринта.

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

2. Определить и упорядочить задачи – поговорить о том, что прошло успешно, а что нуждается в улучшении.

3. Разработать план по внедрению улучшений в процесс работы Scrum-команды, который и будет результатом встречи.

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

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

Артефакты в Scrum

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

➤ Бэклог продукта

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

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

➤ Бэклог спринта

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

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

Задачи, взятые в спринт, могут быть декомпозированы на более мелкие. Как именно – не регламентируется.

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

➤ Инкремент

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

У всей команды должно бы единое понимание того, что считать «готовым» продуктом (критерий прозрачности Scrum).

Критерий готовности (definition of done) – одно из соглашений, которое должна обсудить и принять вся команда. Участники команды определяют, что они подразумевают под словом «готово» применительно к задачам или элементам бэклога.

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

Критерии готовности к взятию в работу (definition of ready) – критерии, которым должна удовлетворять задача из бэклога продукта, чтобы ее можно было считать готовой к взятию в работу.

СюХаРи

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

Название отражает три этапа освоения.

1. Следование правилам.

2. Небольшие эксперименты.

3. Следование интуиции.

h. Стадия Сю – «следуй правилу» / «соблюдай»

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

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

h. Стадия Ха – «сломай правила» / «отделяйся»

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

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

h. Стадия Ри – «отделение от правил» / «превосходи»

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

В айкидо это третья ступень, согласно которой нужно освободиться от правил: их больше нет, есть лишь естественный ход вещей (Дао). «Ри» означает подняться над всем, что изучалось раньше, создать более высокие и общие принципы. На этой ступени уже формируется органичное и естественное поведение на уровне привычек.

Так вот, принцип освоения Scrum похож на методику СюХаРи:

• скраму можно научиться лишь в процессе, при этом сначала нужно хорошо освоить все правила, а потом забыть о них;

• скрам основан на постоянном пополнении опыта, требует особой внимательности и приложения больших сил.

Основы разработки требований

Заинтересованные лица

Заинтересованные в проекте лица (субъект, стейкхолдер, причастная сторона, Stakeholders) – это активно вовлеченные в проект отдельные лица, группы или организации, на которых влияет результат проекта и которые сами могут влиять на этот результат.

Если хотите, можете изучить другие определения термина «стейкхолдер». Это почти наверняка спросят на собеседовании, и неизвестно, какое из них знакомо HR-специалисту.

1. Это лица или организации, имеющие права, долю, требования или интересы относительно системы или ее свойств, удовлетворяющих их потребностям и ожиданиям (ISO/IEC/IEEE15288:2015).

2. Индивидуум, команда, организация или их группы, имеющие интерес в системе (ISO/IEC42010).

3. Люди, группы или организации, которые могут влиять на систему или на которых может повлиять система (OMG Essence).

4. Лицо, группа или организация, которая может влиять, подвергаться влиянию или воспринимать себя подвергнутой влиянию решения, операции или результата проекта (PMBOK).

5. Лицо или организация, которая может воздействовать на осуществление деятельности или принятие решения, быть подверженной их воздействию или воспринимать себя в качестве подверженной воздействию (ISO 9000:2015).

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

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

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

Пример

• Низкая рентабельность

• Вероятность потери доли рынка

• Большой процент простоев

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

Пример

• Отдел заказов работает без сбоев

• Маржинальность составляет минимум 10%

Ожидания – неявные (скрытые) представления заинтересованных лиц о характеристиках целевой ситуации, продукта системы, результата проекта. Имеют прямую связь с интересами этих лиц.

Пример

• Система будет красивой (с моей точки зрения)

• Сопровождение системы не потребует затрат

• Подрядчик будет соблюдать бюджет и сроки в пределах ± 5%

Решения – это диапазон возможных путей устранения выявленных бизнес-проблем.

Пример

• Изменение организационной структуры компании

• Разработка новых или оптимизация существующих бизнес-процессов, изменение бизнес-правил

• Оптимизация или разработка новых стратегических планов организации и т. п.

Типы заинтересованных лиц

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

Ниже приведены примеры наиболее распространенных типов (групп) стейкхолдеров, которые упоминаются в стандартах ГОСТ Р ИСО/МЭК 15288–2005, ISO/IEC29148:2011, ГОСТ Р ИСО/МЭК 12207–2010, OMG Essence, своде знаний по системной инженерии SWEBOK и учебниках по системной инженерии. Под стейкхолдером здесь подразумевается организация или физическое лицо.

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

2. Заказчик, или клиент (customer), получает продукт или услугу.

3. Разработчик (developer) выполняет задачи разработки, включая анализ требований, проектирование, тестирование в течение всего жизненного цикла.

4. Поставщик (supplier) вступает в соглашение с приобретающей стороной на поставку продукта или услуги.

5. Пользователь (user) извлекает пользу в процессе применения системы.

6. Производитель (producer) отвечает за выполнение работы, расписание, бюджет и распределение ресурсов, чтобы удовлетворить клиента.

7. Сопровождающая сторона (maintainer) выполняет поддержку системы на одном или нескольких этапах жизненного цикла, осуществляет деятельность по сопровождению.

8. Ликвидатор (disposer) выполняет ликвидацию (изъятие и списание) системы и связанных с ней эксплуатационных и поддерживающих служб.

9. Аккредитор, или инспектор (accreditor), проверяет систему на соответствие требованиям в процессе сдачи ее в эксплуатацию.

10. Регулирующий орган (regulatory bodies) проверяет систему на соответствие требованиям в процессе эксплуатации.

11. Остальные – персонал поддержки (supporters), инструкторы (trainers), операторы (operators) и другие.

Роли заинтересованных лиц

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

Основные роли заинтересованных в проекте сторон следующие.

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

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

3. Лидер проекта – наиболее авторитетный человек в команде проекта. К его мнению прислушиваются, он принимает большинство технических решений по ходу проекта. Часто лидер и менеджер проекта – одно лицо.

4. Заказчик получает результаты проекта в собственность того или иного вида.

5. Пользователи непосредственно используют результаты проекта в своей деятельности.

6. Организация-исполнитель выполняет проект и несет ответственность за это перед заказчиком. Она может состоять только из его команды и быть создана для реализации одного конкретного проекта.

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

8. Команда управления проектом – часть команды проекта, непосредственно участвующая в деятельности по управлению проектом. Это менеджер проекта и лидер проекта. Также туда могут входить секретарь менеджера, эксперты, помогающие в принятии решений, и т. д.

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

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