Совсем недавно, в своей заметке Ключ на старт я делился своим бесхитростным подходом к подготовке к релизу, и вот сегодня наступили новые времена. Релиз прошел успешно, инциденты в ходе релиза имели место быть, но мы были готовы к ним и результат был достигнут, как все и планировалось. Началась опытно-промышленная эксплуатация, нормальная регулярная поддержка. Сначала с участием консультантов и разработчиков, но это не продлится долго. Дальше наши коллеги поедут без нас самостоятельно, уже сейчас они почти не нуждаются в нашем внимании. И я этому рад, хотя кто-то меня может в этом не поддержать.
Не смотря на то, что мы в подавляющем большинстве проектов работаем в водопадной проектной технике, мы используем значительное количество Agile практик в ходе нашей работы. Организация работ по автоматизации – максимально гибкая: прототипирование, ранние показы, презентации, демо, работа с данными еще в ходе разработки, бэклог, импровизированные "спринты" и т.д. Нас сложно назвать апологетами гибких подходов, и мы во многом не близки "по букве" к наиболее известному scrum, но такой итеративный способ выполнения работ на ограниченном отрезке времени достаточно эффективен, и приближает нас к нашей цели – подготовить систему, среду и заказчика к внедрению.
Опытно-промышленная эксплуатация, вообще представляет собой образец подхода "наблюдай и улучшай". Всегда испытываю определенный трепет в этот момент, если запускается процесс который является для компании новым, или они делали его и раньше, но иначе и у людей есть сопротивляющаяся моторная память. Еще вчера все зависело только от нас, а теперь успех зависит от большого количества совершенно различных людей.
Нельзя сказать, что наше внедрение всегда является для компании эволюционным, иногда бывает наоборот, и в таких случаях мы подготавливаем все, чтобы они могли начать делать свою работу. Мы стараемся сделать так, чтобы нововведения приносили пользу максимальному числу вовлеченных участников, пусть даже это будет выражаться в раскраске форм и перемещению кнопок, каждый клик мыши важен. Но как бы мы не старались, это все равно ступенька, революционное изменение, определенный стресс и связанный с ним страх нового.
Если закончить лирические отступления, то очевидно что мы вынуждены использовать быстрые и классические подходы одновременно.
Лично у меня возникает вопрос о жизнеспособности гибкого подхода в его тотальном применении, и тому есть несколько наблюдаемых причин:
- Существует конфликт интересов поставщика сервиса и его потребителей.
- С одной стороны у нас есть интересы наших потребителей (объединю в этот термин потребителей и заказчиков), и эти интересы для нас имеют первоочередный приоритет. Весь подход основан на user stories, которые говорят нам: какие выгоды получит наш любимый пользователь от выполняемого изменения.
- С другой стороны, у нас есть product/process owner, который в идеале имеет некоторое видение своего продукта, которое может отличаться от пользовательских ожиданий. Но тем оно и ценно, т.к. это видение способно формировать эти самые ожидания.
- В жизни сервиса могут возникать ситуации, когда эволюционных изменений будет недостаточно. Это может происходить из-за того, что:
- За несколько лет накопился неустранимый технический долг, апологеты будут возражать, что такого происходить не должно, но в реальном мире это возможно. Решение стало сплошной заплаткой сплетенной из костылей разных лет, базы данных clipper более не подддерживаются, и т.д., по еще тысяче причин.
- За несколько лет недофинансирования (бизнес конечно считает иначе) продукт или услуга перестает отвечать ожиданиям и дешевле купить новое и готовое и начать с этой точки, чем довести существующий продукт до требуемого состояния. Или требуется новая функциональность, которая не совместима со старой архитектурой.
- Бизнес может говорить о том, что для него длишком дорого держать и кормить прорву разработчиков, от которых он же будет очень сильно зависеть.Для него, это люди, которые непрерывно делают что-то малопонятное со слабо доказуемой полезностью (на это конечно тоже есть возражения, да). По его оценкам стоимость разработчиков SAP и интегратора в конечном итоге выйдет дешевле, т.к. их участие будет все же ограниченным, чем этот нон-стоп карнавал "хипстеров". Ведь даже если бизнес ничего не будет прямо сейчас просить, разработчики будут заниматься рефакторингом, чтобы сделать быстрее-легче-тоньше (6 сигма и все-все-все), чтобы обосновать свою нужность, нет?
- Некоторые вещи (и процессы и продукты) могут быть запущены и использованы только блочно (архитектурно или на основании нормативных ограничений), а значит в эволюционном течении будут пороги различной величины и опасности.
Формируется настойчивое ощущение, что в реальном мире отказаться от "бимодального" IТ будет нельзя.
Легко говорить о будущем, если ты являешься поставщиком только одной уникальной и достаточно простой, одинаковой для всех услуги, например как Twitter, Uber или GisMeteo. Но утверждать о всеобщей истинности подхода на основании такой специфической выборки опасно. Слишком велик туннельный эффект, мир и реальные компании, их ИТ-службы существенно устроены существенно сложнее. Изменения влияют друг на друга, не все йогурты горячо требуемые изменения полезны.
Обращаюсь к коллегам, которые используют agile для проектов с большим месштабом и множеством заинтересованных лиц, вроде внедрение новой БАС, переход с одной ERP на другую, внедрение СМЭВ, расскажите как вы это делаете. Какого размера ваши ступеньки, они же существуют?
Что делать когда компоненты вашей услуги покупные и вы их только эксплуатируте (и мы видим много таких ИТ-служб), это тоже Agile?
Не переплачивает ли бизнес за непрерывное возведение самописных высокорискованных (фактор зависимости) велосипедов, если сравнивать с публичными промышленными решениями?
Сегодня очень многие говорят про Agile, но даже если у вас IaaS, кто-то должен эти серверы запросить, закупить, физически привезти, руками смонтировать, обеспечить кондиционирование и энергоснабжение (ChgM 🙂 ), подключить к управляемой сети и включить в умный вычислительный grid. И только после этого начнeтся "continious deployment", "infrustructure as a code" и прочие радости.
Что-то у меня сегодня "день скептика" и я порождаю больше вопросов чем ответов. Поделитесь пожалуйста вашим опытом или видением.
