Agile

В этом году в секции Team на DUMP выступит agile-коуч компании Wiley Илья Якямсев. Мы поговорили с Ильей о его докладе, злом стендапе и о том, как сценический опыт помогает вести тренинги.

Илья, привет! На DUMP ты выступишь с докладом Говорите, пожалуйста! Как построить эффективную коммуникацию в команде. А еще ты выступаешь как стендап-комик. Мы не будем тебя просить шутить в нашем интервью, а будем просто задавать вопросы тебе-менеджеру, и тебе-комику.

• Расскажи подробнее, о чем будет твой доклад? Можно немного спойлеров:)

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

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

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

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

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

• Где ты учился взаимодействию в команде (или с этим рождаются?) и как прокачивал этот полезный скилл?

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

Да, важно - мне это нравится.

• Как на работу твоей команды повлияла пандемия? Что изменилось?

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

Частично и об этом буду говорить в своём докладе.

• С чего начиналась твоя карьера agile-коуча? Что считаешь твоим (командным) успехом, а что - провалом?

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

Труднее всего не давать советы и не пытаться прямым действием исправить систему. К этому пытаюсь привыкнуть.

• Как ты пришел к своему увлечению стендапом? Какой момент стал поворотным?

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

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

• Какие комики тебя вдохновляют? А проекты и команды?

Меня вдохновляют комики с идеями, где кроме шуток есть интересные точки зрения и/или не банальная литература. Даг Стенхоуп, Джордж Карлин, Саймон Амстел, Эдди Изард, Стюарт Ли.

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

• Где ты берешь материал для шуток? Как его отрабатываешь и проверяешь? Кто герои твоих выступлений?

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

• Что ты чувствуешь, когда стоишь на сцене, слышишь смех в зале? А когда выступаешь на конференциях? А прорывается наружу стендапер?

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

Чувствую удовольствие. Иначе бы не занимался.

• Шутишь ли ты про работу со сцены? И наоборот - привносишь ли опыт комика в работу?

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

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

Ну и тренинги мне из-за этого опыта вести легко и приятно.

• Есть вероятность, что тебе надоест карьера в Wiley и ты будешь собирать залы?

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

• Представь, что ты вернулся на 10 лет назад в прошлое, что посоветуешь себе?

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

Да, ещё хороший совет - не бросать основную работу пока не нашёл другую основную работу.

• А кем видишь себя еще через 10 лет?

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

Мне очень нравится удалёнка.

• На DUMPе ты мы увидим твой полезный доклад для менеджеров разработки. А где можно посмотреть твой стендап (вживую - мы все очень соскучились по офлайну)?

У меня будет концерт в Екатеринбурге, его организуют местные ребята в лофте Место. Вечер 14 мая в 22:00 (после конференции). Приходите, если что.

А послушать Илью как спикера секции Team можно 14 мая в конгресс-центре ЭКСПО оффлайн или в нашей онлайн-трансляции. Билеты выбирай здесь!

Увидимся на DUMP!

В этом году в секции Team на DUMP выступит agile-коуч компании Wiley Илья Якямсев. Мы поговорили с Ильей о его докладе, злом стендапе и о том, как сценический опыт помогает вести тренинги.

Илья, привет! На DUMP ты выступишь с докладом Говорите, пожалуйста! Как построить эффективную коммуникацию в команде. А еще ты выступаешь как стендап-комик. Мы не будем тебя просить шутить в нашем интервью, а будем просто задавать вопросы тебе-менеджеру, и тебе-комику.

• Расскажи подробнее, о чем будет твой доклад? Можно немного спойлеров:)

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

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

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

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

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

• Где ты учился взаимодействию в команде (или с этим рождаются?) и как прокачивал этот полезный скилл?

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

• Как на работу твоей команды повлияла пандемия? Что изменилось?

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

Частично и об этом буду говорить в своём докладе.

• С чего начиналась твоя карьера agile-коуча? Что считаешь твоим (командным) успехом, а что - провалом?

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

Труднее всего не давать советы и не пытаться прямым действием исправить систему. К этому пытаюсь привыкнуть.

• Как ты пришел к своему увлечению стендапом? Какой момент стал поворотным?

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

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

• Какие комики тебя вдохновляют? А проекты и команды?

Меня вдохновляют комики с идеями, где кроме шуток есть интересные точки зрения и/или не банальная литература. Даг Стенхоуп, Джордж Карлин, Саймон Амстел, Эдди Изард, Стюарт Ли.

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

• Где ты берешь материал для шуток? Как его отрабатываешь и проверяешь? Кто герои твоих выступлений?

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

• Что ты чувствуешь, когда стоишь на сцене, слышишь смех в зале? А когда выступаешь на конференциях? А прорывается наружу стендапер?

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

• Шутишь ли ты про работу со сцены? И наоборот - привносишь ли опыт комика в работу?

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

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

• Есть вероятность, что тебе надоест карьера в Wiley и ты будешь собирать залы?

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

• Представь, что ты вернулся на 10 лет назад в прошлое, что посоветуешь себе?

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

Да, ещё хороший совет - не бросать основную работу пока не нашёл другую основную работу.

• А кем видишь себя еще через 10 лет?

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

Послушать Илью как спикера секции Team можно 14 мая в конгресс-центре ЭКСПО оффлайн или в нашей онлайн-трансляции. Подробнее о программе.

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

Почему Trello

Я пользовался большим количеством инструментов, из которых можно выделить основные: Miro - как интерактивный флипчарт, с которым может взаимодействовать вся командa; Google Docs с секциями помапанными на стадии ретроспектив; Confluence (так как все мои проекты пронзены Atlassian-стеком); а также, порой, Jira (вау, это была достаточно плохая идея)!

Я думаю что все пытались нащупать тот самый инструмент, который можно применить фактически в любой области!

И вот я бы выделил основными критериями для проведения Ретро и собирания фидбека о Демо в подобных инструментах:

1. Насколько хорошо оно работает на уровне объектов (во время обсуждений). -> в идеале тут хотелось бы видеть карточки (все таки мы в физическом мире работаем со стикерами) :)

2. Быстрая и эффективная работа с карточками / объектами

3. Подсветка / теги для карточек / объектив (чтоб все могли), не важно как (цвет, тег, еще какая-то штука позволяющая дифференцировать карточки)

4. Перетасовка / изменение порядка карточек / объектов / айтемов

5. Как можно меньшее время, затраченное на следующую последовательность действий: создание секции (списка) -> добавление в него объектов / карточек -> тегирование / подсветка айтемов (членами команды) -> добавление комментария к айтему.

Miro

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

Google Docs

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

В этом плане, знаете, даже google sheets казалось бы удобно использовать, как инструмент более подходящий для нашей аналогии двухмерной-классической-ретро-доски (ну как двухмерной, скорее именно с точки зрения того, что у нас есть некие секции с контентом для хорошо/не оч/ улучшить). Но и тут нас поджидает неудобство - drag-n-drop для айтемов, и их линкование друг с другом работает ужасно. Я еще пробовал в свое время google slides, с подходом слайд-для-секции (например перечислить все те великие свершения, в которые мы шмогли с прошлого спринта) - но в итоге менеджить это было сложно, ввиду тяжеловесности решения, ну и на одном таком канвасе могло одновременно ну человека два работать может, не больше. Ну и подсвечивать айтемы там конечно можно, но оно для того не очень приспособлено.

Confluence

Ну вот же confluence, там же целый шаблон для ретро есть! Скажете вы. И будете правы!

Но хорош этот шаблон для документирования/стенографирования, для журнала принятия решений. А нам это в ретро не нужно! Нам нужна живая дискуссия где народ таскает карточки по колонкам, клонирует, обсуждает, помечает!

