Все, о чем я буду рассказывать в этом докладе, отражено на этой диаграмме – здесь показано, что представляет собой DevOps с точки зрения процесса. Эту картинку придумали не мы, её можно найти в Google по ключевому слову DevOps. И я сейчас попытаюсь провести вас по всем этапам этого процесса.
Первое, на что надо обратить внимание при рассмотрении этой диаграммы – это то, что в принципе нельзя сказать: где процесс начинается, и где он заканчивается. Мы традиционно начнем с планирования, но нужно понимать, что в реальной практике одного этапа планирования обычно не хватает, перепланировать приходится по многу раз – это процесс, который постоянно идет по циклу.
Также по поводу планирования – сразу скажу, что мне повезло меньше, чем коллегам, которые выступали на этой секции до меня и рассказывали, что они при проектировании новой системы все обследовали, продумали все внутренние взаимосвязи и дальше пошли, не ошибаясь. У нас с планированием так никогда не получалось, и у других коллег на реальных проектах я тоже не видел, чтобы все было настолько гладко. Но, конечно, круто, если у кого-то это получается.
Сравнение подходов – Waterfall vs Scrum.
Первый вопрос, который я хочу затронуть, это – «Какой подход правильнее применять на проекте?»
Основная идея подхода Waterfall (водопад) – это то, что мы:
- Сначала обследуем, проектируем;
- Потом разрабатываем, с предположением, что мы все верно спроектировали, ни разу нигде и никогда не ошибившись;
- И дальше все сразу запускаем в эксплуатацию.
В реальной жизни это, конечно, немного не так. На любом проекте при запуске в эксплуатацию мы, так или иначе, сталкиваемся с суровой реальностью, и неизбежно начинается перепланирование, перепроектирование, дополнительная разработка и т.д. Но, тем не менее, до этапа эксплуатации вполне можно себе представить проект, который именно так и идет.
В подходе Scrum мы видим все те же самые виды работ, но они происходят циклично, по спирали.
Подчеркиваю, что Scrum – это не та методология, которую все ищут для того, чтобы что-то сделать, не проектируя систему. Или что-то сделать, не думая. Думать в Scrum приходится больше. Например, учитывая, что консультанты во франчайзи работают в среднем около 1.5 лет, на этапе обследования большого проекта, который будет длиться 2 года, ты можешь делать самые смелые предположения о том, как будут «выкручиваться» твои коллеги на этапе эксплуатации, потому что это будешь точно не ты. Но если мы говорим про Scrum, то у тебя есть, по сути, только 2 недели, спустя которые, независимо от того, прав ты был или ошибался, все узнают истину, включая тебя. По большому счету, это способ, чтобы проектная команда и отвечала за то, что она делает, и проверяла на практике все гипотезы, которые возникают.
Когда правильнее применять водопадный подход? Я считаю, что есть два условия, при одновременном наличии которых он нужен.
- Первое условие – это когда готовый продукт проекта изменить очень сложно (или даже невозможно).
Например, программное обеспечение бортового компьютера космического аппарата Аполлон. Здесь на слайде показано не само устройство, а макет его схемы. Если кто читал, то при проектировании этого ПЗУ использовался узелковый метод записи с ферритовыми кольцами, ненамного отличающийся от того, которым пользовались в своей письменности племена инков. Если в этом программном коде вы где-нибудь в середине найдете баг, то исправить его будет действительно сложно – даже на земле. Чтобы его переделать, нужно будет все расплести и заплести заново. На YouTube есть масса фильмов о том, как разрабатывалось данное программное обеспечение – там на магнитофонной ленте была записана программа для управления, которая в нужном месте позиционировала иглу, чтобы девушки, которые все это плели, в этом месте продевали провод через кольцо.
Здесь по Agile пойти не получится. Что бы вы ни делали, рефакторинг (быстрый и дешевый, во всяком случае) здесь невозможен.
И, конечно, по «водопадной модели» разрабатывается большинство крупных объектов реального мира (их часто приводят в качестве аналогии при проектировании программного обеспечения) – это строительство зданий, самолеты, подводные лодки и т.д.
- Второе условие, при котором «водопадная модель» работает – это когда проект имеет относительно низкую сложность, когда команда действительно с первого раза имеет шанс, хорошо напрягшись и используя свой опыт, IQ и смекалку, спроектировать систему в целом правильно.
А если система сложная и превышает возможности проектной команды, то спроектировать ее с первого раза не получится. Все сложные проекты, как бы формально они не управлялись – это всегда итерационный, эволюционный подход – мы сделали, проверили гипотезу, не получилось, что-то переделали, проверили еще раз.
Итак, есть два условия, когда нужно применять Scrum:
- Когда готовый продукт проекта можно относительно быстро и дешево изменить.
- И второе условие – это высокая сложность проекта. Если проект достаточно сложный, который невозможно реализовать с первого раза в силу ряда факторов (например, слишком много неизвестных, или слишком сложные зависимости между разными факторами), тогда это эволюционный, итеративный подход, именно тот, который применяет окружающий нас мир – живая природа и эволюция.
Почему сейчас подход Scrum применяется все чаще? Основная причина – это то, что мир изменился. Когда-то для разработки программного обеспечения нужно было исписать много бумаги, чтобы потом было меньше итераций – они все равно будут, но их будет меньше. Да, это дорого, но мы понимаем, что переделывать еще дороже.
Сейчас ситуация другая – самый дешевый способ проверить гипотезу – это проверить гипотезу. Берете софт, внедряете в реальную жизнь, смотрите результат. Поскольку инкремент у вас за две недели будет небольшой, то глобально вы ничего не сломаете – вы просто таким образом проектируете систему.
В качестве примера эффективного применения Scrum можно привести доработку программного обеспечения для управления марсоходом Spirit. Там была интересная ошибка. Марсоход находился на расстоянии 200 миллионов километров от Земли, и в его ПЗУ был баг. Но администраторы с использованием удаленного подключения на расстоянии 200 миллионов километров смогли изменить данные, которые хранятся в ПЗУ марсохода, и он продолжил выполнение своей миссии.
На слайде показано, как выглядит устройство, для которого потребовалась эта перепрошивка – здесь 3 Мб памяти, оно реально маленькое. Однако, 3Мб памяти – это в 45 раз больше, чем та память, которая была в ПЗУ космического аппарата Аполлон. Если бы на Аполлоне нужно было бы 3Мб памяти, то узелковое письмо заняло бы 1,2 м3 по сравнению с этой маленькой пластинкой, которая к тому же, перезаписывается, и которую нет проблем отрефакторить даже на большом расстоянии от Земли. К счастью (или, к сожалению) мы на Марс никаких программ на 1С не запускаем, поэтому нам внести изменения в наш код проще. У нас нет проблем с большим пингом на 200 миллионов километров.
Есть ли случаи, когда нельзя применять Scrum?
Его нельзя применять на тех проектах, когда заказчик не заинтересован в том, чтобы что-то запустить или улучшить. Если у заказчика нет такой цели (а это часто бывает, особенно с государственными заказчиками и крупными холдингами, когда им просто пришла разнарядка что-то внедрить) – они внедряют, но им все равно, как запустится система, и как она будет работать. Они просто формально выполняют то распоряжение, которое есть.
Когда мы пытаемся применять Scrum на таких проектах, мы получаем систему Шрёдингера, которая эксплуатируется и не эксплуатируется одновременно.
В виде вымышленной истории расскажу об одном таком проекте. На нем нам удалось запустить систему в течение двух месяцев, причем, после запуска в ней ежедневно работали сотни пользователей в течение полугода. Тем не менее, заказчик упорно утверждал, что система не введена в эксплуатацию. Мы получили классическую ситуацию, когда система и работает и не работает одновременно.
Когда мы показывали заказчику, что системой пользуются, что в нее заходят пользователи – он утверждал, что это не важно, потому что акта ввода в эксплуатацию подписано не было.
- Ну, вот же, есть акт – подпишите.
- Его нельзя подписать, нам нужно, чтобы у вас был протокол тестирования.
- Так вот же, наши тесты, отчеты о тестировании, все интерактивно.
- Нет, так не пойдет, они не согласованы.
- Так давайте мы все протоколы составим, и вы их подпишите.
- Нет, так нельзя, нам нужно ТЗ.
А ТЗ не было из-за того, что проект был сделан по Scrum.
Там возникло недопонимание, суть которого в том, что холдинг заказчика (несколько десятков заводов) решил внедрить систему управления ИТ-проектами, но для него была проблема написать ТЗ. А тут он прочитал, что в Scrum ТЗ не нужно и решил, что это ему подходит. Этапы проекта стали называться спринтами, и мы, применив некоторые лайфхаки, смогли в течение первых двух месяцев ввести систему в опытную эксплуатацию (не просто для целей тестирования, а именно для того, чтобы в реальной жизни приносить реальную ценность). Но дальше все уперлось. В итоге, не смотря на то, что заказчику изначально говорили, что ТЗ не будет написано, его холдинг без согласованного ТЗ принять работу не согласился.
Поэтому в таких случаях, когда заказчику не нужен результат, применять Scrum не стоит, применяйте что-нибудь другое, или вообще не работайте. Это каждый выбирает для себя, конечно.
Этапы и инструменты DevOps
Планирование
От введения перехожу к следующей части. Теперь моя цель – показать вам на реальных примерах в нашей системе, как мы работаем и какие инструменты используем.
Дорожная карта
Первый инструмент – это дорожная карта, с нее мы начинаем планирование.
Для создания дорожных карт мы используем плагин в своей Wiki-системе Confluence.
Дорожная карта – это общий вид на проект сверху: что, когда мы будем делать, какие блоки, в какое время будут запускаться. Надо понимать, что мы не испытываем иллюзий, не считаем, что с первого раза угадаем все с точностью до дня и времени суток. Тем не менее, с помощью дорожной карты мы можем на каждый этап проекта построить наши планы и бюджет.
Сейчас спрашивают, с чего начинать, когда нужно «кусочно» запустить систему? Ответ – в любой непонятной ситуации запускайте НСИ, она точно потребуется. Потому что в любом случае будет ситуация, когда часть блоков уже запущена на новой платформе, а часть работает по-старому. Не важно, что это – 1С, Axapta, SAP, самописная конфигурация или программа на Delphi или FoxPro. В любом случае, между старой и новой системой будет нужен обмен, и пока вы не сделаете единую НСИ, вы этот обмен не запустите. Как только мы запускаем единую НСИ – и у нас, и у заказчика сразу исчезают иллюзии относительно чистоты и структуры этих справочников, относительно того, что их реквизиты осмысленно заполнены, нет дублей и т.д.
Ежедневный Scrum
Следующий этап с точки зрения планирования – это ежедневный Scrum. Он у нас проходит в двух режимах.
Первый режим – асинхронный. Для этой цели в Slack есть специально обученный бот, который нравится мне тем, что никогда не болеет и всегда делает то, что говорят. Если в какое-то время должен случиться стендап – он случается. В асинхронном режиме бот каждому из участников проектной команды задает три сакраментальных вопроса и, более того, эти вопросы повторяет до тех пор, пока человек не ответит. Обычно мы настраиваем бота, чтобы он начал опрашивать участников проектной команды за четыре часа до начала стендапа, чтобы каждый в комфортном режиме смог ответить на эти вопросы.
И потом, за 10 минут до начала совещания, в единый канал публикуется отчет бота – в нем каждый участник проектной команды может увидеть, кто, что отвечал, у кого какие препятствия для работы есть – все это можно заранее проанализировать.
Дальше идет синхронная часть – это уже живой диалог (как правило, видеоконференция Zoom) между участниками команды, которые у нас являются удаленными разработчиками.
Обычно мы начинаем с разбора логов нашего Jenkins – для проектирования мы используем BDD-тесты, которые позволяют в автоматическом режиме проверять, не упала ли конфигурация.
С помощью отчета Allure можно увидеть, какой из тестов упал – и даже проанализировать, на каких частях постановки задачи алгоритм не сработал. Более того, в момент падения сохраняется скриншот, который также можно проанализировать.
Далее мы смотрим результаты работы Sonar Cube – это анализ качества кода. В этом инструменте наглядно видно, что изменилось по сравнению с предыдущим днем.
Можно сразу определить «героев» – понять, кто, какую ошибку допустил. Это сильно повышает качество кода и позволяет избежать совсем глупых ошибок.
Дальше идет рассмотрение Scrum-доски, где обозначено, кто, что сейчас делает. И в результате происходит перепланирование задач – это всем понятные и привычные вещи, которые мы делаем всегда, даже не в Scrum.
Проектирование
Переходим к проектированию.
Проектирование у нас начинается просто – после того, как есть дорожная карта, мы для каждого ее блока описываем бизнес-процесс и делаем это в той же самой системе Confluence – используется плагин draw.io. Схема строится так же, как и в Visio, только ее версионирование происходит вместе со статьей. Это чрезвычайно удобно – у тебя всегда есть последняя версия документации, и никакие файлики на Google Disk загружать не нужно. Кроме того, в Wiki-системе Confluence мы можем реализовать четкую перелинковку между статьями, а также связь с задачами Jira.
Обратите внимание на формат описания – это eEPC (Extended Event Driven Process Chain– поток процессов, управляемый событиями), мы его используем повсеместно. С помощью этих диаграмм мы описываем, какие функции, какой ролью пользователя выполняются. Такая архитектура позволяет описать события не только с точки зрения бизнеса, но и с точки зрения программной логики. В частности, здесь на диаграмме вы можете увидеть надпись RabbitMQ – это тот инструмент, брокер сообщений, который мы используем для обмена.
Основной вопрос, который задают приверженцы линейного подхода диаграммы Ганта в «каскаде» – это «А как же архитектура?».
Архитектуру надо спланировать в любом случае, иначе все будет плохо. И, в принципе, несмотря на то, что официального определения ИТ-архитектуры нет, есть много определений, которые я считаю подходящими. Здесь я привел два, которые мне нравятся.
Архитектура – это очень важная вещь (что бы это ни было).
ИТ-архитектура – это те решения, которые одновременно важны и которые трудно изменить.
Исходя из этих определений, мы в своих решениях стараемся быть гибкими и избегаем важных решений, которые не могут быть изменены.
Мы используем подход к проектированию ИТ-систем, который позволяет быстро и дешево изменять ранее внедренные ИТ-системы – это т.н. «эволюционная архитектура». Для более подробного изучения этого подхода есть две книги, которые я рекомендую.
- Первая книга переведена на русский язык, вышла достаточно давно, и ее точно стоит прочитать. Она называется «Создание микросервисов», но там не только и не столько про микросервисы.
- Вторую книгу, «Построение эволюционной архитектуры», я на русском языке не нашел, но она еще более интересна. Правда, некоторые затронутые там проблемы с точки зрения 1С-ника не совсем актуальны. Например, целая глава посвящена разбору ситуации, когда бизнес-пользователи ругаются на то, что система по 200 раз на дню меняется, и просят, чтобы изменения были не такими частыми – в качестве решения предлагается собирать релизы, а не делать Continuous Deployment. Я не думаю, что эта проблема скоро станет актуальной в мире 1С, но в любом случае, это интересно узнать с точки зрения развития. А все остальные проблемы, затронутые в книге, в принципе, абсолютно для нас актуальны.
Разработка
Следующий этап – это разработка.
Вот так выглядит постановка задачи на языке Gherkin. Мы описываем сценарии пользовательского поведения, которые, с одной стороны, понятны бизнес-консультанту (аналитику), с другой стороны, понятны пользователям, и, самое главное, они понятны программе.
В отличие от обычного ТЗ, с помощью этой постановки мы автоматически валидируем тот код, который делаем. Мы сделали постановку, ее согласовали, и нам не нужен отдел тестирования – система сама себя тестирует и выдает информацию о том, где есть несоответствие между постановкой и программным кодом.
Для запуска тестирования мы запускаем основную конфигурацию в режиме менеджера тестирования, в ней открываем обработку Vanessa Behavior и загружаем в нее сценарии пользовательского поведения (либо в виде каталога с тестами, либо в виде сводного файла сценария).
При запуске выбранного сценария, по мере прохождения шагов, начинают запускаться подчиненные системы в режиме клиента тестирования – заполняются окна, проводятся документы и проверяются результаты – в отчетах, в диалоговых окнах, в связанных системах.
Здесь, например, мы тестируем функциональность нашей MDM-системы, которая отвечает за централизованное управление НСИ, и нам нужно проверить, что элемент справочника, который мы в ней завели, оперативно попадает в другую внешнюю систему. Поэтому мы подключаемся к этой внешней системе и проверяем, что элемент справочника туда доехал, и в нем заполнились те реквизиты, которые должны были заполниться и не заполнились те, которые не должны.
Здесь показывается, как мы работаем в Jira. Для каждой задачи в Jira можно создать отдельную ветку на Git-сервере (у нас это BitBucket).
А при разработке (пользовательских сценариев или кода конфигурации) к этой ветке можно привязать коммиты, связанные с задачей. Таким образом, каждый коммит может быть связан с конкретной задачей.
Получив задачу в Jira, исполнитель может сразу увидеть связанные с ней правки пользовательских сценариев, или даже реального ТЗ, почитать переписку. Все то же самое происходит с точки зрения кода. Так как код – это тоже текст, то можно посмотреть, какой код менялся в конфигурации – причем, посмотреть в режиме сравнения. Все это позволяет делать Git.
Переписку по задаче можно прочитать не только в Jira, но и в Slack при оперативном общении, можно посмотреть, в каких статьях Wiki-системы упоминается эта задача (например, если при ее реализации используются какие-то особенно сложные алгоритмы). Этот комплекс инструментов очень сильно упрощает поддержку и изменение системы – мы не боимся рефакторить. При рефакторинге система по-любому упадет, но, в отличие от традиционного подхода, мы знаем, в каком месте она упадет, а значит, сможем это оперативно исправить. Мы не ждем, пока пользователи нам сами скажут, что наша система не работает.
Непрерывная интеграция
Чтобы все это работало в автоматическом режиме, мы используем Jenkins – это сервер тестирования, который помогает нам автоматически запускать сборки.
У нас есть ночные сборки.
Специально для этой презентации мы собрали зеленый Pipeline. Поскольку у нас нет возможности организовать Git-Flow, и мы пока не перешли с конфигуратора на EDT, то он обычно красный. В ближайшее время мы планируем в качестве эксперимента перевести на EDT разработку наших коробочных продуктов – БИТ:Адаптер и БИТ:MDM. Я думаю, что у нас это даже получится.
В качестве плагина к Jenkins у нас используется Allure – этот сервер отчетов, который позволяет удобно и наглядно видеть результаты и их анализировать.
Можно увидеть шаг, на котором произошло падение, и проанализировать скриншот этого момента (он формируется системой автоматически).
Подготовка к эксплуатации
Следующий этап – это подготовка к эксплуатации.
Мы из своей практики поняли, что разрабатывать печатные инструкции даже в Wiki-системе непродуктивно, потому что пользователи их все равно не читают. Поэтому для обучения у нас есть два способа, которые я рекомендую:
- Для типовой функциональности – «ИТС – это наше все»;
- А если функциональность разработанная – то нужны видеоролики.
В частности, для новых сотрудников, мы разрабатываем курсы по BDD-тестам и работе с Git.
Есть интерактив – видео и статьи.
И есть тестирование.
Эксплуатация
И последний этап, про который я расскажу – это эксплуатация.
На этом этапе особую важность приобретает грамотно построенный сервис-деск. У нас для этого также используется продукт из стека Atlassian – Jira Service Desk. Причем, наш офисный сервис-деск содержит в себе информацию не только по ИТ-инфраструктуре, но и по работе всевозможных бэк-офисных подразделений, включая бухгалтерию, финансы, кадры.
Здесь показывается, как происходит добавление нового сотрудника клиента к нашему проекту. Процесс полностью автоматизирован, происходит согласование, и клиент получает автоматическое письмо о том, что у него теперь есть доступ к Jira, Confluence и Bitbucket со ссылкой на инструкции и видеоролики, как с этим всем работать.
****************
Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2024 EDUCATION. Больше статей можно прочитать здесь.
В 2024 году приглашаем всех принять участие в 7 региональных митапах, а также юбилейной INFOSTART EVENT 2024 в Москве.
Related Posts
Оценка и планирование проекта
Мысли о видах информационных систем…
Конфигурация "Выдача пропусков и учет рабочего времени"
Управление ИТ-проектами. Модуль 3: продвинутый курс по гибкому управлению проектами. Agile. Первый поток. Вебинары проходят с 11 сентября по 27 ноября 2024 г.
Загрузка/Выгрузка Excel для справочника "Графики работы сотрудников"
Онлайн-курсы по управлению ИТ-проектами от Марии Темчиной
Я понял, что не тем в жизни занимаюсь…
Ну, если по душам в справочниках считать, то внешних и внутренних юзеров свыше семи сотен в ERP (без производства))) торговля)) да на ERP).
Ни одной строчки адекватной постановки задач, ни от кого, сплошной вынос мозга только…
Люди не способны формулировать задачи даже на словах частенько…
Да, красивые тут картинки)) мне понравилось)) эх… ну может через год или два ну хоть чета похожее нарисуем))
Это же первый бит, кто бы сомневался. Не удивлюсь, что все это к тому же стажер выпускник какого-нибудь математического в одиночку сделал.
А где в тексте статьи про автоматизацию ночных сборок?
Возьмите все ваши feature-файлы, назовите их «Спецификации», все ключевые слова «Функционал» замените на «Функциональность» и отдайте заказчику на подпись, по-сути это и есть ТЗ. Его понимает и может проверить и компьютер и человек.
А почему Jenkins выбрали? На хабре в статье по введению в CI советуют GitLab CI, на крайний случай Travis CI или Circle CI, дженкинса советуют сторониться:
Начнете думать что Jenkins это и есть CI, а это тупо. Возможное исключение — вы джавист, скалист или котлинист, и для вас там все работает прямо из коробки.
По дженкинс занимает процентов 10 по популярности CI-систем
Договор с контрагентом подписан и имеет юридическую силу. А по мысли Битовцев теперь после подписания должно пойти согласование…. Даже школьники предложили бы этап согласования делать до подписания,,,,
Это все что вам нужно знать о внедренцах компании Бит.
Очень круто!
Только не верится, что в реальной жизни все эти системы применяются и работают так как положено, порой кажется, что это все утопия, типа коммунизма…
Очень интересно, а разработчики фирмы 1С знают о существовании этих технологий? О том, что существуют инструменты автоматического тестирования, например? Судя по качеству типовых конфигураций, постоянных ошибок, неоптимального кода который не позволяет комфортно работать даже на современном оборудовании, архитектуры, при которой одни и те же данные хранятся в 3-4 регистрах…. в отделах разработки 1С ни о чем подобном и не слышали.
(8)Процесс идёт, вроде как на УНФ они всё это «промышленное программирование» пытаются обкатывать…
(7) Это процесс внесения договора в НСИ системы. Конечно, зачем все эти согласования, всё равно непонятно, бюрократия ради бюрократии.
(10) Главное — применили много иностранных слов и технологий и картинок — для чего и как это реально будет работать и будет ли — вторично, третично, четверично и т.д.. 🙂
(11) Работать то будет, но далеко не на всех проектах. Нужна специфическая подготовка Заказчика.
(8)Те же мысли постоянно возникают.
Видел я как-то БИТ:MDM внутри….. мне не понравилось.
Дочитал до нефритовых колец, дальше не стал.
Автор, путающий нефрит с ферритом по определению является гуманитарием и способен только на «эффективный менеджмент».
(9) Не только лишь в УНФ.
Доклады и презентации по «1С:ERP Управление предприятием 2»
Обзор технологий используемых при разработке ERP (Д. Мармышев,»1С»)
Синхронное производство и выпуск конфигураций ERP, КА, УТ, УТ-базовая — 12 релизов за раз. Библотечный подход, автовстраивание. DevOps: автосборка/CI, тестирование, публикация, стат-анализ кода и МД
(15)Этож ПервыйБИТ… Что Вы хотели?
Мне кажется от разработчика до конечного пользователя стало смертельно много прослоек. На каждом этапе происходит невосполнимая потеря времени, информации и денег. А потом искренне удивление о сдохшем проекте. И даже не хватило ума об этом не трубить на всю страну.
О таком эффективном менеджменте уже все сказано классиками: К пуговицам претензии есть? (С) А. Райкин
Но видимо об этом в заумных американских книжках не пишут.
Подскажите, какие параметры сервера разработки на котором это всё у вас крутится, сколько программистов/аналитиков одновременно работают?
Зашел на сайт Внедренные решения 1С и правда открыл первый нашедшийся проект по внедрению ERP от 1С-БИТ.
ООО Эвокар ИНН 9101002730
Почитал отзывы — клиент весьма доволен.
Ну, решил, глянуть — что у них с выручкой (раз так довольны) после внедрения ERP…
В 16 году выручка была почти 28 млн …. В 17 году выручка стала — 21.6
А прибыль упала в 9 раз.
Ждем от 1С-БИТ описание стека технологий использованных на этом проекте (с картинками).
Будем рекомендовать внедрить вашими силами ERP у наших конкурентов.
(4) а что не хватает? Так-то автоматизация сборок это самостоятельная объемная тема.
(6) для нас всё было очень просто, начинали мы с заказа услуги имплементации инженерных практик у Серебряной пули.
Мы вообще хотели Bamboo, но Алексей Лустин отговорил, сказал что он пробовал, и что не взлетит, и даже называл ссылку на ишью, там что-то связанное с кириллицей.
А дальше был выбор между Jenkins и Gitlab. Причем из всего Gitlab использовать только CI — наверное, странно (а остальной стек мы точно хотели оставить Atlassian, так как уже свои специалисты по Atlassian, сейчас уже отдельная команда, которая занимается разработкой плагинов и внедрением проектов на Atlassian). Хотя можно.
А сейчас Jenkins это далеко не только CI. В БИТ:ERP на данный момент порядка 100 серверов в облаке. На всех ставим автоматом при разворачивании агента Jenkins.
Например, задача: развернуть новый проектный сервер по заявке РП из web-интерфейса Jira Service Desk. Для этого нужно:
1. запустить на сервере terraform скрипт для разворачивания сервера (который и машину развернет, и постинсталл запустит)
2. записать параметры машины и развернутых сервисов в Consul
3. отправить ответ обратно в сервис-деск в виде комментария, чтобы закрыть тикет.
Для этого сделан пайплайн в Jenkins, который по REST дергает сервис-деск, а дальше уже всё jenkins.
Я не уверен, что это можно было бы сделать на gitlab ci, но я в этом вопросе недостаточно компетентен.
Остальные CI даже не рассматривали. Мы выбирали из того, что могли предложить ребята из пули (на тот момент), так как у самих релевантного опыта не было от слова совсем.
(8) разумеется не всё, и не всегда. Пока ощущения как будто с многоголовым драконом рубишься: решил одну проблему, две новых появилось. Во всяком случае бэклог проекта DEVOPS растет именно с такой скоростью 🙂 С другой стороны, пытаешься вспомнить — как до всех этих инструментов жили, и приходишь в ужас 🙂
(19) у нас нет единого сервера разработки, под каждый проект разворачивается свой сервер (вернее сейчас два: 1С+MS SQL и RabbitMQ, но вообще собираемся переделать на три, выделив MS SQL на отдельный сервер), тогда проще будет реализовать концепцию immutable server в отношении 1С.
(19) никаких специальных требований к серверу в связи с jenkins не появляется
есть тот кто работает, есть тот кто зарабатывает
есть тот кто умет, есть тот кто учит
…
учитесь у первого бита зарабатывать 🙂
(18)
О таком эффективном менеджменте уже все сказано классиками: К пуговицам претензии есть? (С) А. Райкин
Но видимо об этом в заумных американских книжках не пишут.
Насчет пуговиц и претензий — это подход советский. Он к сожалению ошибочен.
Тот же вариант, но по-капиталистически называется «выращивание бананов».
Мы столь же искренне удивляемся протестам экологов о вырубке тропических лесов, исчезновении видов и глобальном потеплении. И тем не менее сегодня бананы — самая дешевая еда (а не экзотический фрукт) в нашем супермаркете.
Каждый посредник принимает товар с учетом всех возможных собственных невосполнимых потерь. В результате мы имеем идеальную систему обеспечения населения бананами.
Сможете ли вы применить эту систему к разработке проектов? Будут ли покупатели программного обеспечения сопереживать предприятиям, испытавшим трудности или потерпевшим неудачу в результате тестовой проектной эксплуатации этого ПО так сказать «в прошлых жизнях»?
….
(20)
Так это, что не ясно разве, эти 6.4 млн и ушли на внедрение ERP без единой строчки ТЗ )))
Я статью бы назвал «Как не написать ни одной страницы ТЗ, завалить проект и выпустить статью об успешном внедрении».
Набору технологий управления проектом может позавидовать Роскосмос. Очень видимо эффективно. Даже эффективностью можно управлять эффективно.
Команда и Заказчик вероятно сами офигели, узнав (если дошли слухи) наконец набор применяемых на проекте технологий.
(27) вузах учат прикладывать к курсовому проекту перечень использованной литературы побольше..
Спасибо за статью. Очень технологично. У меня вопросы по вот этой части:
Как организован процесс управления требованиями? Судя из вышеприведенной цитаты feature-файлы пишут не аналитики, и не стейкхолдеры заказчика. Стало быть программисты? Поэтому интересно, каким образом вы отслеживаете, что написанные программистом feature-файлы коррелируют с целями заказчика? То есть где гарантия, что когда у вас в Allure всё зелёное — заказчик будет счастлив?
Ну и далее по тексту у вас приведён скриншот сценария на Gherkin, который позиционируется как постановка задачи. Как человек измученный BDD могу сказать, что это — лукавство. Сценарий явно записан средствами VB по уже существующему функционалу (знаменитые «фичи из воздуха»). Программист, который до реализации функционала предсказывает, что после выбора строки выскочит некое предупреждение, которое надо закрыть:
должен получать премии за визионерство.
Обкладывать функционал тестами постфактум — это не плохо, но давайте явно говорить, что сценарии у вас — это не постановка задачи, BDD здесь нет, а есть функциональная регрессионка.
Возможно, что скриншот с примером сценария неудачный, и у вас есть другие с примерами именно постановки задачи через feature-файл. Тогда, конечно, хотелось бы их увидеть.
(0)
Версия Ванессы у вас очень старая: 1.1.131. Ещё до разделения проекта на VA и ADD.
(29)
Примерно так. Сначала делаются тесты (что мы ожидаем увидеть),а затем программист что-то разрабатывает. Тестировщик играет роль
«буквы зю»«обезьянки с клавиатурой» , стоит над душой и ждет пока тест, написанный программистом, покажет что программист написал наконец-то именно то, что должен был написать.(31)
За то, что не стесняетесь использовать условия в сценариях — Зачёт!
И не слова про деньги.
Интересно, сколько времени ушло на обучение и внедрение и настройку всех этих систем для учета и тестирования разработки, можете ответить?
Сколько обычно разработчиков работает на таком проекте?
Непонятно как можно без ТЗ что-то реализовать.
Вернее реализовать то можно, но как потом поддерживать такую систему.
Если процессы и алгоритмы системы нигде не описаны, то дальнейшая успешная доработка невозможна.
Как можно потом что-то доработать, если никто не помнит и нет ТЗ выполненного проекта, в котором написано как должно быть.
(35) Наверное, нет общего ТЗ, но есть много мелких частных ТЗ. И потом уже из них получается документация верхнего уровня. Правда, не очень понятно как оно на практике…
(36) зачем тогда в теме писать «выполнить и не написать ни одной страницы ТЗ»?
(37) Наверное потому, что этого ТЗ не существовало на бумаге в утверждённом заказчиком виде, всё в виде «фичефайлов» 🙂
А мне статья (точнее описаный подход) — понравилась. Не в силу своей жизнеспособности на бескрайних просторах «пост-советских» заказчиков, но именно как попытка вывести управление проектами 1С на новый уровень. Без подобных попыток выбраться из ямы «а мы вот чего-то хотим, но не знаем как, но вы цену и сроки назовите» — возможности нет. Тем более с отягощением в виде чемоданов в большинстве своём мало-пригодных ТЗ и концептов. (Малопригодных опять таки из-за «не созревших» в большинстве своём заказчиков).
И даже не смотря на явные приукрашивания и идеализацию достигнутых результатов — это всё равно лучше чем сидеть в ожидании … а кстати без ожидания. Просто сидеть «на окладе» отвечая только «за пуговицы».
Ведь немаловажным в Scram является командо-образующее составляющее, предполагающее максимальную полезность каждого на большинстве этапов. А это уже шаг по направлению к «качеству» конечного творения. В альтернативу водопад может применяться и без «сплаченной команды», в условиях когда 99% общения заочно через e-mail большими «кусками» информации. Можно в таких условиях сделать хороший проект? — Можно! Но долго, дорого и с меньшей вероятностью (именно «хороший», а не просто сделать).
Поэтому не стоит судить автора строго за некие недомолвки. Лично я ему благодарен за описанный опыт. Применять или нет — дело каждого
Никак
(0) Откуда эта цитата, есть на английском?
«ИТ-архитектура – это те решения, которые одновременно важны и которые трудно изменить.» М. Фаулер
(38) с учетом того, что указано Confluence, то скорее всего у разработчиков в вики и хранится все. Но опять таки это Вики разработчика, а не заказчика.
А где гарантии заказчику? Допустим я заказчик, была договоренность о каком-то функционале. Проходит время и вижу, что функционал не реализован. Если у меня нет подписанного ТЗ, то как я докажу разработчику, что это его недоработка. Без ТЗ я этого доказать не смогу, и мне опять оплачивать оплаченную работу?
(42) Да, должно быть полное доверие между Заказчиком и Исполнителем. И у Заказчика есть доступ в Confluence, скорее всего. Поэтому область применения данного подхода достаточно ограничена, имхо.
(41)
Не помню, где конкретно прочитал в первый раз, но легко гуглится. По запросу «fowler architecture hard to change» мне в первой же ссылке выдал: «Software architecture is those decisions which are both important and hard to change»
(42) (43)
Сама организация работ исключает возможность появления указанной проблемы:
1. Заказчик актирует и оплачивает работу команды за спринт. Команда фиксирована, сумма фиксирована. Заказчик оплачивает и актирует спринт вне зависимости от результатов по итогам демо спринта.
2. В самом начале (когда заказчик ещё не знает нас, а только где-то услышал о существовании команды БИТ:ERP) для того чтобы снять опасения заказчика:
2.1. мы напоминаем, что если его не устраивает качество наших работ, то он может не заактировать спринт без объяснения причин, и продолжить свои поиски подрядчика
2.2. последнее время мы вообще тестируем включение в договор обязательства возврата денег заказчику без объяснения причин по первому требованию, в том числе по подписанным актам, в случае если функционал не получилось (ну или заказчик решил не пробовать) запустить в эксплуатацию, или заказчик решил отказаться от эксплуатации в течение 30 дней после запуска в эксплуатацию.
PS. И да, всё верно. Нужно доверие между заказчиком и исполнителем. Без этого никакой agile работать не будет.
(29)
1. Фичи-файлы пишутся консультантами, дорабатываются разработчиками. Гарантии дает только похоронное бюро 🙂 Именно поэтому кроме демо прототипа до начала разработки мы стремимся как можно быстрее код пропихнуть в прод, чтобы узнать наверняка — коррелирует ли фича с целями заказчика, или нет.
2. Визионерство никакое не нужно. Фича накликивается:
2.1. в случае использования уже имеющегося функционала, путем наклиикивания по нему
2.2. в случае нового функционала — путем набрасывания консультантом формы в Конфигураторе, и накликикивания её в режиме исполнения. Да, тут уже не получится накликать предупреждение, его придется описать. Правда, в этом случае я не очень понимаю в чем визионерство? В том что ты продумываешь поведение формы при работе пользователя? Думаю, что такая вещь была бы написана в 50% случаев, если форма была новая. В оставшихся случаях разработчик бы понял, что нужно предупреждение, согласовал с консультантом и фича была бы доработана (чтобы соответствовать разработанному функционалу).
(30) оказалось, что не такая уж простая задача обновить на идущих проектах ванессу (позиция проектной команды — у которых сроки горят всегда: работает? — не трожь!). А учитывая, что на тесте ранее работающие тесты начали падать, и пришлось вносить изменения в код — это затянулось.
Хорошо хоть изначально было принято решение, что все доработки, которые делаем — оформить пулриквестами и делиться с сообществом. Вроде бы потери времени, но зато есть бонусы:
1. если мы где-то глобально ошибаемся, нам об этом сообщат в ходе обсуждения пул-риквеста
2. новый релиз содержит нужные тебе доработки, и тебе не нужно заниматься объединением конфигураций
надеюсь, что готовящийся пул-риквест, по чтению настроек из consul будет признан полезным для всех, по крайней мере на перспективу, не слышал, чтобы кто-то из команд 1С кроме нашей использовали Consul для управления конфигурацией. Но, может, как раз и начнут 🙂
(34)
Мы скорее в начале пути. Поэтому сколько уйдет пока непонятно. Например, полноценно BDD и CI используется последние полгода только при разработке БИТ.Адаптер и БИТ.МДМ (т.е. новый функционал описан, а старый — только кусками, поэтому общее покрытие до сих пор не большое, хотя достаточно резво описываем критические функции, ну и то, что вылезает у пользователей БИТ.Адаптер), а также для проектных задач внедрения данных продуктов. В остальных областях это до сих пор используется эпизодически и не полностью.
С точки зрения ориентира на задачи R&D тратиться 10-15% от выручки БИТ:ERP. Т.е. де-факто вся прибыль. На 2019 год планируем всё-таки увеличить рентабельность, но не за счет снижения процента инвестиций, а увеличения маржинальности. Есть понимание, что использование agile и современных инженерных практик позволяют за один час работы нашего сотрудника создавать существенно бОльшую ценность клиенту, чем в среднем по рынку. Поэтому новые контракты на 2019 год мы заключаем уже из расчета 4000 руб. без НДС за час работы.
(47)
Ну вы ведь в курсе, что сейчас два проекта развиваются параллельно.
Есть
куда вы делаете пулреквесты
и ещё есть
там пулреквестов пока не видно.
(46) подход понятен.
Также понятна и проблема с вымышленным примером про отсутствие ТЗ. Фичи клиент не видит и не согласовывает, а если бы увидел, то попросил бы побыстрее убрать, чтобы развидеть это. В этом месте то самое доверие между заказчиком и исполнителем, о котором вы пишите в (45), резко идёт вниз, что возможно компенсируется пунктом договора о безоговорочном возврате денег 😉
Вот такие «написанные», а на самом деле «накликанные», консультантами фиче-файлы совершенно не подходят для человека, чтобы увидеть в этом постановку задачи — то есть формализованное требование. При этом человек — это и клиент, и программист. Мне кажется, что после такой «постановки» консультант идёт к программисту и голосом доносит суть задачи («видел мою фичу? я не виноват, меня заставили. а теперь слушай чё сделать надо»).
У вас же всё под Git. Вы могли бы (чтобы я не домысливал) представить версию фичи, написанную консультантом до демонстрации её программисту, а потом доработанную совместными усилиями версию?
И если такие фичи — это всё, что остаётся после работы консультанта+программиста в качестве технической документации, то через пару лет вспомнить, что и для чего делалось, глядя на эти полотна прокликиванья интерфейса, будет невозможно. Или вы параллельно (для обычных людей) фиксируете требования в Confluence?
P.S.
Обратите внимание, как коллега Владимир Литвиненко в своей по работе с Vanessa-ADD в первом примере именно ПИШЕТ фичу. А потом детализирует её с помощью тега @Tree. В результате, свёрнутые сценарии до первого уровня реально человеко-читаемы. И в этом случае вопросов к качеству такой фичи намного меньше (за исключением того, что клиента надо либо научить пользоваться ванессой, либо насильно поставить ему VSC и показать как сворачивать текст до верхнего уровня — чтобы он мог согласовать постановку задачи).
P.P.S
Про визионерство. В случае 2.1 — это не постановка задачи. В случае 2.2. предупреждение на вашем скриншоте ни о чём. Это просто обход какого-то окна 1С, которое по тексту сценария даже непонятно, с какого перепугу всплывает. Пример на скриншоте в высшей степени неудачен в качестве «постановки задачи», что декларируется прямо над ним.
Глеб, просто отличная статья! Можно дать название плагинов к Confluence (планировщик и рисовальщик), а также подробнее немного про бота для Slack (тоже плагин или сами сделали)?
(51)
1. Confluence — RoadMap Planner Macro (встроен), схемы бизнес-процессов draw.io
2. Slack — используем сервис geekbot.io Если речь об интеграции с Jira — то тут делали сами. Планируем в течение нескольких месяцев выложить на продажу на Atlassian Market.
А можно поподробнее, где тут скрам?
(14) качество разработки не зависит от систем коммуникации внутри команды разработчиков.
П.С. не скажу за БИТ: МДМ — какая программа на выходе — хорошая или плохая. Я тут про качество кода вставил три копейки 🙂
(18)
на больших проектах — «да», а на малых вроде как ничего не изменилось.
на то они и большие проекты, что требуется еще управление рисками, командой, задачами, сроками и т.д.
(27) это первый кейс по управлению командой, задачами и проектами внутри сложного комплексного проекта «Внедрение ЕРП».
что ж вы сразу помидорами кидаетесь? 🙂
(20) будем надеяться что инвестиции в разработку технологий управления проектами себя рано или поздно окупят. Сможем выйти на зарубежный рынок. БИТовцы в этом плане первопроходцы, а первопроходцам всегда труднее всех.
(27) ТЗ условно все-таки написано — сколько задач оцифровано !, осталось только во все системы вроде Джира добавить печатные формы вида «Техзадание проекта», чтобы красиво собирало для Заказчика нужную форму ТЗ.
(33) пока что это инвестиции в себя.