Интервью «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, для реорганизации ИТ-структур компаний, и в том числе решения, позволяющие исключать лишние структуры управления. Власть перемещается к Архитектору и это исключает противоречия бюрократии и строгой иерархии.
Здесь , как всегда :), типичная ошибка - забывают о Маркетинге и кто является клиентом. Клиентом является Собственник и Руководство компании, которые устали от того, что ИТ- структуры не справляются с потребностями компании, и им нужно решение этой проблемы. Решение проблемы начинается с принципов организации ИТ-структуры.
Agile - это только инструмент, как и DevOps (Development - разработка и Operations - ИТ-операции) - новая методология разработки ПО, как и многие другие ....
Рынок требует :), чтобы каждые 2- 3 года появлялось что-то новое - и через несколько лет появится что-то другое :)
Как всегда упущено самое важное, а именно - стабильность цели проекта. При этом цель от продуктоориентированной смещается к бизнесс-ориентрированной. Пример с BPM системой. Банку требуется не BPM система как таковая, а ускорение анализа поведения хороших заемщиков по обслуживанию и возврату кредитов и ссуд, сопряженная с анализом изменения рекомендаций ЦБ по резервам и ключевым ставкам + анализ рыночных возможностей по привлечению пассивов и капитала. BPM как таковой именно инструмент. Если целью применения Agile станет решение бизнес-задачи, тогда все что ниже уровнем (ИТ-технологии, аутсоурсинг/инсоурсинг/самостоятельная разработка) станут только элементами в руках Архитектора. Который в свою очередь будет Архитектором бизнес задачи.
Насколько я понял Греф когда превозносил Agile имел именно это в виду. Поднять Архитекторов ИТ до уровня Архитекторов бизнеса. И на сколько я пониманию такой подход приведет к "умным контрактам", когда текст договора будут писать на чем то типа Business Java или тому подобных технологиях.
Дискуссия отредактирована. Сообщения оф-топик удалены.
На первый взгляд, технически DevOps - это всё просто :) -> здесь тоже подразумевается использование гибких инструментов разработки и внедрения, ещё обеспечивается непрерывная доставка новых выпусков приложений, диагностика и передача отладочной информации -> Можно добавить, что отделы разработки и админы - становятся дружественными подразделениями, а не врагами. Это философия и База - это непросто и требует усилий.
Но это всё не объяснит всех его достоинств, лучше с точки зрения Маркетинга -> чем они отличаются по простому :) - Agile - упорядочение Разработки ПО
DevOps - это тоже упорядочение, но цепочка потока задач более длинная:
Разработка <--> ИТ-операции <--> Доставка ценности Клиенту и обратная связь
Греф сравнивает Сбербанк с Amazon по количеству изменений в коде, но он может быть забыл, что Amazon делает более 1000 развертываний рабочего программного обеспечения в день , и заявляют об успешности изменений в 99,999 про-цен-тов!!! - это результат использования чего? - DevOps, конечно! А что требуется Сбербанку? :) Греф лучше нас представляет, что нужно Сбербанку, но он уже ошибался, когда проводил централизацию ИТ систем, и проверить ошибается он ещё раз или нет можно только со временем или нет?