Более того, Atlassian обычно старается сделать confluence неким легковестным решением, если вас кормят всем их стеком. Но по простоте коллаборации там до gDocs как до луны. Возвращаясь к нашему подходу (ищем блочную структуру для карточек) - confluence неудобен. А еще - нестабилен: с потерей контента и его перезатиранием в режиме коллаборации, отвалом соединения и последующими невозможностями сохранить.

Trello

Ну вот а когда мы подходим к Trello - оно просто поддерживает карточки. И голосовалку для этих карточек с помощью power-up'ов (очень просто). Или через тегирование этого дела цветами (что работает просто и быстро).

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

Короче говоря: trello это самый простой в использовании аналог флипчарта со стикерами :)

Подготовка к самой ретроспективе, и ее начало

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

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

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

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

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

Сама Ретроспектива

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

Запланированные улучшения с прошлого спринта

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

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

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

Иногда эта стадия может затянуться (планировали улучшение - не смогли достичь - начинаем погружаться слишком сильно в детали почему). Как фасилитатор, ваша задача помочь команде найти продуктивный путь для выявления настоящей причины в достаточно короткий срок (у нас ведь есть таймбокс). Поэтому мы с вами планируем один обязательный пункт улучшения, два уже имеют риск затянуть начало ретроспективы. Также старайтесь просто запарковать это обсуждение на полее поздние части ретроспективы - если нужно действительно разобраться. А возможно это даже не относится к ретроспективе как к событию, а надо проводить RCA / Post-Mortem?

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

Цели спринта и метрики

Цели Спринта

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

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

Метрики

Метрики спринта важны и как внутренний-SLA для команды, и как общий индикатор, который в комплексе помогает команде понять динамику.

Обычно команда навскидку придумает с десяток факторов, которые для неё препятствия чтоб быть более эффективной. Если поддерживать ведение такой дискуссии в правильном русле (читай, фасилитировать), и помогать команде наводящими вопросами (читай, коучить), ребята сами соорудят путь к улучшению и как его измерять. Главное чтобы был запрос на улучшение, и была понята сама проблема (нафига оно нам вообще). Еще нюансик: не рассматривайте метрики отдельно друг от друга, и стройте связи между опережающими индикаторами (гипотезами) и запаздывающими индикаторами (результатом). Например, действительно ли увеличение покрытия кода тестами увеличивает уверенность в том, что на проде качество улучшается?

Стандарные метрики, которые я стараюсь использовать:

- Lead Time (время от запроса клиента до поставки)

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

- Время в Code Review (атож, сколько задача висит и сколько ее проверяют),

- Количество раз тикет был переоткрыт (помогает вместе с определением Definition of Ready),

- Mean Time to Recovery (инцидент-метрика для понимания среднего времени на устранение),

- Bug Escape Rate (сколько багов мы не поймали на тестовых стендах, но поймали после релиза на прод).

В целом все зависит от ситуации, но я считаю Cycle Time и Lead Time тем самым минимумом для всех. Cycle Time в целом дает вам понимание прозрачности и предсказуемости.

Активность на выявление дельты улучшения ~ 'Хорошо-Плохо-Улучшения

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

Собираем фидбек с команды о том, как прошла ретроспектива

Ну а что, нужно же нам знать, насколько плохо мы справились! Я просто прошу оценить ретро по 10-бальной шкале, и назвать одно улучшение, чтобы увидеть дельту.

Референсы и полезности

У Бена Линдерса (Ben Linders) есть хорошая трелло-доска, в которой люди краудсорсят ретроспективные техники для распределенных команд в трелло.

• https://www.benlinders.com/news/trello-board-retrospective-techniques/ Это, наверное, и разговоры с самим Беном, были огромным подспорьем, чтобы написать этот пост.

Новый мир, болезненные челленджи, сложные кейсы и критические препятствия перед Agile-трансформациями и агентами изменений. Обсудим эти темы на онлайн-митапе 18 мая со спикерами Райффайзенбанка, AgileVerse и Tinkoff.

Регистрируйтесь и присоединяйтесь к нам

О чем поговорим

Сложно, много и опасно. Part 1: как сделать трансформацию на удаленке, наступить на все грабли и выжить

Анастасия Ломакова, ФёдорСлесаренко, Райффайзенбанк

Расскажем про свой кейс LeSS-трансформации на удаленке. Сложности, с которыми мы столкнулись; грабли, на которые наступили, и уроки, которые для себя вынесли.

Сложно, много и опасно. Part 2: что может пойти не так в вашей трансформации

Левон Гончаров,AgileVerse

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

Трансформация как путь. По каким сторонам стоит смотреть, чтобы повысить шансы команды дойти до финиша?

Виктор Никишин, Tinkoff

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

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

Изменения в online-эпоху

Михаил Вязанкин,AgileVerse

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

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

Начнем митап в 19:00 (мск)
Регистрируйтесь, чтобы получить ссылку на трансляцию: письмо придет вам на почту.

И присоединяйтесь к открытому чатуScrumCommunity @ Raiffeisenbank в Telegram. У нас активное коммьюнити, и мы всем рады!

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

Начну, пожалуй, с подходов к обучению.

Обучение Канбану. Канон

Самыми полными и каноничными курсами по погружению в Канбан-Метод по праву считаются классы, которые разрабатывает Канбан Университет структура Дэвида Андерсона, автора метода.

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

Прямая линейка:

• TeamKanbanPractitioner(можно пропустить, это популярная выжимка основных вещей для первичного погружения в тему)

• Kanban System Design

• Kanban System Improvement

• Kanban Maturity Model

• Kanban Coaching Practices

Смежная линейка:

• FitforPurpose(раскрывает тему продуктового управления и работы с клиентом)

• EnterpriseServicePlanning(стратегическое планирование и управление организацией)

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

Минус, как ни странно, это Эволюция.

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

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

То же самое случилось и с подачей материала Канбан Университетом. Вначале, когда метод только развивался, всю имеющуюся информацию Дэвид Андерсон структурировал в небольшой доклад, с которым ездил по профильным конференциям. Когда информации стало больше, появился тренинг и книга Kanban: Successful Evolutionary Change for Your Technology Business (на русском перевели как Канбан. Альтернативный путь в Аджайл).

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

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

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

Другие тренинги. Свой лунный модуль

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

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

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

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

Работа консультантов. Обучение через работу

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

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

Плюсытакого подхода прикладная польза для решения конкретных проблем.

Минусы в будущем проблемы могут быть другими и текущие практики не сработают.

Несколько советов, с чего начать

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

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

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

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

Персональный Канбан

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

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

Также, можно посмотреть на практики категоризации и приоритизации потоковой работы.

Канбан для отдела

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

На какие практики я бы рекомендовал обратить внимание при такой работе?

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

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

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

Канбан для команды

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

Отличительная особенность команды:

• Общий результат

• Общая оценка результатов работы

• Размытие зон ответственности в смежные области для уменьшения точек передачи информации (в отличие, например, от при передаче её через функциональные отделы, где эта самая информация часто теряется)

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

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

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

Канбан для Владельца продукта

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

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

Для определения цепи поставки уже стоит провести воркшопSTATIK(systemthinkingapproachtointroduceKanban, описан в книге Майка Барроуза Канбан-метод: улучшение системы управления)

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

• Объект управления чем именно нужно управлять Владельцу продукта, чтобы процесс поставки ценности был управляем и контролируем

• Группировка сходных типов работ (Фильтры, Цветовая дифференциация, Дорожки, Колонки)

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

