Выступление Михаила Заборова, нашего руководителя стратегических проектов, на круглом столе Московского клуба тестировщиков в Deutsche Bank (2 декабря 2013 года, Москва).

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

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

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

8. В результате
«Вы используете неправильный SCRUM
и поэтому у вас все плохо».
А СКРАМ-то
НЕНАСТОЯЩИЙ!!!
Это не по Scrum-у!!!
8/111

9. ScrumButt
 «We’ve got SCRUM, but…»
9/111

10. Разновидность
«Вы просто еще не пробовали пользоваться
настоящим SCRUM – попробуйте и вы
увидите разницу».
10/111

11. Мой опыт
SCRUM в чистом виде практически
бесполезен, а иногда и наносит
существенный вред
Его нужно адаптировать под себя. Не нужно
его фетишизировать и добиваться
пуританской чистоты
11/111

12. При этом почти ничего плохого
про Agile
≠
12/111

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

14. И немного принципов
14/111

15. Обсуждение
15/111

16. Крупные темы которые можно
обсудить

Философия



C самомотивацией все не так просто
Самоорганизация от сырости не заводится
Практические

Роли в SCRUM (в т.ч. про классовую вражду
и немного про профессию тестировщиков)

SCRUM планирование расслабляет команду
Резюме
16/111

17. Мелкие темы которые можно
обсудить

Требования к итерациям в SCRUM
избыточно жесткие

Ретроспектива по SCRUM’овски –
практически бесполезное занятие

Чаще всего DSM вырождается в пустой
гундеж

В SCRUM’е демонстрация упрощена
до бесполезности
Резюме
17/111

18. Где еще скрам не помогает, а
иногда даже мешает




Архитектура
Работа с персоналом
Долгосрочное планирование
Ресурсное планирование (в том числе
краткосрочное увеличение/уменьшение
команды)
Резюме
18/111

19. Про самомотивацию
19/111

20. Про самомотивацию
 Над проектом должны работать

мотивированные профессионалы
Чтобы работа была сделана, создайте
условия, обеспечьте поддержку
и полностью доверьтесь им
Agile
Manifesto
20/111

21. Что есть самомотивация?
21/111

22. Системы ценностей разных людей
сильно отличаются
 Далеко не всегда то, за что готов платить заказчик,
мотивирует разработчиков
 То, что ценно для разработчика, для заказчика
может быть странной, никому не нужной
самореализацией (самоудовлетворение).
 То, что ценно для заказчика - для программиста
может быть порождением воспаленного разума и
непонятная, неведомая фигня.
 Люди склонны оценивать многие, даже сложные
задачи как рутинные
22/111

23. Матрица компетентность–интерес
23/111

24. Ценности меняются
 Цели и задачи заказчиков регулярно
меняются. Agile рассчитан именно на такие
проекты
“
Делали учетную систему, а в результате
оказалась просто интеграция
”
 То, что было интересным когда-то,
со временем становится рутиной
“
Я всю жизнь строю эти дурацкие мосты
”
24/111

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

26. Примеры мотиваторов
на результат проекта
26/111

27. Самодостаточные люди

Разобраться, как работает сложный
бизнес


Сделать мир чуть лучше
Помочь хорошим людям
27/111

28. Ориентированные на внешний мир

Получить в портфолио сделанный проект
и тем самым повысить свою ценность

Получить признание уважаемых людей
(друзей, родственников, коллег)
Много конъюнктуры
и контуженных гламуром
людей 
28/111

29. Сделать что-то «хорошее»
и «клёвое» – другая мотивация

В общем случае противоречит мотивации
на результат проекта

Безусловно должна присутствовать
в команде
29/111

30. Влияние SCRUM на мотивацию
30/111

31. От скрама мотивация не заводится
 Никакая организационная конструкция
(в том числе, SCRUM) не может создать
мотивацию
 В начале вы набираете команду
мотивированных людей, а потом заводите
SCRUM
31/111

