SlideShare a Scribd company logo

Московский клуб тестировщиков. Круглый стол про Agile

Download as PPTX, PDF
Михаил Заборов, profile picture
Михаил Заборов

Документ обсуждает внедрение метода Scrum в компании Custis и критикует традиционное понимание этого подхода, подчеркивая его адаптацию под конкретные нужды команды. Основное внимание уделяется важности самомотивации и самоорганизации в команде, а также необходимости управления ожиданиями и мотивацией исполнителей в условиях изменяющихся требований к проекту. Доклад также поднимает вопросы роли руководителей и особенностей планирования в Agile-среде.

1 of 158
Downloaded 13 times
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
Круглый стол «Гибкость: как правильно жить и работать?» Михаил Заборов руководитель стратегических проектов 2 декабря 2013 года
Компания CUSTIS   Существует с 1996 года  Agile-like процесс – с рождения Занимается заказной разработкой промышленного корпоративного ПО 2/108
Внедрение SCRUM в CUSTIS Андрей Бибичев    Асхат Уразбаев Первое внедрение – в 2007 Внедрял Асхат Уразбаев В 2009–2010 – регулярные встречи Agile Russia на нашей территории 3/108
Сегодня   В компании 20+ человек  90% используют похожий на SCRUM процесс В компании более 20 производственных команд 4/108
Немного про меня С критическим прищуром и перпендикулярным мнением  5/108
Часто SCRUM воспринимается так: 6/108
Восприятие SCRUM Только использование канонических процессов SCRUM дает действительно существенный позитивный результат Более мягкая формулировка Практики SCRUM зависят друг от друга, образуют систему и наибольший эффект получается при их совместном использовании 7/108
В результате «Вы используете неправильный SCRUM и поэтому у вас все плохо». А СКРАМ-то НЕНАСТОЯЩИЙ!!! Это не по Scrum-у!!! 8/108
ScrumButt  «We’ve got SCRUM, but…» 9/108
Разновидность «Вы просто еще не пробовали пользоваться настоящим SCRUM – попробуйте и вы увидите разницу». 10/108
Мой опыт SCRUM в чистом виде практически бесполезен, а иногда и наносит существенный вред Его нужно адаптировать под себя. Не нужно его фетишизировать и добиваться пуританской чистоты 11/108
При этом почти ничего плохого про Agile ≠ 12/108
Agile это всего лишь манифест 13/108
И немного принципов 14/108
Обсуждение 15/108
Крупные темы которые можно обсудить  Философия    C самомотивацией все не так просто Самоорганизация от сырости не заводится Практические  Роли в SCRUM (в т.ч. про классовую вражду и немного про  SCRUM планирование расслабляет команду профессию тестировщиков) Резюме 16
Мелкие темы которые можно обсудить  Требования к итерациям в SCRUM избыточно жесткие  Ретроспектива по SCRUMовски - практически бесполезное занятие   Чаще всего DSM вырождается в пустой гундеж В SCRUMе демонтрация упрощенна до бесполезности Резюме 17
Где еще скрам не помогает, а иногда даже мешает     Архитектура Работа с персоналом Долгосрочное планирование Ресурсное планирование (в том числе краткосрочное увеличение/уменьшение команды) Резюме 18/108
Про самомотивацию 19/108
Про самомотивацию  Над проектом должны работать  мотивированные профессионалы Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им Agile Manifesto 20/108
Что есть самомотивация? 21/108
Системы ценностей разных людей сильно отличаются  Далеко не всегда то, за что готов платить заказчик, мотивирует разработчиков  То, что ценно для разработчика, для заказчика может быть странной, никому не нужной самореализацией (самоудовлетворение).  То, что ценно для заказчика - для программиста может быть порождением воспаленного разума и непонятная, неведомая фигня.  Люди склонны оценивать многие, даже сложные задачи как рутинные 22/108
Матрица компетентность - интерес 23
Ценности меняются  Цели и задачи заказчиков регулярно меняются. Agile рассчитан именно на такие проекты “ Делали учетную систему, а в результате оказалась просто интеграция ”  То, что было интересным когда-то, со временем становится рутиной “ Я всю жизнь строю эти дурацкие мосты ” 24/108
Самомотивированные на результат проекта профессионалы крайне редки  Есть много людей, которым не очень много нужно от жизни  Еще больше людей, которые не знают, чего на самом деле хотят  Нужны очень эмоционально и ментально зрелые люди. Разработчики же в основном молодежь 25/108
Примеры мотиваторов на результат проекта 26/108
Самодостаточные люди  Разобраться, как работает сложный бизнес   Сделать мир чуть лучше Помочь хорошим людям 27/108
Ориентированные на внешний мир  Получить в портфолио сделанный проект и тем самым повысить свою ценность  Получить признание уважаемых людей (друзей, родственников, коллег) Много конъюнктуры и контуженных гламуром людей  28/108
Сделать что-то «хорошее» и «клѐвое» – другая мотивация  В общем случае противоречит мотивации на результат проекта  Безусловно должна присутствовать в команде 29/108
Влияние SCRUM на мотивацию 30/108
От скрама мотивация не заводится  Никакая организационная конструкция (в том числе, SCRUM) не может создать мотивацию  В начале вы набираете команду мотивированных людей, а потом заводите SCRUM 31/108
От скрама мотивация может испортиться  Мотивированные на результат люди обычно хотят напрямую видеть этот результат и влиять на него. Proxy в виде ProductOwner-а их демотивирует  Ритуалы могут утомлять. Любую хорошую идею можно довести до абсурда  Если вы хотите чистый SCRUM, вам нужно регулярно чистить команду от тех, кто «не восторженно мыслит» 32/108
Мотивированным людям и без скрама хорошо 33/108
Алистер Коберн   Нет корреляции между успехом/провалом проектов и методологиями, которые применялись в проектах Успешность программного проекта на 100% определяется людьми 34/108
Обсуждение Список Тем 35/108
Про самоорганизацию 36/108
Про самоорганизацию  Команда – черный ящик, она подстраивает   себя сама Оставьте ее в покое, и она сама решит все проблемы Единственный способ повлиять на нее – добавить/удалить людей или разогнать SCRUMевангелисты 37/108
38/108
Команда далеко не всегда самоорганизуется эффективным для производства способом Правильно ли называть это «самоорганизацией»? Самоорганизация – результат долгой кропотливой работы специальных людей 39/108
Пример: Product Owner отстранился от принятия решений  Постоянные конфликты  Непродуктивные обсуждения того, что можно не обсуждать  Команду пришлось резать по живому 40/108
Возможное объяснение из теории игр 41/108
Дилемма заключенного Молчит Молчит свободен 20 лет Сдает 3 месяца Сдает свободен 20 лет 5 лет
Маша тестирует задачу, сделанную Петей в условиях жестких сроков и дефицита времени 43/108
Варианты действий Маша сотрудничает Маша и Петя находят компромисс Петя В результате оба немного сотрудничает перерабатывают Продукт выходит вовремя Петя заботится о себе Петя делает работу в притык, так что времени тестирование и исправление ошибок не остается Маша работает в выходные и по ночам Часть ошибок остается неисправленными Маша заботится о себе Маша требует много времени на тестирование Петя работает в выходные и по ночам чтобы успеть к сроку Маша требует много времени на тестирование Петя делает работу впритык, так что времени на тестирование и исправление ошибок не остается Сроки срываются 44/108
Равновесие Нэша  Тип решений игры, в котором ни один участник не может увеличить выигрыш, изменив своѐ решение в одностороннем порядке, когда другие участники не меняют решения Равновесие Парето Молчит Молчит свободен 20 лет Равновесие Нэша Сдает 3 месяца Сдает свободен 20 лет 5 лет 45/108
Слаженность действий 46/108
Нужен выделенный координирующий человек с полномочиями  В ситуации быстро меняющихся требований нужно быстро реагировать  Все это требует координации и выделенного человека, который держит на этом фокус 47/108
Даже самомотивированным людям нужно транслировать смысл задач заказчика  В том числе :  Показывать как именно мир становится лучше  Показывать живых людей, которым становится лучше 48/108
Если у исполнителей мотивация не на результат проекта ($, комфорт, самоудовлетворение), то работать с ними нужно по другому (не чистый скрам) Работа руководителя превращать желания заказчика в мотиваторы исполнителей Том Сойер 49/108
Руководителю нужно работать с людьми индивидуально 50/108
Иногда есть прямой смысл поставить ответственного за задачу целиком Это противоречит чистому SCRUM 51/108
 На этапе начальной разработки  Для плохо проработанных задачи  Для обеспечения квалификационного роста сотрудника  Для оценки квалификации сотрудника  Для повышения ответственности и мотивации сотрудника  Для повышения эффективности и минимизации рисков  Для контроля качества исполнения  Для дублирования компетенций 52/108
