Cje кто это в agile должность

Опубликовано: 01.07.2024

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

Зачем нужен agile-менеджмент?

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

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

Первая роль agile-менеджмента – владелец продукта

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

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

Вторая роль в agile-менеджменте – scrum-мастер

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

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

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

Команда гибкого проекта имеет ряд особенностей. Она должна быть:

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

Команда гибкого проекта имеет ряд особенностей. Она должна быть:

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

3.1.1 РАЗМЕР КОМАНДЫ

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

Если для разработки одного продукта требуется большее количество ресурсов, то недопустимо увеличивать размеры команды сверх рекомендованного, нужно декомпозировать продукт на более мелкие «подпродукты» и/или использовать специальные инструменты масштабирования команд гибких проектов (например, LeSS, SAFe и подобные, в том числе описанные в разделе 1.3).

3.1.2 КОМПЕТЕНЦИИ И ПОЛНОМОЧИЯ

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

Строго не рекомендуется вводить уровни иерархии внутри команды (не путать с уровнями компетентности по тем или иным направлениям). Некоторые из Agile-фреймворков (в частности, Scrum) вообще требуют «плоской» команды, где у всех членов команды, за исключением владельца продукта и Scrumмастера, одна и та же роль — разработчик продукта (то есть не допускаются роли «аналитик», «тестировщик», «дизайнер», могут быть только разработчики, имеющие схожие компетенции) (рисунок 6).

Команда, как совокупность участников:

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

3.1.3 КРОСС-ФУНКЦИОНАЛЬНОСТЬ

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

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

Agile–команда — это кроссфункциональная команда, работа которой ведется по принципам agile, с реализацией гибкого фреймворка (например, Scrum или Kanban).

База знаний
➜
Agile команда

Что такое Agile команда

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

Зачем нужна Agile команда

Для более быстрых поставок продукта на рынок (Time To Market), для снижения количества микроменеджмента, для более точного попадания в потребности клиента.

Какой должна быть Agile команда

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

Когда нужна Agile–команда?

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

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

Работа в Agile–команде

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

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

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

Конечно, команды стремятся такого избегать.

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

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

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

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

Тем не менее, как правило, роли все–таки выделяются.

В самом распространенном фреймворке — Scrum — таких роли три: 1) Владелец Продукта, 2) Скрам–мастер, 3) Разработчик. Это классические роли Agile–команды.

Такое распределение является важным и его имеет смысл придерживаться. Каждая роль отвечает за свой функционал: Владелец Продукта за ценность продукта, Скрам–мастер за процессы в команде, разработчик — за создание продукта.

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

Нужен ли коучинг Agile–команд?

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

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

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

Related Entries

АКЦИИ

Новое на сайте

3 технологии высокой доступности Greenplum для администратора Big Data кластера
Под капотом Apache Kafka: zero copy и быстрые IO-операции с диском
3 оператора Apache Airflow для контейнерных конвейеров данных
Аналитика больших данных со Apache Spark SQL из внешних СУБД: про JDBC-драйверы
Как построить OLAP-конвейер в реальном времени на Greenplum и Apache NiFi: разбор интеграционного коннектора для приема больших данных

Отзывы на Google

Прошел Курс Администрирование кластера Hadoop. Подача материала хорошая, размеренная. Преподаватель отвечает на все вопросы, и пытается как можно прозрачней приподнести материал. read more

Обучался на программе HADM. Подача материала доступная. Порадовало соотношение теории и практики 50/50. Отзывчивый преподаватель. Однозначно рекомендую. read more

Заканчиваю прохождения курса "ADH: Администрирование кластера Arenadata Hadoop". Хочу сказать, что выстроен грамотный план обучения, где отслеживается отличное соотношение практики и теории. Преподаватель, Комисаренко Николай, обладает отличным чувством юмора, что позволило не скучать на серьезных темах, и обладает отличным навыком объяснять сложные вещи простыми словами. На курс приходил с большим числом вопросов, на все из которых получил грамотные ответы, после чего все разложилось по полочкам. read more

В декабре 2020 прошел курс "Администрирование кластера Kafka". Курс проводился удаленно. В части организации обучения придраться не к чему. Необходимую информацию прислали заранее, лабораторный стенд и портал обучения работали стабильно. Немного разочаровали лабораторные работы. На месте BigDataSchool я бы их переделал. В документах с лабами нужно сделать нормальное форматирование и нумерацию пунктов. Все пункты, необходимые для выполнения, нужно сделать в виде текста. В лабах много работ по созданию «обвязки» kafka (создание самоподписных сертификатов, развертывание MIT и т.п), которые можно сделать заранее. Это позволит студентам уделять больше времени изучению самой kafka. BigDataSchool идет навстречу и позволяет пользоваться лабораторным стендом гораздо дольше установленных часов обучения. Это очень к стати, если в течении дня Вы вынуждены отвлекаться от обучения. В целом, курс дает хорошую базу по kafka. Преподаватель хорошо подает материал, делает акценты в нужных местах, подробно отвечает на вопросы. read more

