1. Круглый стол
«Гибкость: как правильно
жить и работать?»
Михаил Заборов
руководитель стратегических проектов
2 декабря 2013 года

2. Компания CUSTIS


Существует с 1996 года

Agile-like процесс –
с рождения
Занимается заказной
разработкой промышленного
корпоративного ПО
2/108

3. Внедрение SCRUM в CUSTIS
Андрей
Бибичев



Асхат Уразбаев
Первое внедрение – в 2007
Внедрял Асхат Уразбаев
В 2009–2010 – регулярные встречи Agile Russia
на нашей территории
3/108

4. Сегодня


В компании 20+ человек

90% используют похожий
на SCRUM процесс
В компании более
20 производственных команд
4/108

5. Немного про меня
С критическим прищуром и перпендикулярным мнением

5/108

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

38. 38/108

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

72. 72/108

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

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

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

76. Про планирование
76/108

77. Оценка и Velocity
 Необходимость оценивать задачи
в каких-либо попугаях
при планировании
 Необходимо мерять скорость команды
SCRUMевангелисты
77/108

78. Люди плохо оценивают время
Например: Люди по разному оценивают в
зависимости от того, знают ли они кто
будет делать эту задачу
78/108

79. Недостатки оценки
 Оценка стоит денег и очень
существенных
 Само по себе наличие оценки вносит
существенное возмущение в процесс
разработки. Она влияет на реальную
скорость работы и задает жесткое
ограничение
79/108

80. Андрей
Бибичев

Модель 1. Пуассоновское распределение. Поток
случайных задержек, сроки отодвигаются из-за него

Модель 2. Броуновское движение. Нас бомбардируют
отклонения от пути... Общая траектория становится
длиннее

Модель 3. PERT. Бета-распределение. Кривая
получается похожая
80/108

81. В результате такой график
вероятности затрат на разработку
Перестраховка



Оптимист - Идеальная ситуация .сделаем если ничего не
предвиденного не случится
Реалист – наиболее вероятное значение реальных затрат. Оценка
опытных разработчиков. Вероятность, что она занижена достаточно
высока (~70%)
Перестраховка – если космос не рухнет на землю, то точно уложимся
81/108

82.  Команде выгоднее
давать оценки типа
«перестраховка»
 Реально работа
занимает все
отведенное под нее
время
 В результате команда
переходит
в расслабленное
состояние

«Чѐ-то мы не успеваем. Давайте понизим
фокус фактор!»
82/108

83.  Даже при перестраховке, все равно существует
5% вероятности, что мы не уложимся
 При очень большом количестве работ, такие
ситуации все равно случаются, и мы имеем
очень неприятные разговоры с Закачиком:

«Вы и так многократно заложились
и все равно не успели»
 Это заставляет команду давать еще более
консервативные оценки. Команда становится
еще медленнее, но при этом более
раздраженной
83/108

84.  Вместо того, чтобы планировать «как мы сделаем
то, что нужно, к нужному сроку», мы планируем то,
что успеет команда в ближайшую итерацию.
 Первичным становится комфорт команды, а не
потребности заказчика
84/108

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

100. Дополнительные слайды
100/108

101. 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
101/108

102. Разработка ПО как конвейерное
производство
 Энтони Лаудер. Культуры программных проектов (2008)
102/108

103. Спланируйте наперѐд

Напишите детальные спецификации продукта, включая
необходимые стандарты качества


Разбейте работу на последовательность нескольких стадий

Опишите оптимальную последовательность простых
повторяемых действий, необходимых на каждом из таких
рабочих мест

Посчитайте время, необходимое для выполнения каждого
действия, и выработайте соответствующее расписание для
каждой стадии, включая время начала и окончания для всего
проекта

Определите ресурсы (материалы, стоимость труда, станки,
инструменты, и т.д.), необходимые для каждого действия.
Просуммируйте их, чтобы определить стоимость каждой стадии
и весь бюджет проекта
Определите специализированные роли для рабочих на каждой
стадии
103/108

104. Начните производство согласно
плану:

Возьмите работников из доступного
персонала и назначьте их на рабочие
места, определѐнные в плане

