Асхат Уразбаев Генеральный директор, Москва
Гибкие методы соединяют старые элементы в новом сочетании проясняем особенности идеологии Agile в формате онлайн-конференции.
Интервью Scrum: революция в проектном менеджменте. Следуйте смыслу, а не плану, опубликованное , вызвало вопросы и комментарии участников Сообщества.
В этой публикации даем ответы на самые интересные из них.
Евгений Корнев: Ничего нового, кроме названий для себя не узнал и не увидел. Все давно и напрочь уже разработано и изобретено до нас.
Новизна может заключаться только в различных интерпретациях сочетаемых или несочетаемых (по правилам) управленческих решений и приемов.
Асхат Уразбаев: 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 и другие.
Василий Ямателтдинов: Проектный план это не только объемы, но еще и, как правило, фиксированные сроки и бюджет. Замечательно, если заказчик готов работать с вами по TM.
А как быть, если он требует 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