Еще про распределение работ в команде  Кроссфункциональность противоречит эффективности, нужен разумный баланс  Нужно дублирование, а не полная кроссфункциональность Баланс в каждом случае свой 53/108
Ситуационный менеджмент 54/108
Обсуждение Список Тем 55/108
Про роли в скраме 56/108
В противовес классическому руководителю:  PO!=Руководитель  PO не член команды. Нечего РО лезть во    внутренности Обязательно нужен Sсrum Master SM и PO не один человек У SM нет никаких полномочий SCRUMевангелисты 57/108
Почему собственно? Почему не оставить руководителей? 58/108
Мнение # 1: Менеджер – это вредный элемент. Его нужно экранировать от команды 59/108
Нужно экранировать свиней от цыплят  Свиньи создают продукт, тогда как цыплята заинтересованы, но не настолько, – ведь им всѐ равно, будет проект удачным или нет, на них это мало отразится  Требования, пожелания, идеи и влияние цыплят принимаются во внимание, но им не разрешают непосредственно включаться в ход SCRUM-проекта. 60/108
Четкая ассоциация менеджеров с заводской культурой Профессия тестировщик, к сожалению, тоже оттуда  Подробно 61/108
Классовая борьба 62/108
Тупые и некомпетентные менеджеры мешают делать работу компетентным исполнителям  Скрам-мастеру нельзя дать   Менеджерофобия полномочия руководителя – иначе он сразу станет тупым менеджером Пусть менеджер занимается своим менеджерскими делами, а команда займется реальным делом Команда лучше самоорганизуется без руководителя 63/108
SCRUM Команда 64/108
Команда в позиции «попробуйте меня уговорить»  «Докажи всем в команде, что твое предложение не дурацкое»  Сильное ограничение власти руководителя  Вместо сотрудничества – борьба 65/108
Плохо работает, когда руководитель – это самый сильный человек в команде (с точки зрения влияния на конечный результат) с богатым опытом проектной деятельности Руководитель 66/108
Примеры таких конструкций в жизни 67/108
 Есть мнение что, все интеллектуальные профессиональные услуги так устроены Дэвид Майстер 68/108
Мнение # 2: Руководитель со всем не справляется, ему нужно помочь 69/108
Избавляем руководителя от ненужной работы  Отделяем определение «что делать» (PO) от «Как    делать» (Команда) PO должен по возможности общаться в терминах ФИЧ и проблем, которые он хотел решить PO не нужно общаться с каждым членом команды Основные интерфейсы общения – Backlog и демонстрация Не нужно заранее закреплять задачу на исполнителе 70/108
Почему именно так ему нужно помогать?  Понятие Product Owner – в общем-то из продуктовой разработки или InHouse  Для заказного софта подходит не очень сильно. Кто PO? Заказчик или человек из компании? 71/108
72/108
Конструкция с замотивированным на результат руководителем и небольшим ядром команды, влияющих на остальную команду, более реалистична чем вся команда ориентированная на результат Сложно искать хорошего руководителя  Найти пару PO+SM ни разу не проще! Может превратится в command&control в худшем виде  Отделение от команды только маскирует и затягивает проблему «плохих» менеджеров. Ее нужно решать в любом случаем Я не предлагаю вернуть обратно директивное управление менеджером. Я предлагаю сдвинуть баланс в сторону руководителя 73/108
PO и SM, схожие навыки  Системное мышление    Эмпатия Коммуникация Активная позиция 74/108
Обсуждение Список Тем 75/108
Про планирование 76/108
Оценка и Velocity  Необходимость оценивать задачи в каких-либо попугаях при планировании  Необходимо мерять скорость команды SCRUMевангелисты 77/108
Люди плохо оценивают время Например: Люди по разному оценивают в зависимости от того, знают ли они кто будет делать эту задачу 78/108
Недостатки оценки  Оценка стоит денег и очень существенных  Само по себе наличие оценки вносит существенное возмущение в процесс разработки. Она влияет на реальную скорость работы и задает жесткое ограничение 79/108
Андрей Бибичев  Модель 1. Пуассоновское распределение. Поток случайных задержек, сроки отодвигаются из-за него  Модель 2. Броуновское движение. Нас бомбардируют отклонения от пути... Общая траектория становится длиннее  Модель 3. PERT. Бета-распределение. Кривая получается похожая 80/108
В результате такой график вероятности затрат на разработку Перестраховка    Оптимист - Идеальная ситуация .сделаем если ничего не предвиденного не случится Реалист – наиболее вероятное значение реальных затрат. Оценка опытных разработчиков. Вероятность, что она занижена достаточно высока (~70%) Перестраховка – если космос не рухнет на землю, то точно уложимся 81/108
 Команде выгоднее давать оценки типа «перестраховка»  Реально работа занимает все отведенное под нее время  В результате команда переходит в расслабленное состояние  «Чѐ-то мы не успеваем. Давайте понизим фокус фактор!» 82/108
 Даже при перестраховке, все равно существует 5% вероятности, что мы не уложимся  При очень большом количестве работ, такие ситуации все равно случаются, и мы имеем очень неприятные разговоры с Закачиком:  «Вы и так многократно заложились и все равно не успели»  Это заставляет команду давать еще более консервативные оценки. Команда становится еще медленнее, но при этом более раздраженной 83/108
 Вместо того, чтобы планировать «как мы сделаем то, что нужно, к нужному сроку», мы планируем то, что успеет команда в ближайшую итерацию.  Первичным становится комфорт команды, а не потребности заказчика 84/108