Прикажите рабочим выполнять
повторяющиеся действия, предписанные
на каждом месте, со
скоростью, необходимой для завершения
проекта вовремя и в рамках бюджета

Нажмите кнопку «Пуск», чтобы запустить
производство
104/108

105. Мониторинг и Контроль:
Непрерывно проверяйте:

Рабочих на местах, чтобы убедиться, что они
выполняют действия согласно плану


Темпы производства, чтобы укладываться в расписание

Конечную продукцию на предмет соответствия
стандартам качества
Потребление экономических ресурсов, чтобы проект
укладывался в бюджет
Там, где инспекция находит проблемы, справьтесь с ними:





Остановите производство
Исправьте причину проблемы, где возможно, путѐм:
Починки сломанного оборудования
Крика и запугивания рабочих
Перезапустите производство
105/108

106. Мониторинг и Контроль:

Там, где причина проблемы не может быть
устранена, попробуйте следующие
методы:


Увеличьте бюджет





Добавьте рабочих к конвейеру
Предложите экономические льготы
рабочим
Добавьте ещѐ один конвейер
Увеличьте сроки проекта
Измените спецификации продукта
Отмените проект
106/108

107. Разработка ПО:

Менеджеры создают план
проекта, разбивающий необходимую работу
на несколько стадий с чѐткими временными
и стоимостными рамками для каждой
стадии, а значит, и для всего проекта в целом

Рабочие берутся из имеющегося персонала и
назначаются последовательно на различные
стадии проекта

На каждой стадии рабочие периодически
пишут status report, чтобы менеджеры могли
следить за прогрессом
107/108

108. Стадии:





Стадия требований: cпецификации продукта заранее
записываются заказчиком или другим авторизованным
человеком, тем самым переводя их бизнес потребности в
спецификационный документ.
Стадия анализа: аналитик переводит спецификации продукта в
полные фиксированные функциональные требования
к программному приложению, производя документ с
функциональными требованиями.
Стадия дизайна: дизайнер переводит функциональные
требования в чѐткую и ясную архитектуру приложения,
формируя технический дизайн.
Стадия кодирования: программист, следуя техническому
дизайну, пишет программный код.
Стадия контроля качества: тестировщики проверяют
функционал программного кода, чтобы удостовериться в том,
что он соответствует всем требованиям из вышеупомянутых
документов.
Обратно
108/108

109. Как это может быть
(один из вариантов):
Это не SCRUM, но по прежнему
Agile
109

110. Роли и их взаимодействие
110

111. • Команды 7-8 человек сидящие вместе
• Есть один человек ответственный за Backlog - PO=
Руководитель
• PO имеет право в тех случаях когда ему необходимо
проваливаться в любую детальность как ему хочется
• В тех местах, где PO уверен в команде он может
полагаться на самоорганизацию a-la SCRUM
• SM- помощник руководителя (если он нужен), с
полномочиями
111

112. Итерации
112

113. • Итерации могут быть разной длины (короткие 2-4
недели)
• Конец итерации назначается руководителем. Может
быть отодвинут им при желании.
• В конце итерации внутреннее демо на котором
руководитель смотрит промежуточный результат и
решает что делать с итерацией (продлить/закончить).
• Между итерациями могут появиться «санитарные
дни». Когда вся команда «чистит хвосты».
113

114. Планирование
114

115. • SCOPE итерации делится на 3 части:
• Сделать кровь-из носу
• Крайне желательно сделать
• Сделать если получится.
• На планировании рассказывают о задачах (в т.ч. откуда они
и зачем), их приоритетах (почему для бизнеса важно
получить задачу к такому сроку) обсуждаются варианты
реализации. Фиксируется SCOPE с командой (в 3х
градациях)
• Оценка задач на планировании не производится
(производится только если команда не в состоянии
подписаться на SCOPE без нее)
• Оценка производится только по требованию клиента/PO – и
это отдельная работа.
115

116. Ритуалы
116

117. • Нужен человек ответственный за процесс (может
быть PO, может быть SM. Может быть любой
назначенный человек из команды, который болеет
за результат – например инженер)
• Он решает назначать или нет DSM, Ретро и Демо
(Практики - инструмент, а не обязанность).
117