• Управление рисками поставки. Проблема в поставке проблема менеджера, Метод дает широкий инструментарий для управления риском: визуализация блокировок; визуализация буферов и очередей; выявление источников проблем; ретроспективы и обзоры поставки

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

• Метрики прогресса: T2MиLeadTime метрики, помогающие прогнозировать сроки; Fit for Purpose criteria продуктовыеметрики; пропускная способностьпроизводственной системы

Канбан для менеджера-проекта

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

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

В отличии от жизненного цикла проекта на управлении которым акцентированы популярные средства управления проектами, Канбан-визуализация должна фокусироваться на жизненном цикле производства элемента продукта и отвечать (например для ИТ-проекта) на вопрос Что нужно сделать, чтобы вывести этот кусок функциональности в Продуктив?

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

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

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

А остальным что делать?

Почти все случаи, которые я описал выше, для решения своих насущных проблем могут обойтись ограниченными практиками, в них не обязательно погружаться глубоко в механики Канбана. Однако, начиная с менеджерского состава, который вовлечен в производство результатов умственного труда, я бы всем рекомендовал пройти три из четырех модулей Канбан Университета (KSD,KSI,KMM) и ответвлениеFitforPurpose. Причем, проходить их не подряд, а с промежутком на применение полученных знаний на практике, так как сама текущая механика обучения подразумевает прохождение эволюции восприятия инструментов Метода.

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

Удачи всем в совершенствовании собственной работы!

По Agile доступно огромное количество курсов. Кроме специализированных курсов по проектному управлению есть ещё сертификации.

Зачем получать сертификаты по проектному управлению? Существуют несколько причин:

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

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

• Проверить свои силы. Сертификация даст ответ насколько ты хорош.

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

• Повышение. Сертификаты повышают вашу стоимость в глазах работодателя.

Сертификаты можно разделить на три типа:

Перед подготовкой к сертификации вам нужно ответить для себя на несколько вопросов:

1. Для чего вам нужен сертификат?

2. Какую методологию/фреймворк вы используете или хотите использовать?

3. Какая у вас текущая или желаемая роль в компании?

ICAgile

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

Agile DeliveryBusiness Agility

Agile Delivery и Business Agility.

Обучение проходит по 8 трекам плюс 1 бизнесовый блок.

В каждом треке есть 2 уровня. Прошёл обучение по каждому уровню получаешь статус по всему треку.

Обучение на каждом уровне длится в течение 3-х дней, много практики.

Сертификат

Сертификат пришлют в течение 4 недель после курса. Сертификат выдаётся бессрочно, продлевать не нужно.

Проверить сертификат на действительность можно по ссылке.

Стоимость обучения варьируется в зависимости от трека от 35 до 90 тысяч рублей. Стоимость курса включает выдачу сертификата. Ничего доплачивать не нужно.

Из плюсов:

• Международный сертификат.

• Разнообразие, можно прослушать курсы по нескольким направлениям: Agile, DevOps, опер блок.

• Сертификат выдаётся бессрочно.

Из минусов:

• Отсутствует экзамен. Человек, который старался, слушал курс, и человек, который просто присутствовал, равны.

PMI

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

Треков нет.

Сертификат

Это одна из немногих сертификаций, до которой ещё необходимо допуститься.

Для получения доступа к экзамену потребуется:

• Не менее 12 месяцев опыта управления проектами за последние 5 лет;

• Не менее 8 месяцев управления Agile проектами за последние 3 года;

• 21 час обучения на любом курсе Agile (не обязательно аккредитованом).

Описание требований для доступа к экзамену. Курсов по подготовке к экзамену не так много.

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

Сам экзамен состоит из 120 вопросов, большая часть вопросов ситуационные, основаны на практических кейсах. На экзамен отводится 3 часа. Критерий успешной сдачи не раскрывается, но, по слухам, составляет примерно 70 правильных ответов. Русский язык на экзамене пока ещё недоступен придётся сдавать на английском.

Проверить сертификат на действительность можно по ссылке.

Сертификат необходимо продлевать каждые 3 года. Для этого достаточно пройти 30 часов обучения на сертифицированных курсах. Подробная информация по ссылке.

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

Из плюсов:

• Одна из самых именитых компаний.

• Необходимо сдать экзамен.

Из минусов:

• Одна из самых сложных сертификаций.

• Необходимо допуститься до экзамена.

• Высокая стоимость экзамена (495 USD).

• Экзамен доступен только на английском языке.

• Нужно продлевать сертификат.

IAPM

IAPM. Малоизвестный провайдер IAMP. Сертификация основана на стандарте AgilePM Guide 2.0. Стандарт включает инструменты и техники из нескольких фреймворков: Agile, Scrum, Kanban и других.

Ссылка на сам стандарт.

IAPM certifications

К сертификации доступно 4 уровня: Certified Junior Agile Project Manager, Certified Agile Project Manager, Certified Senior Agile Project Manager, и Certified International Project Manager.

Сертификат

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

Проверить сертификат на действительность можно только отправив запрос на почту support@iapm.net.

Экзамен состоит из 120 вопросов, на которые будет отведено 80 минут. Для успешной сдачи необходимо правильно ответить на 78 вопросов. Более подробно по ссылке.

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

Из плюсов:

• Международный сертификат.

• Необходимо сдать экзамен.

• Не нужно продлевать сертификат.

Из минусов:

• Малоизвестный провайдер в РФ.

• Экзамен доступен только на английском языке.

Scrum Alliance

Scrum Alliance. Компания была основана в 2002 году авторами The Scrum guide Джеффом Сазерлендом и Кеном Швабером. Сертификат от Scrum Alliance один из двух самых известных в мире сертифицирующих организаций по Scrum. О второй позже.

Certification Types & Tracks.

В Scrum Alliance есть три трека для сертификации по ролям: Scrum master, Product owner, Developer. У всех трёх ролей есть три ступени Certified, Advanced и Professional.

Также Scrum Alliance предлагает еще 4 дополнительных трека Agile Leadership, Team Coach, Enterprise Coach и Trainer.

Сертификат

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

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

Проверить сертификат на действительность можно по ссылке.

Экзамен состоит из 50 вопросов, на решение которых будет отведён 1 час. Критерий прохождения - 37 правильных ответов.

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

Стоимость обучения составляет порядка 65 тысяч рублей за 1 ступень, включая взнос за экзамен и 2 попытки, далее $25 за каждую попытку.

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

Сертификацию нужно продлевать каждые 2 года. Для продления необходимо набрать достаточное количество баллов SEUs на аккредитованных курсах плюс заплатить взнос. К примеру, для продления самой популярной сертификации Product owner и Scrum Master потребуется 30 часов курсов и оплата взноса в размере 175 долларов.

Подробная информация о продлении по ссылке.

Из плюсов:

• Всемирно известная компания.

• Необходимо сдать экзамен.

Из минусов:

• Экзамен доступен только на английском языке.

• Нужно продлевать сертификат.

Scrum.org

Scrum.org. Вторая всемирноизвестная сертификация по Scrum. Компания Scrum.org была основана в 2009 году Кеном Швабером.

Professional SCRUM certifications

Для сертификации доступно8 треков, 3 из которых организованны по ролям: Scrum Master, Product Owner и Developer. Остальные пять Scaled Professional Scrum, Professional Scrum with Kanban, Professional Agile Leadership, Professional Agile Leadership-EBM, Professional Scrum with User experience.

Сертификат

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

Проверить сертификат можно по ссылке.

Количество вопросов и стоимость сертификации отличается от трека к треку.

На примере сертификации Scrum Master.

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

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

Стоимость обучения составляет порядка 50-80 тысяч рублей за 1 ступень, включая взнос за экзамен и 2 попытки.

