2 декабря 2013 года

Круглый стол

«Гибкость: как правильно

жить и работать?»Михаил Заборов

руководитель стратегических проектов

Компания CUSTIS

Существует с 1996 года

Занимается заказной

разработкой промышленного

корпоративного ПО

Agile-like процесс –

с рождения

2/111

Внедрение SCRUM в CUSTIS

Первое внедрение – в 2007

Внедрял Асхат Уразбаев

В 2009–2010 – регулярные встречи Agile Russia

на нашей территории

Андрей

БибичевАсхат Уразбаев

3/111

Сегодня

В компании 20+ человек

В компании более

20 производственных команд

90% используют похожий

на SCRUM процесс

4/111

Немного про меня

С критическим прищуром и перпендикулярным мнением

5/111

Часто SCRUM воспринимается так:

6/111

Восприятие SCRUM

Более мягкая формулировка

Только использование канонических

процессов SCRUM дает действительно

существенный позитивный результат

Практики SCRUM зависят друг от друга,

образуют систему и наибольший эффект

получается при их совместном

использовании

7/108

В результате

«Вы используете неправильный SCRUM

и поэтому у вас все плохо».

А СКРАМ-то

НЕНАСТОЯЩИЙ!!!

Это не по Scrum-у!!!

8/111

ScrumButt

«We’ve got SCRUM, but…»

9/111

Разновидность

«Вы просто еще не пробовали пользоваться

настоящим SCRUM – попробуйте и вы

увидите разницу».

10/111

Мой опыт

SCRUM в чистом виде практически

бесполезен, а иногда и наносит

существенный вред

Его нужно адаптировать под себя. Не нужно

его фетишизировать и добиваться

пуританской чистоты

11/111

При этом почти ничего плохого

про Agile

≠

12/111

Agile это всего лишь манифест

13/111

И немного принципов

14/111

Обсуждение

15/111

Крупные темы которые можно

обсудить

Философия

C самомотивацией все не так просто

Самоорганизация от сырости не заводится

Практические

Роли в SCRUM (в т.ч. про классовую вражду

и немного про профессию тестировщиков)

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

Резюме

16/111

Мелкие темы которые можно

обсудить

Требования к итерациям в SCRUM

избыточно жесткие

Ретроспектива по SCRUM’овски –

практически бесполезное занятие

Чаще всего DSM вырождается в пустой

гундеж

В SCRUM’е демонстрация упрощена

до бесполезности

Резюме

17/111

Где еще скрам не помогает, а

иногда даже мешает

Архитектура

Работа с персоналом

Долгосрочное планирование

Ресурсное планирование (в том числе

краткосрочное увеличение/уменьшение

команды)

Резюме

18/111

Про самомотивацию

19/111

Про самомотивацию

Над проектом должны работать

мотивированные профессионалы

Чтобы работа была сделана, создайте

условия, обеспечьте поддержку

и полностью доверьтесь им

Agile

Manifesto

20/111

Что есть самомотивация?

21/111

Системы ценностей разных людей

сильно отличаются

Далеко не всегда то, за что готов платить заказчик,

мотивирует разработчиков

То, что ценно для разработчика, для заказчика

может быть странной, никому не нужной

самореализацией (самоудовлетворение).

То, что ценно для заказчика - для программиста

может быть порождением воспаленного разума и

непонятная, неведомая фигня.

Люди склонны оценивать многие, даже сложные

задачи как рутинные

22/111

Матрица компетентность–интерес

23/111

Ценности меняются

Я всю жизнь строю эти дурацкие мосты

Делали учетную систему, а в результате

оказалась просто интеграция

Цели и задачи заказчиков регулярно

меняются. Agile рассчитан именно на такие

проекты

То, что было интересным когда-то,

со временем становится рутиной

“”

“ ”24/111

Самомотивированные на результат

проекта профессионалы крайне

редки

Есть много людей, которым не очень

много нужно от жизни

Еще больше людей, которые не знают,

чего на самом деле хотят

Нужны очень эмоционально и ментально

зрелые люди. Разработчики же

в основном молодежь

25/111

Примеры мотиваторов

на результат проекта

26/111

Самодостаточные люди

Разобраться, как работает сложный

бизнес

Сделать мир чуть лучше

Помочь хорошим людям

27/111

Ориентированные на внешний мир