Обсуждение Список Тем 85/108
Про итерации  У итерации фиксированная длина  У итерации фиксированный SCOPE 86/108
Избыточная жесткость  Итерация нужна для планирования работ группами и создания точек синхронизации  Итерации бьются из абстрактного удобства разработчика, а не удобства получения результата (точки синхронизации не тогда, когда нужно)  Регулярно прилетают неожиданные задачи, которые сдвигают сроки и скоуп. А иногда делают итерацию бессмысленной  Нет возможности «подруливать» итерацией в процессе (удалять задачи и/или увеличивать сроки) 87/108
Обсуждение Список Тем 88/108
Про ретроспективу  Нужно проводить ретро в конце каждой    итерации Ретро – это внутреннее дело команды Команда без ретро – это плохо После ретро нужно делать Бэклог на решение проблем 89/108
Про ретроспективу  Команда (да и люди вообще) чаще всего не в состоянии себя запроблематизировать  В результате обсуждается ерунда , мало влияющие на процесс  Большинство реальных рычагов изменений (нанять, уволить, поднять зарплату, поговорить по душам, выделить время, купить сервер, купить библиотеку и т.д.) – не внутри команды  Команда, которая не успевает делать свои текущие дела, вряд ли успеет сделать их одновременно с задачами из дополнительного бэклога 90/108
Обсуждение Список Тем 91/108
Про DSM  Нужно проводить DSM каждый день в одно время  Должна присутствовать вся команда  Обсуждаем кто-что сделал за день, что будет завтра и какие есть проблемы  Ограничиваем DSM пятью минутами 92/108
Про DSM  Формальное действие, которое всех несколько утомляет (ритуал)  Обычно народ бубнит себе что-то под нос, и его почти не слушают  Проблемы практически никогда не обсуждаются  Никаких решений на ДСМ не принимают. ДСМ не влияет на то, чем люди будут заниматься в рабочем процессе  Как только начинается реально интересное обсуждение – его тут же сворачивают (ДСМ – 5 минут)  Искусственная мотивация посещения ДСМ (плюшки, штрафы, кармические бонусы) 93/108
Обсуждение Список Тем 94/108
Про Демонстрацию  Демо нужно производить после каждой итерации  На демо нужно звать всех заинтересованных лиц  На демо нужно показывать все, что сделали за итерацию 95/108
Про Демонстрацию  Внешним стейкходерам зачастую скучны 60% подробностей, которые рассказываются  Членам команды, напротив, обычно интересно и полезно знать детали реализации, чтобы иметь более полную информацию о проекте  Внешним стейкхолдерам и команде результат можно показывать в разном состоянии сырости  Бесконечные баги и сбои на демо раздражают заказчиков  К внешнему демо нужно готовиться тщательнее  От членов команды, наоборот хочется получить реакцию побыстрее  Разным стейкхолдерам интересны разные вещи. Им нужны разные демо  Неправильно подстраивать внешних стейкхолдеров под внутренний ритм проекта. Демо нужно устраивать, когда им удобно 96/108
Обсуждение Список Тем 97/108
Вместо резюме  Все практики носят рекомендательный характер   Вы используете их на свой страх и риск  Вы можете изменять практики в соответствии с проектной необходимостью и собственными представлениями  При применении подключайте голову Ни одна из практик не является обязательной 98/108
Спасибо! Вопросы? Михаил Заборов mzaborov@custis.ru 99/108
Дополнительные слайды 100/108
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
Разработка ПО как конвейерное производство  Энтони Лаудер. Культуры программных проектов (2008) 102/108
Спланируйте наперѐд  Напишите детальные спецификации продукта, включая необходимые стандарты качества   Разбейте работу на последовательность нескольких стадий  Опишите оптимальную последовательность простых повторяемых действий, необходимых на каждом из таких рабочих мест  Посчитайте время, необходимое для выполнения каждого действия, и выработайте соответствующее расписание для каждой стадии, включая время начала и окончания для всего проекта  Определите ресурсы (материалы, стоимость труда, станки, инструменты, и т.д.), необходимые для каждого действия. Просуммируйте их, чтобы определить стоимость каждой стадии и весь бюджет проекта Определите специализированные роли для рабочих на каждой стадии 103/108
Начните производство согласно плану:  Возьмите работников из доступного персонала и назначьте их на рабочие места, определѐнные в плане  Прикажите рабочим выполнять повторяющиеся действия, предписанные на каждом месте, со скоростью, необходимой для завершения проекта вовремя и в рамках бюджета  Нажмите кнопку «Пуск», чтобы запустить производство 104/108
Мониторинг и Контроль: Непрерывно проверяйте:  Рабочих на местах, чтобы убедиться, что они выполняют действия согласно плану   Темпы производства, чтобы укладываться в расписание  Конечную продукцию на предмет соответствия стандартам качества Потребление экономических ресурсов, чтобы проект укладывался в бюджет Там, где инспекция находит проблемы, справьтесь с ними:      Остановите производство Исправьте причину проблемы, где возможно, путѐм: Починки сломанного оборудования Крика и запугивания рабочих Перезапустите производство 105/108
Мониторинг и Контроль:  Там, где причина проблемы не может быть устранена, попробуйте следующие методы:   Увеличьте бюджет      Добавьте рабочих к конвейеру Предложите экономические льготы рабочим Добавьте ещѐ один конвейер Увеличьте сроки проекта Измените спецификации продукта Отмените проект 106/108
Разработка ПО:  Менеджеры создают план проекта, разбивающий необходимую работу на несколько стадий с чѐткими временными и стоимостными рамками для каждой стадии, а значит, и для всего проекта в целом  Рабочие берутся из имеющегося персонала и назначаются последовательно на различные стадии проекта  На каждой стадии рабочие периодически пишут status report, чтобы менеджеры могли следить за прогрессом 107/108
Стадии:      Стадия требований: cпецификации продукта заранее записываются заказчиком или другим авторизованным человеком, тем самым переводя их бизнес потребности в спецификационный документ. Стадия анализа: аналитик переводит спецификации продукта в полные фиксированные функциональные требования к программному приложению, производя документ с функциональными требованиями. Стадия дизайна: дизайнер переводит функциональные требования в чѐткую и ясную архитектуру приложения, формируя технический дизайн. Стадия кодирования: программист, следуя техническому дизайну, пишет программный код. Стадия контроля качества: тестировщики проверяют функционал программного кода, чтобы удостовериться в том, что он соответствует всем требованиям из вышеупомянутых документов. Обратно 108/108
Как это может быть (один из вариантов): Это не SCRUM, но по прежнему Agile 109
Роли и их взаимодействие 110
• Команды 7-8 человек сидящие вместе • Есть один человек ответственный за Backlog - PO= Руководитель • PO имеет право в тех случаях когда ему необходимо проваливаться в любую детальность как ему хочется • В тех местах, где PO уверен в команде он может полагаться на самоорганизацию a-la SCRUM • SM- помощник руководителя (если он нужен), с полномочиями 111
Итерации 112
• Итерации могут быть разной длины (короткие 2-4 недели) • Конец итерации назначается руководителем. Может быть отодвинут им при желании. • В конце итерации внутреннее демо на котором руководитель смотрит промежуточный результат и решает что делать с итерацией (продлить/закончить). • Между итерациями могут появиться «санитарные дни». Когда вся команда «чистит хвосты». 113
Планирование 114
• SCOPE итерации делится на 3 части: • Сделать кровь-из носу • Крайне желательно сделать • Сделать если получится. • На планировании рассказывают о задачах (в т.ч. откуда они и зачем), их приоритетах (почему для бизнеса важно получить задачу к такому сроку) обсуждаются варианты реализации. Фиксируется SCOPE с командой (в 3х градациях) • Оценка задач на планировании не производится (производится только если команда не в состоянии подписаться на SCOPE без нее) • Оценка производится только по требованию клиента/PO – и это отдельная работа. 115
Ритуалы 116
• Нужен человек ответственный за процесс (может быть PO, может быть SM. Может быть любой назначенный человек из команды, который болеет за результат – например инженер) • Он решает назначать или нет DSM, Ретро и Демо (Практики - инструмент, а не обязанность). 117
DSM назначается если: • Есть подозрение что члены команды инкапсулировались в своих задачах и не видят общей картины • Есть новые сотрудники • Есть подозрение что будут сорваны сроки. 118
Различаем 2 типа демонстрации внутренние и внешние 119
Внутреннее демо • собирается только для команды и «сочувствующих». • В конце (или ближе к концу) итерации • Если есть необходимость • Члены команды и/или PO чувствуют, что не понимают что сделано соседями • Руководитель хочет глубже понять состояние проекта • Есть новые сотрудники 120
Внешнее демо • Делается отдельно для разных групп стейкхолдеров • Проводится в тот момент, когда удобно тем кто будет смотреть • Планируется как отдельная работа • Не стоит на них экономить (Формирует правильные ожидания и восприятие для заказчиков (см мою презентацию про клиентоориентированность)) 121
Для получения быстрой обратной связи от заказчика используется другие инструменты (не экономим на этом): • Макеты • Модели • Совещания • Презентации • И т.д. 122
Ретро 123
Каждый раз: думаем одно, говорим другое, делаем третье, получается — то, что есть. Потому что, слова — это пустой звук, а дела — пустая трата времени. Но, тем не менее, нужно делать всѐ как должно, честно и с доверием. Даосский принцип 124/108
Откуда все пошло 125/108
Зачем мы внедряли SCRUM  …и получили ли то, что хотели, – тема отдельного разговора 126/108
Долгий и тяжелый путь осознания внутри компании 127/108
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
Вводится понятие Да-да  http://www.sprettur.is/media/slides2008/Iceland2008MoneyforNothing.pdf 129
ScrumButt «We’ve got SCRUM, but…» 130
SCRUM – это хорошо http://www.sprettur.is/media/slides2008/Iceland2008MoneyforNothing.pdf 131
Но только настоящий Покупайте True SCRUM http://www.sprettur.is/media/slides2008/Iceland2008MoneyforNothing.pdf 132
Причем выигрыш демонстрируется на примере русской компании Exigen Services 133/108
http://www.sprettur.is/media/slides2008/Iceland2008MoneyforNothing.pdf 134
http://www.sprettur.is/media/slides2008/Iceland2008MoneyforNothing.pdf 135
Чтобы понять, правильный ли у вас SCRUM, был разработан Nokia Test 136/108
http://www.sprettur.is/media/slides2008/Iceland2008MoneyforNothing.pdf 137
Пример вопроса http://www.sprettur.is/media/slides2008/Iceland2008MoneyforNothing.pdf 138
Nokia-тест “ Nokia-тест – внутренний инструмент Nokia, который решал совершенно конкретную задачу – унификации процессов в командах разработки Nokia. CUSTIS, декабрь 2009 года Тренинг Артема Марченко (Product Manager Nokia) ” 139
Тест получил широкое распространение 140/108
ScrumButt http://scrumbutt.me/ 141
Проверочная карта 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
Kniberg на AgileDays 2011 Я: Хенрик, что-то у нас оценки на планировании приводят к плохим результатам. Хенрик: Ну и не оценивайте тогда. Я: А что, можно было? 143
Сертификация SCRUM Институционализация и шаблонизация SCRUM. 144
$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
SCRUM-сертификация и ее последствия http://xpinjection.com/2011/08/22/scrum-certification/ «Scrum Alliance выстроил великолепную пирамиду вокруг одной из самых простых методологий разработки». Николай Алименков «Сейчас я полностью разочаровался в сертификации. И виной тому именно программы наподобие Scrum Master». «Во всем мире уже давно поговаривают о сомнительности сертификации Scrum Master-ов, которая проходит после посещения двухдневного курса». 146/108
  Двухдневный курс  Большинство сходивших поначалу требуют вернуть назад «православный SCRUM» Базовые сведения о SCRUM 147
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/108
Казалось бы, про то же самое 150
Однако при этом! Квинтэссенция моего доклада 151
Постепенно (2011–2012 год) появляются и другие статьи 152/108
2011 год. Культ Карго в IT — троллим адептов SCRUM-а http://blog.sibirix.ru/2011/09 /28/cargo_cult_in_it/ IT-шники тоже выполняют бессмысленные ритуалы, например, стояние у Canban-доски по утрам или планирование с помощью карт Planning Poker, абсолютно не понимая смысла происходящего. 153
А нужен ли на самом деле Scrum Master?    Кто угодно справится с этой задачей.  Николай Алименков Scrum Master – фиктивная профессия, программисты, не умеющие хорошо программировать. Scrum Master – катализатор для роста эффективности команды только в умах зомбированных Scrum-конференциями. Scrum Master гордится своими сертификатами, а продуктивность лишь падает. http://xpinjection.com/2011/09/07/is-scrum-master-needed/ 154
2012 год. Stop Using Story Points http://www.industriallogic.com/blog/stop-using-story-points/ 155
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
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
AgileDays – 2013 SCRUM – это не «серебряная пуля» Эволюция Agile, или Погоня за идеальным процессом Усвоенные уроки одной кроссфункциональной команды разработки Перестаньте спрашивать «КОГДА?» Угасающие команды – почему все ломается и как можно их спасти Velocity как инструмент планирования и управления проектом: предсказываем, измеряем, оцениваем 158