На сайте scrum.org доступно бесплатное тестирование, которое может пройти любой желающий. Сертификата не дадут, но можно понять уровень подготовки.

Из плюсов:

• Всемирно известная компания.

• Необходимо сдать экзамен.

• Сертификат не нужно продлевать.

Из минусов:

• Экзамен доступен только на английском языке.

Kanban University

Kanban University. Сертификация проходит аналогично ICAgile, прослушал курс получи сертификат. Для сертификации доступно 5 треков.

Certified kanban.

Team Kanban Practitioner это однодневный курс для тех, кто хочет познакомиться с Kanban.

Чтобы получить Kanban Management Professionalнеобходимо пройти обе ступени KMP1 и KMP2.

Треки Management, Coaching, Consultant и Trainer подойдут для тех, кто планирует стать тренером или коучем по Kanban.

Сертификат

Проверить сертификат можно по ссылке.

Обучение проходит в течении 1-2 дней, зависит от трека. Стоимость составляет порядка 25-50 тысяч рублей за одну ступень.

Из плюсов:

• Международный сертификат.

• Сертификат выдаётся бессрочно.

Из минусов:

• Отсутствует экзамен.

Перечень провайдеров

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

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

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

• Ты стремишься развиваться и получать новые знания.

• Ты знаешь теорию достаточно, чтобы пройти все испытания.

Если есть опыт в получении сертификаций и желание поделиться им, напишите, пожалуйста, в ЛС.

А если я упустил какую-либо информацию, напиши в комментарии. Я обязательно её добавлю.

Итак, я получил сертификат Professional Scrum Master I от Scrum.org. По сути, это демонстрация того, что за Скрам я знаю, и могу с ним работать. И даже немного других учить.

Выдается онлайн, после оплаты 150 долларов США и прохождения теста из 80 вопросов. Положительным результатом считаются 85% правильных ответов или в абсолютном количестве 68. Есть право на 12 ошибок. Время 60 минут.

В целом, по Скраму есть две популярные международные сертификации: PSM и CSM. Вторая расшифровывается как Certified Scrum Master и выдается Scrum Alliance.

PSM считается сложнее - вопросов больше, проходной балл выше, есть лимит по времени - в общем нормальный тест. При этом для CSM обязательно нужно посетить курс под 1к долларов стоимостью. Отличный бизнес. Зато тест на 35 вопросов, можно прерваться, да и никто не гонит - хоть весь день его делай. Проходной балл 68%. Подробнее можно найти погуглив, есть отличные статьи от тех кто обладает обеими сертификатами.

Прелесть PSM I же в том что курсов не нужно - оплатил, и тебе дают одну попытку. Технически это так:
1) Регистрируешься на Scrum.org.
2) Заказываешь и оплачиваешь сертификацию - в моем случае молдавская карта отлично сработала(правда потом её временно заблокировали за странную операцию, но разблочили в итоге).
3) Получаешь на почту пароль.
4) Вводишь на сайте и можешь проходить тест. Пароль бессрочный, но одноразовый.

На тест даётся 60 минут, прерываться, ставить таймер на паузу нельзя. На вопросы можно поставить закладки и потом вернуться через оглавление. Пропускать вопросы не ответив нельзя.

Вопрос как правило на выбор одного, двух или трех правильных или наоборот ложных утверждений. Есть еще True/False.

У меня ушло чуть более получаса на это всё, и в итоге я сделал 9 ошибок, 88.8% верных ответов. И красивый серт.

Подготовка

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

Скрам гайд в итоге и был моим ключевым материалом - 13 страниц при должной усидчивости можно и наизусть заучить.Мое личное мнение - он проще и понятней чем был в старой версии.
Спойлер: но вызубрить не поможет )

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

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

В качестве тренировки я проходил открытые тесты на том же Scrum.org - 30 вопросов рандомно выбранные из пула, в конце показывают где ошибся и объясняют - что полезно.

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

Отмечу, что ни одной книги по Cкраму я так и не прочел.

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

Во-вторых, я в курсе для чего пишутся книги в этой индустрии.

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

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

Тест

И вот этот день настал - я сел за тест. Судя по скорости прохождения тренировочных (рекорд 6 минут на 30 вопросов) - я рассчитывал закончить менее чем за час.

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

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

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

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

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

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

Пример: может/должен. Продакт Оунер должен присутствовать на дэйли скраме. Верно или нет? Ответ в P.S.

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

Тест занял чуть более получаса. Вопросы - от 2 секунд до минуты на каждый. Самые сложные на мой взгляд были из разряда "Тебя назначили Скрам Мастером.." и дальше ряд условий - что ты сделаешь? Надо применять философию на практике.

В заключениипро важность сертификации: на рынке труда зачастую работает презумпция незнания. То есть вы можете (и многие так и делают) - рассказывать о себе все что угодно. Что вы знаете Скрам, Канбан, Лин и Экстремальную разработку. Но пока не покажете доказательства - всё это лишь слова. Сертификат это как раз бумажка с которой вы человек, даже в чем-то мастер )

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

В общем такой был мой опыт. Если у кого есть еще вопросы - приглашаю в комменты.

P.S. Не должен. Это ивент для разработчиков, для ПО - опционально. Хотя у нас по моему у всех всегда присутствует вся честная компания включая СМ и ПО. Никто не верит что разработчики сами справятся )

Вводная часть

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

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

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

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

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

Основная цель безлюдное производство, цифровой завод. Первый шаг навстречу цели - внедрение системы SAP S/4HANA с максимальным использованием стандарта.

Объем проекта

Внедряемые продукты SAP

• SAP S/4HANA

• SAP Fiori LaunchPad (Цифровое окно)

• SAP HCM

• SAP BPC

• SAP MII

• SAP PO

Автоматизируемые процессы

• Бюджетирование

• Финансы

• Снабжение и Сбыт

• Производство и ремонты

• Управление персоналом

• Единое цифровое окно

Особенности работы в удаленном режиме

Обучение ключевых пользователей

Передача знаний на расстоянии

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

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

Подготовка тренинга:

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

• Для ответов на контрольные вопросы и сбор обратной связи мы использовали MS FORMS. Очень удобный инструмент, который позволяет пользователям сразу увидеть свою оценку и экономит время тренеров на проверку. С его помощью можно создать тест, и даже выгрузить его результаты в формате Excel, что позволяет с легкостью отслеживать статистику и делать сводные таблицы. Плюс - ограничений по количеству форм (тестов) нет.

• Сформировали группы на обучение в размере не более 10 человек. И соответственно рассчитали время тренингов. В случае увеличения численности группы время тренинга увеличивалось.

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

• Лучше заранее проверить Интернет-связь, как на стороне тренеров, так и на стороне пользователей, чтобы не было рассинхронизации голоса и трансляции экрана.

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

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

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

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

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

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

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

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

• Так как у нас на обучении была взрослая аудитория, то эффективно удерживать внимание получалось примерно в течение 1 1,5 часов. Далее требовалось сделать перерыв на 10-15 минут. Это необходимо учитывать при планировании времени тренинга. Максимальная продолжительность тренинга в течение дня для одной группы обучающихся без потери качества обучения 4 часа.

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

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

Лайфхаки, или наши полученные уроки:

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

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

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

Тестирование функционала системы

Как протестировать функционал системы в удаленном режиме на предприятии, которое еще в процессе строительства?

Для ответа на данный вопрос разберемся, какая ставилась цель, и какие виды тестирования мы применяли на проекте.

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

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

• Функциональное это локальное тестирование возможностей системы. При таком тестировании осуществляется проверка системы в рамках объектов функционального направления;

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

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