С 30 ноября по 4 декабря прошел курс "Администрирование кластера Hadoop". Учитывая, что я обладал довольно поверхностной информацией в данной теме (я CIO) - ушел с курсов просветленным. Многое стало понятным, в процессе обучения наложил знания на существующую инфраструктуру компании, в которой работаю. Рекомендую коллегам руководителям в ИТ - прокачаться на данном курсе, вы поймете куда двигаться в ближайшие 2-3 года. Админам, работающим или стремящимся в BigData- обязательно! Рекомендация - настойчиво, для тех кто "думает, что знает": перед курсом уделите время работе с командной строкой Linux! Total recall - обязательное условие. Много практической работы, и если есть затык в Linux - будете безнадежно отставать при выполнении лабораторных работ. read more

В октябре прошел курс Анализ данных с Apache Spark, это был второй раз, когда я обучался в этом месте. В целом, все хорошо, думаю что не последний. Не могу не подчеркнуть профессионализм преподавателя Королева Михаила, отвечал на поставленные вопросы, делился своим опытом. В общем, рекомендую! read more

Прошел тут курс "NIFI: Кластер Apache NiFi", вёл Комисаренко Николай. Живое и понятное обучение. Преподаватель отвечал на все вопросы от самых глупых, до самых умных и это было приятно. Так же порадовало, что преподаватель не идёт по заранее проложенным рельсам, а проходит весь путь вместе с вами, стараясь привнести, что-то новое. read more

Спасибо за обучение!

Очень крутое место, много практики, понятное объяснение заданной темы. Еще вернусь :) read more

Обучался на курсе HADM администрирование кластера Arenadata Hadoop. Интересный курс, хорошая подача. read more

Обучался на курсе по администрированию Apache Kafka. Хорошая подача материала, интересные практические задачи. Возникающие вопросы доходчиво и ясно объясняют. Остался очень доволен. read more

Был на курсе "Администрирование кластера Hadoop". Отличная подача материала. Очень много практики и технических подробностей. Подробный обзор стека технологий, платформы и инструментов. Рекомендую! read more

Учился на курсе Администрирование Hadoop. Курс вёл Николай Комиссаренко. Отлично подготовленная, продуманная, системная программа курса. Практические занятия организованы так, что у студентов есть возможность познакомиться с реальными особенностями изучаемого продукта. Отключил голову и прощёлкал лабы по книжке - здесь не работает. Преподаватель легко и развёрнуто отвечает на возникающие вопросы не только по теме предмета, но и по смежным. read more

Прошёл курс по администрированию Apache Kafka. Очень понравилась как подача материала, так и структура курса. Только вот времени маловато оказалось. не всё успел доделать, но это уже не к курсу претензии :). Практики было довольно много, и это хорошо read more

Прошёл курс "Hadoop для инженеров данных" у Николая Комиссаренко. Информация очень актуальна и полезна, заставляет задуматься о текущих методах работы с большими данными в нашей компании и, возможно, что-то поменять. Занятия с большим количеством практики, поэтому материал хорошо усваивается. Отдельное спасибо Николаю за то, что некоторые вещи объяснял простым языком, понятным даже для "чайников" в области Hadoop. read more

I did not find any disadvantages in the course. Pluses: + A lot of practice (50% of the time). + The teacher can explain difficult topics easy way. + Announced topics were considered. Besides additional materials were studied. read more

Посетил курс администрирование Hadoop. На курсе устанавливали кластер с нуля на виртуалках в облаке Amazon. Настраивали Kerberos, тестировали выполнение задач на кластере, управление ресурсами кластера. Т.к. кластер развернут в облаке, после завершения занятий можно самостоятельно работать с кластером из дома. Лекции вел Николай Комиссаренко, после обучения предоставил все материалы. На занятиях отвечал на дополнительные вопросы, рассмотрели как решить пару живых задач от студентов. Хороший курс для начала изучения BigData. Update Дополнительно прошел обучения по Airflow и NiFi. Курсы двух дневные упор на занятиях делался на использовании продуктов, администрированию уделялось меньше времени. Т.к. курсы короткие, то перед занятиями желательно почитать обзорные статьи по продуктам, чтобы не терять время на базовое погружение и задавать более предметные вопросы. Перед началом занятий желательно связаться с школой и запросить что больше интересуется на обучении. Может быть предложить свои кейсы, чтобы на лабораторных отработать не только общий функционал. read more