Получить в портфолио сделанный проект

и тем самым повысить свою ценность

Получить признание уважаемых людей

(друзей, родственников, коллег)

Много конъюнктуры

и контуженных гламуром

людей

28/111

Сделать что-то «хорошее»

и «клёвое» – другая мотивация

В общем случае противоречит мотивации

на результат проекта

Безусловно должна присутствовать

в команде

29/111

Влияние SCRUM на мотивацию

30/111

От скрама мотивация не заводится

Никакая организационная конструкция

(в том числе, SCRUM) не может создать

мотивацию

В начале вы набираете команду

мотивированных людей, а потом заводите

SCRUM

31/111

От скрама мотивация может

испортиться

Мотивированные на результат люди

обычно хотят напрямую видеть этот

результат и влиять на него. Proxy в виде

ProductOwner-а их демотивирует

Ритуалы могут утомлять. Любую хорошую

идею можно довести до абсурда

Если вы хотите чистый SCRUM,

вам нужно регулярно чистить команду

от тех, кто «не восторженно мыслит»

32/111

Мотивированным людям

и без скрама хорошо

33/111

Нет корреляции между успехом/провалом

проектов и методологиями, которые применялись

в проектах

Успешность программного проекта на 100%

определяется людьми

Алистер Коберн

34/111

Обсуждение

Список Тем 35/111

Про самоорганизацию

36/111

Про самоорганизацию

Команда – черный ящик, она подстраивает

себя сама

Оставьте ее в покое, и она сама решит все

проблемы

Единственный способ повлиять на нее –

добавить/удалить людей

или разогнать

SCRUM-

евангелисты

37/111

38/108

Команда далеко не всегда самоорганизуется

эффективным для производства способом

Самоорганизация – результат долгой кропотливой

работы специальных людей

Правильно ли называть

это «самоорганизацией»?

39/108

Пример: Product Owner отстранился

от принятия решений

Постоянные

конфликты

Непродуктивные

обсуждения того, что

можно не обсуждать

Команду пришлось

резать по живому

40/111

Возможное объяснение

из теории игр

41/111

Дилемма заключенного

Молчит

Мо

лч

ит

Сдает

Сд

ает

20 летсвободен

20 летсвободен

5 лет

3 месяца

42

Маша тестирует задачу,

сделанную Петей

в условиях жестких сроков

и дефицита времени

43/111

Варианты

действийМаша сотрудничает Маша заботится о себе

Петя

сотрудничает

Маша и Петя находят

компромисс

В результате оба немного

перерабатывают

Продукт выходит вовремя

Маша требует много времени на

тестирование

Петя работает в выходные и по

ночам чтобы успеть

к сроку

Петя

заботится

о себе

Петя делает работу в притык,

так что времени

тестирование и исправление

ошибок не остается

Маша работает в выходные

и по ночам

Часть ошибок остается

неисправленными

Маша требует много времени на

тестирование

Петя делает работу

впритык, так что времени

на тестирование

и исправление ошибок

не остается

Сроки срываются

44/111

Молчит

Мо

лч

ит

Сдает

Сд

ает

20 летсвободен

20 летсвободен

5 лет

3 месяца

Равновесие Нэша

Тип решений игры, в котором ни один

участник не может увеличить выигрыш,

изменив своё решение в одностороннем

порядке, когда другие участники

не меняют решения

Равновесие

Парето

Равновесие

Нэша

45/111

Слаженность действий

46/111

Нужен выделенный координирующий

человек с полномочиями

В ситуации быстро меняющихся

требований нужно быстро реагировать

Все это требует координации и

выделенного человека, который

держит на этом фокус

47/111

Даже самомотивированным людям

нужно транслировать смысл задач

заказчика

В том числе :

Показывать как именно мир становится лучше

Показывать живых людей, которым становится

лучше

48/111

Если у исполнителей мотивация не на результат

проекта ($, комфорт, самоудовлетворение),

то работать с ними нужно по другому (не чистый

скрам)

Работа руководителя

превращать желания

заказчика в мотиваторы

исполнителей

Том Сойер

49/108

Руководителю нужно

работать с людьми

индивидуально

50/111

Иногда есть прямой смысл

поставить ответственного

за задачу целиком

Это

противоречит

чистому SCRUM

51/111

На этапе начальной разработки