1. Организация процесса тестирования:

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

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

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

2. Интеграционное:

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

3. Приемочное:

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

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

Концепция раннего старта:

Реально ли внедрить систему так, чтобы какие-то отдельные её части запустились раньше, а какие-то позже? Да!

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

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

Для отдельного направления Цифровое окно применялась методология Scrum.

Для управления развитием системы после раннего старта будет применяться Hybrid Agile.

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

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

Я придерживаюсь убеждения, что задача анализа в IT это борьба с неопределённостью, с целью прийти к пониманию, которое выражается в виде модели. Неважно как представлена модель: в виде диаграммы, текста, таблиц, всё равно это модель. Модели бываю разные: модель проблемы, решения, предметной области, модель бизнеса, модель системы, разные модели. И статья целиком состоит из моделей, где будет использоваться простой вымышленный случай, когда потребовалось создание системы. Клиент: Пекарня ООО Три яблока, которая специализируются на производстве выпечки с начинкой из яблок. Заказ: Информационная система поддержки нового продукта пекарни на всех этапах жизненного цикла продукта. Итак, допустим бизнес-аналитики собрали все бизнес-требования, описали все бизнес-процессы. Системные аналитики описали модель данных и процессы на системном уровне. А разработчики реализовали систему по этим описаниям. Тестировщики тоже отработали, критических багов нет. А клиент говорит: Это не то, что нужно! Давай разбираться, где что-то в анализе могло пойти не так. Нас интересует только проблемы анализа.

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

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

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

• Модели не соответствует решаемой задаче аналитика.

• Модели не согласованы внутри себя.

• Модели не согласованы между собой.

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

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

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

Еще один способ движение точек зрения навстречу друг другу:
сверху вниз вовлечение пользователей в процесс разработки;
снизу вверх вовлечение разработчиков в обсуждение задач и проблем бизнеса.

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

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

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

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

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

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

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

А что есть модель? Что описывают модели? Если убрать из рассмотрения парадигмы, то в сухом остатке (исходные, базовые, основные) модели описывают, как субъект выполняет действие над объектом, или субъект взаимодействует с другим субъектом. Дополнительными моделями и элементами моделей могут выступать события, интерфейсы и состояния.

Но основой, вокруг которой всё строится это: субъект, действие, объект. При этом без разницы в каком виде построена модель: BPMN, Use case или UML Диаграмма последовательности. Всё равно, это модель как субъект выполняет действие над объектом, или субъект взаимодействует с другим субъектом.

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

Напомню проблемы, которые нужно решить:

• Модели не согласованы внутри себя.

• Модели не согласованы между собой.

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

Есть еще одна проблема, которую я указал в начале доклада:

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

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

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

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

Если подходить напрямую, то вероятнее всего вы попробуете построить верхеуровневую модель бизнеса. Поискав различные представления, скорее всего найдете Business Model Canvas Александра Остервальдера. И в этом табличном представление обнаружите элементы, которые могут оказать непривычными, если до это вы описывали только операционную деятельность организации. Вы можете попробовать использовать Архитектурные фреймворки, BIZBOK или TOGAF. Но без конкретных примеров они представляют собой теоретические абстракции. По моему мнению, сложность в том, что они созданы не для того, чтобы кого-то научить, они нужны для тех, кто уже знает и понимает, и хочет систематизировать знания.

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

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

И с этим выводом формируется Краеугольный камень анализа:
1) Модели на всех уровнях абстракции должны представить собой систему.
2) Назначение элементов системы определяет система.
3) Назначение самой системы находится на вышестоящем уровне абстракций. То есть его определяет вышестоящая система (экосистемы).

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

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

Есть еще технические приемы. Как много вы думали над тем, почему часть User Story после слова чтобы очень тяжело написать? И почему критерии INVEST именно такие?

Шаблон User Story:

Как <субъект>, я хочу/могу <выполнить деятельность или получить объект>, чтобы <зачем или почему>.

INVEST критерии хорошей User Story:

Independent независимая от других историй;
Negotiable обсуждаемая, отражает суть, а не детали;
Valuable ценная для клиентов, бизнеса и стейкхолдеров;
Estimable оцениваемая по сложности и трудозатратам;
Small компактная, может быть сделана командой за одну итерацию;
Testable тестируемая, имеет критерии приемки.

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

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

Для проработки вопроса назначения и ограничений вместе с Agile подходом можно использовать дополнительные методики: Дизайн мышление, Impact mapping и JTBD. Все они хорошие, рекомендую попробовать практиковать. Но тут есть большое НО это не будет работать, если у вас команда неопытных аналитиков. Несмотря на кажущуюся легкость и заявленную опору на простой здравый смысл использовать Agile могут только квалифицированных специалисты с достаточным опытом. Потому что Agile игнорирует уровни абстракций. А в Scrum, по идее, вообще нет аналитиков, есть кроссфункциональная команда, которая работает, не обращая внимание на уровни абстракции.

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

А есть ли более строгий, аналитический способ понять назначение и ограничения?

Этому будут посвящена вторая часть статьи.

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

В 7й версии PMBok наметился уход от последовательных процессов к гибким и некоторое заимствование принципов Agile

Как видим, очень похоже на то, как если бы в 6ю версию PMBoK guide добавили принципы Agile. Тем не менее, PMBoK все еще остается последовательным фреймворком, в отличие от цикличного Scrum.

Изначально кажется, что проще всего использовать PMBoK. Возможно, так оно и есть. Но какие недостатки такого подхода для разработки электроники?

Основной заключается в том, что мы должны выполнить достаточно большую подготовительную работу по написанию требований, технического задания, описать все необходимые функции (эпики) и т.п. Чаще всего, каждая дополнительная функция в разработке hardware это в первую очередь дополнительная цена в изделии, дополнительная цена и время разработки. Наоборот, не включив нужный функционал в наше итоговое изделие мы рискуем потерять потенциального Заказчика. Поэтому в большинстве спорных ситуаций конечно мы получаем достаточно раздутый функционал и увеличение сроков разработки. Кроме того, необходимость дополнительного функционала очень часто всплывает и в процессе самой разработки. Пример: разветвление слотов PCI Express требует также и разветвления USB, поскольку они содержатся в PCIe стандарте. А это также увеличивает сроки разработки и итоговую стоимость продукта.

К чему в итоге это приводит? И приводит к тому, что мы рискуем получить идеальный (с точки зрения первоначального ТЗ), но в эти сроки уже мало кому нужный продукт.

В этом плане Scrum кажется такой волшебной таблеткой, которая исключить лишние итерации из процесса разработки продукта (product backlog). Но и здесь, особенно в России, мы наталкиваемся на определённые препятствия:

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

• Цикл разработки простой многослойной платы составляет более 4 недель. Давайте посчитаем. Предположим, разработка всех схем заняла одну неделю. Самый длительный процесс изготовление печатных плат. Например изготовление High Tech печатных плат в Резонит занимает обычно 20-25 дней. Плюс 1 неделя на проверку продукта. Итого 5 недель, из которых только первая это непосредственно разработка. Поэтому мы получаем результат только через эти 5 недель. Конечно, 5 недель тоже допустимо, но все равно это намного больше рекомендованных 1-4 недель.

Поэтому наш ответ Канбан, с цикличными включениями от Scrum.

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

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

Следующий шаг сборка mvp (minimum viable product), или минимально функциональный коммерческий продукт. После этой стадии уже можно переходить к шагу оптимизации и DFM. При наличии такого запроса, одновременно с сертификацией, запуском mvp в производство и в дальнейшем поддержкой добавляем функциональные блоки и создаем новые ревизии или SKU продукта.

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

