Блог - The Improved Methods

[https://facebook.com/tim.com.ua] The Improved Methods Обучение Agile методам, Agile трансформация компаний, консультации Обо мне Услуги Обучение Видео-курс “Agile своими силами” Внедрение и трансформация Масштабирование Agile Отзывы Блог Наши проекты Scrum Card Game Мероприятия Будущие мероприятия Контакты Search Блог Весенний бум мероприятий: Agile Fundamentals, Leading SAFe, ScrumDayUA, AgileEE и IT Spring Tim Yevgrashyn 08/03/201711/10/2020 Обо всем , Управление проектами Радует, что сегодня можно много куда ÑÑ Ð¾Ð´Ð¸Ñ‚ÑŒ и много чему поучиться. Выбирайте на свой вкус:) Начну со ÑÐ²Ð¾Ð¸Ñ Ñ‚Ñ€ÐµÐ½Ð¸Ð½Ð³Ð¾Ð²: 24-25 марта 2017 года в Киеве проведу Agile Fundamentals. Программа тренинга аккредитована International Consortium for Agile (ICAgile) . Курс рассчитан на Ñ‚ÐµÑ , кто мало знаком с принципами гибкой разработки, либо желает структурировать свои знания. По окончании тренинга участники получают именной сертификат ICAgile Certified Professional (ICP), который признается во всем мире. Детали, программа и регистрация здесь. И конечно же, промокод TIM дает возможность 10% скидки:) 26-27 марта 2017 года все в том же Киеве проведу Leading SAFe  (Scaled Agile Framework). Это открытый сертификационный курс Leading SAFe , в котором мы детально изучим один из ÑÐ°Ð¼Ñ‹Ñ Ð¿Ð¾Ð¿ÑƒÐ»ÑÑ€Ð½Ñ‹Ñ Ñ„Ñ€ÐµÐ¹Ð¼Ð²Ð¾Ñ€ÐºÐ¾Ð² для масштабирования компании с помощью Agile – Scaled Agile Framework . Детали, программа и регистрация здесь. И тут тоже промокод TIM дает возможность 10% скидки:) Теперь по поводу конференций: 11 марта 2017 года  в Киеве пройдет конференция  ScrumDayUA , название   говорит само за себя: много Ð¸Ð½Ñ‚ÐµÑ€ÐµÑÐ½Ñ‹Ñ Ð´Ð¾ÐºÐ»Ð°Ð´Ð¾Ð² и докладчиков. Если вы еще не решились, то поторопитесь, тем более что есть промокод ScrumTim на 10% скидки. 7-8 апреля 2017 года  в Киеве Международная конференция Agile Eastern Europe. Esse quam videri — “Быть, а не казаться” — лозунг Восьмого сезона конференции AgileEE. Организаторы  уверены, чтобы по-настоящему быть Agile, а не казаться, Ð½ÐµÐ¾Ð±Ñ Ð¾Ð´Ð¸Ð¼ прорыв. Очень рекомендую посетить конференцию.  Зарегистрируйтесь на конференцию по промокоду 55YWXS5WPM1H и получите скидку 5% 28-29 апреля  2017 года уже в Минске (Беларусь) пройдет международная конференция о лидерстве и менеджменте — IT Spring 2017 .  Это крупнейшая международная конференция, посвященная IT-бизнесу, которая однозначно стоит посещения! Упражнение для обсуждения ролей в Scrum или другом Agile-методе Tim Yevgrashyn 30/11/201630/11/2016 Управление проектами Для принятия “культуры Agile” важны понимание ролей и ÑƒÑ Ð¾Ð´ от должностей. В книге, о которой я писал раньше , Джеф Сазерленд рассказывает о своей первой Scrum-команде. Трансформация началась с того, что Джеф сказал им: “Порвите свои визитки”. Все практикующие “аджалисты” ÑÑ Ð¾Ð´ÑÑ‚ÑÑ в том, что в Agile-методе важны роли – как наборы обязанностей, ответственностей и практик. Для Ð¼Ð½Ð¾Ð³Ð¸Ñ ÐºÐ¾Ð¼Ð°Ð½Ð´ Ð¿ÐµÑ€ÐµÑ Ð¾Ð´ к Scrum (или к другой методологии из семейства Agile Software Development) начинается с определения того, кто и что делает, и за что отвечает. Понимание и обсуждение ролей всегда было частью Ð¼Ð¾Ð¸Ñ Ð¿ÑƒÐ±Ð»Ð¸Ñ‡Ð½Ñ‹Ñ Ð¸ ÐºÐ¾Ð¼Ð°Ð½Ð´Ð½Ñ‹Ñ Ñ‚Ñ€ÐµÐ½Ð¸Ð½Ð³Ð¾Ð². Сейчас я готовлю серию постов о создании Agile-тренинга для команды , и в результате опубликую готовый шаблон такого тренинга, поэтому расскажу об этом упражнении подробнее. Самое простое, что Ð¿Ñ€Ð¸Ñ Ð¾Ð´Ð¸Ñ‚ на ум для обсуждения ролей – сортировка терминов. В итоге Ð¼ÐµÑ Ð°Ð½Ð¸Ð·Ð¼ упражнения (или “игры”) предельно прост: участники делятся на группы по 2-4 человека и сортируют пачку терминов, которые относятся к ролям Scrum (в Scrum Ð¸Ñ 3, но вы можете ввести Ð½ÐµÐ¾Ð±Ñ Ð¾Ð´Ð¸Ð¼Ð¾Ðµ вам количество ролей). После работы в Ð³Ñ€ÑƒÐ¿Ð¿Ð°Ñ Ð¼Ð°Ñ‚ÐµÑ€Ð¸Ð°Ð» лучше закрепить общим обсуждением и уточнением, чтобы не было ошибок в понимании и разницы в трактовке. Я называют это “игра в бинго”. Мы берем одну роль, и каждая группа по очереди называет термин, который она отнесла к ней. Если остальные группы тоже отнесли термин к этой роли, они кричат “бинго”. Если нет – начинается обсуждение. Именно за обсуждения я и люблю это упражнение – в Ð½Ð¸Ñ Ð¼Ñ‹ проясняем понимание и углубляемся в аспекты той или иной практики, принципа или концепции.  Даже если у вашей группы достаточно опыта и Ñ€Ð°ÑÑ Ð¾Ð¶Ð´ÐµÐ½Ð¸Ð¹ в сортировке терминов нет, просите участников привести практические примеры. Так вы можете проверить Ð¸Ñ Ð·Ð½Ð°Ð½Ð¸Ñ более глубоко. Но где взять термины? Долгое время я использовал набор фраз, которые составил вместе с моими коллегами-консультантами. Но они были не совсем понятны участникам. С Ñ‚ÐµÑ Ð¿Ð¾Ñ€, как я узнал про Agile Topic Cards , я заменил фразы карточками, и все стало работать во много раз лучше! Как вы помните (или можете прочитать), Agile Topic Cards представляют собой карточки, на ÐºÐ¾Ñ‚Ð¾Ñ€Ñ‹Ñ Ð½Ð°Ñ€Ð¸ÑÐ¾Ð²Ð°Ð½Ñ‹ Agile-термины. Зеленые – это практики, синие – принципы, а красные – концепции. Из 166 карточек можно выбрать любое количество, которое покажется вам Ð½ÐµÐ¾Ð±Ñ Ð¾Ð´Ð¸Ð¼Ñ‹Ð¼ для дискуссии. Лично я выбрал следующие номера: 2 – Definition of Done По моему мнению, это ответственность команды, Ñ Ð¾Ñ‚Ñ Scrum-мастер может отвечать за внедрение и поддержку этого внутреннего договора. 3 – Vision 9 – User Story 10 – Backlog Имеется в виду Product/Project Backlog, за которые отвечает Владелец Продукта. 11 – Trade Offs Для меня это – договоренности и компромиссы, ÐºÐ¾Ñ‚Ð¾Ñ€Ñ‹Ñ Ð’Ð»Ð°Ð´ÐµÐ»ÐµÑ† Продукта достигает между бизнесом и командой, но всегда можно обсудить, как это понимаете вы. 14 – Team Performance (Velocity и другие) 25 – 1:1s 26 – Vertical Slice Это – Ñ Ð¸Ñ‚Ñ€Ð°Ñ карточка. Прежде всего имеется в виду, что Владелец Продукта должен мыслить функциональностью (Features), а не задачами. Но также нужно, чтобы команда сфокусировалась на Ð²ÑÐµÑ Ñ‚ÐµÑ Ð½Ð¸Ñ‡ÐµÑÐºÐ¸Ñ Ð°ÑÐ¿ÐµÐºÑ‚Ð°Ñ Ð¸ делала функциональность целостной – от UI до глубин БД. Эта дискуссия может перекликаться с тем, о чем я писал в статье “ Какого цвета ваш Бэклог ”. 31 – Adaptive Planning Это ответственность Владельца Продукта. Картинка показывает движение к Цели (эта Цель – звезда, нарисованная на карточке Vision(#3)). 40 – Code Review 41 – Slicing 42 – Test Driven Development 47 – KPI’s 54 – Timebox 60 – Team Development Эта картинка означает модель развития команды Брюса Такмана: Forming-Storming-Norming-Performing. 63 – End to End testing 64 – Decision Making По-моему, это Владелец Продукта решает, чего не делать, и говорит пожеланиям “да” или “нет”. 66 – Face to Face conversation Эту картинку я трактую так: команда должна предпочитать прямое общение другим типам коммуникации. 68 – Pair Programming 69 – Autonomy Здесь подразумевается, что cross-functional-команда должна иметь достаточно автономности. 71 – Collective Code Ownership 72 – Visualization 78 – Motivation 83 – Transparency 84 – Sprint Burndown 85 – Release Burnup 86 – Forecasts and Velocity 87 – Retrospective 89 – Team dependencies 94 – Relative Estimation 95 – Poker Planning 99 – Iterative & Incremental 100 – Backlog Grooming Тут я обычно даю выбрать большинству. Иногда Владелец Продукта заинтересован в том, чтобы узнать от команды “цену” ÑÐ»ÐµÐ´ÑƒÑŽÑ‰Ð¸Ñ ÑÐ»ÐµÐ¼ÐµÐ½Ñ‚Ð¾Ð² бэклога. Иногда Scrum-мастер заинтересован в том, чтобы команда получила качественные Элементы Бэклога (PBI) до начала планирования следующего спринта. 101 – Continious Deployment 102 – Continious Delivery 104 – Clean Code 107 – Daily StandUp 111 – Demo Продемонстрировать результаты и получить обратную связь – это ответственность команды (!). Во всяком случае, в Ð½Ð¾Ñ€Ð¼Ð°Ð»ÑŒÐ½Ñ‹Ñ ÐºÐ¾Ð¼Ð¿Ð°Ð½Ð¸ÑÑ :). 114 – Risks Риски, о ÐºÐ¾Ñ‚Ð¾Ñ€Ñ‹Ñ Ð·Ð°Ð±Ð¾Ñ‚Ð¸Ñ‚ÑÑ Владелец Продукта, или менеджер, который стоит за командой и Sсrum-мастером (на картинке основные категории рисков: Бизнес, Ð¢ÐµÑ Ð½Ð¾Ð»Ð¾Ð³Ð¸Ð¸, Социальный, Дедлайны). 117 – Outcome VS Output Владелец Продукта занимается тем, что максимизирует результат (Outcome) – больше ÑÑ‡Ð°ÑÑ‚Ð»Ð¸Ð²Ñ‹Ñ Ð¿Ð¾Ð»ÑŒÐ·Ð¾Ð²Ð°Ñ‚ÐµÐ»ÐµÐ¹. 120 – Continious Integration 126 – Servant Leadership 128 – Refactoring 132 – Automated Test Checking 143 – Sprint Backlog 146 – Team Kick-off/Lift-off Это означает запуск Ð½Ð¾Ð²Ñ‹Ñ ÐºÐ¾Ð¼Ð°Ð½Ð´ или запуск нового проекта в команде. Итак, все, что нужно для этого упражнения – перемешать, не взбалтывать и разделить на три или более пачки в соответствии с ролями в вашем Agile-процессе. Приятного обсуждения! Agile Topics Cards – универсальный инструмент agile-коуча, и не только Tim Yevgrashyn 22/09/201623/09/2016 Обо всем Agile Coaching – это практическая работа с командой, которая позволяет ее членам освоить гибкие Ð¿Ð¾Ð´Ñ Ð¾Ð´Ñ‹ к разработке программного обеспечения. Но даже если вы не коуч, а руководите командой или организовываете проекты, вам нужен простой инструмент, который поможет объяснить все Ð½ÐµÐ¾Ð±Ñ Ð¾Ð´Ð¸Ð¼Ñ‹Ðµ термины и понятия. Для меня таким инструментом стали Agile Topics Cards . Это карточки с визуализацией терминов философии Agile Software Development . Ð˜Ñ Ð¿Ñ€Ð¸Ð´ÑƒÐ¼Ð°Ð» Джимми Джанлен (Jimmy Janlen) из шведской консалтинговой группы Crisp, которая уже радовала нас трудами Хенрика Книберга и Маттиаса Скарина. Всего карточек – 162. Каждая карточка содержит термин и его визуализацию. Карточки делятся на: – зеленые : практики, Ñ‚ÐµÑ Ð½Ð¸ÐºÐ¸ и инструменты; – синие : темы для обсуждения; – красные : абстрактные модели и теории. Чтобы начать работать с терминами, карточки (или Ð¸Ñ Ñ‡Ð°ÑÑ‚ÑŒ) нужно распечатать и желательно заламинировать. Только представьте количество вариантов Ð¸Ñ Ð¸ÑÐ¿Ð¾Ð»ÑŒÐ·Ð¾Ð²Ð°Ð½Ð¸Ñ! Джимми предлагает 9 Ð¿ÐµÑ€Ð²Ð¾Ð½Ð°Ñ‡Ð°Ð»ÑŒÐ½Ñ‹Ñ Ð¸Ð´ÐµÐ¹: Выбор темы для обсуждения в формате Lean Coffee . Ð’Ð´Ð¾Ñ Ð½Ð¾Ð²ÐµÐ½Ð¸Ðµ для статей в блоге (мне точно стоит попробовать! :)) Обсуждение один на один – отличный вариант для парного коучинга. Источник тем для очередной ретроспективы в команде. Личное развитие : выберите термин и за 20 минут попробуйте найти в гугле как можно больше информации на эту тему. Аудит/оценка состояния команды или организации: выберите определенные карточки и проанализируйте, знают или не знают про эти термины в команде, делают/не делают и т. п. Тема недели : выберите карточку и повесьте ее на видном месте, чтобы в течении недели побуждать обсуждение этой темы командой. Рассказ историй : произвольно выберите 4-5 карточек и рассказывайте с Ð¸Ñ Ð¿Ð¾Ð¼Ð¾Ñ‰ÑŒÑŽ истории. Короткое выступление на произвольно выбранные темы для обмена знаниями (например, во время обеда). Меня познакомили с этими карточками на моем любимом “слете коучей” Play4Agile. Там собираются такие, как я, чтобы обменяться идеями и практиками, и создать новые игры для обучения и развития команд. Конечно же, мы решили придумать как можно больше упражнений с этими карточками. Вот вам несколько Ð½Ð°ÑˆÐ¸Ñ Ð¸Ð´ÐµÐ¹: Speed Dating with Agile Topics Cards . Всем участникам раздаются выбранные карточки, и каждый по очереди рассказывает своему партнеру о том, что знает на эту тему. Затем один ряд участников сдвигается, и новые пары повторяют обсуждение. С помощью карточек можно договориться о Ð¿Ñ€Ð°ÐºÑ‚Ð¸ÐºÐ°Ñ Ð¸ Ð¿Ñ€Ð¸Ð½Ñ†Ð¸Ð¿Ð°Ñ , которые Ñ Ð¾Ñ‡ÐµÑ‚ применять вся команда. Для этого карточки делятся на три категории: Ð½ÐµÐ¾Ð±Ñ Ð¾Ð´Ð¸Ð¼Ñ‹Ðµ (Must), полезные (Should) и просто интересные (Nice to have). С помощью терминов можно обсудить ответственность и практики для каждой из ролей в команде (это упражнение стало моим любимым, и я напишу о нем отдельно). Сортировка ÑÐ²ÑÐ·Ð°Ð½Ð½Ñ‹Ñ Ñ‚ÐµÑ€Ð¼Ð¸Ð½Ð¾Ð² (Like to like). Можно складывать рядом термины, которые вы считаете связанными между собой. Получается эдакий мега-пазл. Сортировка карточек по категориям “прекратить” (Stop doing), “начать” (Start) и “продолжить” (Continue) Ñ Ð¾Ñ€Ð¾ÑˆÐ¾ подойдет для ретроспективы или просто командного обсуждения совместной работы. Можно использовать карточки как дополнение к другим играм или Ñ‚ÐµÑ Ð½Ð¸ÐºÐ°Ð¼ фасилитации. Например, к созданной с моим участием игре Nobody’s Perfect или другой, не менее интересной игре – Fearless Journey. Ну и для завершения на веселой ноте – карточки можно использовать для игры в “крокодила” . Первая команда передает игроку второй команды карточку с термином, а он должен изобразить его только знаками, без слов, или Ñ Ð¾Ñ‚Ñ бы не используя ключевые слова. Члены второй команды должны угадать, что это за термин 🙂 Хорошим дополнением к карточкам станет книжка Agile Planet . Это некий сводный словарь терминов, но кроме пиктограммы, там есть краткое пояснение. Хорошо подойдет для первичного понимания Ð½ÐµÐ·Ð½Ð°ÐºÐ¾Ð¼Ñ‹Ñ Ñ‚ÐµÑ€Ð¼Ð¸Ð½Ð¾Ð², а уже потом можно искать в интернете статьи и материалы, связанные с этими терминами. Как видите, идей можно придумать очень много. Рекомендую вам как можно скорее скачать файл с карточками и начать Ð¸Ñ Ð¸ÑÐ¿Ð¾Ð»ÑŒÐ·Ð¾Ð²Ð°Ñ‚ÑŒ. Немного анонсов: Leading SAFe в Киеве и Agile Tour Belarus Tim Yevgrashyn 13/09/201611/09/2017 Обо всем Совсем скоро пройдут два Ð²Ð°Ð¶Ð½Ñ‹Ñ Ð¼ÐµÑ€Ð¾Ð¿Ñ€Ð¸ÑÑ‚Ð¸Ñ. 23-24 сентября 2016 года в Киеве пройдет  открытый сертификационный курс Leading SAFe , в котором мы детально изучим один из ÑÐ°Ð¼Ñ‹Ñ Ð¿Ð¾Ð¿ÑƒÐ»ÑÑ€Ð½Ñ‹Ñ Ñ„Ñ€ÐµÐ¹Ð¼Ð²Ð¾Ñ€ÐºÐ¾Ð² для масштабирования компании с помощью Agile – Scaled Agile Framework. За два дня обучения будут освещены принципы и практики Scaled Agile Framework® (SAFe®) версии 4.0, что актуально для масштабирования Agile в ÐºÑ€ÑƒÐ¿Ð½Ñ‹Ñ ÐºÐ¾Ð¼Ð¿Ð°Ð½Ð¸ÑÑ , ÑÐ¾ÑÑ‚Ð¾ÑÑ‰Ð¸Ñ Ð¸Ð· множества Ð·Ð°Ð²Ð¸ÑÐ¸Ð¼Ñ‹Ñ ÐºÐ¾Ð¼Ð°Ð½Ð´ и проектов. В завершение класса участники допускаются к сдаче экзамена на сертифицированного SAFe Agilist. Как один из организаторов и тренеров этого мероприятия, добавлю, что следующий такой класс состоится не скоро, так что не упустите возможность:) Детали мероприятия на страничке в facebook . Регистрация: https://goo.gl/klWS6l 24 сентября в Минске пройдёт AgileTour Belarus 2016 — конференция о Ð³Ð¸Ð±ÐºÐ¸Ñ Ð¼ÐµÑ‚Ð¾Ð´Ð¾Ð»Ð¾Ð³Ð¸ÑÑ Ð² управлении ИТ-проектами. Здесь планируют говорить о внедрении Agile в ÐºÐ¾Ð¼Ð°Ð½Ð´Ð°Ñ Ð¸ ÐºÐ¾Ð¼Ð¿Ð°Ð½Ð¸ÑÑ , о Ð²Ð¾Ð·Ð½Ð¸ÐºÐ°ÑŽÑ‰Ð¸Ñ Ð¿Ñ€Ð¾Ð±Ð»ÐµÐ¼Ð°Ñ Ð¸ ÑÐ¿Ð¾ÑÐ¾Ð±Ð°Ñ Ð¸Ñ Ñ€ÐµÑˆÐµÐ½Ð¸Ñ. Организатор мероприятия — команда SPACE при поддержке AgileLAB, частью которого я являюсь. Конференция будет полезна руководителям компаний и менеджерам проектов, Scrum-мастерам и владельцам продуктов, разработчикам, аналитикам и тем, кто заинтересован в совершенствовании процессов разработки. Новые знания получат как опытные Agile-практики, так и новички. Стоимость — $73. Участники Ð¿Ñ€ÐµÐ´ÑÑ‚Ð¾ÑÑ‰Ð¸Ñ Ñ‚Ñ€ÐµÐ½Ð¸Ð½Ð³Ð¾Ð² о Ð³Ð¸Ð±ÐºÐ¸Ñ Ð¼ÐµÑ‚Ð¾Ð´Ð¾Ð»Ð¾Ð³Ð¸ÑÑ Ð¾Ñ‚ AgileLAB могут попасть на мероприятие бесплатно или со скидкой 50%. Приобрести билеты можно на сайте мероприятия. Ключевые доклады конференции: Lean Organization, or what’s slowing you down? Tomasz Wykowski (первый сертифицированный Scrum-тренер в Польше), расскажет, как проанализировать процессы работы над проектом и понять, насколько они результативны, и как правильно распределить время, чтобы обеспечить оперативную разработку ПО; How minions can help creating a complementary team and finding a bliss? Vladimirs Ivanovs (международный консультант и тренер из Латвии) привезет доклад о ÑÑ‚Ð°Ñ€Ñ‹Ñ Ð´Ð¾Ð±Ñ€Ñ‹Ñ Ñ€Ð¾Ð»ÑÑ Ð² команде по Адизесу с массой Ð°Ð½ÐµÐºÐ´Ð¾Ñ‚Ð¸Ñ‡Ð½Ñ‹Ñ Ð¿Ñ€Ð¸Ð¼ÐµÑ€Ð¾Ð² из реальной жизни; Lean Change Management — управляем изменениями как стартапом Алексей Пикулев (лицензированный Management 3.0 и ICAgile тренер, Польша) расскажет, как научиться действовать спланировано и обдуманно, быть осмотрительными и осторожными и доводить задуманные изменения до реализации; 5 опор команды или управленческий минимум Денис Тучин (Agile тренер, Россия) осветит типичные проблемы Agile-ретроспектив в ÑƒÑÐ»Ð¾Ð²Ð¸ÑÑ Ð¿Ñ€Ð¾Ñ†ÐµÑÑÐ° непрерывного совершенствования и расскажет, как с ними бороться. Полный список докладчиков доступен на agiletour.by, а новости конференции появляются на Facebook . Зарегистрироваться и приобрести билеты можно на сайте конференции. Две интересные книги про переговоры Tim Yevgrashyn 14/07/2016 Саморазвитие Сегодня я расскажу о Ð´Ð²ÑƒÑ ÐºÐ½Ð¸Ð³Ð°Ñ : “ Я слышу вас насквозь ” Марка Гоулстоуна и “ Договориться можно обо всем ” Гвена Кеннеди . Сначала разберемся, чем они Ñ Ð¾Ñ€Ð¾ÑˆÐ¸. Для меня, как тренера , консультанта и Agile-коуча интересна та книга, которая оказалась полезной в работе; та, которую я буду советовать и выдержки из которой можно цитировать в общении и на Ñ‚Ñ€ÐµÐ½Ð¸Ð½Ð³Ð°Ñ , иллюстрируя тот или иной пример. Более чем полвека тому назад появилось такое понятие « Индекс цитирования ». Его ввел в 1960 году Институт научной информации (основатель – Юджин Гарфилд). Хотя первые попытки индексировать количество ссылок на ту или иную публикацию предпринимались еще в 19 веке. Потом «Индекс цитирования» начали называть «Индекс Ð¸Ð½Ñ‚ÐµÑ€ÐµÑÐ½Ñ‹Ñ Ð¼Ñ‹ÑÐ»ÐµÐ¹Â». Так вот, я эти две  книги прочитал давно, а в работе они мне помогают до ÑÐ¸Ñ Ð¿Ð¾Ñ€. Я часто вспоминаю о Ð½Ð¸Ñ , привожу своим слушателям примеры из ÑÑ‚Ð¸Ñ ÐºÐ½Ð¸Ð³. Одним словом, мой личный индекс цитирования очень высокий. Гвен Кеннеди «Договориться можно обо всем» Эта книга, о Ð¿ÐµÑ€ÐµÐ³Ð¾Ð²Ð¾Ñ€Ð°Ñ , с фокусом на Ð¿Ñ€Ð¾Ð´Ð°Ð¶Ð°Ñ . Суть слов Гвена в том, что мы всегда что-то продаем: вещи, идеи, услуги – в Ð¿ÐµÑ€ÐµÐ³Ð¾Ð²Ð¾Ñ€Ð½Ñ‹Ñ Ð¾Ñ‚Ð½Ð¾ÑˆÐµÐ½Ð¸ÑÑ Ð¼Ñ‹ Ð½Ð°Ñ Ð¾Ð´Ð¸Ð¼ÑÑ почти постоянно. Книга Гвена Кеннеди очень интересна своей структурой. Автор вводит идею Ñ‡ÐµÑ‚Ñ‹Ñ€ÐµÑ Ñ‚Ð¸Ð¿Ð¾Ð² переговорщиков. И, соответственно, перед каждой главой дается некий кейс. Один из Ð½Ð¸Ñ â€“ “совы”, очень мудрые переговорщики, которые ищут оптимальное решение. Есть еще “лисы”, которые всегда отстаивают  свою выгоду. “Лисы” и “совы”, наверное, наиболее удачные переговорщики. Но совы более экологичные, потому что они ищут решение, которое будет выгодно всем. Есть также “ослы” и “бараны”. Одни не понимают, что Ð¸Ñ Ð²ÑÐµ время так или иначе обманывают на Ð¿ÐµÑ€ÐµÐ³Ð¾Ð²Ð¾Ñ€Ð°Ñ , а вторые стоят на своем, даже если они не правы. Автор говорит: «Вот такая ситуация: вы продаете или покупаете. Какое решение вы бы приняли? А, B, С, D». В конце главы он разбирает этот кейс: «Смотрите, вариант А принадлежит переговорщикам, которые упертые. Они не Ñ Ð¾Ñ‚ÑÑ‚ признавать  мнение другой стороны. Вариант С, например, может принадлежать опытным переговорщикам, которые ищут наилучшее решение», и так далее. Таким образом, эта книга фактически является тренажером, если ее читать вдумчиво, анализировать свои ответы и понимать, почему ты ответил неправильно. Навыки, описанные в издании, очень быстро закрепляются, при том, что саму книгу читать просто интересно. Свои выводы автор подкрепляет наглядными примерами из жизни. Например, почему нельзя давать скидки? Автор приводит рассказ о том, как во время «золотой Ð»Ð¸Ñ Ð¾Ñ€Ð°Ð´ÐºÐ¸Â» за неким коммивояжером, ÐµÑ Ð°Ð²ÑˆÐ¸Ð¼ в город, погнались волки. Он начал отрезать куски и бросать им куски мяса от туши оленя, которая у него была с собой. Волки поняли, что им незачем останавливаться и есть кусок мяса, если у коммивояжера в ÑÐ°Ð½ÑÑ ÐµÑ‰Ðµ целая туша. И они погнались за ним. Когда он Ð¿Ñ€Ð¸ÐµÑ Ð°Ð» в город, его ругали все жители, потому что раньше волки никогда не гонялись за санями. А теперь коммивояжер показал, что это можно делать. По сути, этот пример показывает один из аспектов переговоров. Сейчас все потребители любят скидки. Тем не менее, для Ð½ÐµÐºÐ¾Ñ‚Ð¾Ñ€Ñ‹Ñ ÑÑ„ÐµÑ€ бизнеса эта стратегия может оказаться невыгодной – вас будут “отжимать”, требуя еще больше. В таком же контексте Гвен Кеннеди рассказал о продаже кофе. Всем известно, что кофе, который мы покупаем в кафе рядом, стоит в 20-30 раз дороже, чем кофейные зерна на плантации. И на самом деле, торги при закупке кофе – наиболее яркая область для  переговоров, потому, что там играет роль всё: кто доставляет кофе, кто фасует, кто его обжаривает и перемалывает. Одна из Ñ†ÐµÐ½Ð½Ñ‹Ñ , для меня, идей книги: если атакуют ваше предложение, то всегда атакуют цену. Зачастую цену можно не снижать с помощью скидок, а просто менять пакет услуг – это уменьшает цену, как просит клиент. Но при этом клиент понимает, что он чем-то жертвует торгуясь. Также в книге содержатся яркие примеры на тему, почему нельзя жертвовать качеством и как такие жертвы в конечном итоге отпугивают клиентов. Марк Гоулстон «Я слышу вас насквозь» Вторая книга, которая мне очень сильно запомнилась: «Я слышу вас насквозь». Там отражены разные аспекты переговоров. Если первая книга – это элемент торгов, Ñ‚ÐµÑ Ð½Ð¸ÐºÐ¸, как продавать и принимать какие-то предложения, то вторая – это больше про Ð¸Ñ Ð¿ÑÐ¸Ñ Ð¾Ð»Ð¾Ð³Ð¸Ñ‡ÐµÑÐºÐ¸Ð¹ аспект. Автор книги – очень интересный человек, практикующий Ð¿ÑÐ¸Ñ Ð¾Ð»Ð¾Ð³, ведет тренинги для ФБР, для отделов переговоров при Ð·Ð°Ñ Ð²Ð°Ñ‚Ðµ заложников. В первой части книги даётся теория и объясняется, как именно мозг принимает решения. Автор условно это называет Â«Ð¿ÐµÑ€ÐµÑ Ð¾Ð´ от НЕТ к ДА», ссылаясь при этом на книгу «12 правил мозга», написанную Джоном Мединой. Вторая часть  – это практические принципы принятия решений, которые мы не осознаем, но они есть. Третья часть книги – прикладные Ñ‚ÐµÑ Ð½Ð¸ÐºÐ¸ ведения переговоров. И четвертая – конкретные связки и конкретные примеры с пояснением, почему в той или иной ситуации оптимальной является эта или другая Ñ‚ÐµÑ Ð½Ð¸ÐºÐ°. Опять же, жизненность и яркость примеров, которые он приводит, делает эту книгу Ð·Ð°Ñ Ð²Ð°Ñ‚Ñ‹Ð²Ð°ÑŽÑ‰ÐµÐ¹ и позволяет прочитать ее на одном Ð´Ñ‹Ñ Ð°Ð½Ð¸Ð¸. Современные книги достаточно скучны. Все книги, которые больше 200 страниц, тяжело читать, если в Ð½Ð¸Ñ Ð½ÐµÑ‚ никакого литературного аспекта. Так, бизнес романы все читают на ура по той простой причине, что читаешь фактически Ñ ÑƒÐ´Ð¾Ð¶ÐµÑÑ‚Ð²ÐµÐ½Ð½ÑƒÑŽ книгу с элементами обучения. Если видишь 400 страниц забористого текста на умные темы, то это всё Ñ Ð¾Ñ€Ð¾ÑˆÐ¾, но скучно. Эти две книги можно читать вместе. Эти книги явно Ñ Ð¾Ñ€Ð¾ÑˆÐ¾ подойдут менеджерам проектов, задействованным в Ð¿ÐµÑ€ÐµÐ³Ð¾Ð²Ð¾Ñ€Ð°Ñ Ñ заказчиками. Они подойдут HR, и далее всем, кто работает с людьми и участвует в Ð¿ÐµÑ€ÐµÐ³Ð¾Ð²Ð¾Ñ€Ð°Ñ . В Украине почти все компании, так или иначе, аутсорсинговые. И HR зачастую вынуждены торговаться как с клиентом за какие-то условия начала работы и так же с людьми, которые будучи в аутсорсинге начинают качать права. В этом плане HR специалистам точно будет интересно 🙂 В общем-то, эти книги вышли давно, но раз они у меня постоянно на ÑÐ»ÑƒÑ Ñƒ, значит, стоит поговорить о Ð½Ð¸Ñ ÑÐ½Ð¾Ð²Ð°. Хотя бы потому, что описанные в Ð½Ð¸Ñ Ñ‚ÐµÑ Ð½Ð¸ÐºÐ¸ существенно упрощают общение с клиентами и заказчиками! Как создавать тренинги — практическое руководство на личном примере Tim Yevgrashyn 16/05/2016 Обо всем В последнее время коллеги и знакомые все чаще интересуются моим Ð¿Ð¾Ð´Ñ Ð¾Ð´Ð¾Ð¼ к созданию тренингов. В итоге я решил рассказать об этом процессе. Одновременно покажу пример создания однодневного тренинга по Scrum для команды и дам готовую структуру, которую сможет использовать каждый из вас. Скажу сразу, что я не претендую на звание мега «тренера тренеров». Я начал проводить тренинги еще в 2007 году. Но с Ñ‚ÐµÑ Ð¿Ð¾Ñ€ я многому научился, в том числе и сам прошел «тренинг для тренеров». Как показывает практика, если что-то долго делать, опыт и знания все-таки появятся 🙂 Работая с коллегами-консультантами, Ð¿Ñ€Ð¸Ñ Ð¾Ð´Ð¸Ð»Ð¾ÑÑŒ не раз обучать Ð½Ð°Ñ‡Ð¸Ð½Ð°ÑŽÑ‰Ð¸Ñ Ñ‚Ñ€ÐµÐ½ÐµÑ€Ð¾Ð². Я уверен: даже если мои ученики не ведут тренинги регулярно, то полученные навыки не раз им пригодились. Несмотря на то, что я часто предлагаю готовые программы ( описание ÐºÐ¾Ñ‚Ð¾Ñ€Ñ‹Ñ ÐµÑÑ‚ÑŒ на сайте ), в Ñ Ð¾Ð´Ðµ работы с клиентами мне Ð¿Ñ€Ð¸Ñ Ð¾Ð´Ð¸Ð»Ð¾ÑÑŒ создавать тренинги под конкретные нужды, и этот путь мы с вами пройдем в этой серии статей . Этап 1. Хочу создать тренинг. С чего начать? Я убежден: тренинг – продукт. А для продуктов я рекомендую создавать « Видение Продукта », которое помогает ответить на простые вопросы и держать в фокусе конечный результат. Первый вопрос: « Для кого этот тренинг? » Для команды, которая только думает о внедрении Agile-методов? Для команды, которая Ð¸Ñ ÑƒÐ¶Ðµ практикует, но Ñ Ð¾Ñ‡ÐµÑ‚ переосмыслить, что и как они делают? Для группы менеджеров компании, которые Ñ Ð¾Ñ‚ÑÑ‚ побольше узнать, как работать по Scrum-методологии? Для отдела DevOps, который внедряет Kanban? А может для HR-отдела, который Ñ Ð¾Ñ‡ÐµÑ‚ узнать новые слова или, наоборот, внедрить некие легковесные процессы, чтобы лучше делать свое дело? 🙂 Второй вопрос: « Зачем ИМ этот тренинг? » Частично он Ð²Ñ‹Ñ Ð¾Ð´Ð¸Ñ‚ из ответа на первый вопрос, добавляя фокус и цели тренинга. Тренинг может быть направлен на ознакомление с широким кругом принципов и методов или на практические навыки в одной узкой области. Особенно Ñ Ð¾Ñ€Ð¾ÑˆÐ¾, если участники соберутся уже на следующий день, чтобы использовать полученные знания и навыки. Вопрос третий: « Какие у нас ограничения? » Первое и самое распространенное ограничение – время. Если у меня есть один день, тогда можно рассчитывать на раскрытие 3-4-Ñ Ñ‚ÐµÐ¼, с учетом теории и Ð¿Ñ€Ð°ÐºÑ‚Ð¸Ñ‡ÐµÑÐºÐ¸Ñ ÑƒÐ¿Ñ€Ð°Ð¶Ð½ÐµÐ½Ð¸Ð¹. Два и больше дней, а это, можно сказать, уже роскошь, дают возможность глубоко погрузиться в разные темы, которые вместе создают целостное понимание Ð¾Ñ‚Ð´ÐµÐ»ÑŒÐ½Ñ‹Ñ Ñ‡Ð°ÑÑ‚ÐµÐ¹ общей картины. Но иногда время строго лимитировано и есть только полдня (примерно 4 часа) или мастер-класс на два часа. В таком случае нужно выбрать более узкий фокус и отказаться от Ð¼Ð½Ð¾Ð³Ð¸Ñ Ð¸Ð½Ñ‚ÐµÑ€ÐµÑÐ½Ñ‹Ñ Ñ‚ÐµÐ¼, которые вы не успеете рассмотреть. Другое, не такое критическое ограничение – материалы. Флипчарт, стикеры и распечатки вы можете найти в любом офисе. Отлично, если есть возможность заранее собрать дополнительные материалы для упражнений – монеты, карточки для упражнений и прочие домашние заготовки. Поэтому, несмотря на мою безграничную любовь к Lego, я предпочитаю не использовать его для тренинга: нужно таскать с собой огромную коробку. А так я готов провести тренинг почти в любое время и в любом месте с минимальной подготовкой. Конечно, на фоне всего этого у вас должна проскочить мысль о месте для тренинга. Где вы его проведете? Какое помещение вам доступно? Есть ли там столы для работы в Ð³Ñ€ÑƒÐ¿Ð¿Ð°Ñ Ð¸ другие материалы? Об этом поговорим позже, когда приступим к упражнениям. Дополнительные вопросы: «Какие критические атрибуты?» и «На что может быть Ð¿Ð¾Ñ Ð¾Ð¶ этот тренинг?». Частично они уже понятны из Ð²ÑÐµÑ Ð¿Ñ€ÐµÐ´Ñ‹Ð´ÑƒÑ‰Ð¸Ñ Ð¾Ñ‚Ð²ÐµÑ‚Ð¾Ð². Но стоит обратить внимание на один важный аспект: количество участников. Я сторонник концепции «Training from the back of the room» (тренинг из дальнего конца комнаты). Другими словами, я считаю, что в тренинге должно быть больше интерактива между участниками и меньше Â«Ð¼Ð¾Ð½Ð¾Ð¿Ð¾Ð»ÑŒÐ½Ñ‹Ñ Â» рассказов тренера. Лучше всего тренинг Ð¿Ñ€Ð¾Ñ Ð¾Ð´Ð¸Ñ‚ в относительно Ð½ÐµÐ±Ð¾Ð»ÑŒÑˆÐ¸Ñ Ð³Ñ€ÑƒÐ¿Ð¿Ð°Ñ Ð¾Ñ‚ 8 до 16 человек. При максимуме в 20 человек еще можно рассчитывать на внимание тренера к каждой группе участников. Если же у вас больше участников, то нужно будет думать о Ð¿Ð¾Ð¼Ð¾Ñ‰Ð½Ð¸ÐºÐ°Ñ Ð¸Ð»Ð¸ об ÑƒÐ¿Ñ€Ð°Ð¶Ð½ÐµÐ½Ð¸ÑÑ , которые не требуют особого внимания тренера. В зависимости от количества людей на тренинге, вам придется продумать, какие использовать методы, чтобы вовлечь Ð²ÑÐµÑ Ð¸ сбалансировать динамику тренинга, чтобы никто не сидел в сторонке. Еще Сократ сказал, что вовлечение в обучение способствует запоминанию. Это знают все, кто так или иначе знаком с проблемой обучения практическим навыкам (а гибкие методы работы – тоже навык). Хорошая новость: в арсенале тренера множество способов интерактива. Например: обдумывание вопроса самостоятельно, обсуждение в Ð¿Ð°Ñ€Ð°Ñ Ð¸Ð»Ð¸ Ð³Ñ€ÑƒÐ¿Ð¿Ð°Ñ Ð´Ð¾ 5 человек, участие в упражнении (serious play), разбор кейсов или просто общее интерактивное обсуждение с тренером и многое другое. Обо всем этом мы поговорим в ÑÐ»ÐµÐ´ÑƒÑŽÑ‰Ð¸Ñ ÑÑ‚Ð°Ñ‚ÑŒÑÑ , когда будем наполнять наш тренинг. Итак, давайте посмотрим, что у вас может получиться и создадим тренинг вместе, как я и обещал в самом начале. Создаем тренинг для участников, которые пока еще мало знакомы с Agile-принципами разработки и в частности Scrum-методом. Это может быть отдельная команда или сборная группа в компании. Цель тренинга – раскрытие Ð¾ÑÐ½Ð¾Ð²Ð½Ñ‹Ñ Ñ‚ÐµÐ¼, Ñ‚Ð°ÐºÐ¸Ñ ÐºÐ°Ðº понимание идеи Agile, знание практик работы по Scrum-методологии, методы командной оценки и планирования итераций и проектов. Также обязательно получение Ð¿Ñ€Ð°ÐºÑ‚Ð¸Ñ‡ÐµÑÐºÐ¸Ñ Ð½Ð°Ð²Ñ‹ÐºÐ¾Ð², чтобы начать Ð¸Ñ Ð¿Ñ€Ð¸Ð¼ÐµÐ½ÑÑ‚ÑŒ сразу после тренинга. По времени мы можем рассчитывать на однодневный тренинг при оптимальном количестве в 15 человек. Так и назовем его – «Однодневный Scrum-тренинг» Далее мы поговорим о том, как создать структуру тренинга, чтобы упаковать туда все Ð½ÐµÐ¾Ð±Ñ Ð¾Ð´Ð¸Ð¼Ñ‹Ðµ темы. Обсудим, как сбалансировать расписание и подобрать интерактивные упражнения, которые объединяют теорию и практику. Постараюсь не откладывать следующие статьи в долгий ящик. С нетерпением жду комментариев и вопросов, чтобы понять насколько эта тема интересна. Оставайтесь с нами . Конференции, открытые тренинги и воркшопы в ближайшее время Tim Yevgrashyn 06/05/2016 Обо всем , Управление проектами Глянул в свой календарь, и понял, что накопилось много мероприятий, где либо буду выступать, либо сам проводить. Обычно всего так много, что я иногда не успеваю и написать об этом, но в этот раз успею поделиться:) 13 мая 2016 года (on-line)  в формате вебинара поговорим о том, как “ Масштабировать компанию по Agile принципам “. Эта тема все больше и больше обсуждается и я решил собрать свои мысли и заодно дать небольшие пояснения об ÑÐ»ÐµÐ¼ÐµÐ½Ñ‚Ð°Ñ , которые используются в Scaled Agile Ñ„Ñ€ÐµÐ¹Ð¼Ð²Ð¾Ñ€ÐºÐ°Ñ . Участие бесплатное, регистрация обязательна . 15 мая 2016 года (Киев, Украина)  играем в Scrum Card Game , о которой я недавно писал . Это Ñ Ð¾Ñ€Ð¾ÑˆÐ°Ñ возможность для Ð²ÑÐµÑ : и Ñ‚ÐµÑ , кто Ñ Ð¾Ñ‡ÐµÑ‚ немного соприкоснуться со скрамом, и для Ñ‚ÐµÑ , кто Ñ Ð¾Ñ‡ÐµÑ‚ научиться фасилитровать эту игру, чтобы в игровой форме обучить основам Scrum. Количество мест ограничено, присоединяйтесь. 19-20 мая 2016 года (Киев, Украина)  проводим первый в Украине открытый тренинг Leading SAFe (SAFe Agilist certification).  На этом тренинге мы будем детально разбирать Scaled Agile Framework, практиковаться на симуляции, проводить планирование группой команд и учиться управлять портфолио на основе ценности для бизнеса. Скидка 20% по промо-коду www./ (Да-да, это для Ð²Ð½Ð¸Ð¼Ð°Ñ‚ÐµÐ»ÑŒÐ½Ñ‹Ñ Ñ‡Ð¸Ñ‚Ð°Ñ‚ÐµÐ»ÐµÐ¹ 🙂 ) 24-25 мая 2016 года (Минск, Беларусь) в Ñ€Ð°Ð¼ÐºÐ°Ñ ÐºÐ¾Ð½Ñ„ÐµÑ€ÐµÐ½Ñ†Ð¸Ð¸ IT Spring 2016  провожу также открытый тренинг Leading SAFe (SAFe Agilist certification) , впервые в Беларуси. Еще раз напоминаю, что это тренинг по масштабированию Agile процессов для лидеров разработки и руководителей Ñ€Ð°Ð·Ð»Ð¸Ñ‡Ð½Ñ‹Ñ ÑƒÑ€Ð¾Ð²Ð½ÐµÐ¹. 26-27 мая 2016 года (Минск, Беларусь), также в Ñ€Ð°Ð¼ÐºÐ°Ñ ÐºÐ¾Ð½Ñ„ÐµÑ€ÐµÐ½Ñ†Ð¸Ð¸ IT Spring 2016, проводим тренинг  ICP Agile Project Management . Это  тренинг международного консорциума по гибким методологиям ICAgile по управлению Agile проектами для менеджеров проектов, а также Scrum мастеров, ÑÑ‚Ñ€ÐµÐ¼ÑÑ‰Ð¸Ñ ÑÑ к менеджменту проектов. Тренинг продвинутого уровня требует наличие одного из сертификатов мирового уровня по базовым владениям гибкими методологиями (CSM, CSPO, PSM или ICP). 29-30 мая 2016 года (Минск, Беларусь) конференция IT Spring 2016 . 29 мая в Ñ€Ð°Ð¼ÐºÐ°Ñ Â Keynotes Day буду говорить про “М асштабирование компании по Agile-принципам”, на второй день проведу воркшоп “Scaled Ball point game”. Если вы Ñ Ð¾Ñ‚Ð¸Ñ‚Ðµ посетить и тренинги и конференцию – обратитесь к организаторам, у Ð½Ð¸Ñ ÐµÑÑ‚ÑŒ интересное предложение 🙂 2-3 июня 2016 года (Днепропетровск, Украина) конференция ITEM  (IT Evolution Meeting), где до конференции, 1 июня, проведу мастер-класс по созданию Ð¾Ð±ÑƒÑ‡Ð°ÑŽÑ‰Ð¸Ñ ÑƒÐ¿Ñ€Ð°Ð¶Ð½ÐµÐ½Ð¸Ð¹ и игр AGILE GAME JAM , а во время конференции буду модерировать поток Project Management и выступлю с рассказом “Закат ÑÐ¿Ð¾Ñ Ð¸ Agile или The Force Awakening” о том, как мы докатились до того, что известный бренд на букву “A” уже Ñ Ð¾Ñ€Ð¾Ð½ÑÑ‚ и при этом по прежнему индустрия нуждается в развитии и Ð¸Ð·Ð¼ÐµÐ½ÐµÐ½Ð¸ÑÑ . До встречи! Scrum Card Game – настольная Scrum игра Tim Yevgrashyn 06/04/201616/01/2020 Обо всем , Управление проектами Когда я только начинал вести тренинги по Scrum методологии и принципам Agile разработки, пришло понимание – теория легко забывается. Проще учится на своем опыте. Так мне понадобилась Scrum игра. Существует много Scrum игр и симуляций, и все-таки большинство из Ð½Ð¸Ñ Ð¼Ð½Ðµ не нравятся. Они либо излишне упрощены, либо наоборот громоздки и тренеру Ð½ÐµÐ¾Ð±Ñ Ð¾Ð´Ð¸Ð¼Ð¾ носить с собой килограммы материалов для упражнений. Так родилась идея, а затем и настольная игра – Scrum Card Game . С Ñ‚ÐµÑ Ð¿Ð¾Ñ€ она отлично послужила мне и многим моим коллегам-консультантам. Меня неоднократно просили сделать ее доступной для широкой публики те, кто Ñ Ð¾Ñ‚ÑŒ раз в нее играл. Настало время! 🙂 Официальная страница Scrum игры содержит ссылки на самую актуальную версию для скачивания на Ñ€Ð°Ð·Ð½Ñ‹Ñ ÑÐ·Ñ‹ÐºÐ°Ñ . Там же можно купить печатную версию ScrumCardGame в Ñ Ð¾Ñ€Ð¾ÑˆÐµÐ¼ качестве. Суть игры в том, чтобы участники получили опыт работы по Scrum, пройдя этапы Планирования Спринта и его Исполнения, встречаясь с максимально близкими к реальности неожиданностями. На основе своего опыта, команды делают выводы и учатся в течении Ñ‚Ñ€ÐµÑ ÑÐ¿Ñ€Ð¸Ð½Ñ‚Ð¾Ð²-итераций. Для игры вам понадобится сделать игровые карточки: достаточно скачать инструкцию на странице игры Scrum Card Game – там же внутри есть шаблон карточек для печати. Вам также понадобятся два кубика (игральные кости) на каждую команду. Команды рекомендую собирать по 4-5 человек, максимум 6. Они работают независимо друг от друга, поэтому игру можно использовать и для большой аудитории, лишь бы были запасные наборы 🙂 Итак, объявите цель игры: каждая команда разрабатывает новый продукт и после третьей итерации Ð²Ñ‹Ñ Ð¾Ð´Ð¸Ñ‚ в “production” со всем, что они успеют сделать. Каждая команда должна Запланировать спринт, Исполнить спринт и Адаптироваться на основе своего опыта. Зайдите на страницу игры и скачайте подробные инструкции. Scrum Card Game Ñ Ð¾Ñ€Ð¾ÑˆÐ° еще и тем, что ее легко адаптировать под разнообразную аудиторию. У меня заняло несколько минут, чтобы сделать версию для не-ИТ аудитории, просто создавая альтернативный бэклог. Уверен, разобравшись, вы сможете приспособить игру под свои нужды. Скачиваемая версия ScrumCardGame опубликована по Creative Commons Attribution-ShareAlike 4.0 International License . Это означает, что вы можете свободно использовать игру в своей работе, даже в ÐºÐ¾Ð¼Ð¼ÐµÑ€Ñ‡ÐµÑÐºÐ¸Ñ Ñ‚Ñ€ÐµÐ½Ð¸Ð½Ð³Ð°Ñ Ð¸ Ð¿Ñ€Ð¾ÐµÐºÑ‚Ð°Ñ , при условии, что упомянете авторство и источник, а также при условии, что все производные игры публикуются под такой же лицензией. Печатная версия распространяется на ÑƒÑÐ»Ð¾Ð²Ð¸ÑÑ Ð¿Ð¾Ð»Ð½Ð¾Ð³Ð¾ авторского копирайта. С удовольствием обсужу ваш опыт игры или идеи по ее развитию. Вы можете связаться со мной на странице “Контакты” . Притчи о любви к пользователям Tim Yevgrashyn 10/03/201623/03/2016 Управление проектами Моя работа непосредственно связана с созданием того, чем будут пользоваться люди. И пусть программное обеспечение они чаще всего воспринимают как нечто абстрактное, но его присутствие в Ð¸Ñ Ð¶Ð¸Ð·Ð½Ð¸ более чем реально. Так уж сложилось, что когда я участвовал в Ñ€Ð°Ð·Ñ€Ð°Ð±Ð¾Ñ‚ÐºÐ°Ñ , на Ð¼Ð¾Ð¸Ñ Ð³Ð»Ð°Ð·Ð°Ñ Ñ€Ð¾Ð¶Ð´Ð°Ð»Ð¸ÑÑŒ новые идеи. Они развивались и превращались в реальный результат. Конечно, многолетний опыт работы неизбежно приводит к так называемой профессиональной деформации. В повседневной жизни становятся очевидными многие вещи. Например, видно невооруженным взглядом, что полученный результат совершенно не соответствует нуждам пользователей. Такая ситуация наталкивает на мысль, что работники (не ИТ) в своей работе руководствовались какими-то другими критериями и уж явно не беспокоились о среднестатистическом клиенте. Расскажу всего лишь пару историй, на основе ÑÐ¾Ð±ÑÑ‚Ð²ÐµÐ½Ð½Ñ‹Ñ Ð½Ð°Ð±Ð»ÑŽÐ´ÐµÐ½Ð¸Ð¹. Назовем Ð¸Ñ Ð¿Ñ€Ð¸Ñ‚Ñ‡Ð°Ð¼Ð¸. Притча первая: "Туалет в торговом центре" Представьте себе свежепостроенный торговый центр. Казалось бы, как нынче говорят, “стильно, модно, современно”. Кругом чистота и красота. Вот Ð·Ð°Ñ Ð¾Ð¶Ñƒ я туда первый раз в места общественного пользования  и вижу яркий пример того, что разработчики четко следовали поставленному Ñ‚ÐµÑ Ð½Ð¸Ñ‡ÐµÑÐºÐ¾Ð¼Ñƒ заданию. Они его выполнили. В задании наверняка было указано так: “должно быть четыре умывальника, четыре мыльницы для Ð½Ð¸Ñ Ð¸ большое зеркало”. Вот так — коротко и ясно. Разработчики однозначно следовали инструкциям: установили умывальники и зеркало. Настала очередь мыльниц. Вероятно, решив что сверлить дырки в зеркале слишком Ñ Ð»Ð¾Ð¿Ð¾Ñ‚Ð½Ð¾, разработчики повесили мыльницы там, где им было удобнее. Результат получился такой: Мне как пользователю, который Ñ Ð¾Ñ‡ÐµÑ‚ помыть руки, не нравится это  решение. С какой стороны не посмотреть, а сделано Ð¿Ð»Ð¾Ñ Ð¾. Можно подойти в середину, но там нет мыльницы. Также можно стать сбоку, где мыльниц сразу две. Но тогда, если кто-то Ð·Ð°Ñ Ð¾Ñ‡ÐµÑ‚ ними воспользоваться, он будет вынужден тянуться через другого человека, стоящего в углу. Одним словом — не комфортно. И вот, вроде бы все выполнено согласно Ñ‚ÐµÑ Ð½Ð¸Ñ‡ÐµÑÐºÐ¾Ð¼Ñƒ заданию, придраться не к чему, но с точки зрения любви к пользователям такая работа никуда не годится. Притча вторая: “Номер для Ð´Ð²Ð¾Ð¸Ñ Ð² отеле” Современный человек обязан быть мобильным. Поездки по разным городам Украины и за границу стали частью жизни почти каждого из нас. Динамичный ритм жизни приводит к тому, что нам волей-неволей Ð¿Ñ€Ð¸Ñ Ð¾Ð´Ð¸Ñ‚ÑÑ останавливаться в гостинице. Но иногда мы ездим не одни, а например, с коллегой. Снять один номер на Ð´Ð²Ð¾Ð¸Ñ â€” обычный Ð²Ñ‹Ñ Ð¾Ð´, чтобы сэкономить и не заскучать. В этой ситуации начинаешь ценить некоторые аспекты дизайна интерьера. Попалась нам как-то одна гостиница, где действительно подумали о Ñ‚Ð°ÐºÐ¸Ñ Ð¿Ð¾Ð»ÑŒÐ·Ð¾Ð²Ð°Ñ‚ÐµÐ»ÑÑ , как мы. Природные потребности утром у каждого человека по сути одинаковые. Помочь пользователям Ð¸Ñ ÑƒÐ´Ð¾Ð²Ð»ÐµÑ‚Ð²Ð¾Ñ€Ð¸Ñ‚ÑŒ, не мешая друг другу можно, достаточно легко. Решение в гостинице меня просто поразило: Кажется, что разделить душ и туалет на две комнаты — ничего особенного. Но как известно, все гениальное — просто.  Так стандартное решение “как везде” превратили в другое, более удобное. И дизайнеры не испугались отойти от аксиомы “все так делают”. Пользователи оказались важнее. Позже мне объяснили: на дизайн повлияло еще одно не-функциональное требование. В этой гостинице часто останавливаются паломники, религия ÐºÐ¾Ñ‚Ð¾Ñ€Ñ‹Ñ Ð¿Ñ€ÐµÐ´Ð¿Ð¸ÑÑ‹Ð²Ð°ÐµÑ‚, что заставлять ждать другого человека — это Ð³Ñ€ÐµÑ . Поэтому, если есть лишь одна комната, то человек, который Ð½Ð°Ñ Ð¾Ð´Ð¸Ñ‚ÑÑ в ней, автоматически грешит. Ведь он заставляет ждать того, кто снаружи. Но в любом случае, какими бы ни были причины для такого решения, результат Ð¿Ñ€ÐµÐ²Ð¾ÑÑ Ð¾Ð´Ð¸Ñ‚ ожидания потребителей. К чему я это все? Я уже писал о том, что "мне не нужно Ñ‚ÐµÑ Ð·Ð°Ð´Ð°Ð½Ð¸Ðµ" . Старый Ð¿Ð¾Ð´Ñ Ð¾Ð´, который давно изжил себя. Описание будущего продукта в стиле “система должна” совершенно неуместно. Система никому и ничего не должна: она неживая и сама по себе ничего не Ñ Ð¾Ñ‡ÐµÑ‚. В современном мире фокус уже давно сместился на пользователя. Любое решение (будь то ПО или что-то другое) создается в первую очередь для нужд людей, которые будут его применять на практике. Неудачное решение, причиняющее постоянные неудобства, обречено быть забыто. Оно так и умрет, не отыскав ÑÐ²Ð¾Ð¸Ñ Ð¿Ð¾ÐºÑƒÐ¿Ð°Ñ‚ÐµÐ»ÐµÐ¹. Важно думать в стиле “пользователю нужно” или “пользователь Ñ Ð¾Ñ‡ÐµÑ‚”. Только так и никак иначе мы будем точно понимать, что мы делаем и зачем. Большинство читателей уже знакомы с форматом записи требований, которые так и назвали “Истории Пользователя”. Суть идеи проста, пишем в стиле: Как <КТО>, я Ñ Ð¾Ñ‡Ñƒ <ЧТО>, потому что <ЗАЧЕМ> На первый взгляд, идея элементарная, но одновременно она очень мощная. Ведь мы сразу концентрируемся на (ЗАЧЕМ) — Ñ†ÐµÐ»ÑÑ , которыми будет руководствоваться (КТО) — пользователь нашего решения. Таким образом, создавая свое решение, мы думаем о том, будет ли удобно пользоваться тем, что мы сделали. Есть еще целый ряд Agile-методов анализа нужд и описания требований: Use Case, Story Mapping, Impact Mapping. На мой взгляд, такая формула работает не только для разработки ПО, ее можно применять и в Ð´Ñ€ÑƒÐ³Ð¸Ñ ÑÑ„ÐµÑ€Ð°Ñ . Основная миссия — создать “продукт”, который будет отвечать желаниям пользователей. Сразу скажу: не обманывайтесь простотой формата. Есть и у него свои подводные камни. Требуется навык и небольшая “домашняя работа”, чтобы начать предугадывать потребности ÑÐ²Ð¾Ð¸Ñ Ð¿Ð¾Ð»ÑŒÐ·Ð¾Ð²Ð°Ñ‚ÐµÐ»ÐµÐ¹ во всем, что вы для Ð½Ð¸Ñ ÑÐ¾Ð·Ð´Ð°ÐµÑ‚Ðµ. Пока просто постарайтесь думать о Ñ‚ÐµÑ , для кого вы создаете продукт или оказываете сервис. Полюбите Ð²Ð°ÑˆÐ¸Ñ Ð¿Ð¾Ð»ÑŒÐ·Ð¾Ð²Ð°Ñ‚ÐµÐ»ÐµÐ¹ 🙂 К этой теме я еще вернусь с более практическими советами. Оставайтесь с нами или задавайте вопросы в ÐºÐ¾Ð¼Ð¼ÐµÐ½Ñ‚Ð°Ñ€Ð¸ÑÑ . Agile вне ИТ или как построить машину, пользуясь Agile-принципами Tim Yevgrashyn 15/01/2016 Обо всем , Управление проектами Один из ÑÐ°Ð¼Ñ‹Ñ Ð¿Ð¾Ð¿ÑƒÐ»ÑÑ€Ð½Ñ‹Ñ Ð²Ð¾Ð¿Ñ€Ð¾ÑÐ¾Ð², который мне задают на Ñ‚Ñ€ÐµÐ½Ð¸Ð½Ð³Ð°Ñ â€” как применять Agile-методы в не IT-Ð¿Ñ€Ð¾ÐµÐºÑ‚Ð°Ñ . Разработка нового или развитие существующего программного обеспечения всегда была областью высокой неопределенности. Тут сложно рассчитывать на то, что даже типовой проект пойдет точь-в-точь как предыдущие. Вопрос не в том, будут ли изменения в Ð¿ÐµÑ€Ð²Ð¾Ð½Ð°Ñ‡Ð°Ð»ÑŒÐ½Ñ‹Ñ Ñ‚Ñ€ÐµÐ±Ð¾Ð²Ð°Ð½Ð¸ÑÑ , а скорее в том, как быстро они появятся.  В тоже время, многие другие проекты условно сводятся к “производству”: изготавливаются почти одинаковые продукты по типовому процессу.  Эти проекты условно-линейные и полностью поддаются планированию. И все же люди из обычного мира бизнеса часто сравнивают разработку ПО и автомобильный конвейер. Иногда на моем тренинге или после доклада слегка наивный слушатель заявляет: “Мы же не можем собирать машину по частям: сначала колеса, потом двигатель, потом капот”. Подобное заблуждение возникло из-за подмены понятия конвейера, где идет сборка Ð¾Ð´Ð½Ð¾Ð¾Ð±Ñ€Ð°Ð·Ð½Ñ‹Ñ Ð¼Ð¾Ð´ÐµÐ»ÐµÐ¹ Ñ‚ÐµÑ Ð¶Ðµ машин, и работы дизайнерского бюро. Разработка ПО – проблема из области дизайна, а не производства. Чтобы окончательно развеять заблуждение относительно автомобилей, давайте посмотрим на проект разработки автомобиля с использованием Agile-принципов. Я имею ввиду проект WIKISPEED. Он участвовал в конкурсе ÑÑƒÐ¿ÐµÑ€ÑÐºÐ¾Ð½Ð¾Ð¼Ð¸Ñ‡Ð½Ñ‹Ñ Ð°Ð²Ñ‚Ð¾Ð¼Ð¾Ð±Ð¸Ð»ÐµÐ¹, как автомобиль пригодный для езды по официальным дорогам, который потребляет два литра на 100 километров .  До этого попытки собрать подобный автомобиль велись на протяжении уже десятка лет. Это должен быть не просто некий космический болид, где пилот лежа проедет по идеально ровной пустыне. Речь идет о машине, в которой мы с вами можем ездить по городу и автотрассам. Машине, у которой Ñ€Ð°ÑÑ Ð¾Ð´ на 100 км чуть больше 2-Ñ Ð»Ð¸Ñ‚Ñ€Ð¾Ð². В своем интервью автор проекта  Джо Джастис (Joe Justice) рассказывает , что с самого первого места работы он работал менеджером в Agile-ÐºÐ¾Ð¼Ð°Ð½Ð´Ð°Ñ . Для него это был, по сути, образ мысли и стиль жизни. Джастису довелось работать над разработкой ПО в Ð¼Ð°Ð»ÐµÐ½ÑŒÐºÐ¸Ñ Ð¸ Ð±Ð¾Ð»ÑŒÑˆÐ¸Ñ Ñ€Ð°ÑÐ¿Ñ€ÐµÐ´ÐµÐ»ÐµÐ½Ð½Ñ‹Ñ ÐºÐ¾Ð¼Ð°Ð½Ð´Ð°Ñ . Опять же, перед ним НЕ стояла задача сделать “Agile-машину” или “Lean-машину”. У него была цель создать ультра-эффективный автомобиль с помощью команды волонтеров, распределенной по всему миру . И уже как лидер и менеджер Джо Джастис выбирал методологию, которая помогла группе работать результативно. Нельзя ставить целью внедрение процесса, методов или принципов. Такие цели не долговечны, они не помогают организации двигаться к созданию ценности, не мотивируют команду и встречают много сопротивления. Другое дело, если цель компании в принесении максимальной пользы, а роль менеджера в этом — помочь делать все это быстро и эффективно. Итогом является максимизация результата для клиента и креативной работы сотрудников. При этом минимизация бумажной волокиты, рутины, Ð½ÐµÐ½ÑƒÐ¶Ð½Ñ‹Ñ Ð·Ð°ÑÐµÐ´Ð°Ð½Ð¸Ð¹ и всего, что не является работой над созданием результата и пользы. Agile, Lean и Scrum — набор Ð¾Ñ€Ð³Ð°Ð½Ð¸Ð·Ð°Ñ†Ð¸Ð¾Ð½Ð½Ñ‹Ñ Ð¸Ð½ÑÑ‚Ñ€ÑƒÐ¼ÐµÐ½Ñ‚Ð¾Ð² для максимизации результата, видимого клиентам и пользователем. Итак, команда взялась собрать машину. Участники знали общие требования: обычная комплектация машины, комфортная для каждого. Также они знали дополнительные требования – Ð½ÐµÐ¾Ð±Ñ Ð¾Ð´Ð¸Ð¼Ð¾Ðµ для “быть пригодным к езде по официальным дорогам”. Сам Джо, автор проекта, выступил экспертом, так как незадолго до этого участвовал в разработке ПО для учета машин. Тогда они изучали много требований пригодности от федеральной службы дорог. Разработка велась итерациями, в результате каждой из ÐºÐ¾Ñ‚Ð¾Ñ€Ñ‹Ñ Ð±Ñ‹Ð» создан некий функциональный прототип. Своей работой он показывал всей команде, насколько текущий результат далек от Ð¸Ñ Ñ†ÐµÐ»Ð¸, а также помогал выбрать,  каким будет следующий шаг и цель следующей итерации. Это то, что я называю “Agile продукта”. Для меня этот термин обобщает все методы и принципы принятия решений. Все, что надо делать дальше, чтобы приносить определенную пользу. Она может выражаться как в результате, потребляемом пользователями, так и в знании или прояснении Ñ€Ð¸ÑÐºÐ¾Ð²Ð°Ð½Ð½Ñ‹Ñ Ð¾Ð±Ð»Ð°ÑÑ‚ÐµÐ¹. Если интересно, погуглите на темы “Lean Design Thinking” и “Agile Product Design”. Та же, популярная нынче, концепция Lean Startup большей частью адресует эту область.  Одной из проблем проекта WIKISPEED было то, что команда распределена. Десятилетия назад говорил о том, что Agile методы лучше работают для команд, ÑÐ¸Ð´ÑÑ‰Ð¸Ñ Ñ€ÑÐ´Ð¾Ð¼. За последнее время появилось много инструментов, которые могут обеспечить команде общую среду общения: YouTube для записи демонстрации, Google Docs, онлайн доски задач, сервис конференц-звонков и, немаловажное, общая email рассылка на команду. Эти инструменты позволили распределенной команде волонтеров чувствовать себя так же, как Scrum команды, сидящие в одной комнате. Плюс к тому же, одним из Ð¾Ð±ÑÐ·Ð°Ñ‚ÐµÐ»ÑŒÐ½Ñ‹Ñ ÑƒÑÐ»Ð¾Ð²Ð¸Ð¹ для Ð½Ð¸Ñ Ð±Ñ‹Ð»Ð°  прозрачность Ð²ÑÐµÑ Ð¾Ð±ÑÑƒÐ¶Ð´ÐµÐ½Ð¸Ð¹ и документов. Даже если они создаются “другими” командами, каждый может посмотреть материалы соседей, когда ему это Ð½ÐµÐ¾Ð±Ñ Ð¾Ð´Ð¸Ð¼Ð¾. Сюда же стоит добавить большую автономность принятия решений у команд, которые работают над развитием Ñ‚ÐµÑ Ð¸Ð»Ð¸ Ð¸Ð½Ñ‹Ñ Ñ‡Ð°ÑÑ‚ÐµÐ¹ машины. В проекте участвовали 44 человека. Все они были волонтерами, для ÐºÐ¾Ñ‚Ð¾Ñ€Ñ‹Ñ Ð¿Ñ€Ð¾ÐµÐºÑ‚ WIKISPEED был Ñ Ð¾Ð±Ð±Ð¸. Это то, что я называю “Agile людей” . Принципы самоорганизации, совместная работа группы над одной целью итерации, общая ответственность за результат — просто неотъемлемые части Agile-методов и самой философии “гибкости” и сотрудничества. Многие современные книги о менеджменте, мотивации, лидерстве и командообразовании говорят о том как использовать эти принципы для достижения максимума в работе â€œÐºÑ€ÐµÐ°Ñ‚Ð¸Ð²Ð½Ñ‹Ñ ÐºÐ¾Ð¼Ð°Ð½Ð´â€. Если покопаться, то термин “Intelectual workers” ввел еще дедушка Питер Друкер. В современном мире большинство работ относится к этому типу, а не только разработка ПО. Ну и понятно, что учитывая опыт главного менеджера-организатора, все команды WIKISPEED работали по Scrum, адаптированному для Ð¸Ñ ÑÐ¸Ñ‚ÑƒÐ°Ñ†Ð¸Ð¸. У Ð½Ð¸Ñ Ð±Ñ‹Ð»Ð¸ спринты-итерации и небольшие команды, которые фокусировались на улучшении Ñ‚ÐµÑ Ð¸Ð»Ð¸ Ð¸Ð½Ñ‹Ñ Ð¿Ð°Ñ€Ð°Ð¼ÐµÑ‚Ñ€Ð¾Ð² автомобиля. В течение итерации команды ежедневно ÑÐ¸Ð½Ñ Ñ€Ð¾Ð½Ð¸Ð·Ð¸Ñ€Ð¾Ð²Ð°Ð»Ð¸ÑÑŒ и активно общались. Как правило в режиме “информация для Ð²ÑÐµÑ â€. А в конце итерации собиралась новая версия автомобиля. Члены команды вместе смотрели на полученный результат и обсуждали, что можно улучшить как в продукте, так и в Ð¸Ñ ÑÐ¿Ð¾ÑÐ¾Ð±Ðµ работы над ним. Это то, что я называю “Agile процессов” . Все методологии и фреймворки, которые помогают быстро начать двигаться к результату, адаптируются под условия проекта. К сожалению они — наиболее видимая часть “айсберга”, который мы называем Agile. По той же причине популярен Scrum – для него проще всего найти курсы или тренинги. При этом нередко совершенно забывают об Ð¾ÑÑ‚Ð°Ð»ÑŒÐ½Ñ‹Ñ , ÑƒÐ¿Ð¾Ð¼ÑÐ½ÑƒÑ‚Ñ‹Ñ Ð²Ñ‹ÑˆÐµ Ð°ÑÐ¿ÐµÐºÑ‚Ð°Ñ . На мой взгляд, они гораздо важнее любой методологии. Если оглянуться и присмотреться, то сегодня многие компании, далекие от разработки ПО, применяют принципы и философию Agile. И дело не только в примере об автомобиле. Кроме разработки автомобиля, я знаю много Ð´Ñ€ÑƒÐ³Ð¸Ñ ÑÐ»ÑƒÑ‡Ð°ÐµÐ²: написание  сценария телесериала, ведение юридической практики, оказание контент-услуг. Agile вне ИТ активно применяется компаниями. Особенно когда речь идет о Ð»ÑŽÐ´ÑÑ , Ñ€ÐµÑˆÐµÐ½Ð¸ÑÑ Ð¸ Ð¿Ñ€Ð¾Ñ†ÐµÑÑÐ°Ñ . Все это позволяет командам быть более гибкими и лучше достигать целей. « Previous Перевод Категорії Обо всем Организация Команд Саморазвитие Управление временем Управление проектами Недавні записи Весенний бум мероприятий: Agile Fundamentals, Leading SAFe, ScrumDayUA, AgileEE и IT Spring Упражнение для обсуждения ролей в Scrum или другом Agile-методе Agile Topics Cards – универсальный инструмент agile-коуча, и не только Немного анонсов: Leading SAFe в Киеве и Agile Tour Belarus Две интересные книги про переговоры Как создавать тренинги — практическое руководство на личном примере Конференции, открытые тренинги и воркшопы в ближайшее время Scrum Card Game – настольная Scrum игра Притчи о любви к пользователям Agile вне ИТ или как построить машину, пользуясь Agile-принципами Позначки Agile agilebc agileee Backlog daily stand up games IT-Jam IT-People itbrunch Kanban lean pecha-kucha Pomodoro technique product owner scrum ScrumMaster Вебинар Владелец Продукта Ловушки времени видео время доверие доклад замечательные идеи знания инструменты искусство возможного книги команда конференции лидерство мотивация обратная связь обучение оценки планирование позитивное мышление приоритет развитие руководитель самомотивация скрам совещание тренинг цель Последние статьи Весенний бум мероприятий: Agile Fundamentals, Leading SAFe, ScrumDayUA, AgileEE и IT Spring Упражнение для обсуждения ролей в Scrum или другом Agile-методе Agile Topics Cards – универсальный инструмент agile-коуча, и не только Немного анонсов: Leading SAFe в Киеве и Agile Tour Belarus Две интересные книги про переговоры ССЫЛКИ AgileLAB PechaKucha Ukraine Mountain Goat Software NOOP.NL Наши контакты По всем вопросам пишите: info(at)tim.com.ua © The Improved Methods При использовании материалов сайта обязательна прямая гиперссылка, индексируемая поисковыми системами, указывающая на материал или главную страницу веб-сайта tim.com.ua