118. DSM назначается если:
• Есть подозрение что члены команды
инкапсулировались в своих задачах и не видят
общей картины
• Есть новые сотрудники
• Есть подозрение что будут сорваны сроки.
118

119. Различаем 2 типа демонстрации внутренние и
внешние
119

120. Внутреннее демо
• собирается только для команды и «сочувствующих».
• В конце (или ближе к концу) итерации
• Если есть необходимость
• Члены команды и/или PO чувствуют, что не
понимают что сделано соседями
• Руководитель хочет глубже понять состояние
проекта
• Есть новые сотрудники
120

121. Внешнее демо
• Делается отдельно для разных групп
стейкхолдеров
• Проводится в тот момент, когда удобно тем кто
будет смотреть
• Планируется как отдельная работа
• Не стоит на них экономить (Формирует
правильные ожидания и восприятие для
заказчиков (см мою презентацию про
клиентоориентированность))
121

122. Для получения быстрой обратной связи от заказчика
используется другие инструменты (не экономим на
этом):
• Макеты
• Модели
• Совещания
• Презентации
• И т.д.
122

123. Ретро
123

124. Каждый раз: думаем одно, говорим другое, делаем
третье, получается — то, что есть.
Потому что, слова — это пустой звук, а дела —
пустая трата времени.
Но, тем не менее, нужно делать всѐ как
должно, честно и с доверием.
Даосский принцип
124/108

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

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

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

128. 2006 год. Jeff Sutherland
Money For Nothing
QCon London 2006: Jeff Sutherland «Scrum and not-Scrum»
http://www.infoq.com/interviews/jeff-sutherland-scrum-rules
http://www.slideshare.net/gerrykirk/money-for-nothing-agile-2008-presentation
http://www.sprettur.is/media/slides2008/Iceland2008MoneyforNothing.pdf
128

129. Вводится понятие
Да-да 
http://www.sprettur.is/media/slides2008/Iceland2008MoneyforNothing.pdf
129

130. ScrumButt
«We’ve got SCRUM, but…»
130

131. SCRUM – это хорошо
http://www.sprettur.is/media/slides2008/Iceland2008MoneyforNothing.pdf
131

132. Но только настоящий
Покупайте
True
SCRUM
http://www.sprettur.is/media/slides2008/Iceland2008MoneyforNothing.pdf
132

133. Причем выигрыш демонстрируется
на примере русской компании
Exigen Services
133/108

134. http://www.sprettur.is/media/slides2008/Iceland2008MoneyforNothing.pdf
134

135. http://www.sprettur.is/media/slides2008/Iceland2008MoneyforNothing.pdf
135

136. Чтобы понять,
правильный ли у вас SCRUM,
был разработан Nokia Test
136/108

137. http://www.sprettur.is/media/slides2008/Iceland2008MoneyforNothing.pdf
137

138. Пример вопроса
http://www.sprettur.is/media/slides2008/Iceland2008MoneyforNothing.pdf
138

139. Nokia-тест
“
Nokia-тест – внутренний
инструмент Nokia, который
решал совершенно конкретную
задачу – унификации процессов
в командах разработки Nokia.
CUSTIS, декабрь 2009 года
Тренинг Артема Марченко (Product Manager Nokia)
”
139

140. Тест получил
широкое распространение
140/108

141. ScrumButt
http://scrumbutt.me/
141

142. Проверочная карта Scrum
Хенрик Книберг
http://blog.crisp.se/henrikkniberg/2008/02/01/1201823760000.html
http://lib.custis.ru/Scrum-checklist (перевод на русский)
http://www.crisp.se/file-uploads/10-ways-to-screw-up-with-Scrum-and-XP.pdf
142

143. Kniberg на AgileDays 2011
Я: Хенрик, что-то у нас оценки на планировании приводят
к плохим результатам.
Хенрик: Ну и не оценивайте тогда.
Я: А что, можно было?
143

144. Сертификация SCRUM
Институционализация и шаблонизация SCRUM.
144