Для плохо проработанных задачи

Для обеспечения квалификационного роста

сотрудника

Для оценки квалификации сотрудника

Для повышения ответственности и мотивации

сотрудника

Для повышения эффективности и минимизации

рисков

Для контроля качества исполнения

Для дублирования компетенций

52/111

Еще про распределение работ

в команде

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

эффективности, нужен разумный

баланс

Нужно дублирование, а не полная

кроссфункциональность

Баланс в каждом

случае свой

53/111

Ситуационный менеджмент

54/111

Обсуждение

Список Тем 55/111

Про роли в скраме

56/111

В противовес классическому

руководителю:

PO!=Руководитель

PO не член команды. Нечего РО лезть во

внутренности

Обязательно нужен Sсrum Master

SM и PO не один человек

У SM нет никаких полномочий

SCRUM-

евангелисты

57/111

Почему собственно?

Почему не оставить

руководителей?

58/111

Мнение # 1: Менеджер – это

вредный элемент. Его нужно

экранировать от команды

59/108

Нужно экранировать свиней

от цыплят

Свиньи создают продукт, тогда как цыплята

заинтересованы, но не настолько, – ведь им всё равно,

будет проект удачным или нет, на них это мало отразится

Требования, пожелания, идеи и влияние цыплят

принимаются во внимание, но им не разрешают

непосредственно включаться в ход SCRUM-проекта.

60/111

Четкая ассоциация менеджеров

с заводской культурой

Профессия

тестировщика,

к сожалению,

тоже оттуда

Подробно

61/111

Классовая

борьба

62/108

Тупые и некомпетентные менеджеры

мешают делать работу

компетентным исполнителям

Скрам-мастеру нельзя дать

полномочия руководителя – иначе он

сразу станет тупым менеджером

Пусть менеджер занимается своим

менеджерскими делами, а команда

займется реальным делом

Команда лучше самоорганизуется без

руководителя

Менеджеро-

фобия

63/111

SCRUM

Команда

64/108

Команда в позиции «попробуйте

меня уговорить»

«Докажи всем в команде, что твое

предложение не дурацкое»

Сильное ограничение власти

руководителя

Вместо сотрудничества – борьба

65/111

Руководитель

Плохо работает, когда руководитель –

это самый сильный человек в команде

(с точки зрения влияния на конечный

результат) с богатым опытом проектной

деятельности

66/108

Примеры таких конструкций

в жизни

67/111

Есть мнение что,

все

интеллектуальные

профессиональные

услуги так устроены

Дэвид Майстер

68/111

Мнение # 2: Руководитель

со всем не справляется, ему

нужно помочь

69/111

Избавляем руководителя

от ненужной работы

Отделяем определение «что делать» (PO) от «Как

делать» (Команда)

PO должен по возможности общаться в терминах

ФИЧ и проблем, которые он хотел решить

PO не нужно общаться с каждым членом команды

Основные интерфейсы общения – Backlog

и демонстрация

Не нужно заранее закреплять задачу

на исполнителе

70/111

Почему именно так ему нужно

помогать?

Понятие Product Owner – в общем-то

из продуктовой разработки

или InHouse

Для заказного софта подходит не

очень сильно. Кто PO? Заказчик или

человек из компании?

71/111

72/108

Сложно искать хорошего руководителя

Найти пару PO+SM ни разу не проще!

Может превратится в command&control в худшем

виде

Отделение от команды только маскирует и

затягивает проблему «плохих» менеджеров. Ее

нужно решать в любом случаем

Конструкция с замотивированным на результат

руководителем и небольшим ядром команды,

влияющих на остальную команду, более реалистична

чем вся команда ориентированная на результат

Я не предлагаю вернуть обратно директивное

управление менеджером. Я предлагаю сдвинуть

баланс в сторону руководителя

73/108

PO и SM, схожие навыки

Системное

мышление

Эмпатия

Коммуникация

Активная позиция

74/111

Обсуждение

Список Тем

75/111

Про планирование

76/111

Оценка и Velocity

Необходимость оценивать задачи

в каких-либо попугаях

при планировании

Необходимо мерять скорость команды

SCRUM-

евангелисты

77/111

Люди плохо оценивают время

Например: Люди по разному оценивают

в зависимости от того, знают ли они, кто

будет делать эту задачу

78/111

Недостатки оценки