32. От скрама мотивация может
испортиться
 Мотивированные на результат люди
обычно хотят напрямую видеть этот
результат и влиять на него. Proxy в виде
ProductOwner-а их демотивирует
 Ритуалы могут утомлять. Любую хорошую
идею можно довести до абсурда
 Если вы хотите чистый SCRUM,
вам нужно регулярно чистить команду
от тех, кто «не восторженно мыслит»
32/111

33. Мотивированным людям
и без скрама хорошо
33/111

34. Алистер Коберн


Нет корреляции между успехом/провалом
проектов и методологиями, которые применялись
в проектах
Успешность программного проекта на 100%
определяется людьми
34/111

35. Обсуждение
Список Тем
35/111

36. Про самоорганизацию
36/111

37. Про самоорганизацию
 Команда – черный ящик, она подстраивает


себя сама
Оставьте ее в покое, и она сама решит все
проблемы
Единственный способ повлиять на нее –
добавить/удалить людей
или разогнать
SCRUMевангелисты
37/111

38. 38/108

39. Команда далеко не всегда самоорганизуется
эффективным для производства способом
Правильно ли называть
это «самоорганизацией»?
Самоорганизация – результат долгой кропотливой
работы специальных людей
39/108

40. Пример: Product Owner отстранился
от принятия решений

Постоянные
конфликты

Непродуктивные
обсуждения того, что
можно не обсуждать

Команду пришлось
резать по живому
40/111

41. Возможное объяснение
из теории игр
41/111

42. Дилемма заключенного
Молчит
Молчит
Сдает
3 месяца
свободен
20 лет
Сдает
свободен
20 лет
5 лет
42

43. Маша тестирует задачу,
сделанную Петей
в условиях жестких сроков
и дефицита времени
43/111

44. Варианты
действий
Маша сотрудничает
Маша и Петя находят
компромисс
Петя
В результате оба немного
сотрудничает перерабатывают
Продукт выходит вовремя
Петя
заботится
о себе
Петя делает работу в притык,
так что времени
тестирование и исправление
ошибок не остается
Маша работает в выходные
и по ночам
Часть ошибок остается
неисправленными
Маша заботится о себе
Маша требует много времени на
тестирование
Петя работает в выходные и по
ночам чтобы успеть
к сроку
Маша требует много времени на
тестирование
Петя делает работу
впритык, так что времени
на тестирование
и исправление ошибок
не остается
Сроки срываются
44/111

45. Равновесие Нэша
Тип решений игры, в котором ни один
участник не может увеличить выигрыш,
изменив своё решение в одностороннем
порядке, когда другие участники
не меняют решения
Равновесие
Парето
Молчит
Молчит
3 месяца
Равновесие
Нэша
Сдает
свободен
20 лет
Сдает

свободен
20 лет
5 лет
45/111

46. Слаженность действий
46/111

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

48. Даже самомотивированным людям
нужно транслировать смысл задач
заказчика
 В том числе :
 Показывать как именно мир становится лучше
 Показывать живых людей, которым становится
лучше
48/111

49. Если у исполнителей мотивация не на результат
проекта ($, комфорт, самоудовлетворение),
то работать с ними нужно по другому (не чистый
скрам)
Работа руководителя
превращать желания
заказчика в мотиваторы
исполнителей
Том Сойер
49/108

50. Руководителю нужно
работать с людьми
индивидуально
50/111

51. Иногда есть прямой смысл
поставить ответственного
за задачу целиком
Это
противоречит
чистому SCRUM
51/111

52.  На этапе начальной разработки
 Для плохо проработанных задачи
 Для обеспечения квалификационного роста
сотрудника
 Для оценки квалификации сотрудника
 Для повышения ответственности и мотивации
сотрудника
 Для повышения эффективности и минимизации
рисков
 Для контроля качества исполнения
 Для дублирования компетенций
52/111