Для решения данной сложной задачи, была предложена программа, которая включает в себя 4 этапа:

1. Оценка готовности производственных подразделений к трансформации

2. Разработка этапов трансформации

3. Разработка механизмов трансформации

4. Разработка ценностной модели обоснования трансформации

Для реализации первого этапа, я разработал программу оценки готовности, которая состоит из следующих частей:

1. Понимание и применение фреймворка SCRUM

2. Разработка и поставка продукта

3. Гибкое управление продуктовыми направлениями

4. Развитие продуктовых команд

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

Философия эмпиризма

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

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

Культурные ценности

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

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

Команда как функциональная единица

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

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

[14 - 20] - средний результат, характеризующий наличие команды как класса, но существуют определенные ограничения для полного раскрытия потенциала. Необходимо определить проблемные характеристики для улучшения и разработать мероприятия. Допускается применение мероприятий без общей программы.

[17 - 20] - высокий результат, характеризующий наличие самодостаточной организационной единицы производства инкремента продукта, признанной на уровне организации. При данном результате, рекомендуется сделать акцент на мероприятиях направленные на управление продуктом, непрерывное обеспечение качества и CI/CD, как вектор роста команды

События

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

• кто должен коммуницировать?

• когда должен коммуницировать?

• с какой целью должен коммуницировать?

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

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

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

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

Артефакты

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

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

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

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

[ 0 - 9 ] - низкий результат, характеризующий сложность существующих подходов в части управления и планирования содержанием работ. Данная сложность может быть причиной увеличения времени ожидания ответа на запрос внутри команды, а также причиной низкой концентрацией на актуальных задачах.

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

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

Критерии завершенности

Список критериев завершенности (далее DoD, от английского definition of done) является формальным чек-листом для принятия решения о выпуске инкремента. Критерии определяются стандартами организации или в случае если они отсутствуют, то команда сама должна определить список DoD. По мере развития команды, список критериев завершенности будет развиваться параллельно улучшению качества выпускаемого инкремента.

[ 0 - 31] - низкий результат, характеризующий отсутствие системы критериев завершенности, как механизма принятия решения о выпуске инкремента продукта. Для данного кейса свойственен иррациональный критерий - наступление даты релиза. Рекомендуется разработать комплексную программу внедрения критериев завершенности в минимальном составе. По мере того, как критерии будут приобретать рутинный характер, можно рассмотреть внедрение новых для улучшения качества выпускаемого инкремента.

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

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

Масштабирование

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

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

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

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

• Архитектура - механизм, который регулирует способ управления и развития архитектуры. Первый способ - монолитная архитектура, второй способ - микросервисный монолит, третий способ - микросервисная архитектура, четвертый способ - оркестратор бизнес процессов.

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

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

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

Остальные части программы оценки готовности к трансформации:
SCRUM: Понимание и применение фреймворка
SCRUM: Разработка и поставка продукта
SCRUM: Гибкое управление продуктовыми направлениями

Фасилитация встреч и мероприятий

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

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

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

Методы развития продуктовых команд

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

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

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

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

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

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

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

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

[21 - 25] - высокий результат, характеризующий зрелую систему развития и поддержки продуктовых команд. В арсенале компании имеются все доступные методы для формирования у сотрудников необходимого проактивного паттерна отношения к труду, новых навыков и знаний. При данном результате, компания осознаёт необходимость инвестицией в человеческий ресурс, так как он является потенциалом роста продуктовых направлений. Рекомендуется рассмотреть создание образовательного комплекса (аналоги GeekBrains, SkillFactory и т.д.) в периметре компании в целях становления и развития кадрового резерва.

Стили управления

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

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

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

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

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

Термин бережливого производства (Lean) в настоящее время на слуху. Мы все знаем результаты применения данной идеи в компании Toyota, которые позволили выпускать малые партии комплектующих точно в срок (Just-In-Time, JIT).

В книге Microsoft Secrets (1995 года) авторы (Кузумано и Ричард Селби) описали подходы контроля качества схожие с Lean применяемым в Toyota.

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

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

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

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

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

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

Отправная точка

Изначально в команде применялась несколько упрощенная методология Scrum. Ниже приведу ее описание.

Набор артефактов:

1. Project backlog журнал требований, реализуемых в рамках проекта, обнаруженные в процессе эксплуатации инциденты. Обычно требования оформляются в виде User Story. В качестве инструмента для верхнеуровневого планирования использовали Excel. Там же, для удобства, чтобы все было в одном месте, на отдельной странице сделали диаграмму Ганта и диаграмму сгорания.

2. Sprint backlog журнал требований и инцидентов реализуемых за спринт.

3. Scrum-доска. В качестве инструмента использовали доску Trello с расширением Plus For Trello для контроля трудоемкости.

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

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

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

3. Команда разработчиков состоит из опытных разработчиков и новичков, которые повышают свои компетенции в процессе участия на проекте.

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

Совещания:

1. Ежедневный митинг команды.

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

3. Ежеквартальные ретроспективы.

Параметры спринта:

1. Продолжительность: 1 месяц.

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

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

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

Хьюстон, у нас проблемы

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

Для исправления ситуации было решено провести экстренную ретроспективу и собрать все существующие проблемы.

Удалось выявить следующие точки улучшения:

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

2. Недостаточное качество итогового кода, требуется повысить контроль качества.

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

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

5. Много времени уходит на разработку и доработку, консультанты простаивают.

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

А что думает заказчик? Заказчик недоволен динамикой реализации требований. Но готов рассмотреть вариант с четким и прогнозируемым планом.

Именно в этот момент появилась идея использовать подход JIT для улучшения текущей ситуации.

Какие преимущества Agile-Lean мы попробуем использовать в нашем проекте

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

Сильные стороны:

1. Получение результата в ограниченное время.

2. Устранение ненужных действий, которые могут снизить стоимость.

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

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

Слабые стороны:

1. Большие требования к вовлеченности команды в процесс.

2. Строгая документация, что несколько противоречит принципам Agile, когда продукт важнее документации.

3. Необходимость детального планирования перед каждым спринтом.

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

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

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

Адаптируем 7 принципов Lean

Согласно методологии Lean для разработки программных продуктов, выделяется 7 основных принципов:

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

• Акцент на обучении. Короткие циклы разработки, раннее тестирование, частая обратная связь с заказчиком.

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

• Предельно быстрая доставка заказчику. Короткие итерации.

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

• Интегрирование. Передать целостную информацию заказчику. Стремиться к целостной архитектуре. Рефакторинг.

• Целостное видение. Стандартизация, установление отношений между разработчиками. Разделение разработчиками принципов бережливости. Мыслить широко, делать быстро, ошибаться мало; учиться стремительно.

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

1. Убрать ненужное

Под ненужным будем понимать следующее:

1. Все, что не приносит пользы конечным пользователям. Сюда относятся непонятные и несрочные требования, редко проявляющиеся дефекты. Мы их откладываем или отказываемся вовсе после согласования с заказчиком.

2. Ненужный код, дублирование кода.

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

4. Программные дефекты. Любые дефекты появляются, когда код не проходит достаточную проверку качества.

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

Что мы сделали, чтобы решить задачу:

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

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

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

4. Формирование задач из набора требований в рамках одного реализуемого процесса. Расчет: разработчик загружен на одну задачу не менее 8 часов.

2. Создавать знания и обмениваться ими

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

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

3. Повышение качества кода

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

Для повышения качества были приняты следующие предложения:

1. Парное программирование. Непосредственное взаимодействие тимлида с разработчиками, совместный анализ требований, проектирование, решение сложных задач.