145. $1000–$1500 ежегодно
+ $250 ежегодно, за каждый курс
$150 каждые 2 года
$750 в год
$100 каждые 2 года
$100 каждые 2 года
$300 каждые 2 года
$250 один раз +
$5000 в год +
$50 за каждого студента
http://www.scrumalliance.org/pages/fee_payment_links
http://www.scrumalliance.org/resources/2743
http://www.scrumalliance.org/pages/certified_scrum_coach
http://www.scrumalliance.org/resources/2186
145/108

146. SCRUM-сертификация и ее последствия
http://xpinjection.com/2011/08/22/scrum-certification/
«Scrum Alliance выстроил великолепную
пирамиду вокруг одной из самых простых
методологий разработки».
Николай Алименков
«Сейчас я полностью разочаровался
в сертификации. И виной тому именно
программы наподобие Scrum Master».
«Во всем мире уже давно поговаривают
о сомнительности сертификации
Scrum Master-ов, которая проходит
после посещения двухдневного курса».
146/108

147. 

Двухдневный курс

Большинство сходивших
поначалу требуют
вернуть назад
«православный SCRUM»
Базовые сведения
о SCRUM
147

148. Agile-конференции
Закрепляют и развивают одни и те же
базовые идеи
Who is your Product Owner, and what does he/she do?
Масштабирование Agile
Как внедрить Agile?
Toward Agile Scalability: From components to feature teams
Agile Planning
Scrum Master – кто ты?
Enterprise Agile: Управление Agile проектами на уровне компании
Scrum в Fixed-Price проектах: практический опыт
Velocity как инструмент планирования и управления
проектом: предсказываем, измеряем, оцениваем
148

149. Какие еще есть мнения
149/108

150. Казалось бы,
про то же самое
150

151. Однако при этом!
Квинтэссенция
моего доклада
151

152. Постепенно (2011–2012 год)
появляются и другие статьи
152/108

153. 2011 год. Культ Карго в IT —
троллим адептов SCRUM-а
http://blog.sibirix.ru/2011/09
/28/cargo_cult_in_it/
IT-шники тоже выполняют бессмысленные ритуалы, например, стояние
у Canban-доски по утрам или планирование с помощью карт Planning
Poker, абсолютно не понимая смысла происходящего.
153

154. А нужен ли на самом деле
Scrum Master?



Кто угодно справится с этой задачей.

Николай Алименков
Scrum Master – фиктивная профессия,
программисты, не умеющие хорошо
программировать.
Scrum Master – катализатор для роста
эффективности команды только в умах
зомбированных Scrum-конференциями.
Scrum Master гордится своими сертификатами,
а продуктивность лишь падает.
http://xpinjection.com/2011/09/07/is-scrum-master-needed/
154

155. 2012 год. Stop Using Story Points
http://www.industriallogic.com/blog/stop-using-story-points/
155

156. 2012 год. Stop Using Story Points
In 2007, a series of experiments led my colleagues and me to
increase our agility by dropping story points and velocity
calculations.
Those same experiments led us to replace fixed-length sprints
with a flow-based workflow, and move from standup meetings
to frequent team huddles.
Our process today looks nothing like a by-the-book,
mainstream Agile method largely because we actively look for
process waste and experiment to discover better ways of working.
http://www.industriallogic.com/blog/stop-using-story-points/
156

157. 2012 год. Stop Using Story Points
Story points and velocity calculations are now seen as
defacto parts of Agile, legitimized by popular
books, embedded in planning tools, verified in certifications
and widely practiced in the industry.
Yet nearly all of the veteran agile practitioners I know
haven't used story points or velocity calculations in
years.
In the early days of Agile we thought there was a point to
story points.
Yet we were careful to not let our ideas and practices ossify:
to become set in a rigidly conventional pattern.
http://www.industriallogic.com/blog/stop-using-story-points/
157

158. AgileDays – 2013
SCRUM – это не «серебряная пуля»
Эволюция Agile, или Погоня за идеальным процессом
Усвоенные уроки одной кроссфункциональной команды разработки
Перестаньте спрашивать «КОГДА?»
Угасающие команды – почему все ломается и как можно их спасти
Velocity как инструмент планирования и управления
проектом: предсказываем, измеряем, оцениваем
158