53. Еще про распределение работ
в команде
 Кроссфункциональность противоречит
эффективности, нужен разумный
баланс
 Нужно дублирование, а не полная
кроссфункциональность
Баланс в каждом
случае свой
53/111

54. Ситуационный менеджмент
54/111

55. Обсуждение
Список Тем
55/111

56. Про роли в скраме
56/111

57. В противовес классическому
руководителю:
 PO!=Руководитель
 PO не член команды. Нечего РО лезть во



внутренности
Обязательно нужен Sсrum Master
SM и PO не один человек
У SM нет никаких полномочий
SCRUMевангелисты
57/111

58. Почему собственно?
Почему не оставить
руководителей?
58/111

59. Мнение # 1: Менеджер – это
вредный элемент. Его нужно
экранировать от команды
59/108

60. Нужно экранировать свиней
от цыплят

Свиньи создают продукт, тогда как цыплята
заинтересованы, но не настолько, – ведь им всё равно,
будет проект удачным или нет, на них это мало отразится

Требования, пожелания, идеи и влияние цыплят
принимаются во внимание, но им не разрешают
непосредственно включаться в ход SCRUM-проекта.
60/111

61. Четкая ассоциация менеджеров
с заводской культурой
Профессия
тестировщика,
к сожалению,
тоже оттуда 
Подробно
61/111

62. Классовая
борьба
62/108

63. Тупые и некомпетентные менеджеры
мешают делать работу
компетентным исполнителям
 Скрам-мастеру нельзя дать


Менеджерофобия
полномочия руководителя – иначе он
сразу станет тупым менеджером
Пусть менеджер занимается своим
менеджерскими делами, а команда
займется реальным делом
Команда лучше самоорганизуется без
руководителя
63/111

64. SCRUM
Команда
64/108

65. Команда в позиции «попробуйте
меня уговорить»
 «Докажи всем в команде, что твое
предложение не дурацкое»
 Сильное ограничение власти
руководителя
 Вместо сотрудничества – борьба
65/111

66. Плохо работает, когда руководитель –
это самый сильный человек в команде
(с точки зрения влияния на конечный
результат) с богатым опытом проектной
деятельности
Руководитель
66/108

67. Примеры таких конструкций
в жизни
67/111

68. 
Есть мнение что,
все
интеллектуальные
профессиональные
услуги так устроены
Дэвид Майстер
68/111

69. Мнение # 2: Руководитель
со всем не справляется, ему
нужно помочь
69/111

70. Избавляем руководителя
от ненужной работы
 Отделяем определение «что делать» (PO) от «Как
делать» (Команда)
 PO должен по возможности общаться в терминах
ФИЧ и проблем, которые он хотел решить
 PO не нужно общаться с каждым членом команды
Основные интерфейсы общения – Backlog
и демонстрация
 Не нужно заранее закреплять задачу
на исполнителе
70/111

71. Почему именно так ему нужно
помогать?
 Понятие Product Owner – в общем-то
из продуктовой разработки
или InHouse
 Для заказного софта подходит не
очень сильно. Кто PO? Заказчик или
человек из компании?
71/111

72. 72/108

73. Конструкция с замотивированным на результат
руководителем и небольшим ядром команды,
влияющих на остальную команду, более реалистична
чем вся команда ориентированная на результат
Сложно искать хорошего руководителя

Найти пару PO+SM ни разу не проще!
Может превратится в command&control в худшем
виде
 Отделение от команды только маскирует и
затягивает проблему «плохих» менеджеров. Ее
нужно решать в любом случаем
Я не предлагаю вернуть обратно директивное
управление менеджером. Я предлагаю сдвинуть
баланс в сторону руководителя
73/108

74. PO и SM, схожие навыки

Системное
мышление



Эмпатия
Коммуникация
Активная позиция
74/111

75. Обсуждение
Список Тем
75/111

76. Про планирование
76/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

85. Обсуждение
Список Тем
85/111

