Что такое Scrum? Асхат Уразбаев отвечает на вопросы участников Executive.ru

Интервью «Scrum: революция в проектном менеджменте. Следуйте смыслу, а не плану», опубликованное на Executive.ru 26 апреля 2016 года, вызвало вопросы и комментарии участников Сообщества. В этой публикации даем ответы на самые интересные из них.

Евгений Корнев: Ничего нового, кроме названий для себя не узнал и не увидел. Все давно и напрочь уже разработано и изобретено до нас. Новизна может заключаться только в различных интерпретациях сочетаемых или несочетаемых (по правилам) управленческих решений и приемов.

Асхат Уразбаев: Agile – cоединение старых элементов в новом сочетании. Как и любая инновация вообще.

Сергей Курбатов: Метод разбиения большого проекта на малые его подпроекты (с 1956 года) для достижения основной цели проекта (о которой должен знать любой член проектной команды, выпускающей пусть не суперлайнеры, а хлеб насущный) - фундаментальная основа управления проектами. Метод разбиения на подпроекты должен упрощать работу команды проекта, о чем уважаемый Lockheed и поведал миру в 1956 году. Асхат Уразаев, напротив, усложняет, использует далеко не всем понятный лексикон. Методы ЛСП и ЛСМ также, как и телескоп, изобретены задолго до автора.

А.У.: Хм. Я – не автор Agile. «Мопед не мой». Термин был введен в 2001 году, когда известные методологи собрались и приняли манифест гибкой разработки. Там же можно посмотреть всех подписантов. Что касается разбиения проекта на части — тут есть некоторый нюанс. В Agile разбиение происходит на мелкие части, каждая из которых несет ценность и в идеале происходит независимо. Проще наверное привести пример. Допустим, вы банк и решили внедрить новую BPM систему. Вам нужно покрыть несколько десятков процессов. Проект большой и вы разбиваете его на части. Пишете бизнес-требования 2-3 месяца, потом функциональные требования, потом у вас этап разработки, затем тестирование и приемка. Это, конечно, не Agile. В гибком подходе каждый автоматизируемый процесс выходил бы в поставку независимо и более-менее последовательно так, чтобы пользователи могли начать им пользоваться. При этом первая поставка случилась бы, наверное, примерно через пару итераций.

Владимир Зонзов: Почему в проектном управлении выпучивание итеративного подхода, в пику линейному, является лживым? Потому что там эти подходы являются двумя сторонами одной медали. Линейный подход отражает причинно-следственную связь между работами, выполнение которых приводит проект от его замысла к его результатам. А необходимость итерационного подхода – это следствие желательности-необходимости дополнять-уточнять замысел-работы-результаты.

А.У.: Каждому подходу – свое место. Мартин Фаулер, очень авторитетный архитектор программного обеспечения, приводит такую аналогию. Я изложу ее своими словами. Допустим, вы занимаетесь возведением торговых центров. После того, как все спецификации и документация по проекту готова, начинается строительство. Оно может занимать от нескольких месяцев до нескольких лет. Так вот, в разработке программного обеспечения аналогичную работу выполняет компилятор. По имеющимся спецификациям (программному коду) он строит итоговый продукт (файлы в машинных кодах) за считанные секунды. Имеет ли смысл делать строительство торговых центров по Agile? Нет, конечно. Однако, например, создание проектов торговых центров уже вполне разумная задача и есть компании-проектировщики, которые с успехом применяют гибкие подходы.

Тимур Хащеватский: В зрелых (в хорошем смысле слова) компаниях с серьезными проектами и опытными пиэмами (проектными менеджерами - прим. Executive.ru) Scrum не нужен. Он похож на трехколесный велосипед - позволяет ездить, не падая, но не слишком быстро.

А.У.: Agile постепенно становится стандартом де-факто в крупных компаниях, например банках по всему миру. Появилось множество подходов по внедрению и масштабированию Agile на всю организацию: например, Scaled Agile Framework, Large Scale Scrum, Nexus и другие.

Василий Ямателтдинов: Проектный план – это не только объемы, но еще и, как правило, фиксированные сроки и бюджет. Замечательно, если заказчик готов работать с вами по T&M. А как быть, если он требует fixed price (что, собственно, и происходит в большинстве случаев)? Об этом апологеты agile почему-то умалчивают.

А.У.: Сам по себе fixed price (фиксированная цена) не является препяствием. Проблема в fixed scope (фиксированном объеме работ). Такая фиксация вызывает проблемы для самого заказчика, ему самому труднее менять требования при необходимости, при этом каждое изменение приводит к удорожанию и удлинению проекта.