More Related Content

PDF
Гибкость: как правильно жить и работать?
CUSTIS
 
PDF
Я, Трансформатор
Maxim Gaponov
 
PPTX
Agile - ответ на вызовы третьей промышленной революции - цепков custis
Maxim Tsepkov
 
DOCX
Rabota komandy
vsemspasibo
 
PDF
Записная книжка мистера Томпкинса (из книги Тома Демарко "Deadline: роман об ...
Mikhail Galushko
 
DOCX
работа команды
olya_kar2
 
PPTX
Активные методы ведения переговоров. Анастасия Ивко. Антон Шалейников. Вадим ...
Vadim Nareyko
 
PDF
Качество продукта через управление проектом
Ольга Павлова
 
Гибкость: как правильно жить и работать?
CUSTIS
 
Я, Трансформатор
Maxim Gaponov
 
Agile - ответ на вызовы третьей промышленной революции - цепков custis
Maxim Tsepkov
 
Rabota komandy
vsemspasibo
 
Записная книжка мистера Томпкинса (из книги Тома Демарко "Deadline: роман об ...
Mikhail Galushko
 
работа команды
olya_kar2
 
Активные методы ведения переговоров. Анастасия Ивко. Антон Шалейников. Вадим ...
Vadim Nareyko
 
Качество продукта через управление проектом
Ольга Павлова
 

What's hot (20)

PPTX
Воркшоп по управлению командой проекта в Академии ПВТ
Aliaksei Minkevich
 
PPT
эффективность управленцев
Erkin Dzhamanbaev
 
PDF
Новинки сезона ГК "Институт Тренинга - АРБ Про" май 2015
Training Institute - ARB Pro Group
 
PPTX
TOC2 - Current reality tree (CRT) and other tools
Yevheniy Veselov, MBA, PMP
 
PDF
Построение эффективных проектных команд
Mikhail Andronov
 
PDF
Цели и ответственность в профессии и в жизни
CUSTIS
 
DOC
Модель организационных изменений Курта Левина
CKPPK
 
PDF
Организационные изменения и участие в них
Maxim Gaponov
 
PPTX
Формирование проектной команды
Диалог Информационные Технологии
 
PPT
Организационные изменения: модель Джона Коттера
Cleverics
 
PPT
Джон Коттер "Впереди перемен"
uymaslides
 
PPT
Джон Коттер “Впереди перемен”
uymaslides
 
PDF
Джон Коттер. Впереди перемен.
Oleg Afanasyev
 
PDF
Как понять, подходит ли Agile вашей компании
Maxim Tsepkov
 
PDF
Самоорганизующиеся команды
ITCP Community
 
PDF
система томаса в решении управленческих задач Os
lera_sol
 
PDF
UX Design Рrocess
Darya Bolhovskaya
 
PDF
Organizing self-organizing teams
Agileee
 
PPTX
Agile and the Third Wave (IT Spring 2017)
Maxim Tsepkov
 
PDF
ЗНАЧЕНИЕ СИСТЕМНОГО МЫШЛЕНИЯ. Alfredo Moscardini. BPI Group
Всеукраинский Форум "Развитие производственных систем"
 
Воркшоп по управлению командой проекта в Академии ПВТ
Aliaksei Minkevich
 
эффективность управленцев
Erkin Dzhamanbaev
 
Новинки сезона ГК "Институт Тренинга - АРБ Про" май 2015
Training Institute - ARB Pro Group
 
TOC2 - Current reality tree (CRT) and other tools
Yevheniy Veselov, MBA, PMP
 
Построение эффективных проектных команд
Mikhail Andronov
 
Цели и ответственность в профессии и в жизни
CUSTIS
 
Модель организационных изменений Курта Левина
CKPPK
 
Организационные изменения и участие в них
Maxim Gaponov
 
Формирование проектной команды
Диалог Информационные Технологии
 
Организационные изменения: модель Джона Коттера
Cleverics
 
Джон Коттер "Впереди перемен"
uymaslides
 
Джон Коттер “Впереди перемен”
uymaslides
 
Джон Коттер. Впереди перемен.
Oleg Afanasyev
 
Как понять, подходит ли Agile вашей компании
Maxim Tsepkov
 
Самоорганизующиеся команды
ITCP Community
 
система томаса в решении управленческих задач Os
lera_sol
 
UX Design Рrocess
Darya Bolhovskaya
 
Organizing self-organizing teams
Agileee
 
Agile and the Third Wave (IT Spring 2017)
Maxim Tsepkov
 
ЗНАЧЕНИЕ СИСТЕМНОГО МЫШЛЕНИЯ. Alfredo Moscardini. BPI Group
Всеукраинский Форум "Развитие производственных систем"
 
Ad

Similar to Московский клуб тестировщиков. Круглый стол про Agile (20)

PDF
Максим Цепков. Agile — ответ на вызовы третьей промышленной революции.
ScrumTrek
 
PPTX
Agile — ответ на вызовы третьей промышленной революции
CUSTIS
 
PDF
Cluster.Integrity
Константин Сирик
 
PDF
2013.08.24 Антон Киселёв семинар "Agile (Scrum)"
Alexey Fedorov
 
PPTX
Открытие HR-конференции "HR-практики: Будущее за теми, кто..."
Training Institute - ARB Pro Group
 
PDF
То что ежедневно делают бренд-менеджеры ведущих компаний
Newbt
 
PPTX
Agile - новый тренд или хорошо знакомый подход (ВШМ)
Natalia Khametdulova
 
PDF
Аудиторные тимбилдинги
SunHouse Team
 
PPTX
Максим Цепков, Действуй, опираясь на ценности, а не просто применяй инструменты!
ScrumTrek
 
PDF
действуй опираясь на ценности а не просто применяй инструменты максим цепков
Maxim Tsepkov
 
PPT
Дмитрий Безуглый - Почему из ИТ-ков получаются плохие руководители?
Luxoft Education Center
 
PPT
Борис Иосифов о тимбилдинге и продаже проектов
Vladimir Ivanov
 
PPT
Лидерство и Управление Командой Разработчиков ПО
Media Gorod
 
PPTX
Как контролировать работу? Вадим Нарейко
Vadim Nareyko
 
PPTX
Самоопределяйся технологично!
SQALab
 
PPTX
Самоопределяйся технологично!
Maxim Tsepkov
 
PDF
ТРИЗ. Решение задач. Поиск новых идей
triz-profi
 
PPTX
Рефлексивная игра "Ключ к будущему компании"
Alexander Shokhov
 
PDF
Рефлексивная игра "Ключ к будущему компании"
Alexander Shokhov
 
PPTX
Agileee Petelin самый непонимаемый принцип Agile Manifesto
Agileee
 
Максим Цепков. Agile — ответ на вызовы третьей промышленной революции.
ScrumTrek
 
Agile — ответ на вызовы третьей промышленной революции
CUSTIS
 
Cluster.Integrity
Константин Сирик
 
2013.08.24 Антон Киселёв семинар "Agile (Scrum)"
Alexey Fedorov
 
Открытие HR-конференции "HR-практики: Будущее за теми, кто..."
Training Institute - ARB Pro Group
 
То что ежедневно делают бренд-менеджеры ведущих компаний
Newbt
 
Agile - новый тренд или хорошо знакомый подход (ВШМ)
Natalia Khametdulova
 
Аудиторные тимбилдинги
SunHouse Team
 
Максим Цепков, Действуй, опираясь на ценности, а не просто применяй инструменты!
ScrumTrek
 
действуй опираясь на ценности а не просто применяй инструменты максим цепков
Maxim Tsepkov
 
Дмитрий Безуглый - Почему из ИТ-ков получаются плохие руководители?
Luxoft Education Center
 
Борис Иосифов о тимбилдинге и продаже проектов
Vladimir Ivanov
 
Лидерство и Управление Командой Разработчиков ПО
Media Gorod
 
Как контролировать работу? Вадим Нарейко
Vadim Nareyko
 
Самоопределяйся технологично!
SQALab
 
Самоопределяйся технологично!
Maxim Tsepkov
 
ТРИЗ. Решение задач. Поиск новых идей
triz-profi
 
Рефлексивная игра "Ключ к будущему компании"
Alexander Shokhov
 
Рефлексивная игра "Ключ к будущему компании"
Alexander Shokhov
 
Agileee Petelin самый непонимаемый принцип Agile Manifesto
Agileee
 
Ad

More from Михаил Заборов (6)

PPTX
Заборов Михаил .Омниканальность в рознице
Михаил Заборов
 
PPTX
Архитектура - что это?
Михаил Заборов
 
PPTX
Системная архитектура вместо требований
Михаил Заборов
 
PPTX
Архитектура и agile
Михаил Заборов
 
PPTX
Развитие персонала.. Вы уверены?
Михаил Заборов
 
PPTX
Расстройство клиентоориентированности
Михаил Заборов
 
Заборов Михаил .Омниканальность в рознице
Михаил Заборов
 
Архитектура - что это?
Михаил Заборов
 
Системная архитектура вместо требований
Михаил Заборов
 
Архитектура и agile
Михаил Заборов
 
Развитие персонала.. Вы уверены?
Михаил Заборов
 
Расстройство клиентоориентированности
Михаил Заборов
 

Московский клуб тестировщиков. Круглый стол про Agile

  • 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
  • 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
  • 16. Крупные темы которые можно обсудить  Философия    C самомотивацией все не так просто Самоорганизация от сырости не заводится Практические  Роли в SCRUM (в т.ч. про классовую вражду и немного про  SCRUM планирование расслабляет команду профессию тестировщиков) Резюме 16
  • 17. Мелкие темы которые можно обсудить  Требования к итерациям в SCRUM избыточно жесткие  Ретроспектива по SCRUMовски - практически бесполезное занятие   Чаще всего DSM вырождается в пустой гундеж В SCRUMе демонтрация упрощенна до бесполезности Резюме 17
  • 18. Где еще скрам не помогает, а иногда даже мешает     Архитектура Работа с персоналом Долгосрочное планирование Ресурсное планирование (в том числе краткосрочное увеличение/уменьшение команды) Резюме 18/108
  • 20. Про самомотивацию  Над проектом должны работать  мотивированные профессионалы Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им Agile Manifesto 20/108
  • 22. Системы ценностей разных людей сильно отличаются  Далеко не всегда то, за что готов платить заказчик, мотивирует разработчиков  То, что ценно для разработчика, для заказчика может быть странной, никому не нужной самореализацией (самоудовлетворение).  То, что ценно для заказчика - для программиста может быть порождением воспаленного разума и непонятная, неведомая фигня.  Люди склонны оценивать многие, даже сложные задачи как рутинные 22/108
  • 24. Ценности меняются  Цели и задачи заказчиков регулярно меняются. Agile рассчитан именно на такие проекты “ Делали учетную систему, а в результате оказалась просто интеграция ”  То, что было интересным когда-то, со временем становится рутиной “ Я всю жизнь строю эти дурацкие мосты ” 24/108
  • 25. Самомотивированные на результат проекта профессионалы крайне редки  Есть много людей, которым не очень много нужно от жизни  Еще больше людей, которые не знают, чего на самом деле хотят  Нужны очень эмоционально и ментально зрелые люди. Разработчики же в основном молодежь 25/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
  • 37. Про самоорганизацию  Команда – черный ящик, она подстраивает   себя сама Оставьте ее в покое, и она сама решит все проблемы Единственный способ повлиять на нее – добавить/удалить людей или разогнать SCRUMевангелисты 37/108
  • 39. Команда далеко не всегда самоорганизуется эффективным для производства способом Правильно ли называть это «самоорганизацией»? Самоорганизация – результат долгой кропотливой работы специальных людей 39/108
  • 40. Пример: Product Owner отстранился от принятия решений  Постоянные конфликты  Непродуктивные обсуждения того, что можно не обсуждать  Команду пришлось резать по живому 40/108
  • 43. Маша тестирует задачу, сделанную Петей в условиях жестких сроков и дефицита времени 43/108
  • 44. Варианты действий Маша сотрудничает Маша и Петя находят компромисс Петя В результате оба немного сотрудничает перерабатывают Продукт выходит вовремя Петя заботится о себе Петя делает работу в притык, так что времени тестирование и исправление ошибок не остается Маша работает в выходные и по ночам Часть ошибок остается неисправленными Маша заботится о себе Маша требует много времени на тестирование Петя работает в выходные и по ночам чтобы успеть к сроку Маша требует много времени на тестирование Петя делает работу впритык, так что времени на тестирование и исправление ошибок не остается Сроки срываются 44/108
  • 45. Равновесие Нэша  Тип решений игры, в котором ни один участник не может увеличить выигрыш, изменив своѐ решение в одностороннем порядке, когда другие участники не меняют решения Равновесие Парето Молчит Молчит свободен 20 лет Равновесие Нэша Сдает 3 месяца Сдает свободен 20 лет 5 лет 45/108
  • 47. Нужен выделенный координирующий человек с полномочиями  В ситуации быстро меняющихся требований нужно быстро реагировать  Все это требует координации и выделенного человека, который держит на этом фокус 47/108
  • 48. Даже самомотивированным людям нужно транслировать смысл задач заказчика  В том числе :  Показывать как именно мир становится лучше  Показывать живых людей, которым становится лучше 48/108
  • 49. Если у исполнителей мотивация не на результат проекта ($, комфорт, самоудовлетворение), то работать с ними нужно по другому (не чистый скрам) Работа руководителя превращать желания заказчика в мотиваторы исполнителей Том Сойер 49/108
  • 50. Руководителю нужно работать с людьми индивидуально 50/108
  • 51. Иногда есть прямой смысл поставить ответственного за задачу целиком Это противоречит чистому SCRUM 51/108
  • 52.  На этапе начальной разработки  Для плохо проработанных задачи  Для обеспечения квалификационного роста сотрудника  Для оценки квалификации сотрудника  Для повышения ответственности и мотивации сотрудника  Для повышения эффективности и минимизации рисков  Для контроля качества исполнения  Для дублирования компетенций 52/108
  • 53. Еще про распределение работ в команде  Кроссфункциональность противоречит эффективности, нужен разумный баланс  Нужно дублирование, а не полная кроссфункциональность Баланс в каждом случае свой 53/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
  • 63. Тупые и некомпетентные менеджеры мешают делать работу компетентным исполнителям  Скрам-мастеру нельзя дать   Менеджерофобия полномочия руководителя – иначе он сразу станет тупым менеджером Пусть менеджер занимается своим менеджерскими делами, а команда займется реальным делом Команда лучше самоорганизуется без руководителя 63/108
  • 65. Команда в позиции «попробуйте меня уговорить»  «Докажи всем в команде, что твое предложение не дурацкое»  Сильное ограничение власти руководителя  Вместо сотрудничества – борьба 65/108
  • 66. Плохо работает, когда руководитель – это самый сильный человек в команде (с точки зрения влияния на конечный результат) с богатым опытом проектной деятельности Руководитель 66/108
  • 69. Мнение # 2: Руководитель со всем не справляется, ему нужно помочь 69/108
  • 70. Избавляем руководителя от ненужной работы  Отделяем определение «что делать» (PO) от «Как    делать» (Команда) PO должен по возможности общаться в терминах ФИЧ и проблем, которые он хотел решить PO не нужно общаться с каждым членом команды Основные интерфейсы общения – Backlog и демонстрация Не нужно заранее закреплять задачу на исполнителе 70/108
  • 71. Почему именно так ему нужно помогать?  Понятие Product Owner – в общем-то из продуктовой разработки или InHouse  Для заказного софта подходит не очень сильно. Кто PO? Заказчик или человек из компании? 71/108
  • 73. Конструкция с замотивированным на результат руководителем и небольшим ядром команды, влияющих на остальную команду, более реалистична чем вся команда ориентированная на результат Сложно искать хорошего руководителя  Найти пару PO+SM ни разу не проще! Может превратится в command&control в худшем виде  Отделение от команды только маскирует и затягивает проблему «плохих» менеджеров. Ее нужно решать в любом случаем Я не предлагаю вернуть обратно директивное управление менеджером. Я предлагаю сдвинуть баланс в сторону руководителя 73/108
  • 74. PO и SM, схожие навыки  Системное мышление    Эмпатия Коммуникация Активная позиция 74/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
  • 86. Про итерации  У итерации фиксированная длина  У итерации фиксированный SCOPE 86/108
  • 87. Избыточная жесткость  Итерация нужна для планирования работ группами и создания точек синхронизации  Итерации бьются из абстрактного удобства разработчика, а не удобства получения результата (точки синхронизации не тогда, когда нужно)  Регулярно прилетают неожиданные задачи, которые сдвигают сроки и скоуп. А иногда делают итерацию бессмысленной  Нет возможности «подруливать» итерацией в процессе (удалять задачи и/или увеличивать сроки) 87/108
  • 89. Про ретроспективу  Нужно проводить ретро в конце каждой    итерации Ретро – это внутреннее дело команды Команда без ретро – это плохо После ретро нужно делать Бэклог на решение проблем 89/108
  • 90. Про ретроспективу  Команда (да и люди вообще) чаще всего не в состоянии себя запроблематизировать  В результате обсуждается ерунда , мало влияющие на процесс  Большинство реальных рычагов изменений (нанять, уволить, поднять зарплату, поговорить по душам, выделить время, купить сервер, купить библиотеку и т.д.) – не внутри команды  Команда, которая не успевает делать свои текущие дела, вряд ли успеет сделать их одновременно с задачами из дополнительного бэклога 90/108
  • 92. Про DSM  Нужно проводить DSM каждый день в одно время  Должна присутствовать вся команда  Обсуждаем кто-что сделал за день, что будет завтра и какие есть проблемы  Ограничиваем DSM пятью минутами 92/108
  • 93. Про DSM  Формальное действие, которое всех несколько утомляет (ритуал)  Обычно народ бубнит себе что-то под нос, и его почти не слушают  Проблемы практически никогда не обсуждаются  Никаких решений на ДСМ не принимают. ДСМ не влияет на то, чем люди будут заниматься в рабочем процессе  Как только начинается реально интересное обсуждение – его тут же сворачивают (ДСМ – 5 минут)  Искусственная мотивация посещения ДСМ (плюшки, штрафы, кармические бонусы) 93/108
  • 95. Про Демонстрацию  Демо нужно производить после каждой итерации  На демо нужно звать всех заинтересованных лиц  На демо нужно показывать все, что сделали за итерацию 95/108
  • 96. Про Демонстрацию  Внешним стейкходерам зачастую скучны 60% подробностей, которые рассказываются  Членам команды, напротив, обычно интересно и полезно знать детали реализации, чтобы иметь более полную информацию о проекте  Внешним стейкхолдерам и команде результат можно показывать в разном состоянии сырости  Бесконечные баги и сбои на демо раздражают заказчиков  К внешнему демо нужно готовиться тщательнее  От членов команды, наоборот хочется получить реакцию побыстрее  Разным стейкхолдерам интересны разные вещи. Им нужны разные демо  Неправильно подстраивать внешних стейкхолдеров под внутренний ритм проекта. Демо нужно устраивать, когда им удобно 96/108
  • 98. Вместо резюме  Все практики носят рекомендательный характер   Вы используете их на свой страх и риск  Вы можете изменять практики в соответствии с проектной необходимостью и собственными представлениями  При применении подключайте голову Ни одна из практик не является обязательной 98/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
  • 113. • Итерации могут быть разной длины (короткие 2-4 недели) • Конец итерации назначается руководителем. Может быть отодвинут им при желании. • В конце итерации внутреннее демо на котором руководитель смотрит промежуточный результат и решает что делать с итерацией (продлить/закончить). • Между итерациями могут появиться «санитарные дни». Когда вся команда «чистит хвосты». 113
  • 115. • SCOPE итерации делится на 3 части: • Сделать кровь-из носу • Крайне желательно сделать • Сделать если получится. • На планировании рассказывают о задачах (в т.ч. откуда они и зачем), их приоритетах (почему для бизнеса важно получить задачу к такому сроку) обсуждаются варианты реализации. Фиксируется SCOPE с командой (в 3х градациях) • Оценка задач на планировании не производится (производится только если команда не в состоянии подписаться на SCOPE без нее) • Оценка производится только по требованию клиента/PO – и это отдельная работа. 115
  • 117. • Нужен человек ответственный за процесс (может быть PO, может быть SM. Может быть любой назначенный человек из команды, который болеет за результат – например инженер) • Он решает назначать или нет DSM, Ретро и Демо (Практики - инструмент, а не обязанность). 117
  • 118. DSM назначается если: • Есть подозрение что члены команды инкапсулировались в своих задачах и не видят общей картины • Есть новые сотрудники • Есть подозрение что будут сорваны сроки. 118
  • 119. Различаем 2 типа демонстрации внутренние и внешние 119
  • 120. Внутреннее демо • собирается только для команды и «сочувствующих». • В конце (или ближе к концу) итерации • Если есть необходимость • Члены команды и/или PO чувствуют, что не понимают что сделано соседями • Руководитель хочет глубже понять состояние проекта • Есть новые сотрудники 120
  • 121. Внешнее демо • Делается отдельно для разных групп стейкхолдеров • Проводится в тот момент, когда удобно тем кто будет смотреть • Планируется как отдельная работа • Не стоит на них экономить (Формирует правильные ожидания и восприятие для заказчиков (см мою презентацию про клиентоориентированность)) 121
  • 122. Для получения быстрой обратной связи от заказчика используется другие инструменты (не экономим на этом): • Макеты • Модели • Совещания • Презентации • И т.д. 122
  • 124. Каждый раз: думаем одно, говорим другое, делаем третье, получается — то, что есть. Потому что, слова — это пустой звук, а дела — пустая трата времени. Но, тем не менее, нужно делать всѐ как должно, честно и с доверием. Даосский принцип 124/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
  • 131. SCRUM – это хорошо http://www.sprettur.is/media/slides2008/Iceland2008MoneyforNothing.pdf 131
  • 133. Причем выигрыш демонстрируется на примере русской компании Exigen Services 133/108
  • 136. Чтобы понять, правильный ли у вас SCRUM, был разработан Nokia Test 136/108
  • 139. Nokia-тест “ Nokia-тест – внутренний инструмент Nokia, который решал совершенно конкретную задачу – унификации процессов в командах разработки Nokia. CUSTIS, декабрь 2009 года Тренинг Артема Марченко (Product Manager Nokia) ” 139
  • 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
  • 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
  • 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

Editor's Notes

  • #41: РМС, Хорошая команда. Все было хорошо пока PO не решил попробовать настоящий SCRUM