86. Про итерации
 У итерации фиксированная длина
 У итерации фиксированный SCOPE
86/111

87. Избыточная жесткость
 Итерация нужна для планирования работ
группами и создания точек синхронизации
 Итерации бьются из абстрактного удобства
разработчика, а не удобства получения
результата (точки синхронизации не тогда,
когда нужно)
 Регулярно прилетают неожиданные задачи,
которые сдвигают сроки и скоуп. А иногда
делают итерацию бессмысленной
 Нет возможности «подруливать» итерацией
в процессе (удалять задачи и/или
увеличивать сроки)
87/111

88. Обсуждение
Список Тем
88/111

89. Про ретроспективу
 Нужно проводить ретро в конце каждой



итерации
Ретро – это внутреннее дело команды
Команда без ретро – это плохо
После ретро нужно делать Бэклог
на решение проблем
89/111

90. Про ретроспективу
 Команда (да и люди вообще) чаще всего
не в состоянии себя запроблематизировать
 В результате обсуждается ерунда , мало
влияющие на процесс
 Большинство реальных рычагов изменений
(нанять, уволить, поднять зарплату,
поговорить по душам, выделить время,
купить сервер, купить библиотеку и т.д.) –
не внутри команды
 Команда, которая не успевает делать свои
текущие дела, вряд ли успеет сделать
их одновременно с задачами
из дополнительного бэклога
90/111

91. Обсуждение
Список Тем
91/111

92. Про DSM
 Нужно проводить DSM каждый день
в одно время
 Должна присутствовать вся команда
 Обсуждаем кто-что сделал за день,
что будет завтра и какие есть
проблемы
 Ограничиваем DSM пятью минутами
92/111

93. Про DSM
 Формальное действие, которое всех несколько
утомляет (ритуал)
 Обычно народ бубнит себе что-то под нос, и его
почти не слушают
 Проблемы практически никогда не обсуждаются
 Никаких решений на ДСМ не принимают. ДСМ не
влияет на то, чем люди будут заниматься в рабочем
процессе
 Как только начинается реально интересное
обсуждение – его тут же сворачивают (ДСМ – 5
минут)
 Искусственная мотивация посещения ДСМ (плюшки,
штрафы, кармические бонусы)
93/111

94. Обсуждение
Список Тем
94/111

95. Про Демонстрацию
 Демо нужно производить после каждой
итерации
 На демо нужно звать всех
заинтересованных лиц
 На демо нужно показывать все,
что сделали за итерацию
95/111

96. Про Демонстрацию

Внешним стейкходерам зачастую скучны 60% подробностей,
которые рассказываются
 Членам команды, напротив, обычно интересно и полезно
знать детали реализации, чтобы иметь более полную
информацию о проекте
 Внешним стейкхолдерам и команде результат можно
показывать в разном состоянии сырости
 Бесконечные баги и сбои на демо раздражают заказчиков
 К внешнему демо нужно готовиться тщательнее
 От членов команды, наоборот хочется получить реакцию
побыстрее
 Разным стейкхолдерам интересны разные вещи. Им нужны
разные демо
 Неправильно подстраивать внешних стейкхолдеров
под внутренний ритм проекта. Демо нужно устраивать, когда им
удобно
96/111

97. Обсуждение
Список Тем
97/111

98. Вместо резюме

Все практики носят рекомендательный
характер


Вы используете их на свой страх и риск

Вы можете изменять практики в
соответствии с проектной необходимостью
и собственными представлениями

При применении подключайте голову
Ни одна из практик не является
обязательной
98/111

99. Дополнительные слайды
99/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

108. Откуда все пошло
108/111

109. Зачем мы внедряли SCRUM

…и получили ли
то, что хотели, –
тема отдельного
разговора
109/111

110. Долгий и тяжелый путь осознания
внутри компании
110/111

111. Спасибо!
Вопросы?
Михаил Заборов
mzaborov@custis.ru
111/111