2. Степень готовности (Definition of Done, DoD). Задача считается завершенной только в том случае, когда разработчик обсудил реализацию с тимлидом и провел демонстрацию разработанной функциональности консультанту, который закреплен за данной задачей.

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

4. Сокращение спринтов

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

Поэтому решили сделать ряд ограничений на спринт:

1. Спринт длится 1 рабочую неделю.

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

3. Все реализованные доработки тестируются на специальной копии продуктивной системы с продуктивными данными (PreProd), и только после успешной проверки публикуются на продуктивную среду (Prod).

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

5. После каждого спринта собирается сокращенная ретроспектива на 30 минут для сбора фидбека с команды.

5. Расширение полномочий команды

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

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

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

6. Не торопиться с принятием решений

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

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

7. Регулярная оптимизация процесса

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

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

Для реализации данного принципа с тимлида команды разработки были сняты все задачи по разработке и переданы команде, объем задач на спринт был сокращен, т.к. команда разработки фактически ослабла.

Тимлид команды теперь выступает в качестве наставника:

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

2. Инициирует передачу опыта между разработчиками.

3. Помогает консультантам в формировании требований, а разработчикам в реализации этих требований.

4. Занимается развитием разработчиков и расширением их компетенций.

5. Занимается подбором и развитием инструментария, повышающего эффективность процесса разработки.

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

Основная проблема бережливого производства отодвигание сроков

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

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

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

Итоги

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

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

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

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

1. Обеспечить единую общую среду общения и обмена знаниями.

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

3. Не пренебрегать неформальным общением.

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

По итогам внедрения Lean получили следующие количественные изменения:

1. Скорость разработки стала прогнозируемой и составила примерно 4 крупные задачи (до 6 часов на задачу в среднем) на сотрудника в неделю, ранее мощность команды в среднем составляла до 2-3 завершенных задач в неделю на сотрудника. Да, задачи крупные и это не совсем по Agile, но это помогло в нашей ситуации.

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

3. Уменьшилось вдвое количество задач, возвращаемых на доработку.

4. Еженедельно закрывалось по 3 крупные задачи из техдолга.

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

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

Спасибо за внимание, коллеги! Хотелось бы увидеть в комментариях ваш опыт использования Agile-Lean (или их адаптации) на ваших проектах.

Перевод подготовлен в рамках скорого старта курса "Enterprise Architect".

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

Слишком много проектов, инициированных традиционными предприятиями, не могут дать значимых бизнес-результатов в разумные сроки. Проведенный в 2018 году опрос Gartner показал, что 90% руководителей компаний считают цифровые технологии своим главным приоритетом, но при этом 83% руководителей затрудняются добиться значимого прогресса в цифровой трансформации.

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

Boston Consulting Group выделяет три основные причины провала крупных инициатив по трансформации бизнеса:

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

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

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

Вовлечение enterprise architecture в agile-проекты

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

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

Стратегия и тактика

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

7 преимуществ использования архитектуры в проектах цифровой трансформации

1. Лучшая согласование ваших agile-проектов со стратегиями и тактиками компании,

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

3. Оптимальное планирование и управление производственными мощностями и ресурсами для реализации Agile-проектов,

4. Лучшее взаимопонимание между agile-командами, чтобы избежать дублирования проектов,

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

6. Превосходная вовлеченность сотрудников и

7. Улучшенная отчетность и аналитика в реальном времени для точной настройки процесса принятия решений.

Финансовая система и определение приоритетов

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

Планирования проекта

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

Проверки выполнения проекта

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

Показатели успеха

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

Архитектура и SAFe

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

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

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

Подробнее о цифровой трансформации:

• 7 secrets for getting digital transformation right

• Digital KPIs: Your keys to measuring digital transformation success

• 6 hot digital transformation trends and 4 going cold

• 4 things successful CIOs know about digital transformation

• What is digital transformation? A necessary disruption

• 12 reasons why digital transformations fail

Также к прочтению:

• IT leaders re-evaluate skillsets for the long haul

• 7 IT hiring trends for 2021

• 13 most difficult-to-fill IT jobs

• CEO directives: Top 10 initiatives for IT leaders

• 10 technologies that will disrupt business in 2021

• 7 management books every CIO must read

• 7 business skills every IT leader needs to succeed

• 10 most misused buzzwords in IT

• Top IT spending priorities for 2021

• Top 5 strategic priorities for IT leaders in 2021

• CIO resumes: 9 best practices and 8 strong examples

Узнать подробнее о курсе "Enterprise Architect"

Смотреть вебинар Прошлое, настоящее и будущее: роли архитектора предприятия

Перевод материала подготовлен в рамках курса "Enterprise Architect".

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

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

Использовать Agile

Agile это не методология; это образ мышления, который вы можете применить в своей жизни и в своем способе ведения бизнеса. Agile широко распространено в индустрии разработки программного обеспечения, но любая отрасль может использовать и извлекать выгоду из образа мышления agile. Для меня использование Agile это реализация определенного поведения или способов ведения бизнеса на основе четырех ценностей и двенадцати принципов (Agile Manifesto). Таким образом, один из способов использовать Agile это реализовать фреймворки или методы, которые очень эффективны для организации, совместной работы и определения приоритетов задач и рабочих процессов в команде, такие как Scrum или Kanban.

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

Быть Agile

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

Почему быть Agile так сложно

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

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

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

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

Простое решение

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

Как менеджер, вы должны принять влияние agile на разработку. Вы не можете просить команду использовать Kanban, имея двухлетний план фич, которые команда должна разработать. Вместо этого было бы лучше, если бы вы приняли образ мышления ученика. Как говорит Джефф Готельф, вы создаете бесконечный продукт. Продукт, который постоянно развивается вместе с рынком, и вы не можете знать, что рынок захочет через два года. Образ мышления ученика подразумевает многократные пробы и обучение (на неудачах).

Во-вторых, пробовать и учиться сложно, если вы не создаете психологической безопасности для своей команды, чтобы исследовать неизвестное. Это новый способ руководства, при котором лидерам необходимо уметь вести важные беседы, чтобы понять, что означает неудача для каждого члена его/ее команды. Лучший способ стимулировать это - сместить поощрение с быстрых результатов на быстрые циклы обучения. Ретроспективы и самоанализ имеют решающее значение, но не сосредоточены только на технических вопросах. Изучите индивидуальное взгляды членов команды. Можно начать с простого вопроса: как вы себя чувствовали во время эксперимента?

Наконец, как лидеру, вам необходимо сформировать общее видение, в котором все понимают, что строка кода влияет на рентабельность инвестиций компании. Вы должны быть последовательны и соответствовать желаемым результатам. Иметь четкие цели и ключевые результаты (OKR - objectives and key results) это нормально, но они должны быть сосредоточены на изменении поведения клиентов.

Заключение

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

Узнать больше о курсе "Enterprise Architect".

Смотреть открытый урок Прошлое, настоящее и будущее роли архитектора предприятия.

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

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

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

Опросы

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

Еженедельный опрос

В конце каждой недели мы получаем опросник на 30 секунд с вопросами: как часто у вас не было сил выполнять работу? Получал ли удовольствие от задачи? Сколько часов переработал? На выходе мы строим график для всей команды в динамике за последние 6 недель и обсуждаем на ретроспективе.

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

Опрос в конце спринта

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

Опросы раздражают

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

Мотивация

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

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

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

Боли (от выполнения ручной/неудобной работы)

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

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

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

• Опять же посмотреть в Jira и рассмотреть что мы можем делать лишнего, или что уже не актуально и можно упразднить. Например, мы рассматривали релиз-тикеты и пытались понять какие моменты мы можем делать быстрее. Так мы обнаружили, что security scan кода занимал по 20-30 минут, мы подумали, что можно делать всё проще и в итоге сейчас это занимает около 5-10 минут.

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