В Agile мы чаще используем fixed budget (фиксированный бюджет). При этом требования могут меняться. А Scrum, по большому счету, используется как метод управления изменениями. Безусловно, очень важна готовность заказчика работать по такой модели. «Подпольно» запустить Scrum – малореально :-)

Алексей Божин: По моей практике, такой метод итераций хорошо себя показывает, когда клиент сам не знает, чего точно хочет или у него постоянно появляются новые идеи.Тогда можно все его идеи реализовывать и гибко оценивать их стоимость.

Алексей Чернышев: Если отбросить англоязычные термины, статья должна называться «Как не облажаться при мутном ТЗ и гарантированно получить деньги с заказчика при непонятном результате». Плюс наблудить на его (заказчика) метаниях еще пару проектов.

А.У.: «Мутное ТЗ» – неизбежно при повышении сложности проекта. Неопределенности разных типов приводят к его изменению. Неясные новые технологии, непонятности с инфраструктурой, изменение ситуации на рынке, неожиданные действия регуляторов неизбежно превратят даже кристально ясное ТЗ в мутное. Для сайтов-визиток это, безусловно, не так критично.

Можно обвинять заказчика, но получается неэффективно. Вроде и вендор не виноват, и заказчик тоже не на все может повлиять — а результат плохой: заказчик получает не то что ему нужно с большими задержками.

Scrum — очень прозрачный для заказчика процесс. Его представители могут участвовать на ежедневной основе в работе команды, например на ежедневных стендапах (летучках). Раз в 2 недели проводятся презентации для заказчика. Он быстро может узнать о том, что у вендора есть проблемы с поставкой и принять правильное решение вовремя.

Владимир Зонзов: Если за время разработки цель разработки устаревает, то о каком ее результате может идти речь? (Результате, в смысле SMART). В условиях слабости заказчика, в части формулировки заказа, конечно, желательно разбивать разработку на периоды; достаточно короткие, чтобы не уйти далеко в «не ту степь».

А.У.: +1 :-)

Александр Соловьев: В проектах, которые работают, власть перемещается к Архитектору программного обеспечения, который видит в проекте кроме работы на Заказчика, работу по развитию Платформы, и от этого выигрывают все, и Заказчики в первую очередь. Поэтому рассказы о том, что Agile is Dead, плохом коде, ошибках в разработке - все это в основном о неудачных проектах, где был плохой Архитектор или Архитектор был слаб и играл второстепенную роль.

А.У.: Высокая техническая компетенция в Agile у исполнителей важна. Мой опыт однако говорит, что она важна вне зависимости от типа жизненного цикла проекта. Некомпетентность стоит намного дороже.

Валерий Овсий: В идеологии Agile высшая власть должна принадлежит инвестору. Меняются бюджеты, корректируется цели и пути достижения. Это все может быть только в компетенции инвестора, иначе начинают работать все минусы Agile/ Scrum.

А.У.: В Agile право принятия решений по объему работ и сроках лежат на владельце продукта. Если все решения принимает кто-то находящийся слишком высоко сверху над ним, то скорость принятия решений замедляется, и процесс начинает буксовать.

Василий Ямалетдинов: Гибкие технологии создания ПО проистекают из самой его природы (soft = «мягкий»), поэтому и рассматриваться, как справедливо было замечено, должны именно в этом контексте. Но в интервью этот ключевой момент почему-то обходится стороной, при этом делается упор на то, что эта методология применима и для проектов в других сферах - например, упоминаются банки, но как конкретно это там применяется, почему-то так же умалчивается. Что касается производственных/ строительных проектов, полностью согласен, сложно представить строительство, скажем, моста по технологии Scrum. Ну а если такой мост и будет когда-либо построен, лично мне не хотелось бы по нему ездить

А.У.: +1

Расскажите коллегам:
Комментарии
Нач. отдела, зам. руководителя, Москва

Александр Соловьев:
В проектах, которые работают, власть перемещается к
Архитектору программного обеспечения, который видит в проекте кроме работы на Заказчика, работу по развитию Платформы, и от этого выигрывают все, и Заказчики в первую очередь.
Асхат Уразбаев:
Высокая техническая компетенция в Agile у исполнителей важна ...

Здесь речь о другом, не компетенции - Вы отрываете Agile от среды в которой всё происходит, и это всего лишь инструмент. В этой среде есть потребности быстрых изменений, противоречия, бюрократия - отсюда и возникли две Модели трансформации ИТ-служб на основе Концепции Бимодальности и Многопоточности. Если у Архитектора нет власти, ничего не будут работать из-за сопротивления Среды и внутренних проблем Команды.

Нач. отдела, зам. руководителя, Москва
Асхат Уразбаев:
Agile –
cоединение старых элементов в новом сочетании. Как и любая инновация вообще.