Был на основах хадупа, все материалы описаны доступным языком. В частности хочу отметить преподавателя Николая Комисаренко, как очень квалифицированного преподавателя и специалиста. read more

Отличные курсы по "Администрированию Hadoop" и отличная организация проведения занятий, все по делу и понятно. Очень понравилось, знания получены основательные. Материал подаётся основательно. Постараюсь ещё попасть на другие курсы. read more

Курс по Isilon у Николая Комиссаренко мне тоже понравился. Грамотный и отзывчивый. Возникали вопросы по курсу он отвечал на все вопросы. Спасибо. Успехов ему read more

Эффективный практический курс. Прошел курс Администрирование Hadoop в октябре 2018. Хорошо наполненный материал, оптимальная длительность курса и все делалось своими руками. Местами было непросто, но преодолимо. Оправдал все ожидания, после курса появилось целостное понимание создания и работы кластера. Николай, большое спасибо read more

Прошёл курс по администрированию Hadoop Cloudera. Отличная "живая" подача материала на "простом" языке. Как плюс работа с кластером построена на платформе AWS. На курсах не скучно, рекомендую! read more

Я узнал много нового посетив курс уважаемого Николая Комиссаренко по айзелону. Очень грамотный специалист обучение было очень полезным и грамотным. Спасибо вам большое read more

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

В чём идея

Гибкую методологию управления придумали, чтобы решить ряд проблем классической/каскадной/водопадной методологии (Waterfall). Например, слишком большой упор на планирование и влияние задержек в одних командах на работу других. Для этого, как я уже сказал, пришлось полностью пересмотреть взгляд на проектную работу, а не менять какие-то отдельные механики.

«Гибкость» заключается в способности agile-команды постоянно адаптироваться к изменяющимся условиям и достигается за счёт:

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

Основные ценности Agile-методологии

Методология — набор методов и принципов, подкреплённых теорией.

Так вот теория в случае с Agile — это ценности, описанные в Agile Manifesto:

Люди и взаимодействие важнее процессов и инструментов . Если в твоей команде есть принципы, традиции, структуры, инструменты или условия, которые явно мешают работе — от них следует избавиться. Люди сами должны выбирать способ организации, набор процессов, используемые инструменты. В конце концов, всё это должно помогать работе, а не мешать.
Работающий продукт важнее документации . Это не значит «работать по Agile — работать без документов». В agile-командах тоже есть документация, но на неё не тратят огромное количество времени и ресурсов.
Сотрудничество с заказчиком важнее согласования условий контракта . Посмотри немного дальше согласования ТЗ и сметы. Нет смысла портить отношения с заказчиком, пусть и ценой своевременной оплаты. Если ты не можешь согласовать работы и портишь общение, в итоге потеряешь и этого клиента, и, возможно, следующих. Любые контракты, документы и соглашения должны идти на руку твоим взаимоотношениям с клиентами, а не портить их.
Готовность к изменениям важнее следования первоначальному плану . Даже если есть план проекта, в него, почти наверняка, со временем придётся внести изменения — в этом суть Agile.

Ещё в Манифесте описаны принципы, но скорее в попытке разжевать ценности. Так что приводить я их здесь не буду. Если хочешь, сходи почитай на Википедии .

Какие могут быть проблемы

Ай, какой классный Agile, да? Увы, хотя его и можно применять в любой компании (даже если ты — прости, Господи — банк), подходит он далеко не всем. Да ещё и его внедрение может быть крайней болезненным.

Я вижу три проблемы (хотя, вполне может статься, что их больше), из-за которых нельзя советовать переходить на Agile всем подряд:

Сложно отказаться от концепции «начальник — подчинённый» . Ведь Agile — это не способ планирования, а философия работы всей команды. Далеко не каждая компания сможет спокойно пережить подобную трансформацию.
Не все готовы к по-настоящему командной работе . Многим людям комфортнее работать в одиночку, отчитываться перед руководством и никуда не лезть. А в случае с Agile всем придётся во всём разбираться и постоянно участвовать в чужой работе.
Не все готовы к тому, что часть времени может просто пропасть . Допустим, команда работала над задачей, а потом оказалось, что цели проекта поменялись и продолжать почти законченную работу нет смысла. Все твои усилия были напрасны. Это психологически сложная ситуация, которая может запросто убить всю мотивацию.

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

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

Главное, помни, что Agile – это методология и философия. Чтобы применять всё это для управления проектами, из этого конструктора нужно собрать свою методику или выбрать одну из существующих — о них я расскажу в следующих статьях.

Читайте также: