Выступление Михаила Заборова, нашего руководителя стратегических проектов, на круглом столе Московского клуба тестировщиков в Deutsche Bank (2 декабря 2013 года, Москва).
Активные методы ведения переговоров. Анастасия Ивко. Антон Шалейников. Вадим ...Vadim Nareyko
Школа Управленческого Мастерства (ШУМ) - 8. Тренинг по переговорам и эффективной коммуникации. В ходе тренинга прорабатывался 4-х этапный алгоритм работы с возражениями и 3 группы техник деловой борьбы.
Ведущие: Анастасия Ивко, Антон Шалейников, Вадим Нарейко
Страница: https://www.facebook.com/ManagementMasters
Активные методы ведения переговоров. Анастасия Ивко. Антон Шалейников. Вадим ...Vadim Nareyko
Школа Управленческого Мастерства (ШУМ) - 8. Тренинг по переговорам и эффективной коммуникации. В ходе тренинга прорабатывался 4-х этапный алгоритм работы с возражениями и 3 группы техник деловой борьбы.
Ведущие: Анастасия Ивко, Антон Шалейников, Вадим Нарейко
Страница: https://www.facebook.com/ManagementMasters
Менеджмент, лидерство, инициативность в сбалансированной командеAlexander Postnikov
Данная презентация была подготовлена для семинара-дискуссии в одной из команд разработки программного обеспечения. Команда проработала более двух лет, и многие участники считали, что "упёрлись в потолок" в плане своего развития, рассматривая при этом только развитие "по вертикали".
Цель семинара была в том, чтобы поделиться с участниками команды мыслями и исследованиями в области менеджмента и лидерства в сбалансированных командах, и сформировать общее понимание, есть ли другие векторы развития, кроме классического вертикального.
Как работает ваша команда? Все ли в порядке? Ваша команда – самоорганизующаяся? Что такое самоорганизация вообще? Что нужно сделать, чтобы команду можно было действительно назвать самоорганизующейся?
О самых распространенных мифах, которые касаются самоорганизующихся команд; о том, какую команду можно в принципе считать командой; какие признаки говорят об успешности команды; и что собственно говоря можно сделать, чтобы команда могла стать самоорганизующейся.
Dnepr IT PM Club #11
Speaker - Angelina Linskaya [PM в IT-департаменте компании БаДМ]
https://www.linkedin.com/in/angelina-linskaya-92236186/
Тема: "Что такое «самоорганизующаяся команда» и мое видение как это работает"
Основные тезисы:
- Самоорганизующаяся команда — это миф или реальность»?
- Откуда взялось это понятие и что за ним стоит?
- Какие условия нужны для того, чтобы самоорганизующаяся команда действительно заработала?
О спикере:
Более 5 лет опыта как Project Manager и Business Analyst в сфере IT. Основное направление работы Enterprise проекты: разработка и внедрение EAM, ERP, MES, MRP, CRM систем.
Воркшоп по управлению командой проекта в Академии ПВТAliaksei Minkevich
Наша презентация с ВОРКШОПА ПО УПРАВЛЕНИЮ КОМАНДОЙ ПРОЕКТА 29 января в 19.00
Лидеры компании Juno поделятся с вами собственным опытом по следующим темам:
Как набирать и развивать команду проекта
Какие шаги проходит группа людей во время создания команды
Инструмент “Устав Команды”
Управление командой проекта
Обратная связь
Урегулирование конфликтов
Решение проблем
Принятие решений
Делегирование
Максим Цепков. Agile — ответ на вызовы третьей промышленной революции.ScrumTrek
Третья промышленная революция, которая была предсказана в далеком 1980 году Элвисом Тоффлером в книге «Третья волна», уже перестала быть делом будущего, а становится частью настоящего. Вызовы, которые она несла, в первую очередь пришли в IT-отрасль в конце 20 века. А в начале 21 века появился ответ на них — практики Agile, которые развиваются уже полтора десятилетия, в том числе вбирая из традиционного менеджмента все ценное и применимое в будущем мире. Сейчас новые вызовы и связанная с ними турбулентность идут в другие отрасли, которые могут в ответ изобретать собственные практики, а могут воспользоваться апробированными ответами Agile, наполнив его практики своей спецификой. Темп изменений в разных отраслях различается, однако приход нового неизбежен, потому что изменился mindset нового поколения соцсетей — тех, кто начал активно общаться и завоевывать лидерство в виртуальном пространстве еще в школе. И по мере того, как такие люди будут приходить в организации, они будут необратимо менять их культуру. Распространение бирюзовых организаций, описанных Фредериком Лалу в книге «Открывая организации будущего», — зримое проявление этих изменений. И вовсе не случайно организационный фреймворк для таких компаний — холакратия — тоже появился в IT-отрасли и распространяется за ее пределы. В докладе будет описана big picture современного развития, в которой каждой из организаций предстоит самоопределиться и выбрать собственный путь. Доклад является развитием моих выступлений по темам Agile и Спиральной динамики, доступных на моем сайте http://mtsepkov.org/Agile.
Agile - ответ на вызовы третьей промышленной революции - цепков custisMaxim Tsepkov
http://mtsepkov.org/AgileAgainstThirdWave доклад на AgileDays-2017 Третья промышленная революция, которая была предсказана в далеком 1980 году Элвисом Тоффлером в книге «Третья волна», уже перестала быть делом будущего, а становится частью настоящего. Вызовы, которые она несла, в первую очередь пришли в IT-отрасль в конце 20 века. А в начале 21 века появился ответ на них — практики Agile, которые развиваются уже полтора десятилетия, в том числе вбирая из традиционного менеджмента все ценное и применимое в будущем мире. Сейчас новые вызовы и связанная с ними турбулентность идут в другие отрасли, которые могут в ответ изобретать собственные практики, а могут воспользоваться апробированными ответами Agile, наполнив его практики своей спецификой. Темп изменений в разных отраслях различается, однако приход нового неизбежен, потому что изменился mindset нового поколения соцсетей — тех, кто начал активно общаться и завоевывать лидерство в виртуальном пространстве еще в школе. И по мере того, как такие люди будут приходить в организации, они будут необратимо менять их культуру. Распространение бирюзовых организаций, описанных Фредериком Лалу в книге «Открывая организации будущего», — зримое проявление этих изменений. И вовсе не случайно организационный фреймворк для таких компаний — холакратия — тоже появился в IT-отрасли и распространяется за ее пределы. В докладе будет описана big picture современного развития, в которой каждой из организаций предстоит самоопределиться и выбрать собственный путь.
Алексей Ильичев, Принятие решений: как учесть все мнения и не увязнутьScrumTrek
Современные процессы и культуры опираются на децентрализованные механизмы принятия решений. Если мы жестко регламентируем зоны ответственности, то неизбежно появляются “серые зоны”, в которых и возникает большинство проблем. Альтернатива — это команды, в которых зоны ответственности пересекаются. Но возникает вопрос, как такая команда принимает решения? Изобретением 20-го века стал консенсус. Команда принимает важные решения вместе, и каждый должен с этим решением согласиться. Но у консенсуса есть свои ограничения. Чтобы все договорились, нужно потратить на обсуждение существенное время. Плюс в процессе обсуждения имеющихся альтернатив, как правило команда принимает гибридный или компромиссный вариант, который уже не так нравится автору. Ну и наконец, ответственность за решения размывается.
В организациях без управленческих иерархий используются альтернативные консенсусу процессы принятия решений. Их суть в том, чтобы дать людям пространство для автономного принятия решений, которое тем не менее позволяет учесть интересы всех участников. О том, как это работает, и в каких условиях применимо, я расскажу в своём докладе.
Денис Тучин - Внедрение изменений: семь раз отмерь – один отрежь на UlCamp.Wi...Denis Tuchin
В докладе рассмотрим два ключевых момента: решение о целесообразности внедрения изменений и лучшие практики самого процесса внедрения. В том числе разберём отдельные элементы модели Коттера, проверку цели на экологичность и модель ADKAR. Также обсудим, как внедрение изменений на разных этапах развития команды влияет на его динамику.
Наталія Романенко "Куди йдуть співробітники"Petro Savych
Презентація Наталії Романенко, яка була підготовлена для вебінару "Куди йдуть співробітники, аюо навчи стартапера", підготованого в рамках підготовки до Human Capital Forum
Менеджмент, лидерство, инициативность в сбалансированной командеAlexander Postnikov
Данная презентация была подготовлена для семинара-дискуссии в одной из команд разработки программного обеспечения. Команда проработала более двух лет, и многие участники считали, что "упёрлись в потолок" в плане своего развития, рассматривая при этом только развитие "по вертикали".
Цель семинара была в том, чтобы поделиться с участниками команды мыслями и исследованиями в области менеджмента и лидерства в сбалансированных командах, и сформировать общее понимание, есть ли другие векторы развития, кроме классического вертикального.
Как работает ваша команда? Все ли в порядке? Ваша команда – самоорганизующаяся? Что такое самоорганизация вообще? Что нужно сделать, чтобы команду можно было действительно назвать самоорганизующейся?
О самых распространенных мифах, которые касаются самоорганизующихся команд; о том, какую команду можно в принципе считать командой; какие признаки говорят об успешности команды; и что собственно говоря можно сделать, чтобы команда могла стать самоорганизующейся.
Dnepr IT PM Club #11
Speaker - Angelina Linskaya [PM в IT-департаменте компании БаДМ]
https://www.linkedin.com/in/angelina-linskaya-92236186/
Тема: "Что такое «самоорганизующаяся команда» и мое видение как это работает"
Основные тезисы:
- Самоорганизующаяся команда — это миф или реальность»?
- Откуда взялось это понятие и что за ним стоит?
- Какие условия нужны для того, чтобы самоорганизующаяся команда действительно заработала?
О спикере:
Более 5 лет опыта как Project Manager и Business Analyst в сфере IT. Основное направление работы Enterprise проекты: разработка и внедрение EAM, ERP, MES, MRP, CRM систем.
Воркшоп по управлению командой проекта в Академии ПВТAliaksei Minkevich
Наша презентация с ВОРКШОПА ПО УПРАВЛЕНИЮ КОМАНДОЙ ПРОЕКТА 29 января в 19.00
Лидеры компании Juno поделятся с вами собственным опытом по следующим темам:
Как набирать и развивать команду проекта
Какие шаги проходит группа людей во время создания команды
Инструмент “Устав Команды”
Управление командой проекта
Обратная связь
Урегулирование конфликтов
Решение проблем
Принятие решений
Делегирование
Максим Цепков. Agile — ответ на вызовы третьей промышленной революции.ScrumTrek
Третья промышленная революция, которая была предсказана в далеком 1980 году Элвисом Тоффлером в книге «Третья волна», уже перестала быть делом будущего, а становится частью настоящего. Вызовы, которые она несла, в первую очередь пришли в IT-отрасль в конце 20 века. А в начале 21 века появился ответ на них — практики Agile, которые развиваются уже полтора десятилетия, в том числе вбирая из традиционного менеджмента все ценное и применимое в будущем мире. Сейчас новые вызовы и связанная с ними турбулентность идут в другие отрасли, которые могут в ответ изобретать собственные практики, а могут воспользоваться апробированными ответами Agile, наполнив его практики своей спецификой. Темп изменений в разных отраслях различается, однако приход нового неизбежен, потому что изменился mindset нового поколения соцсетей — тех, кто начал активно общаться и завоевывать лидерство в виртуальном пространстве еще в школе. И по мере того, как такие люди будут приходить в организации, они будут необратимо менять их культуру. Распространение бирюзовых организаций, описанных Фредериком Лалу в книге «Открывая организации будущего», — зримое проявление этих изменений. И вовсе не случайно организационный фреймворк для таких компаний — холакратия — тоже появился в IT-отрасли и распространяется за ее пределы. В докладе будет описана big picture современного развития, в которой каждой из организаций предстоит самоопределиться и выбрать собственный путь. Доклад является развитием моих выступлений по темам Agile и Спиральной динамики, доступных на моем сайте http://mtsepkov.org/Agile.
Agile - ответ на вызовы третьей промышленной революции - цепков custisMaxim Tsepkov
http://mtsepkov.org/AgileAgainstThirdWave доклад на AgileDays-2017 Третья промышленная революция, которая была предсказана в далеком 1980 году Элвисом Тоффлером в книге «Третья волна», уже перестала быть делом будущего, а становится частью настоящего. Вызовы, которые она несла, в первую очередь пришли в IT-отрасль в конце 20 века. А в начале 21 века появился ответ на них — практики Agile, которые развиваются уже полтора десятилетия, в том числе вбирая из традиционного менеджмента все ценное и применимое в будущем мире. Сейчас новые вызовы и связанная с ними турбулентность идут в другие отрасли, которые могут в ответ изобретать собственные практики, а могут воспользоваться апробированными ответами Agile, наполнив его практики своей спецификой. Темп изменений в разных отраслях различается, однако приход нового неизбежен, потому что изменился mindset нового поколения соцсетей — тех, кто начал активно общаться и завоевывать лидерство в виртуальном пространстве еще в школе. И по мере того, как такие люди будут приходить в организации, они будут необратимо менять их культуру. Распространение бирюзовых организаций, описанных Фредериком Лалу в книге «Открывая организации будущего», — зримое проявление этих изменений. И вовсе не случайно организационный фреймворк для таких компаний — холакратия — тоже появился в IT-отрасли и распространяется за ее пределы. В докладе будет описана big picture современного развития, в которой каждой из организаций предстоит самоопределиться и выбрать собственный путь.
Алексей Ильичев, Принятие решений: как учесть все мнения и не увязнутьScrumTrek
Современные процессы и культуры опираются на децентрализованные механизмы принятия решений. Если мы жестко регламентируем зоны ответственности, то неизбежно появляются “серые зоны”, в которых и возникает большинство проблем. Альтернатива — это команды, в которых зоны ответственности пересекаются. Но возникает вопрос, как такая команда принимает решения? Изобретением 20-го века стал консенсус. Команда принимает важные решения вместе, и каждый должен с этим решением согласиться. Но у консенсуса есть свои ограничения. Чтобы все договорились, нужно потратить на обсуждение существенное время. Плюс в процессе обсуждения имеющихся альтернатив, как правило команда принимает гибридный или компромиссный вариант, который уже не так нравится автору. Ну и наконец, ответственность за решения размывается.
В организациях без управленческих иерархий используются альтернативные консенсусу процессы принятия решений. Их суть в том, чтобы дать людям пространство для автономного принятия решений, которое тем не менее позволяет учесть интересы всех участников. О том, как это работает, и в каких условиях применимо, я расскажу в своём докладе.
Денис Тучин - Внедрение изменений: семь раз отмерь – один отрежь на UlCamp.Wi...Denis Tuchin
В докладе рассмотрим два ключевых момента: решение о целесообразности внедрения изменений и лучшие практики самого процесса внедрения. В том числе разберём отдельные элементы модели Коттера, проверку цели на экологичность и модель ADKAR. Также обсудим, как внедрение изменений на разных этапах развития команды влияет на его динамику.
Наталія Романенко "Куди йдуть співробітники"Petro Savych
Презентація Наталії Романенко, яка була підготовлена для вебінару "Куди йдуть співробітники, аюо навчи стартапера", підготованого в рамках підготовки до Human Capital Forum
Семинар по управлению проектами. Часть 1. КомандаVasiliy Deynega
Семинар в магистратуре, проведенный командой портала "it works!", специально для Уральского Федерального Университета (бывший УГТУ-УПИ).
Тренеры:
Малых Денис Александрович
Дейнега Василий Михайлович
Часть 1: Команда
iLLi Studio
Портал it works (http://ru.itworks-portal.com)
Блог для менеджеров:
http://itw66.ru/blog/project_management/
Выступление Владимира Рахтеенко, нашего генерального директора, и Германа Алексеева, ИТ-директора ГК «Спортмастер», на Неделе российского ритейла (7 июня 2017 года, Москва).
Будущее уже наступило: от Agile к бирюзовым организациямCUSTIS
Выступление Максима Цепкова, нашего главного архитектора дирекции развития решений, на форуме «Дни PR и маркетинга на Юге» (1 июня 2017 года, Ростов-на-Дону).
Диаграммы учета как средство для наглядного и целостного отображения правил у...CUSTIS
Выступление Максима Цепкова, нашего главного архитектора дирекции развития решений, на конференции «Соколовские чтения «Бухгалтерский учет: взгляд из прошлого в будущее» (22 апреля 2017 года, Санкт-Петербург).
Опыт построения микросервисной архитектуры в цифровом банкеCUSTIS
Выступление Андрея Солощака, ведущего архитектора «Бинбанка», на профессиональной встрече CUSTIS Meetup: Микросервисы в Enterprise (16 марта 2017 года, Москва).
Золотая лихорадка MSA: почему нам не подошли микросервисы?CUSTIS
Выступление Юрия Веретельникова, сооснователя и технического директора Solit Clouds, на профессиональной встрече CUSTIS Meetup: Микросервисы в Enterprise (16 марта 2017 года, Москва).
Выступление Игоря Беспальчука, нашего руководителя проектов, на профессиональной встрече CUSTIS Meetup: Микросервисы в Enterprise (16 марта 2017 года, Москва).
От монолитных моделей предметной области — к модульнымCUSTIS
Выступление Максима Цепкова, нашего главного архитектора дирекции развития решений, на World Information Architecture Day (18 февраля 2017 года, Санкт-Петербург).
Будущее omni-channel маркетинга: инструменты, кейсы и цифрыCUSTIS
Выступление Артема Казакова, директора по маркетингу Retail Rocket, на бизнес-завтраке «К 2017 готовы: продвинутые инструменты маркетинга для интернет-магазинов» (13 декабря 2016 года, Москва).
Опыт применения метода ATAM для оценки архитектурыCUSTIS
Выступление Игоря Беспальчука, нашего руководителя проектов дирекции архитектуры, на заседании русского отделения INCOSE (9 ноября 2016 года, Москва).
Видеозапись выступления:
https://vimeo.com/190918892
Process и Case Management в информационной системе: от автоматизации As Is к ...CUSTIS
Выступление Максима Цепкова, нашего главного архитектора дирекции развития решений, на ежегодной конференции CEE-SECR – 2016 (29 октября 2016 года, Москва).
Process и Case Management в информационной системе: от автоматизации As Is к ...
Гибкость: как правильно жить и работать?
1. Круглый стол
«Гибкость: как правильно
жить и работать?»
Михаил Заборов
руководитель стратегических проектов
2 декабря 2013 года
2. Компания CUSTIS
Существует с 1996 года
Agile-like процесс –
с рождения
Занимается заказной
разработкой промышленного
корпоративного ПО
2/111
3. Внедрение SCRUM в CUSTIS
Андрей
Бибичев
Асхат Уразбаев
Первое внедрение – в 2007
Внедрял Асхат Уразбаев
В 2009–2010 – регулярные встречи Agile Russia
на нашей территории
3/111
4. Сегодня
В компании 20+ человек
90% используют похожий
на SCRUM процесс
В компании более
20 производственных команд
4/111
5. Немного про меня
С критическим прищуром и перпендикулярным мнением
5/111
7. Восприятие SCRUM
Только использование канонических
процессов SCRUM дает действительно
существенный позитивный результат
Более мягкая формулировка
Практики SCRUM зависят друг от друга,
образуют систему и наибольший эффект
получается при их совместном
использовании
7/108
8. В результате
«Вы используете неправильный SCRUM
и поэтому у вас все плохо».
А СКРАМ-то
НЕНАСТОЯЩИЙ!!!
Это не по Scrum-у!!!
8/111
10. Разновидность
«Вы просто еще не пробовали пользоваться
настоящим SCRUM – попробуйте и вы
увидите разницу».
10/111
11. Мой опыт
SCRUM в чистом виде практически
бесполезен, а иногда и наносит
существенный вред
Его нужно адаптировать под себя. Не нужно
его фетишизировать и добиваться
пуританской чистоты
11/111
16. Крупные темы которые можно
обсудить
Философия
C самомотивацией все не так просто
Самоорганизация от сырости не заводится
Практические
Роли в SCRUM (в т.ч. про классовую вражду
и немного про профессию тестировщиков)
SCRUM планирование расслабляет команду
Резюме
16/111
17. Мелкие темы которые можно
обсудить
Требования к итерациям в SCRUM
избыточно жесткие
Ретроспектива по SCRUM’овски –
практически бесполезное занятие
Чаще всего DSM вырождается в пустой
гундеж
В SCRUM’е демонстрация упрощена
до бесполезности
Резюме
17/111
18. Где еще скрам не помогает, а
иногда даже мешает
Архитектура
Работа с персоналом
Долгосрочное планирование
Ресурсное планирование (в том числе
краткосрочное увеличение/уменьшение
команды)
Резюме
18/111
20. Про самомотивацию
Над проектом должны работать
мотивированные профессионалы
Чтобы работа была сделана, создайте
условия, обеспечьте поддержку
и полностью доверьтесь им
Agile
Manifesto
20/111
22. Системы ценностей разных людей
сильно отличаются
Далеко не всегда то, за что готов платить заказчик,
мотивирует разработчиков
То, что ценно для разработчика, для заказчика
может быть странной, никому не нужной
самореализацией (самоудовлетворение).
То, что ценно для заказчика - для программиста
может быть порождением воспаленного разума и
непонятная, неведомая фигня.
Люди склонны оценивать многие, даже сложные
задачи как рутинные
22/111
24. Ценности меняются
Цели и задачи заказчиков регулярно
меняются. Agile рассчитан именно на такие
проекты
“
Делали учетную систему, а в результате
оказалась просто интеграция
”
То, что было интересным когда-то,
со временем становится рутиной
“
Я всю жизнь строю эти дурацкие мосты
”
24/111
25. Самомотивированные на результат
проекта профессионалы крайне
редки
Есть много людей, которым не очень
много нужно от жизни
Еще больше людей, которые не знают,
чего на самом деле хотят
Нужны очень эмоционально и ментально
зрелые люди. Разработчики же
в основном молодежь
25/111
28. Ориентированные на внешний мир
Получить в портфолио сделанный проект
и тем самым повысить свою ценность
Получить признание уважаемых людей
(друзей, родственников, коллег)
Много конъюнктуры
и контуженных гламуром
людей
28/111
29. Сделать что-то «хорошее»
и «клёвое» – другая мотивация
В общем случае противоречит мотивации
на результат проекта
Безусловно должна присутствовать
в команде
29/111
31. От скрама мотивация не заводится
Никакая организационная конструкция
(в том числе, SCRUM) не может создать
мотивацию
В начале вы набираете команду
мотивированных людей, а потом заводите
SCRUM
31/111
32. От скрама мотивация может
испортиться
Мотивированные на результат люди
обычно хотят напрямую видеть этот
результат и влиять на него. Proxy в виде
ProductOwner-а их демотивирует
Ритуалы могут утомлять. Любую хорошую
идею можно довести до абсурда
Если вы хотите чистый SCRUM,
вам нужно регулярно чистить команду
от тех, кто «не восторженно мыслит»
32/111
34. Алистер Коберн
Нет корреляции между успехом/провалом
проектов и методологиями, которые применялись
в проектах
Успешность программного проекта на 100%
определяется людьми
34/111
37. Про самоорганизацию
Команда – черный ящик, она подстраивает
себя сама
Оставьте ее в покое, и она сама решит все
проблемы
Единственный способ повлиять на нее –
добавить/удалить людей
или разогнать
SCRUMевангелисты
37/111
39. Команда далеко не всегда самоорганизуется
эффективным для производства способом
Правильно ли называть
это «самоорганизацией»?
Самоорганизация – результат долгой кропотливой
работы специальных людей
39/108
40. Пример: Product Owner отстранился
от принятия решений
Постоянные
конфликты
Непродуктивные
обсуждения того, что
можно не обсуждать
Команду пришлось
резать по живому
40/111
44. Варианты
действий
Маша сотрудничает
Маша и Петя находят
компромисс
Петя
В результате оба немного
сотрудничает перерабатывают
Продукт выходит вовремя
Петя
заботится
о себе
Петя делает работу в притык,
так что времени
тестирование и исправление
ошибок не остается
Маша работает в выходные
и по ночам
Часть ошибок остается
неисправленными
Маша заботится о себе
Маша требует много времени на
тестирование
Петя работает в выходные и по
ночам чтобы успеть
к сроку
Маша требует много времени на
тестирование
Петя делает работу
впритык, так что времени
на тестирование
и исправление ошибок
не остается
Сроки срываются
44/111
45. Равновесие Нэша
Тип решений игры, в котором ни один
участник не может увеличить выигрыш,
изменив своё решение в одностороннем
порядке, когда другие участники
не меняют решения
Равновесие
Парето
Молчит
Молчит
3 месяца
Равновесие
Нэша
Сдает
свободен
20 лет
Сдает
свободен
20 лет
5 лет
45/111
47. Нужен выделенный координирующий
человек с полномочиями
В ситуации быстро меняющихся
требований нужно быстро реагировать
Все это требует координации и
выделенного человека, который
держит на этом фокус
47/111
48. Даже самомотивированным людям
нужно транслировать смысл задач
заказчика
В том числе :
Показывать как именно мир становится лучше
Показывать живых людей, которым становится
лучше
48/111
49. Если у исполнителей мотивация не на результат
проекта ($, комфорт, самоудовлетворение),
то работать с ними нужно по другому (не чистый
скрам)
Работа руководителя
превращать желания
заказчика в мотиваторы
исполнителей
Том Сойер
49/108
51. Иногда есть прямой смысл
поставить ответственного
за задачу целиком
Это
противоречит
чистому SCRUM
51/111
52. На этапе начальной разработки
Для плохо проработанных задачи
Для обеспечения квалификационного роста
сотрудника
Для оценки квалификации сотрудника
Для повышения ответственности и мотивации
сотрудника
Для повышения эффективности и минимизации
рисков
Для контроля качества исполнения
Для дублирования компетенций
52/111
53. Еще про распределение работ
в команде
Кроссфункциональность противоречит
эффективности, нужен разумный
баланс
Нужно дублирование, а не полная
кроссфункциональность
Баланс в каждом
случае свой
53/111
57. В противовес классическому
руководителю:
PO!=Руководитель
PO не член команды. Нечего РО лезть во
внутренности
Обязательно нужен Sсrum Master
SM и PO не один человек
У SM нет никаких полномочий
SCRUMевангелисты
57/111
59. Мнение # 1: Менеджер – это
вредный элемент. Его нужно
экранировать от команды
59/108
60. Нужно экранировать свиней
от цыплят
Свиньи создают продукт, тогда как цыплята
заинтересованы, но не настолько, – ведь им всё равно,
будет проект удачным или нет, на них это мало отразится
Требования, пожелания, идеи и влияние цыплят
принимаются во внимание, но им не разрешают
непосредственно включаться в ход SCRUM-проекта.
60/111
63. Тупые и некомпетентные менеджеры
мешают делать работу
компетентным исполнителям
Скрам-мастеру нельзя дать
Менеджерофобия
полномочия руководителя – иначе он
сразу станет тупым менеджером
Пусть менеджер занимается своим
менеджерскими делами, а команда
займется реальным делом
Команда лучше самоорганизуется без
руководителя
63/111
65. Команда в позиции «попробуйте
меня уговорить»
«Докажи всем в команде, что твое
предложение не дурацкое»
Сильное ограничение власти
руководителя
Вместо сотрудничества – борьба
65/111
66. Плохо работает, когда руководитель –
это самый сильный человек в команде
(с точки зрения влияния на конечный
результат) с богатым опытом проектной
деятельности
Руководитель
66/108
69. Мнение # 2: Руководитель
со всем не справляется, ему
нужно помочь
69/111
70. Избавляем руководителя
от ненужной работы
Отделяем определение «что делать» (PO) от «Как
делать» (Команда)
PO должен по возможности общаться в терминах
ФИЧ и проблем, которые он хотел решить
PO не нужно общаться с каждым членом команды
Основные интерфейсы общения – Backlog
и демонстрация
Не нужно заранее закреплять задачу
на исполнителе
70/111
71. Почему именно так ему нужно
помогать?
Понятие Product Owner – в общем-то
из продуктовой разработки
или InHouse
Для заказного софта подходит не
очень сильно. Кто PO? Заказчик или
человек из компании?
71/111
73. Конструкция с замотивированным на результат
руководителем и небольшим ядром команды,
влияющих на остальную команду, более реалистична
чем вся команда ориентированная на результат
Сложно искать хорошего руководителя
Найти пару PO+SM ни разу не проще!
Может превратится в command&control в худшем
виде
Отделение от команды только маскирует и
затягивает проблему «плохих» менеджеров. Ее
нужно решать в любом случаем
Я не предлагаю вернуть обратно директивное
управление менеджером. Я предлагаю сдвинуть
баланс в сторону руководителя
73/108
74. PO и SM, схожие навыки
Системное
мышление
Эмпатия
Коммуникация
Активная позиция
74/111
77. Оценка и Velocity
Необходимость оценивать задачи
в каких-либо попугаях
при планировании
Необходимо мерять скорость команды
SCRUMевангелисты
77/111
78. Люди плохо оценивают время
Например: Люди по разному оценивают
в зависимости от того, знают ли они, кто
будет делать эту задачу
78/111
79. Недостатки оценки
Оценка стоит денег и очень
существенных
Само по себе наличие оценки вносит
существенное возмущение в процесс
разработки. Она влияет на реальную
скорость работы и задает жесткое
ограничение
79/111
80. Андрей
Бибичев
Модель 1. Пуассоновское распределение. Поток
случайных задержек, сроки отодвигаются из-за него
Модель 2. Броуновское движение. Нас бомбардируют
отклонения от пути... Общая траектория становится
длиннее
Модель 3. PERT. Бета-распределение. Кривая
получается похожая
80/111
81. В результате такой график
вероятности затрат на разработку
Перестраховка
Оптимист - Идеальная ситуация .сделаем если ничего не
предвиденного не случится
Реалист – наиболее вероятное значение реальных затрат. Оценка
опытных разработчиков. Вероятность, что она занижена достаточно
высока (~70%)
Перестраховка – если космос не рухнет на землю, то точно уложимся
81/111
82. Команде выгоднее
давать оценки типа
«перестраховка»
Реально работа
занимает все
отведенное под нее
время
В результате команда
переходит
в расслабленное
состояние
«Че-то мы не успеваем. Давайте понизим
фокус фактор!»
82/111
83. Даже при перестраховке, все равно существует
5% вероятности, что мы не уложимся
При очень большом количестве работ, такие
ситуации все равно случаются, и мы имеем
очень неприятные разговоры с Закачиком:
«Вы и так многократно заложились
и все равно не успели»
Это заставляет команду давать еще более
консервативные оценки. Команда становится
еще медленнее, но при этом более
раздраженной
83/111
84. Вместо того, чтобы планировать «как мы сделаем
то, что нужно, к нужному сроку», мы планируем то,
что успеет команда в ближайшую итерацию.
Первичным становится комфорт команды,
а не потребности заказчика
84/111
86. Про итерации
У итерации фиксированная длина
У итерации фиксированный SCOPE
86/111
87. Избыточная жесткость
Итерация нужна для планирования работ
группами и создания точек синхронизации
Итерации бьются из абстрактного удобства
разработчика, а не удобства получения
результата (точки синхронизации не тогда,
когда нужно)
Регулярно прилетают неожиданные задачи,
которые сдвигают сроки и скоуп. А иногда
делают итерацию бессмысленной
Нет возможности «подруливать» итерацией
в процессе (удалять задачи и/или
увеличивать сроки)
87/111
89. Про ретроспективу
Нужно проводить ретро в конце каждой
итерации
Ретро – это внутреннее дело команды
Команда без ретро – это плохо
После ретро нужно делать Бэклог
на решение проблем
89/111
90. Про ретроспективу
Команда (да и люди вообще) чаще всего
не в состоянии себя запроблематизировать
В результате обсуждается ерунда , мало
влияющие на процесс
Большинство реальных рычагов изменений
(нанять, уволить, поднять зарплату,
поговорить по душам, выделить время,
купить сервер, купить библиотеку и т.д.) –
не внутри команды
Команда, которая не успевает делать свои
текущие дела, вряд ли успеет сделать
их одновременно с задачами
из дополнительного бэклога
90/111
92. Про DSM
Нужно проводить DSM каждый день
в одно время
Должна присутствовать вся команда
Обсуждаем кто-что сделал за день,
что будет завтра и какие есть
проблемы
Ограничиваем DSM пятью минутами
92/111
93. Про DSM
Формальное действие, которое всех несколько
утомляет (ритуал)
Обычно народ бубнит себе что-то под нос, и его
почти не слушают
Проблемы практически никогда не обсуждаются
Никаких решений на ДСМ не принимают. ДСМ не
влияет на то, чем люди будут заниматься в рабочем
процессе
Как только начинается реально интересное
обсуждение – его тут же сворачивают (ДСМ – 5
минут)
Искусственная мотивация посещения ДСМ (плюшки,
штрафы, кармические бонусы)
93/111
95. Про Демонстрацию
Демо нужно производить после каждой
итерации
На демо нужно звать всех
заинтересованных лиц
На демо нужно показывать все,
что сделали за итерацию
95/111
96. Про Демонстрацию
Внешним стейкходерам зачастую скучны 60% подробностей,
которые рассказываются
Членам команды, напротив, обычно интересно и полезно
знать детали реализации, чтобы иметь более полную
информацию о проекте
Внешним стейкхолдерам и команде результат можно
показывать в разном состоянии сырости
Бесконечные баги и сбои на демо раздражают заказчиков
К внешнему демо нужно готовиться тщательнее
От членов команды, наоборот хочется получить реакцию
побыстрее
Разным стейкхолдерам интересны разные вещи. Им нужны
разные демо
Неправильно подстраивать внешних стейкхолдеров
под внутренний ритм проекта. Демо нужно устраивать, когда им
удобно
96/111
98. Вместо резюме
Все практики носят рекомендательный
характер
Вы используете их на свой страх и риск
Вы можете изменять практики в
соответствии с проектной необходимостью
и собственными представлениями
При применении подключайте голову
Ни одна из практик не является
обязательной
98/111
100. Agile Manifesto 2.1
Teamwork & responsibility over Individuals
and Interaction
Business Value over Working software
Prepare for change over Respond to Change
Partnership elaboration over Customer
collaboration
100/111
101. Разработка ПО как конвейерное
производство
Энтони Лаудер. Культуры программных проектов (2008)
101/111
102. Спланируйте наперёд
Напишите детальные спецификации продукта, включая
необходимые стандарты качества
Разбейте работу на последовательность нескольких стадий
Опишите оптимальную последовательность простых
повторяемых действий, необходимых на каждом из таких
рабочих мест
Посчитайте время, необходимое для выполнения каждого
действия, и выработайте соответствующее расписание для
каждой стадии, включая время начала и окончания для всего
проекта
Определите ресурсы (материалы, стоимость труда, станки,
инструменты, и т.д.), необходимые для каждого действия.
Просуммируйте их, чтобы определить стоимость каждой стадии
и весь бюджет проекта
Определите специализированные роли для рабочих на каждой
стадии
102/111
103. Начните производство согласно
плану:
Возьмите работников из доступного
персонала и назначьте их на рабочие
места, определённые в плане
Прикажите рабочим выполнять
повторяющиеся действия, предписанные
на каждом месте, со скоростью,
необходимой для завершения проекта
вовремя и в рамках бюджета
Нажмите кнопку «Пуск», чтобы запустить
производство
103/111
104. Мониторинг и Контроль:
Непрерывно проверяйте:
Рабочих на местах, чтобы убедиться, что они
выполняют действия согласно плану
Темпы производства, чтобы укладываться в расписание
Конечную продукцию на предмет соответствия
стандартам качества
Потребление экономических ресурсов, чтобы проект
укладывался в бюджет
Там, где инспекция находит проблемы, справьтесь с ними:
Остановите производство
Исправьте причину проблемы, где возможно, путём:
Починки сломанного оборудования
Крика и запугивания рабочих
Перезапустите производство
104/111
105. Мониторинг и Контроль:
Там, где причина проблемы не может быть
устранена, попробуйте следующие
методы:
Увеличьте бюджет
Добавьте рабочих к конвейеру
Предложите экономические льготы
рабочим
Добавьте ещё один конвейер
Увеличьте сроки проекта
Измените спецификации продукта
Отмените проект
105/111
106. Разработка ПО:
Менеджеры создают план проекта,
разбивающий необходимую работу
на несколько стадий с чёткими временными
и стоимостными рамками для каждой стадии,
а значит, и для всего проекта в целом
Рабочие берутся из имеющегося персонала и
назначаются последовательно на различные
стадии проекта
На каждой стадии рабочие периодически
пишут status report, чтобы менеджеры могли
следить за прогрессом
106/111
107. Стадии:
Стадия требований: cпецификации продукта заранее
записываются заказчиком или другим авторизованным
человеком, тем самым переводя их бизнес потребности в
спецификационный документ.
Стадия анализа: аналитик переводит спецификации продукта в
полные фиксированные функциональные требования
к программному приложению, производя документ с
функциональными требованиями.
Стадия дизайна: дизайнер переводит функциональные
требования в чёткую и ясную архитектуру приложения,
формируя технический дизайн.
Стадия кодирования: программист, следуя техническому
дизайну, пишет программный код.
Стадия контроля качества: тестировщики проверяют
функционал программного кода, чтобы удостовериться в том,
что он соответствует всем требованиям из вышеупомянутых
документов.
Обратно
107/111