Upload
-
View
414
Download
0
Embed Size (px)
DESCRIPTION
Citation preview
2 декабря 2013 года
Круглый стол«Гибкость: как правильно жить и работать?»Михаил Заборовруководитель стратегических проектов
Компания CUSTIS
Существует с 1996 года
Занимается заказной разработкой промышленного корпоративного ПО
Agile-like процесс –с рождения
2/108
Внедрение SCRUM в CUSTIS
Первое внедрение – в 2007
Внедрял Асхат Уразбаев
В 2009–2010 – регулярные встречи Agile Russiaна нашей территории
Андрей Бибичев
Асхат Уразбаев
3/108
Сегодня
В компании 20+ человек
В компании более20 производственных команд
90% используют похожийна SCRUM процесс
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
16
Крупные темы которые можно обсудить
Философия
C самомотивацией все не так просто
Самоорганизация от сырости не заводится
Практические
Роли в SCRUM (в т.ч. про классовую вражду и немного про профессию тестировщиков)
SCRUM планирование расслабляет команду
Резюме
17
Мелкие темы которые можно обсудить
Требования к итерациям в SCRUM избыточно жесткие
Ретроспектива по SCRUMовски - практически бесполезное занятие
Чаще всего DSM вырождается в пустой гундеж
В SCRUMе демонтрация упрощенна до бесполезности
Резюме
Где еще скрам не помогает, а иногда даже мешает
Архитектура
Работа с персоналом
Долгосрочное планирование
Ресурсное планирование (в том числе краткосрочное увеличение/уменьшение команды)
18/108Резюме
Про самомотивацию
19/108
Про самомотивацию
Вставка рисунка Над проектом должны работать мотивированные профессионалы
Чтобы работа была сделана, создайте условия, обеспечьте поддержкуи полностью доверьтесь им
AgileManifesto
20/108
Что есть самомотивация?
Вставка рисунка
21/108
Системы ценностей разных людей сильно отличаются
Далеко не всегда то, за что готов платить заказчик, мотивирует разработчиков
То, что ценно для разработчика, для заказчика может быть странной, никому не нужной самореализацией (самоудовлетворение).
То, что ценно для заказчика - для программиста может быть порождением воспаленного разума и непонятная, неведомая фигня.
Люди склонны оценивать многие, даже сложные задачи как рутинные
22/108
23/108
Матрица компетентность - интерес
Ценности меняются
Вставка рисунка
Я всю жизнь строю эти дурацкие мосты
Делали учетную систему, а в результате оказалась просто интеграция
Цели и задачи заказчиков регулярно меняются. 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 лет
свободен
20 лет
свободен 5 лет
3 месяца
Маша тестирует задачу, сделанную Петейв условиях жестких сроков и дефицита времени
43/108
Варианты действий
Маша сотрудничает Маша заботится о себе
Петя сотрудничает
Маша и Петя находят компромисс
В результате оба немного перерабатывают
Продукт выходит вовремя
Маша требует много времени на тестирование
Петя работает в выходные и по ночам чтобы успеть к сроку
Петя заботится о себе
Петя делает работу в притык, так что времени тестирование и исправление ошибок не остается
Маша работает в выходные и по ночам
Часть ошибок остается неисправленными
Маша требует много времени на тестирование
Петя делает работу впритык, так что времени на тестирование и исправление ошибок не остается
Сроки срываются
44/108
Молчит
Мол
чи
т
Сдает
Сд
ает
20 летсвободе
н
20 лет
свободен 5 лет
3 месяца
Равновесие Нэша
Тип решений игры, в котором ни один участник не может увеличить выигрыш, изменив своё решение в одностороннем порядке, когда другие участники не меняют решения
Равновесие Парето
Равновесие Нэша
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
Формальное действие, которое всех несколько утомляет (ритуал)
Обычно народ бубнит себе что-то под нос, и его почти не слушают
Проблемы практически никогда не обсуждаются
Никаких решений на ДСМ не принимают. ДСМ не влияет на то, чем люди будут заниматься в рабочем процессе
Как только начинается реально интересное обсуждение – его тут же сворачивают (ДСМ – 5 минут)
Искусственная мотивация посещения ДСМ (плюшки, штрафы, кармические бонусы)
Про DSM
93/108
Обсуждение
Вставка рисунка
94/108Список Тем
Про Демонстрацию
Демо нужно производить после каждой итерации
На демо нужно звать всех заинтересованных лиц
На демо нужно показывать все,что сделали за итерацию
95/108
Внешним стейкходерам зачастую скучны 60% подробностей, которые рассказываютсяЧленам команды, напротив, обычно интересно и полезно знать детали реализации, чтобы иметь более полную информацию о проектеВнешним стейкхолдерам и команде результат можно показывать в разном состоянии сыростиБесконечные баги и сбои на демо раздражают заказчиковК внешнему демо нужно готовиться тщательнееОт членов команды, наоборот хочется получить реакцию побыстрееРазным стейкхолдерам интересны разные вещи. Им нужны разные демоНеправильно подстраивать внешних стейкхолдеров под внутренний ритм проекта. Демо нужно устраивать, когда им удобно
Про Демонстрацию
96/108
Обсуждение
Вставка рисунка
97/108Список Тем
Вместо резюме
Все практики носят рекомендательный характер
Вы используете их на свой страх и риск
Ни одна из практик не является обязательной
Вы можете изменять практики в соответствии с проектной необходимостью и собственными представлениями
При применении подключайте голову
98/108
Дополнительные слайды
100/108
Agile Manifesto 2.1
Teamwork & responsibility over Individuals and Interaction
Business Value over Working software
Partnership elaboration over Customer collaboration
Prepare for change over Respond to Change
101/108
Разработка ПО как конвейерное производство
Энтони Лаудер. Культуры программных проектов (2008)
102/108
Спланируйте наперёд Напишите детальные спецификации продукта, включая
необходимые стандарты качества
Разбейте работу на последовательность нескольких стадий
Определите специализированные роли для рабочих на каждой стадии
Опишите оптимальную последовательность простых повторяемых действий, необходимых на каждом из таких рабочих мест
Посчитайте время, необходимое для выполнения каждого действия, и выработайте соответствующее расписание для каждой стадии, включая время начала и окончания для всего проекта
Определите ресурсы (материалы, стоимость труда, станки, инструменты, и т.д.), необходимые для каждого действия. Просуммируйте их, чтобы определить стоимость каждой стадии и весь бюджет проекта
103/108
Начните производство согласно плану:
Возьмите работников из доступного персонала и назначьте их на рабочие места, определённые в плане
Прикажите рабочим выполнять повторяющиеся действия, предписанные на каждом месте, со скоростью, необходимой для завершения проекта вовремя и в рамках бюджета
Нажмите кнопку «Пуск», чтобы запустить производство
104/108
Мониторинг и Контроль:
Непрерывно проверяйте:
Рабочих на местах, чтобы убедиться, что они выполняют действия согласно плану
Темпы производства, чтобы укладываться в расписание
Потребление экономических ресурсов, чтобы проект укладывался в бюджет
Конечную продукцию на предмет соответствия стандартам качества
Там, где инспекция находит проблемы, справьтесь с ними:
Остановите производство
Исправьте причину проблемы, где возможно, путём:
Починки сломанного оборудования
Крика и запугивания рабочих
Перезапустите производство 105/108
Мониторинг и Контроль:
Там, где причина проблемы не может быть устранена, попробуйте следующие методы: Увеличьте бюджет
Предложите экономические льготы рабочим
Добавьте рабочих к конвейеру
Добавьте ещё один конвейер
Увеличьте сроки проекта
Измените спецификации продукта
Отмените проект
106/108
Разработка ПО:
Менеджеры создают план проекта, разбивающий необходимую работу на несколько стадий с чёткими временными и стоимостными рамками для каждой стадии, а значит, и для всего проекта в целом
Рабочие берутся из имеющегося персонала и назначаются последовательно на различные стадии проекта
На каждой стадии рабочие периодически пишут status report, чтобы менеджеры могли следить за прогрессом
107/108
Стадии: Стадия требований: cпецификации продукта заранее
записываются заказчиком или другим авторизованным человеком, тем самым переводя их бизнес потребности в спецификационный документ.
Стадия анализа: аналитик переводит спецификации продукта в полные фиксированные функциональные требования к программному приложению, производя документ с функциональными требованиями.
Стадия дизайна: дизайнер переводит функциональные требования в чёткую и ясную архитектуру приложения, формируя технический дизайн.
Стадия кодирования: программист, следуя техническому дизайну, пишет программный код.
Стадия контроля качества: тестировщики проверяют функционал программного кода, чтобы удостовериться в том, что он соответствует всем требованиям из вышеупомянутых документов.
108/108Обратно
109
Как это может быть (один из вариантов):
Это не SCRUM, но по прежнему Agile
110
Роли и их взаимодействие
111
• Команды 7-8 человек сидящие вместе
• Есть один человек ответственный за Backlog -
PO= Руководитель
• PO имеет право в тех случаях когда ему
необходимо проваливаться в любую
детальность как ему хочется
• В тех местах, где PO уверен в команде он
может полагаться на самоорганизацию a-la
SCRUM
• SM- помощник руководителя (если он нужен), с
полномочиями
112
Итерации
113
• Итерации могут быть разной длины (короткие
2-4 недели)
• Конец итерации назначается руководителем.
Может быть отодвинут им при желании.
• В конце итерации внутреннее демо на
котором руководитель смотрит
промежуточный результат и решает что
делать с итерацией (продлить/закончить).
• Между итерациями могут появиться
«санитарные дни». Когда вся команда «чистит
хвосты».
114
Планирование
115
• SCOPE итерации делится на 3 части:
• Сделать кровь-из носу
• Крайне желательно сделать
• Сделать если получится.
• На планировании рассказывают о задачах (в т.ч.
откуда они и зачем), их приоритетах (почему для
бизнеса важно получить задачу к такому сроку)
обсуждаются варианты реализации. Фиксируется
SCOPE с командой (в 3х градациях)
• Оценка задач на планировании не производится
(производится только если команда не в состоянии
подписаться на SCOPE без нее)
• Оценка производится только по требованию
клиента/PO – и это отдельная работа.
116
Ритуалы
117
• Нужен человек ответственный за процесс
(может быть PO, может быть SM. Может
быть любой назначенный человек из
команды, который болеет за результат –
например инженер)
• Он решает назначать или нет DSM, Ретро и
Демо (Практики - инструмент, а не
обязанность).
118
DSM назначается если:
• Есть подозрение что члены команды
инкапсулировались в своих задачах и не
видят общей картины
• Есть новые сотрудники
• Есть подозрение что будут сорваны
сроки.
119
Различаем 2 типа демонстрации внутренние и
внешние
120
Внутреннее демо
• собирается только для команды и
«сочувствующих».
• В конце (или ближе к концу) итерации
• Если есть необходимость
• Члены команды и/или PO чувствуют, что не
понимают что сделано соседями
• Руководитель хочет глубже понять
состояние проекта
• Есть новые сотрудники
121
Внешнее демо
• Делается отдельно для разных групп
стейкхолдеров
• Проводится в тот момент, когда удобно тем
кто будет смотреть
• Планируется как отдельная работа
• Не стоит на них экономить (Формирует
правильные ожидания и восприятие для
заказчиков (см мою презентацию про
клиентоориентированность))
122
Для получения быстрой обратной связи от
заказчика используется другие инструменты
(не экономим на этом):
• Макеты
• Модели
• Совещания
• Презентации
• И т.д.
123
Ретро
Даосский принцип
Каждый раз: думаем одно, говорим другое, делаем третье, получается — то, что есть.
Потому что, слова — это пустой звук, а дела — пустая трата времени.
Но, тем не менее, нужно делать всё как должно, честно и с доверием.
124/108
Откуда все пошло
125/108
Зачем мы внедряли SCRUM
…и получили ли то, что хотели, – тема отдельного разговора
126/108
Долгий и тяжелый путь осознания внутри компании
127/108
128
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
2006 год. Jeff SutherlandMoney For Nothing
129
http://www.sprettur.is/media/slides2008/Iceland2008MoneyforNothing.pdf
Вводится понятие
Да-да
130
ScrumButt
«We’ve got SCRUM, but…»
131http://www.sprettur.is/media/slides2008/Iceland2008MoneyforNothing.pdf
SCRUM – это хорошо
132http://www.sprettur.is/media/slides2008/Iceland2008MoneyforNothing.pdf
Но только настоящий
ПокупайтеTrue SCRUM
Причем выигрыш демонстрируется на примере русской компании Exigen Services
133/108
134http://www.sprettur.is/media/slides2008/Iceland2008MoneyforNothing.pdf
135http://www.sprettur.is/media/slides2008/Iceland2008MoneyforNothing.pdf
Чтобы понять,правильный ли у вас SCRUM, был разработан Nokia Test
136/108
137http://www.sprettur.is/media/slides2008/Iceland2008MoneyforNothing.pdf
138
Пример вопроса
http://www.sprettur.is/media/slides2008/Iceland2008MoneyforNothing.pdf
139
CUSTIS, декабрь 2009 года
Тренинг Артема Марченко (Product Manager Nokia)
Nokia-тест
Nokia-тест – внутреннийинструмент Nokia, который решал совершенно конкретнуюзадачу – унификации процессов в командах разработки Nokia.
“
”
Тест получилширокое распространение
140/108
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
Хенрик Книберг
143
Kniberg на AgileDays 2011
Я: Хенрик, что-то у нас оценки на планировании приводятк плохим результатам.
Хенрик: Ну и не оценивайте тогда.
Я: А что, можно было?
144
Сертификация SCRUM
Институционализация и шаблонизация SCRUM.
http://www.scrumalliance.org/pages/fee_payment_linkshttp://www.scrumalliance.org/resources/2743http://www.scrumalliance.org/pages/certified_scrum_coachhttp://www.scrumalliance.org/resources/2186
$750 в год
$150 каждые 2 года
$250 один раз +$5000 в год +$50 за каждого студента
$300 каждые 2 года
$100 каждые 2 года
$100 каждые 2 года
$1000–$1500 ежегодно+ $250 ежегодно, за каждый курс
145/108
http://xpinjection.com/2011/08/22/scrum-certification/
«Scrum Alliance выстроил великолепную пирамиду вокруг одной из самых простых методологий разработки».
«Во всем мире уже давно поговариваюто сомнительности сертификацииScrum Master-ов, которая проходитпосле посещения двухдневного курса».
«Сейчас я полностью разочаровалсяв сертификации. И виной тому именнопрограммы наподобие Scrum Master».Николай Алименков
SCRUM-сертификация и ее последствия
146/108
147
Двухдневный курс
Базовые сведенияо SCRUM
Большинство сходивших поначалу требуют вернуть назад «православный SCRUM»
148
Agile-конференцииЗакрепляют и развивают одни и те же базовые идеи
Who is your Product Owner, and what does he/she do?
Как внедрить Agile?Масштабирование Agile
Agile Planning
Scrum в Fixed-Price проектах: практический опыт
Toward Agile Scalability: From components to feature teams
Enterprise Agile: Управление Agile проектами на уровне компании
Scrum Master – кто ты?
Velocity как инструмент планирования и управления проектом: предсказываем, измеряем, оцениваем
Какие еще есть мнения
149/108
150
Казалось бы,про то же самое
151
Однако при этом!
Квинтэссенция моего доклада
Постепенно (2011–2012 год) появляются и другие статьи
152/108
153
2011 год. Культ Карго в IT — троллим адептов SCRUM-а
IT-шники тоже выполняют бессмысленные ритуалы, например, стояние у Canban-доски по утрам или планирование с помощью карт Planning Poker, абсолютно не понимая смысла происходящего.
http://blog.sibirix.ru/2011/09/28/cargo_cult_in_it/
154http://xpinjection.com/2011/09/07/is-scrum-master-needed/
А нужен ли на самом деле Scrum Master?
Scrum Master – фиктивная профессия, программисты, не умеющие хорошо программировать.
Кто угодно справится с этой задачей.
Scrum Master гордится своими сертификатами, а продуктивность лишь падает.
Scrum Master – катализатор для роста эффективности команды только в умах зомбированных Scrum-конференциями.
Николай Алименков
155
2012 год. Stop Using Story Points
http://www.industriallogic.com/blog/stop-using-story-points/
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/
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/
158
AgileDays – 2013
SCRUM – это не «серебряная пуля»
Эволюция Agile, или Погоня за идеальным процессом
Усвоенные уроки одной кроссфункциональной команды разработки
Перестаньте спрашивать «КОГДА?»
Угасающие команды – почему все ломается и как можно их спасти
Velocity как инструмент планирования и управления проектом: предсказываем, измеряем, оцениваем