Бизнес требует от IT ускорять обороты. Сроки выхода проектов на рынок постоянно сокращаются. Применение гибких методологий Agile/ Scrum в небольшой команде позволяет значительно уменьшить Time-to-Market.
Однако в крупной компании прямое использование Agile/ Scrum затруднено: даже простое на первый взгляд изменение бизнес-процесса может затрагивать несколько систем, за которые отвечают разные команды. Релиз приходится координировать с большим количеством заинтересованных лиц. Это сильно замедляет и проектирование и финальное интеграционное тестирование. В результате добиться снижения Time-to-Market кажется очень сложной задачей, осложненной к тому же непростой «политической» ситуацией, типичной для крупной организации.
Вообще, вокруг гибких методологий существует множество мифов. В интервью «Scrum: революция в проектном менеджменте. Следуйте смыслу, а не плану», опубликованном на Executive.ru 26 апреля 2016 года, я назвал один из них: «Люди действительно очень любят планы, и когда рассказываешь им про Agile, они почему-то думают, что Agile и Scrum – способ работы без плана. Это не так. Есть разные модели жизненного цикла проекта, например, «водопадная» и итеративная. Scrum – пример итеративной модели. В IT также используют модель, которую называют Code and fix (кодируй и исправляй). Это то, что применяется, когда прибегает заказчик и кричит: «Ребята! Бежим туда!». Все снимаются и бегут. Затем заказчик командует: «Бежим обратно!». Все бегут обратно. При таком подходе можно бесконечно бегать вокруг колышка и никогда не достигнуть цели. Это – точно не Agile. Это – противоположность Agile. В Agile мы всегда, в каждый момент времени, представляем конечную цель, к которой мы приходим, и двигаемся к ней, как я уже говорил, короткими итерациями. В конце каждой короткой итерации, «спринта», мы оцениваем, приблизились мы к цели или нет. Общий план движения по проекту тоже есть, он называется Backlog, но он не является подробным. Слепость или не слепость определяет Product owner – его задача состоит в том, чтобы с помощью Backlog оценивать, правильно ли мы движемся к цели.
На этом тренинге мы рассматриваем этапы грамотного выстраивания Agile-процесса и роль Product Owner’a в нем. Базовые идеи, зная которые можно понять мир Agile. Тренинг раскрывает суть таких понятий как Story Mapping, концепции (Vision), объясняет принципы сбора и управления требованиями, а также уровни планирования в Agile».
На самом деле это – не единственный миф, сопутствующий гибким методологиям. Обсуждение интервью показало, что у участников Сообщества есть и другие заблуждения по поводу Scrum. Редакция Executive.ru и компания ScrumTrek планируют в конце мая – начале июня 2016 года подготовить публикацию, в которой мы ответим на вопросы и комментарии, размещенные в дискуссии под интервью.
Например, там написано:
Уточняю? 1) опыт Каких компаний? или только компании автора 2) Под новым углом - Т.е материал будет отличаться от общедоступной информации?
Поясняю - меня удивило совпадение текста первой статьи, на которую ссылаетесь, с общедоступными материалами.
1. Компании ScrumTrek и ее партнеров.
2. Мне не известно, что Вы понимаете под "общедоступной информацией". Текст интервью А.Уразбаева, как Вы считаете, содержит общедоступную информацию,
а другие участники дискуссии находят для себя в публикации нечто новое. Как это понять: эта информация для них -- не общедоступна? :)) У них -- что --доступа в Google нет? Есть. Тем не менее, информация для них -- новая. Следовательно, слово "общедоступная", которое Вы используете, здесь неуместно. Здесь нужна другая лексика: антитеза "Я в теме/ Я не в теме". Эта антитеза все ставит на свои места:
Те, кто не в теме, кто находит для себя нечто новое -- идут на мастер-класс (если хотят).
Те, кто в теме, кто не находит, -- не идут.
Только и всего.
друзья, а почему мой комментарий удалили? Такой поступок совсем не по Agile. Грустно :(