Оценка стоит денег и очень

существенных

Само по себе наличие оценки вносит

существенное возмущение в процесс

разработки. Она влияет на реальную

скорость работы и задает жесткое

ограничение

79/111

Модель 1. Пуассоновское распределение. Поток

случайных задержек, сроки отодвигаются из-за него

Модель 2. Броуновское движение. Нас бомбардируют

отклонения от пути... Общая траектория становится

длиннее

Модель 3. PERT. Бета-распределение. Кривая

получается похожая

Андрей

Бибичев

80/111

В результате такой график

вероятности затрат на разработку

Оптимист - Идеальная ситуация .сделаем если ничего не

предвиденного не случится

Реалист – наиболее вероятное значение реальных затрат. Оценка

опытных разработчиков. Вероятность, что она занижена достаточно

высока (~70%)

Перестраховка – если космос не рухнет на землю, то точно уложимся

Перестраховка

81/111

«Че-то мы не успеваем. Давайте понизим

фокус фактор!»

Команде выгоднее

давать оценки типа

«перестраховка»

Реально работа

занимает все

отведенное под нее

время

В результате команда

переходит

в расслабленное

состояние

82/111

«Вы и так многократно заложились

и все равно не успели»

Даже при перестраховке, все равно существует

5% вероятности, что мы не уложимся

При очень большом количестве работ, такие

ситуации все равно случаются, и мы имеем

очень неприятные разговоры с Закачиком:

Это заставляет команду давать еще более

консервативные оценки. Команда становится

еще медленнее, но при этом более

раздраженной

83/111

Вместо того, чтобы планировать «как мы сделаем

то, что нужно, к нужному сроку», мы планируем то,

что успеет команда в ближайшую итерацию.

Первичным становится комфорт команды,

а не потребности заказчика

84/111

Обсуждение

Список Тем

85/111

Про итерации

У итерации фиксированная длина

У итерации фиксированный SCOPE

86/111

Итерация нужна для планирования работ

группами и создания точек синхронизации

Итерации бьются из абстрактного удобства

разработчика, а не удобства получения

результата (точки синхронизации не тогда,

когда нужно)

Регулярно прилетают неожиданные задачи,

которые сдвигают сроки и скоуп. А иногда

делают итерацию бессмысленной

Нет возможности «подруливать» итерацией

в процессе (удалять задачи и/или

увеличивать сроки)

Избыточная жесткость

87/111

Обсуждение

Список Тем

88/111

Про ретроспективу

Нужно проводить ретро в конце каждой

итерации

Ретро – это внутреннее дело команды

Команда без ретро – это плохо

После ретро нужно делать Бэклог

на решение проблем

89/111

Команда (да и люди вообще) чаще всего

не в состоянии себя запроблематизировать

В результате обсуждается ерунда , мало

влияющие на процесс

Большинство реальных рычагов изменений

(нанять, уволить, поднять зарплату,

поговорить по душам, выделить время,

купить сервер, купить библиотеку и т.д.) –

не внутри команды

Команда, которая не успевает делать свои

текущие дела, вряд ли успеет сделать

их одновременно с задачами

из дополнительного бэклога

Про ретроспективу

90/111

Обсуждение

Список Тем

91/111

Про DSM

Нужно проводить DSM каждый день

в одно время

Должна присутствовать вся команда

Обсуждаем кто-что сделал за день,

что будет завтра и какие есть

проблемы

Ограничиваем DSM пятью минутами

92/111

Формальное действие, которое всех несколько

утомляет (ритуал)

Обычно народ бубнит себе что-то под нос, и его

почти не слушают

Проблемы практически никогда не обсуждаются

Никаких решений на ДСМ не принимают. ДСМ не

влияет на то, чем люди будут заниматься в рабочем

процессе

Как только начинается реально интересное

обсуждение – его тут же сворачивают (ДСМ – 5

минут)

Искусственная мотивация посещения ДСМ (плюшки,

штрафы, кармические бонусы)

Про DSM

93/111

Обсуждение

Список Тем

94/111

Про Демонстрацию

Демо нужно производить после каждой

итерации

На демо нужно звать всех

заинтересованных лиц

На демо нужно показывать все,

что сделали за итерацию

95/111

Внешним стейкходерам зачастую скучны 60% подробностей,

которые рассказываются

