Очень часто и очень многие понимают SCRUM догматично: «Только использование канонических процессов SCRUM дает действительно существенный позитивный результат». На самом деле, это часто вредит процессу. Можно и нужно периодически отходить от «правил» скрама, не отходя при этом от принципов agile. Можно, конечно, не называть это SCRUM-ом. Но дело вовсе не в названии, а в том, что любую хорошую вещь (в том числе, SCRUM) нужно использовать без фанатизма. В докладе будут рассмотрены некоторые "каноны" SCRUM. Например, такие как: * Роли SM и PO, запрет на совмещение с руководителем проекта. * Необходимость оценивать задачи при планировании. * Фиксированная длина и жесткий SCOPE итераций. * Обязательность DSM каждый день, Ретро и Демо после каждой итерации. * Требования отгружать готовое ПО после каждой итерации. * Самоорганизация команды. * Кросс-функциональность команды. Будут рассмотрены случаи из реальной практики, когда следование "канонам" не помогает, а, иногда, и существенно вредит процессу, а также варианты ослабления требований к процессу или его альтернативная организация. Это доклад о том, что: * Ни одна из практик SCRUM не является обязательной. * Можно и нужно изменять практики в соответствии с проектной необходимостью и собственным представлениям. * При применении практик нужно обязательно подключать голову.

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

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

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

21.  Мы не может отказаться от коммитмента заказчику!

22.  Само по себе наличие оценки вносит существенное
возмущение в процесс разработки

24.  Команде выгоднее давать
оценки типа «перестраховка»
 Реально работа занимает все
отведенное под нее время
 В результате команда переходит
в расслабленное состояние

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

26. http://www.industriallogic.com/blog/
stop-using-story-points/

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

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

38. 



