Школа Управленческого Мастерства (ШУМ) - 4. Тренинг по контролю выполнения работ.
Посвящен типичным ошибкам управления при внедрении гибких (адаптивных, Agile) методологий. Разбираются активности и роли на примере методологии Scrum.
Ведущий: Вадим Нарейко
Страница: https://www.facebook.com/ManagementMasters
3. ПОЧЕМУ СЕГОДНЯ ФОКУСИРУЕМСЯ НА
ОШИБКАХ?
• «Проанализировав результаты, исследователи обнаружили: в группе, которая училась на
ошибках, качество знаний было выше, чем в той, которая училась на правильных решениях.»
«Психология Убеждения. 50 доказанных способов быть убедительным» Р. Чалдини, Н.Гольдштейн,
С.Мартин
4. ПРАВИЛА
• Работают все
• Глупых вопросов не бывает
• Отключаем звук и вибрацию в телефонах
• Говорим от своего имени
• Не играем в «партизана»
• Общаемся с максимальным количеством участников
5. ИЗМЕНЕНИЯ
• Используем Task Board и Burndown Chart для планирования и
контроля за тренингом
• Запланировано много информации
7. ПРОВЕРЯЕМ ГЛОБАЛЬНЫЕ ОЖИДАНИЯ
• Понять, как создавать команду
• Развить навыки общения в команде
• Познакомиться с новыми людьми
• Научиться мотивировать других
• Совершенствование внутреннего опыта
• Расшевелить структуру своей компании
• Оценить свои знания
• Поделиться знаниями
• Понять, какие навыки нужны
• Грамотное делегирование полномочий
• Научиться работать в команде
• Понять мотивации в работе команды
• Научиться общаться со специалистами
• Понять, как работают процессы
• Структурировать и получить знания
• Понять, как использовать опыт ИТ в других сферах
• Поменять специальность
• Понять, нравится ли управлять
• Хороший – Жесткий руководитель
• Научиться ошибаться и учиться на этом
• Применить знания на практике
• Встряхнуться и удовлетворить любопытство
• Грамотное проведение переговоров
• Научиться управлять людьми
8. НАШИ ОЖИДАНИЯ
• Научиться контролировать себя и других
• Использовать опыт из IT из другой сферы
• Что такое оптимальный контроль?
• Как найти баланс в контроле?
• Освоить новые методики и практики
• Узнать, что такое Scrum/Agile
• Как правильно контролировать?
• Научиться работать в команде
• Найти «подводные камни» в Scrum
• Побороть застенчивость
• Познакомиться с новыми людьми
• Прорекламировать свой проект
• Понять, что такое ШУМ
• Развеяться от офисных будней
• Обучаться управлению
• Возобновить знания
• Понять, как правильно проводить совещания
• Какие методы ведут к негативу от управления
• Узнать новые методы контроля
• Увеличить эффективность работы сотрудничества
• Проверить, правильно ли я знаю Agile
• Говорить с разработчиками на одном языке
9. НАШИ ОЖИДАНИЯ-2
• Узнать какие ошибки совершаются при
внедрении скрам
• Узнать какие ошибки совершаются в процессе
работы
• Проанализировать свои собственне ошибки
• Понять как сделать правильный процесс в своём
проекте
• Разобраться в планировании и оценке
• Понаблюдать за происходящим
• Разобраться как мотивировать людей получить
результат
• Пообщаться с интересными людьми
• Как организовать максимально комфортную
атмосферу в команде
• Изучить методику проведения тренинга как
такового
• Узнать для себя продолжать ли посещение
данного мероприятия
• Опыт управления людьми
• Практики построения отдела
• Применение адаптивных технологий
• Узнать, что такое управление
• Узнать о конкретных инструментах управления
10. РАЗБИВАЕМСЯ НА ГРУППЫ
• 7-9 человек
• Выбираем модератора (в идеале – участник,
который подготовился и распечатал план
обсуждения, взял компьютер или планшет
для опубликования результатов обсуждения)
• Обсудить проблемы, возникающие в
процессе контроля и выработать 5 пунктов,
отвечающих «Зачем нужно контролировать
выполнение работы?»
12. ПОЧЕМУ НА ПРИМЕРЕ SCRUM?
• «Простая» методика для внедрения
• «Модная» тенденция управления
• Много литературы и мало «правильного» опыта
13. AGILE-МАНИФЕСТ РАЗРАБОТКИ ПРОГРАММНОГО
ОБЕСПЕЧЕНИЯ
(HTTP://AGILEMANIFESTO.ORG/ISO/RU/)
Мы постоянно открываем для себя более совершенные методы разработки программного
обеспечения, занимаясь разработкой непосредственно и помогая в этом другим. Благодаря
проделанной работе мы смогли осознать, что:
Люди и взаимодействие важнее процессов и инструментов
Работающий продукт важнее исчерпывающей документации
Сотрудничество с заказчиком важнее согласования условий контракта
Готовность к изменениям важнее следования первоначальному плану
То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева
14. 12 ПРИНЦИПОВ AGILE-МАНИФЕСТА
HTTP://AGILEMANIFESTO.ORG/ISO/RU/PRINCIPLE
S.HTML
1. Наивысшим приоритетом для нас является удовлетворение
потребностей заказчика, благодаря регулярной и ранней
поставке ценного программного обеспечения.
2. Изменение требований приветствуется, даже на поздних
стадиях разработки. Agile-процессы позволяют использовать
изменения для обеспечения заказчику конкурентного
преимущества.
3. Работающий продукт следует выпускать как можно чаще, с
периодичностью от пары недель до пары месяцев.
4. На протяжении всего проекта разработчики и представители
бизнеса должны ежедневно работать вместе.
5. Над проектом должны работать мотивированные
профессионалы. Чтобы работа была сделана, создайте
условия, обеспечьте поддержку и полностью доверьтесь им.
6. Непосредственное общение является наиболее практичным и
эффективным способом обмена информацией как с самой
командой, так и внутри команды.
7. Работающий продукт — основной показатель прогресса.
8. Инвесторы, разработчики и пользователи должны иметь
возможность поддерживать постоянный ритм бесконечно.
Agile помогает наладить такой устойчивый процесс
разработки.
9. Постоянное внимание к техническому совершенству и
качеству проектирования повышает гибкость проекта.
10. Простота — искусство минимизации лишней работы — крайне
необходима.
11. Самые лучшие требования, архитектурные и технические
решения рождаются у самоорганизующихся команд.
12. Команда должна систематически анализировать возможные
способы улучшения эффективности и соответственно
корректировать стиль своей работы.
19. ЗА ЧТО ОТВЕЧАЕТ ВЛАДЕЛЕЦ ПРОДУКТА?
(PRODUCT OWNER)
HTTP://WWW.ROMANPICHLER.COM/
1. Отвечает за product vision
2. Понимает бизнес-модель продукта, включая
предлагаемые ценности и желаемые бизнес-
преимущества
3. Составляет и отвечает за план выпуска
(roadmap) продукта
4. Тесно сотрудничает с командой и Scrum-
мастером
5. Ведет бэклог продукта
6. Определяет приоритеты и цели каждой
итерации
7. Выбирает подходящие методы для
тестирования и демонстрации версий
(increments) заинтересованным лицам
8. Анализирует идеи, данные и обратную связь
и изменяет бэклог продукта
9. Контролирует бюджет и ход проекта
10. Координирует активности по запуску
продукта на рынок
20. PRODUCT OWNER В КАРТИНКЕ
HTTP://WWW.ROMANPICHLER.COM/BLOG/ROLES/
ONE-PAGE-PRODUCT-OWNER/
21. СТАНДАРТНЫЕ «ПРОБЛЕМЫ» PRODUCT
OWNER
• Не хватает полномочий
• Слишком занят
• Частичная занятость
• Удаленный
• «Прокси»
• Комитет
«Agile Product Management with Scrum. Creating Products that Customers Love» - Roman Pichler
33. ДЗ 4.1
• Отсортировать проблемы в порядке важности (самое важное – наверху)
• Написать, с которой из проблем сталкивались в последнее время и как ее решили
Срок – 72 часа
35. SCRUM MASTER
1. Помогает вести процесс (мониторит и контролирует)
2. Следит за мотивацией команды
3. «Продает» процесс команде и заинтересованным лицам (Наставник и Коуч)
4. Обеспечивает прозрачную коммуникацию
5. Следит за качеством процессов и инициирует изменения
6. Решает проблемы и разрешает конфликты (Защищает команду от внешних трудностей и
воздействий)
47. ДЗ 4.2
• Отсортировать проблемы в порядке важности (самое важное – наверху)
• Написать, с которой из проблем сталкивались в последнее время и как ее решили
Срок – 96 часов
49. ОТВЕТСТВЕННОСТЬ SCRUM TEAM
1. Ответственна за процесс
2. Владеет планом итерации
3. Принимает обязательства достичь цели
итерации
4. Ежедневно синхронизирует работу и
активности
5. Самоорганизуется для улучшения процесса и
решения задач
6. Оценивает задачи (пользовательские
истории)
7. Информирует Scrum Master о возможных и
возникших трудностях
8. Общается с Product Owner для уточнения
задач
9. Демонстрирует результат заинтересованным
лицам
51. ЖЕСТКОЕ ПЛАНИРОВАНИЕ
• Предполагает, что люди работают, как компьютеры
• Предполагает, что все известно в самом начале
• Команда известна в самом начале и ее эффективность также спланирована
• Не позволяет вносить оперативные изменения
• Не учитывает наличия промежуточной рыночной ценности
57. ТРЕНИНГ ПО ОЦЕНКЕ
• Команда просматривает список и быстро определяет, какая из задач самая маленькая
• После этого данной задаче назначается вес 1
• Потом все задачи оцениваются по порядку, исходя из того, сколько самых маленьких задач в
очередной задаче
• Оценка идет быстро – все выбирают карточки с оценкой, одновременно вскрывают карты
• Те участники, которые оценили минимально или максимально, говорят остальным, почему они
так оценили
• После этого оценка повторяется, пока не сойдется на одной оценке
• Команда может договориться, как поступать, если оценка долго не сходится
66. ДЗ 4.3
• Отсортировать проблемы в порядке важности (самое важное – наверху)
• Написать, с которой из проблем сталкивались в последнее время и как ее решили
Срок – 120 часов
68. DAILY STANDUP
• 15 минут синхронизации
• То же время
• То же место
• Организовано командой и для команды
3 вопроса:
1. Что делал вчера?
2. Чем займусь сегодня?
3. Какие есть помехи для выполнения работы?
81. ДЗ 4.4
• Отсортировать проблемы в порядке важности (самое важное – наверху)
• Написать, с которой из проблем сталкивались в последнее время и как ее решили
Срок – 144 часа
83. ДЕМОНСТРАЦИЯ (СМОТР РЕЗУЛЬТАТОВ)
• Команда показывается готовый результат заинтересованным лицам
• Демонстрируется только 100% готовое
• Каждый показывает только то, что сделал сам
• Владелец продукта или принимает функционал или возвращает назад в план (бэклог)
• Команда получает обратную связь от заинтересованных лиц
92. ДЗ 4.5
• Отсортировать проблемы в порядке важности (самое важное – наверху)
• Написать, с которой из проблем сталкивались в последнее время и как ее решили
Срок – 168 часа
94. ФАБРИКА ШАРОВ
• Разбиваемся на 2 команды
• Передать как можно больше шаров
• Каждый член команды должен коснуться шара
• Шары должны летать (нельзя передавать из рук в руки)
• Никаких шаров соседу (слева или справа)
• Итерации по 2 минуты
• Обсуждаете процесс, пока занимается вторая команда
95. РЕТРОСПЕКТИВА
Коллективное рассказываение историй в конце итераций или проекта для пересмотра событий с целью
научиться на полученном опыте
1. Открытие (5%)
2. Сбор данных (30-50%)
3. Проникновение в суть (20-30%)
4. Решаем что делать (15-20%)
5. Закрытие (10%)
Agile Retrospectives: Making Good Teams Great
Esther Derby, Diana Larsen
96. ”
“Вне зависимости от того, что мы сегодня выясним
мы понимаем и верим, что все действовали по мере
своих сил и возможностей,
принимая во внимание доступную на тот момент
информацию, умения, навыки и наличие ресурсов в
данной ситуации.
«Project Retrospectives: A Handbook for Team Reviews» - Norman L. Kerth
Основная директива
108. ДЗ 4.6
• Отсортировать проблемы в порядке важности (самое важное – наверху)
• Написать, с которой из проблем сталкивались в последнее время и как ее решили
Срок – 196 часов
112. ЛИТЕРАТУРА
• «Психология Убеждения. 50 доказанных
способов быть убедительным» - Р. Чалдини,
Н.Гольдштейн, С.Мартин
• «Agile Retrospectives Making Good Teams
Great» - Esther Derby, Diana Larsen
• «Agile Product Management with Scrum.
Creating Products that Customers Love» -
Roman Pichler
• «Project Retrospectives: A Handbook for Team
Reviews» - Norman L. Kerth