Членам команды, напротив, обычно интересно и полезно

знать детали реализации, чтобы иметь более полную

информацию о проекте

Внешним стейкхолдерам и команде результат можно

показывать в разном состоянии сырости

Бесконечные баги и сбои на демо раздражают заказчиков

К внешнему демо нужно готовиться тщательнее

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

побыстрее

Разным стейкхолдерам интересны разные вещи. Им нужны

разные демо

Неправильно подстраивать внешних стейкхолдеров

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

удобно

Про Демонстрацию

96/111

Обсуждение

Список Тем

97/111

Вместо резюме

Все практики носят рекомендательный

характер

Вы используете их на свой страх и риск

Ни одна из практик не является

обязательной

Вы можете изменять практики в

соответствии с проектной необходимостью

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

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

98/111

Дополнительные слайды

99/111

Agile Manifesto 2.1

Teamwork & responsibility over Individuals

and Interaction

Business Value over Working software

Partnership elaboration over Customer

collaboration

Prepare for change over Respond to Change

100/111

Разработка ПО как конвейерное

производство

Энтони Лаудер. Культуры программных проектов (2008)

101/111

Спланируйте наперёд

Напишите детальные спецификации продукта, включая

необходимые стандарты качества

Разбейте работу на последовательность нескольких стадий

Определите специализированные роли для рабочих на каждой

стадии

Опишите оптимальную последовательность простых

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

рабочих мест

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

действия, и выработайте соответствующее расписание для

каждой стадии, включая время начала и окончания для всего

проекта

Определите ресурсы (материалы, стоимость труда, станки,

инструменты, и т.д.), необходимые для каждого действия.

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

и весь бюджет проекта

102/111

Начните производство согласно

плану:

Возьмите работников из доступного

персонала и назначьте их на рабочие

места, определённые в плане

Прикажите рабочим выполнять

повторяющиеся действия, предписанные

на каждом месте, со скоростью,

необходимой для завершения проекта

вовремя и в рамках бюджета

Нажмите кнопку «Пуск», чтобы запустить

производство103/111

Мониторинг и Контроль:

Непрерывно проверяйте:

Рабочих на местах, чтобы убедиться, что они

выполняют действия согласно плану

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

Потребление экономических ресурсов, чтобы проект

укладывался в бюджет

Конечную продукцию на предмет соответствия

стандартам качества

Там, где инспекция находит проблемы, справьтесь с ними:

Остановите производство

Исправьте причину проблемы, где возможно, путём:

Починки сломанного оборудования

Крика и запугивания рабочих

Перезапустите производство 104/111

Мониторинг и Контроль:

Там, где причина проблемы не может быть

устранена, попробуйте следующие

методы:

Увеличьте бюджет

Предложите экономические льготы

рабочим

Добавьте рабочих к конвейеру

Добавьте ещё один конвейер

Увеличьте сроки проекта

Измените спецификации продукта

Отмените проект105/111

Разработка ПО:

Менеджеры создают план проекта,

разбивающий необходимую работу

на несколько стадий с чёткими временными

и стоимостными рамками для каждой стадии,

а значит, и для всего проекта в целом

Рабочие берутся из имеющегося персонала и

назначаются последовательно на различные

стадии проекта

На каждой стадии рабочие периодически

пишут status report, чтобы менеджеры могли

следить за прогрессом

106/111

Стадии:

Стадия требований: cпецификации продукта заранее

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

человеком, тем самым переводя их бизнес потребности в

спецификационный документ.

Стадия анализа: аналитик переводит спецификации продукта в

полные фиксированные функциональные требования

к программному приложению, производя документ с

функциональными требованиями.

Стадия дизайна: дизайнер переводит функциональные

требования в чёткую и ясную архитектуру приложения,

формируя технический дизайн.

Стадия кодирования: программист, следуя техническому

дизайну, пишет программный код.

Стадия контроля качества: тестировщики проверяют

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

что он соответствует всем требованиям из вышеупомянутых

документов.

Обратно 107/111

Откуда все пошло

108/111

Зачем мы внедряли SCRUM

…и получили ли

то, что хотели, –

тема отдельного

разговора

109/111

Долгий и тяжелый путь осознания

внутри компании

110/111

Спасибо!

Вопросы?

Михаил Заборов

mzaborov@custis.ru

111/111