По поводу темы революционности, которая поднималась в обсуждении к первой статье. Вот как раз Концепции Бимодальности и Многопоточности и приводят к революционным изменениям в принципах организации ИТ-службы,. Agile - это только инструмент.

Пример решения - использовании проектных офисов на основе Agile, для реорганизации ИТ-структур компаний, и в том числе решения, позволяющие исключать лишние структуры управления. Власть перемещается к Архитектору и это исключает противоречия бюрократии и строгой иерархии.

Нач. отдела, зам. руководителя, Москва

Асхат Уразбаев: Agile постепенно становится стандартом де-факто в крупных компаниях, например банках по всему миру.

Здесь , как всегда :), типичная ошибка - забывают о Маркетинге и кто является клиентом. Клиентом является Собственник и Руководство компании, которые устали от того, что ИТ- структуры не справляются с потребностями компании, и им нужно решение этой проблемы. Решение проблемы начинается с принципов организации ИТ-структуры.

Agile - это только инструмент, как и DevOps (Development - разработка и Operations - ИТ-операции) - новая методология разработки ПО, как и многие другие ....

Рынок требует :), чтобы каждые 2- 3 года появлялось что-то новое - и через несколько лет появится что-то другое :)

Аналитик, Москва

Как всегда упущено самое важное, а именно - стабильность цели проекта. При этом цель от продуктоориентированной смещается к бизнесс-ориентрированной. Пример с BPM системой. Банку требуется не BPM система как таковая, а ускорение анализа поведения хороших заемщиков по обслуживанию и возврату кредитов и ссуд, сопряженная с анализом изменения рекомендаций ЦБ по резервам и ключевым ставкам + анализ рыночных возможностей по привлечению пассивов и капитала. BPM как таковой именно инструмент. Если целью применения Agile станет решение бизнес-задачи, тогда все что ниже уровнем (ИТ-технологии, аутсоурсинг/инсоурсинг/самостоятельная разработка) станут только элементами в руках Архитектора. Который в свою очередь будет Архитектором бизнес задачи.

Насколько я понял Греф когда превозносил Agile имел именно это в виду. Поднять Архитекторов ИТ до уровня Архитекторов бизнеса. И на сколько я пониманию такой подход приведет к "умным контрактам", когда текст договора будут писать на чем то типа Business Java или тому подобных технологиях.

Редактор, Москва

Дискуссия отредактирована. Сообщения оф-топик удалены.

Нач. отдела, зам. руководителя, Москва
Игорь Скородумов пишет: При этом цель от продуктоориентированной смещается к бизнесс-ориентрированной. ...
Греф когда превозносил Agile ...
продуктоориентированный подход - это ближе к DevOps.

На первый взгляд, технически DevOps - это всё просто :) -> здесь тоже подразумевается использование гибких инструментов разработки и внедрения, ещё обеспечивается непрерывная доставка новых выпусков приложений, диагностика и передача отладочной информации -> Можно добавить, что отделы разработки и админы - становятся дружественными подразделениями, а не врагами. Это философия и База - это непросто и требует усилий.

Но это всё не объяснит всех его достоинств, лучше с точки зрения Маркетинга -> чем они отличаются по простому :) - Agile - упорядочение Разработки ПО

DevOps - это тоже упорядочение, но цепочка потока задач более длинная:

Разработка <--> ИТ-операции <--> Доставка ценности Клиенту и обратная связь

Греф сравнивает Сбербанк с Amazon по количеству изменений в коде, но он может быть забыл, что Amazon делает более 1000 развертываний рабочего программного обеспечения в день , и заявляют об успешности изменений в 99,999 про-цен-тов!!! - это результат использования чего? - DevOps, конечно! А что требуется Сбербанку? :) Греф лучше нас представляет, что нужно Сбербанку, но он уже ошибался, когда проводил централизацию ИТ систем, и проверить ошибается он ещё раз или нет можно только со временем или нет?



Оставлять комментарии могут только зарегистрированные пользователи
Статью прочитали
Обсуждение статей
Все комментарии
Дискуссии
Все дискуссии
HR-новости
Россияне стали меньше тревожиться из-за работы

Год назад уровень тревожности россиян по поводу различных возможных проблем на работе был выше.

Уровень счастья напрямую влияет на продуктивность большинства россиян

При этом почти каждый четвертый респондент считает, что их руководитель ничего не делает для счастья сотрудников.

70% россиян отмечают сильное влияние работы на уровень стресса

Наибольший стресс создают строгие дедлайны, внезапные и большие объемы задач, а также собственные ошибки при выполнении задач.