В результате у нас всё задокументировано в Jira в эпиках (с чем мы уже можем прийти к PO для обсуждения включения этих улучшений в дорожную карту на следующий квартал), у нас уже есть правило, что 10% времени в спринте каждый тратит на развитие своих навыков, и у нас уже был план кто и что будет изучать. В нашей компании у всех есть доступ к обучающим курсам на разных площадках, поэтому вопрос самообучения был решён автоматически, но мы договорились о следующем:

• Изучение будет происходить в паре/тройке. Так и интересней, и если кто-то уйдёт в отпуск - работа не встанет.

• Пары/тройки будут меняться в будущем. Чтобы команда не дробилась на небольшие "кружки по интересам" и оставалась одной командой.

• Внутри пары/тройки нет ограничений на источник обучения. Кому-то могут нравиться курсы с LinkedIn, кому-то с Udemy, а кто-то вообще нашёл крутой разбор темы на YouTube на своём родном языке.

Больше болтовни

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

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

Также мы заметили, что когда люди включают web-камеру - они более искренне и более разговорчивы. Если вся команда не разговорчива, мы просто используем Wheel Of Names и там уже рандомом выбираем кто будет говорить.

Фидбеки

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

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

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

• Кастомеры задавали вопросы на одни и те же сообщения в логе. Суть в том, что в логе мы печатали что-то вроде "Module: service XXX call, RC = Y, RSN = ZZ". Т.к. это вообще не понятно никому, L2 выстраивали у себя сводную таблицу таких сообщений, чтобы отвечать кастомерам. Если какая-то новая комбинация - то это шло дальше в L3 (к разработчикам). Решением было простым: мы просто написали функцию которая по кодам печатает user-friendly сообщения с полным описанием причины проблемы.

• Кастомеры находили уже пофикшенные баги. С каждым релизом мы не так много внимания уделяли описанию проблем. В итоге, когда пользователь встречал баг, он открывал описания выпущенных релизов и искал там свою проблему - разумеется он там ничего не находил и писал в саппорт. Ребятам из L2 приходилось лезть в нашу Jira и они пытались найти баги, похожие на кастомерские. Решение банально - мы стали лучше описывать баги с их симптомами в релизах. Кастомеры стали меньше писать в саппорт, т.к. находили свои баги в описаниях релизов, а если уж и открывалось, L2 на них почти всегда могли ответить самостоятельно и быстро.

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

Ежедневный отчёт

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

Я хочу ещё раз подчеркнуть, что этот "отчёт" - был создан внутри команды для нас самих же и не занимает больше 5 минут в день для его поддержания.

Свои метрики

Внутри команды у нас есть свои метрики. Некоторые пересекаются с менеджерскими, некоторые уникальны.

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

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

Мы используем и другие метрики, включая самые очевидные: процент покрытия кода юнит-тестами, покрытие QA тестами функционала продукта, время жизни пулл-ревквеста или velocity команды.

Больше правил

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

Можно долго спорить и ругаться, например, что лучше: табы или пробелы, можно назначать митинги для их обсуждения, создавать новые чаты, ругаться в пулл-реквестах, а можно просто написать правило "только пробелы" и просто следовать ему. Кто-то будет недоволен, но теперь это правило, и его не обсуждают, ему просто следуют. Поэтому, рекомендую задокументировать всё, что связано с правилами написания кода. А ещё лучше, посоветовать команде почитать какой-нибудь Code Complete, чтобы разработчики (особенно начинающие) имели представление откуда эти правила берутся.

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

Также, правила должны подвергаться пересмотру. Например, в какой-то момент времени у нас случилось несколько кастомерских проблем из-за релиза, баги в котором могли быть замечены аж на трёх этапах: Разработка (code review), Просмотр билда разработчиками, и уже QA. На всех трёх этапах можно было предотвратить ошибку. Разумеется, после этого инцидента все этапы были ужесточены. В итоге то, что раньше могло занимать до 5 дней, стало занимать до 10 дней. Со временем все ужесточения были пересмотрены. Некоторые до сих пор остались, просто был изменён процесс чтобы действие занимало меньше времени, что-то было упразднено, а что-то наоборот добавилось.

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

Ответственность на всех

В нашей команде мы стараемся играть в "трёх мушкетёров", т.е. ответственность за всё лежит на ВСЕЙ команде, никто не будет осуждать члена команды вне команды. Если кто-то один облажался и это привело к каким-то последствиям, то всё равно виноваты все, потому что:

• Плохие вещи случаются. Нельзя запланировать и предвидеть всё.

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

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

• Обвинения не решают проблем. Вообще никаких.

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

• Женщину, которая в полной темноте переходила дорогу в неположенном месте?

• Водителя автомобиля с автопилотом, который вряд ли сам среагировал бы?

• Компанию, которая разрабатывает автопилот?

• Разработчиков, кто писал код для автопилота?

• QA кто выпустил этот код в прод?

Субъективно, тут виноваты все, либо никто. Но, очевидно, что виновные есть, т.к. в итоге женщина скончалась. Значит виноваты все.

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

Team Building

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

Заключение

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

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

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

Так почему бы не автоматизировать этот процесс? Идея проста: написать что-нибудь, что может опрашивать каждого человека о рабочем дне. Желательно, чтобы это что-нибудь обладало голосом. Мой выбор пал на Алису, поскольку при помощи станции в переговорке вполне можно провести стендап.

Так я написал навык Проведи стендап.

О навыке

Возможности

• Добавление/удаление людей из команды. Какой стендап без команды? Для того, чтобы навык знал о составе вашей команды, есть фразы: Добавь в команду ИМЯ [ФАМИЛИЯ], Удали из команды ИМЯ [ФАМИЛИЯ] и дополнительная фраза Добавь в команду человека ИМЯ [ФАМИЛИЯ]. Зачем нужна ещё одна фраза будет описано в разделе про интенты. Достаточно сделать это один раз - информация о команде сохранится.

• Собственно, проведение стендапа. После того как вы добавили всю свою команду, можно начать стендап, сказав начни стендап. Навык будет по очереди предлагать каждому выступить и рассказать о своём дне. После того как навык услышит фразу у меня всё/конец/я закончил, он вызовет следующего участника. Также можно пропустить участника, сообщив его/её нет или он/она отсутствует.

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

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

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

Разработка

Сам по себе навык - простой веб сервер с одним обработчиком, куда поступают все запросы с репликами пользователей. Я реализовал этот сервер на питоне через Flask. В качестве базы данных была выбрана PostgreSQL.

Хотелось бы отметить 2 возможности, которые Яндекс предоставляет для навыков:

Интенты

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

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

Авторизация

Яндекс.Диалоги предоставляют возможность авторизации через навык в сторонних сервисах, поддерживающих OAuth. Однако по неизвестным причинам прикрутить авторизацию в гитхабе у меня не получилось, и поддержка не смогла помочь с поиском проблемы. В итоге авторизация в гитхабе проходит через Github App. Чтобы она работала, нужно установить приложение в свой репозиторий, и тогда авторизация и работа с гитхабом идут уже от лица приложения. С трекером Яндекса вышло проще - OAuth авторизация заработала без проблем. Но есть один минус - OAuth авторизация поддерживается максимум только для одного сервиса. (Поэтому, если бы получилось сделать авторизацию для гитхаба, пришлось бы делать костыли для авторизации в трекере).

Итоги

С исполнением такой простой задачи, как вызов участников, Алиса справляется успешно, голосовой интерфейс удачно вписывается в стендапы.

Репозиторий

Навык