Как запустить 1С:ERP 2 на тысячу пользователей и не написать ни одной страницы ТЗ?

Публикация № 982582

Методология - Управление проектом

Глеб Стальной делится опытом построения полного цикла процесса DevOps на проектах 1С с помощью использования современных инженерных практик – разработки через поведение, автоматизации ночных сборок, непрерывного анализа качества кода и т.д. В статье много внимания уделяется работе с инструментами (Slack, Zoom, Jira, Confluence, Jira Service Desk, Bitbucket, Vanessa Behavior, БИТ.Адаптер, Jenkins, SonarQube 1C (BSL) Plugin, Allure и т.п.)

Все, о чем я буду рассказывать в этом докладе, отражено на этой диаграмме – здесь показано, что представляет собой 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 2018 EDUCATION. Больше статей можно прочитать здесь.

В 2020 году приглашаем всех принять участие в 7 региональных митапах, а также юбилейной INFOSTART EVENT 2020 в Москве.

Выбрать мероприятие.

Специальные предложения

Комментарии
Избранное Подписка Сортировка: Древо развёрнутое
Свернуть все
1. Kamikadze 46 17.01.19 18:02 Сейчас в теме
Я понял, что не тем в жизни занимаюсь...
shiaju; AlexK_2012; manlak; user842280; KroVladS; ihtiking; rovenko.n; mityushov.vv; TreeDogNight; Somebody1; wowik; kd88@ya.ru; fancy; timurhv; acanta; lunjio; McSlym; +17 Ответить
2. Brawler 468 17.01.19 18:42 Сейчас в теме
Ну, если по душам в справочниках считать, то внешних и внутренних юзеров свыше семи сотен в ERP (без производства))) торговля)) да на ERP).
Ни одной строчки адекватной постановки задач, ни от кого, сплошной вынос мозга только...
Люди не способны формулировать задачи даже на словах частенько...

Да, красивые тут картинки)) мне понравилось)) эх... ну может через год или два ну хоть чета похожее нарисуем))
papche; lunjio; +2 Ответить
3. lunjio 63 17.01.19 19:42 Сейчас в теме
Это же первый бит, кто бы сомневался. Не удивлюсь, что все это к тому же стажер выпускник какого-нибудь математического в одиночку сделал.
rovenko.n; dnikolaev; TreeDogNight; papche; EMelihoff; +5 Ответить
4. mistermp3 17.01.19 19:56 Сейчас в теме
А где в тексте статьи про автоматизацию ночных сборок?
21. glebushka 235 18.01.19 16:54 Сейчас в теме
(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С.
5. vlad.frost 187 17.01.19 19:57 Сейчас в теме
В итоге, не смотря на то, что заказчику изначально говорили, что ТЗ не будет написано, его холдинг без согласованного ТЗ принять работу не согласился.


Возьмите все ваши feature-файлы, назовите их "Спецификации", все ключевые слова "Функционал" замените на "Функциональность" и отдайте заказчику на подпись, по-сути это и есть ТЗ. Его понимает и может проверить и компьютер и человек.
6. s_vidyakin 17.01.19 22:02 Сейчас в теме
А почему Jenkins выбрали? На хабре в статье по введению в CI советуют GitLab CI, на крайний случай Travis CI или Circle CI, дженкинса советуют сторониться:
На начальных стадиях знакомства с CI избегайте Jenkins и TeamCity. В этих олдскульных системах слишком много оверхеда, так что придется больше разбираться с особенностями систем, чем фигачить сам CI.
Начнете думать что Jenkins это и есть CI, а это тупо. Возможное исключение — вы джавист, скалист или котлинист, и для вас там все работает прямо из коробки.

По статистике гитхаба дженкинс занимает процентов 10 по популярности CI-систем
7. ZOMI 427 18.01.19 01:59 Сейчас в теме
Договор с контрагентом подписан и имеет юридическую силу. А по мысли Битовцев теперь после подписания должно пойти согласование.... Даже школьники предложили бы этап согласования делать до подписания,,,,

Это все что вам нужно знать о внедренцах компании Бит.
Прикрепленные файлы:
obsfromekb; proektor; vova196; rovenko.n; TreeDogNight; sm.artem; dabu-dabu; papche; EMelihoff; mitia.mackarevich; lunjio; nyam-nyam; pm74; +13 1 Ответить
10. genayo 18.01.19 06:22 Сейчас в теме
(7) Это процесс внесения договора в НСИ системы. Конечно, зачем все эти согласования, всё равно непонятно, бюрократия ради бюрократии.
11. AlexeyFreeLife 18.01.19 07:27 Сейчас в теме
(10) Главное - применили много иностранных слов и технологий и картинок - для чего и как это реально будет работать и будет ли - вторично, третично, четверично и т.д.. :)
TreeDogNight; +1 Ответить
12. genayo 18.01.19 07:56 Сейчас в теме
(11) Работать то будет, но далеко не на всех проектах. Нужна специфическая подготовка Заказчика.
8. ZHPN24 74 18.01.19 05:57 Сейчас в теме
Очень круто!
Только не верится, что в реальной жизни все эти системы применяются и работают так как положено, порой кажется, что это все утопия, типа коммунизма...
Очень интересно, а разработчики фирмы 1С знают о существовании этих технологий? О том, что существуют инструменты автоматического тестирования, например? Судя по качеству типовых конфигураций, постоянных ошибок, неоптимального кода который не позволяет комфортно работать даже на современном оборудовании, архитектуры, при которой одни и те же данные хранятся в 3-4 регистрах.... в отделах разработки 1С ни о чем подобном и не слышали.
chemezov; vova196; papche; Bassgood; +4 Ответить
9. genayo 18.01.19 06:19 Сейчас в теме
(8)Процесс идёт, вроде как на УНФ они всё это "промышленное программирование" пытаются обкатывать...
16. vlad.frost 187 18.01.19 11:25 Сейчас в теме
(9) Не только лишь в УНФ.
Доклады и презентации по "1С:ERP Управление предприятием 2"
https://its.1c.ru/db/metod81#content:7072:hdoc

Обзор технологий используемых при разработке ERP (Д. Мармышев,"1С")
Синхронное производство и выпуск конфигураций ERP, КА, УТ, УТ-базовая - 12 релизов за раз. Библотечный подход, автовстраивание. DevOps: автосборка/CI, тестирование, публикация, стат-анализ кода и МД
http://fserver.1c.ru/its/files/public/erp/train2018/d3_09_00.ppt?_=1547716619
https://its.1c.ru/video/erp_train2018_d3_09_00
Rustig; Vladimir Litvinenko; Man4kin; +3 Ответить
13. muskul 18.01.19 09:29 Сейчас в теме
(8)Те же мысли постоянно возникают.
14. Dzenn 390 18.01.19 09:48 Сейчас в теме
Видел я как-то БИТ:MDM внутри..... мне не понравилось.
dabu-dabu; +1 Ответить
54. Rustig 1416 04.06.19 20:11 Сейчас в теме
(14) качество разработки не зависит от систем коммуникации внутри команды разработчиков.
П.С. не скажу за БИТ: МДМ - какая программа на выходе - хорошая или плохая. Я тут про качество кода вставил три копейки :)
15. asved.ru 35 18.01.19 10:45 Сейчас в теме
Дочитал до нефритовых колец, дальше не стал.
Автор, путающий нефрит с ферритом по определению является гуманитарием и способен только на "эффективный менеджмент".
obsfromekb; vova196; rovenko.n; dabu-dabu; JulianK; Арчибальд; EMelihoff; mitia.mackarevich; ZOMI; surikateg; nyam-nyam; +11 2 Ответить
17. nyam-nyam 18.01.19 12:00 Сейчас в теме
(15)Этож ПервыйБИТ... Что Вы хотели?
18. adapter 540 18.01.19 14:43 Сейчас в теме
Мне кажется от разработчика до конечного пользователя стало смертельно много прослоек. На каждом этапе происходит невосполнимая потеря времени, информации и денег. А потом искренне удивление о сдохшем проекте. И даже не хватило ума об этом не трубить на всю страну.
О таком эффективном менеджменте уже все сказано классиками: К пуговицам претензии есть? (С) А. Райкин
Но видимо об этом в заумных американских книжках не пишут.
morin; Spartan; itriot11; vova196; rovenko.n; dabu-dabu; Арчибальд; lunjio; argut; EMelihoff; ZOMI; +11 2 Ответить
24. acanta 74 19.01.19 14:44 Сейчас в теме
(18)
Мне кажется от разработчика до конечного пользователя стало смертельно много прослоек. На каждом этапе происходит невосполнимая потеря времени, информации и денег. А потом искренне удивление о сдохшем проекте. И даже не хватило ума об этом не трубить на всю страну.
О таком эффективном менеджменте уже все сказано классиками: К пуговицам претензии есть? (С) А. Райкин
Но видимо об этом в заумных американских книжках не пишут.


Насчет пуговиц и претензий - это подход советский. Он к сожалению ошибочен.
Тот же вариант, но по-капиталистически называется "выращивание бананов".
Мы столь же искренне удивляемся протестам экологов о вырубке тропических лесов, исчезновении видов и глобальном потеплении. И тем не менее сегодня бананы - самая дешевая еда (а не экзотический фрукт) в нашем супермаркете.
Каждый посредник принимает товар с учетом всех возможных собственных невосполнимых потерь. В результате мы имеем идеальную систему обеспечения населения бананами.
Сможете ли вы применить эту систему к разработке проектов? Будут ли покупатели программного обеспечения сопереживать предприятиям, испытавшим трудности или потерпевшим неудачу в результате тестовой проектной эксплуатации этого ПО так сказать "в прошлых жизнях"?
55. Rustig 1416 04.06.19 20:26 Сейчас в теме
(18)
от разработчика до конечного пользователя стало смертельно много прослоек

на больших проектах - "да", а на малых вроде как ничего не изменилось.
на то они и большие проекты, что требуется еще управление рисками, командой, задачами, сроками и т.д.
19. AlexKo 99 18.01.19 15:53 Сейчас в теме
Подскажите, какие параметры сервера разработки на котором это всё у вас крутится, сколько программистов/аналитиков одновременно работают?
22. glebushka 235 18.01.19 16:55 Сейчас в теме
(19) никаких специальных требований к серверу в связи с jenkins не появляется
20. ZOMI 427 18.01.19 16:42 Сейчас в теме
Зашел на сайт Внедренные решения 1С и правда открыл первый нашедшийся проект по внедрению ERP от 1С-БИТ.

https://1c.ru/rus/partners/solutions/response.jsp?solutionID=797039

ООО Эвокар ИНН 9101002730

Почитал отзывы - клиент весьма доволен.

Ну, решил, глянуть - что у них с выручкой (раз так довольны) после внедрения ERP...

В 16 году выручка была почти 28 млн .... В 17 году выручка стала - 21.6

А прибыль упала в 9 раз.

Ждем от 1С-БИТ описание стека технологий использованных на этом проекте (с картинками).

Будем рекомендовать внедрить вашими силами ERP у наших конкурентов.
Прикрепленные файлы:
Бизнес_Справка_9101002730_2017_.pdf
Rustig; mitia.mackarevich; MashaAkimova; YanTsys; itriot11; rovenko.n; TreeDogNight; EMelihoff; papche; leshik; lunjio; ZHPN24; +12 Ответить
26. lunjio 63 19.01.19 19:21 Сейчас в теме
(20)

Так это, что не ясно разве, эти 6.4 млн и ушли на внедрение ERP без единой строчки ТЗ )))
57. Rustig 1416 04.06.19 20:34 Сейчас в теме
(20) будем надеяться что инвестиции в разработку технологий управления проектами себя рано или поздно окупят. Сможем выйти на зарубежный рынок. БИТовцы в этом плане первопроходцы, а первопроходцам всегда труднее всех.
23. argut 91 18.01.19 17:23 Сейчас в теме
есть тот кто работает, есть тот кто зарабатывает
есть тот кто умет, есть тот кто учит
...
учитесь у первого бита зарабатывать :)
TreeDogNight; EMelihoff; lunjio; acanta; +4 Ответить
25. acanta 74 19.01.19 16:01 Сейчас в теме
27. papche 375 21.01.19 11:15 Сейчас в теме
Я статью бы назвал "Как не написать ни одной страницы ТЗ, завалить проект и выпустить статью об успешном внедрении".
Набору технологий управления проектом может позавидовать Роскосмос. Очень видимо эффективно. Даже эффективностью можно управлять эффективно.
Команда и Заказчик вероятно сами офигели, узнав (если дошли слухи) наконец набор применяемых на проекте технологий.
Spartan; vova196; Herby; TreeDogNight; ZOMI; EMelihoff; 1ceo_2015; acanta; +8 Ответить
28. acanta 74 21.01.19 12:03 Сейчас в теме
(27) вузах учат прикладывать к курсовому проекту перечень использованной литературы побольше..
56. Rustig 1416 04.06.19 20:32 Сейчас в теме
(27) это первый кейс по управлению командой, задачами и проектами внутри сложного комплексного проекта "Внедрение ЕРП".
что ж вы сразу помидорами кидаетесь? :)
58. Rustig 1416 04.06.19 20:44 Сейчас в теме
(27) ТЗ условно все-таки написано - сколько задач оцифровано !, осталось только во все системы вроде Джира добавить печатные формы вида "Техзадание проекта", чтобы красиво собирало для Заказчика нужную форму ТЗ.
29. oleynik.dv 142 21.01.19 12:35 Сейчас в теме
Спасибо за статью. Очень технологично. У меня вопросы по вот этой части:

Вот так выглядит постановка задачи на языке Gherkin. Мы описываем сценарии пользовательского поведения, которые, с одной стороны, понятны бизнес-консультанту (аналитику), с другой стороны, понятны пользователям, и, самое главное, они понятны программе.


Как организован процесс управления требованиями? Судя из вышеприведенной цитаты feature-файлы пишут не аналитики, и не стейкхолдеры заказчика. Стало быть программисты? Поэтому интересно, каким образом вы отслеживаете, что написанные программистом feature-файлы коррелируют с целями заказчика? То есть где гарантия, что когда у вас в Allure всё зелёное - заказчик будет счастлив?

Ну и далее по тексту у вас приведён скриншот сценария на Gherkin, который позиционируется как постановка задачи. Как человек измученный BDD могу сказать, что это - лукавство. Сценарий явно записан средствами VB по уже существующему функционалу (знаменитые "фичи из воздуха"). Программист, который до реализации функционала предсказывает, что после выбора строки выскочит некое предупреждение, которое надо закрыть:

должен получать премии за визионерство.
Обкладывать функционал тестами постфактум - это не плохо, но давайте явно говорить, что сценарии у вас - это не постановка задачи, BDD здесь нет, а есть функциональная регрессионка.
Возможно, что скриншот с примером сценария неудачный, и у вас есть другие с примерами именно постановки задачи через feature-файл. Тогда, конечно, хотелось бы их увидеть.
obsfromekb; vova196; tsukanov; Vladimir Litvinenko; Pr-Mex; papche; 1ceo_2015; +7 Ответить
31. acanta 74 21.01.19 13:19 Сейчас в теме
(29)
Обкладывать функционал тестами постфактум - это не плохо, но давайте явно говорить, что сценарии у вас - это не постановка задачи, BDD здесь нет, а есть функциональная регрессионка.

Примерно так. Сначала делаются тесты (что мы ожидаем увидеть),а затем программист что-то разрабатывает. Тестировщик играет роль "буквы зю" "обезьянки с клавиатурой" , стоит над душой и ждет пока тест, написанный программистом, покажет что программист написал наконец-то именно то, что должен был написать.
32. Pr-Mex 125 21.01.19 13:33 Сейчас в теме
(31)
За то, что не стесняетесь использовать условия в сценариях - Зачёт!
46. glebushka 235 26.01.19 13:52 Сейчас в теме
(29)
1. Фичи-файлы пишутся консультантами, дорабатываются разработчиками. Гарантии дает только похоронное бюро :) Именно поэтому кроме демо прототипа до начала разработки мы стремимся как можно быстрее код пропихнуть в прод, чтобы узнать наверняка - коррелирует ли фича с целями заказчика, или нет.

2. Визионерство никакое не нужно. Фича накликивается:
2.1. в случае использования уже имеющегося функционала, путем наклиикивания по нему
2.2. в случае нового функционала - путем набрасывания консультантом формы в Конфигураторе, и накликикивания её в режиме исполнения. Да, тут уже не получится накликать предупреждение, его придется описать. Правда, в этом случае я не очень понимаю в чем визионерство? В том что ты продумываешь поведение формы при работе пользователя? Думаю, что такая вещь была бы написана в 50% случаев, если форма была новая. В оставшихся случаях разработчик бы понял, что нужно предупреждение, согласовал с консультантом и фича была бы доработана (чтобы соответствовать разработанному функционалу).
50. oleynik.dv 142 28.01.19 04:06 Сейчас в теме
(46) подход понятен.
Также понятна и проблема с вымышленным примером про отсутствие ТЗ. Фичи клиент не видит и не согласовывает, а если бы увидел, то попросил бы побыстрее убрать, чтобы развидеть это. В этом месте то самое доверие между заказчиком и исполнителем, о котором вы пишите в (45), резко идёт вниз, что возможно компенсируется пунктом договора о безоговорочном возврате денег ;-)

Вот такие "написанные", а на самом деле "накликанные", консультантами фиче-файлы совершенно не подходят для человека, чтобы увидеть в этом постановку задачи - то есть формализованное требование. При этом человек - это и клиент, и программист. Мне кажется, что после такой "постановки" консультант идёт к программисту и голосом доносит суть задачи ("видел мою фичу? я не виноват, меня заставили. а теперь слушай чё сделать надо").

У вас же всё под Git. Вы могли бы (чтобы я не домысливал) представить версию фичи, написанную консультантом до демонстрации её программисту, а потом доработанную совместными усилиями версию?

И если такие фичи - это всё, что остаётся после работы консультанта+программиста в качестве технической документации, то через пару лет вспомнить, что и для чего делалось, глядя на эти полотна прокликиванья интерфейса, будет невозможно. Или вы параллельно (для обычных людей) фиксируете требования в Confluence?

P.S.
Обратите внимание, как коллега Владимир Литвиненко в своей новой статье по работе с Vanessa-ADD в первом примере именно ПИШЕТ фичу. А потом детализирует её с помощью тега @Tree. В результате, свёрнутые сценарии до первого уровня реально человеко-читаемы. И в этом случае вопросов к качеству такой фичи намного меньше (за исключением того, что клиента надо либо научить пользоваться ванессой, либо насильно поставить ему VSC и показать как сворачивать текст до верхнего уровня - чтобы он мог согласовать постановку задачи).

P.P.S
Про визионерство. В случае 2.1 - это не постановка задачи. В случае 2.2. предупреждение на вашем скриншоте ни о чём. Это просто обход какого-то окна 1С, которое по тексту сценария даже непонятно, с какого перепугу всплывает. Пример на скриншоте в высшей степени неудачен в качестве "постановки задачи", что декларируется прямо над ним.
30. Pr-Mex 125 21.01.19 12:52 Сейчас в теме
(0)
Версия Ванессы у вас очень старая: 1.1.131. Ещё до разделения проекта на VA и ADD.
47. glebushka 235 26.01.19 14:05 Сейчас в теме
(30) оказалось, что не такая уж простая задача обновить на идущих проектах ванессу (позиция проектной команды - у которых сроки горят всегда: работает? - не трожь!). А учитывая, что на тесте ранее работающие тесты начали падать, и пришлось вносить изменения в код - это затянулось.
Хорошо хоть изначально было принято решение, что все доработки, которые делаем - оформить пулриквестами и делиться с сообществом. Вроде бы потери времени, но зато есть бонусы:
1. если мы где-то глобально ошибаемся, нам об этом сообщат в ходе обсуждения пул-риквеста
2. новый релиз содержит нужные тебе доработки, и тебе не нужно заниматься объединением конфигураций
надеюсь, что готовящийся пул-риквест, по чтению настроек из consul будет признан полезным для всех, по крайней мере на перспективу, не слышал, чтобы кто-то из команд 1С кроме нашей использовали Consul для управления конфигурацией. Но, может, как раз и начнут :)
49. Pr-Mex 125 27.01.19 14:30 Сейчас в теме
(47)
Ну вы ведь в курсе, что сейчас два проекта развиваются параллельно.
Есть
https://github.com/silverbulleters/add
куда вы делаете пулреквесты
и ещё есть
https://github.com/Pr-Mex/vanessa-automation
там пулреквестов пока не видно.
33. SergeyLunev 21.01.19 17:40 Сейчас в теме
И не слова про деньги.
chemezov; Rustig; +2 Ответить
59. Rustig 1416 04.06.19 20:46 Сейчас в теме
(33) пока что это инвестиции в себя.
34. mityushov.vv 170 23.01.19 11:14 Сейчас в теме
Интересно, сколько времени ушло на обучение и внедрение и настройку всех этих систем для учета и тестирования разработки, можете ответить?

Сколько обычно разработчиков работает на таком проекте?
48. glebushka 235 26.01.19 14:15 Сейчас в теме
(34)
Интересно, сколько времени ушло на обучение и внедрение и настройку всех этих систем


Мы скорее в начале пути. Поэтому сколько уйдет пока непонятно. Например, полноценно BDD и CI используется последние полгода только при разработке БИТ.Адаптер и БИТ.МДМ (т.е. новый функционал описан, а старый - только кусками, поэтому общее покрытие до сих пор не большое, хотя достаточно резво описываем критические функции, ну и то, что вылезает у пользователей БИТ.Адаптер), а также для проектных задач внедрения данных продуктов. В остальных областях это до сих пор используется эпизодически и не полностью.
С точки зрения ориентира на задачи R&D тратиться 10-15% от выручки БИТ:ERP. Т.е. де-факто вся прибыль. На 2019 год планируем всё-таки увеличить рентабельность, но не за счет снижения процента инвестиций, а увеличения маржинальности. Есть понимание, что использование agile и современных инженерных практик позволяют за один час работы нашего сотрудника создавать существенно бОльшую ценность клиенту, чем в среднем по рынку. Поэтому новые контракты на 2019 год мы заключаем уже из расчета 4000 руб. без НДС за час работы.
Rustig; freddy121; mityushov.vv; +3 Ответить
35. Herby 24.01.19 12:10 Сейчас в теме
Непонятно как можно без ТЗ что-то реализовать.
Вернее реализовать то можно, но как потом поддерживать такую систему.
Если процессы и алгоритмы системы нигде не описаны, то дальнейшая успешная доработка невозможна.

Как можно потом что-то доработать, если никто не помнит и нет ТЗ выполненного проекта, в котором написано как должно быть.
36. genayo 24.01.19 12:46 Сейчас в теме
(35) Наверное, нет общего ТЗ, но есть много мелких частных ТЗ. И потом уже из них получается документация верхнего уровня. Правда, не очень понятно как оно на практике...
37. Herby 24.01.19 13:25 Сейчас в теме
(36) зачем тогда в теме писать "выполнить и не написать ни одной страницы ТЗ"?
38. genayo 24.01.19 13:44 Сейчас в теме
(37) Наверное потому, что этого ТЗ не существовало на бумаге в утверждённом заказчиком виде, всё в виде "фичефайлов" :)
42. Herby 25.01.19 09:45 Сейчас в теме
(38) с учетом того, что указано Confluence, то скорее всего у разработчиков в вики и хранится все. Но опять таки это Вики разработчика, а не заказчика.

А где гарантии заказчику? Допустим я заказчик, была договоренность о каком-то функционале. Проходит время и вижу, что функционал не реализован. Если у меня нет подписанного ТЗ, то как я докажу разработчику, что это его недоработка. Без ТЗ я этого доказать не смогу, и мне опять оплачивать оплаченную работу?
43. genayo 25.01.19 09:48 Сейчас в теме
(42) Да, должно быть полное доверие между Заказчиком и Исполнителем. И у Заказчика есть доступ в Confluence, скорее всего. Поэтому область применения данного подхода достаточно ограничена, имхо.
45. glebushka 235 26.01.19 13:42 Сейчас в теме
(42) (43)

Сама организация работ исключает возможность появления указанной проблемы:
1. Заказчик актирует и оплачивает работу команды за спринт. Команда фиксирована, сумма фиксирована. Заказчик оплачивает и актирует спринт вне зависимости от результатов по итогам демо спринта.
2. В самом начале (когда заказчик ещё не знает нас, а только где-то услышал о существовании команды БИТ:ERP) для того чтобы снять опасения заказчика:
2.1. мы напоминаем, что если его не устраивает качество наших работ, то он может не заактировать спринт без объяснения причин, и продолжить свои поиски подрядчика
2.2. последнее время мы вообще тестируем включение в договор обязательства возврата денег заказчику без объяснения причин по первому требованию, в том числе по подписанным актам, в случае если функционал не получилось (ну или заказчик решил не пробовать) запустить в эксплуатацию, или заказчик решил отказаться от эксплуатации в течение 30 дней после запуска в эксплуатацию.

PS. И да, всё верно. Нужно доверие между заказчиком и исполнителем. Без этого никакой agile работать не будет.
AlexK_2012; acanta; +2 Ответить
39. vova196 23 24.01.19 15:32 Сейчас в теме
А мне статья (точнее описаный подход) - понравилась. Не в силу своей жизнеспособности на бескрайних просторах "пост-советских" заказчиков, но именно как попытка вывести управление проектами 1С на новый уровень. Без подобных попыток выбраться из ямы "а мы вот чего-то хотим, но не знаем как, но вы цену и сроки назовите" - возможности нет. Тем более с отягощением в виде чемоданов в большинстве своём мало-пригодных ТЗ и концептов. (Малопригодных опять таки из-за "не созревших" в большинстве своём заказчиков).
И даже не смотря на явные приукрашивания и идеализацию достигнутых результатов - это всё равно лучше чем сидеть в ожидании ... а кстати без ожидания. Просто сидеть "на окладе" отвечая только "за пуговицы".
Ведь немаловажным в Scram является командо-образующее составляющее, предполагающее максимальную полезность каждого на большинстве этапов. А это уже шаг по направлению к "качеству" конечного творения. В альтернативу водопад может применяться и без "сплаченной команды", в условиях когда 99% общения заочно через e-mail большими "кусками" информации. Можно в таких условиях сделать хороший проект? - Можно! Но долго, дорого и с меньшей вероятностью (именно "хороший", а не просто сделать).
Поэтому не стоит судить автора строго за некие недомолвки. Лично я ему благодарен за описанный опыт. Применять или нет - дело каждого
chemezov; Rustig; AlexK_2012; oberonm; Vladimir Litvinenko; +5 Ответить
40. user743102 24.01.19 21:06 Сейчас в теме
41. Gesperid 2 25.01.19 08:47 Сейчас в теме
(0) Откуда эта цитата, есть на английском?
"ИТ-архитектура – это те решения, которые одновременно важны и которые трудно изменить." М. Фаулер
44. glebushka 235 26.01.19 13:22 Сейчас в теме
(41)
"ИТ-архитектура – это те решения, которые одновременно важны и которые трудно изменить." М. Фаулер


Не помню, где конкретно прочитал в первый раз, но легко гуглится. По запросу "fowler architecture hard to change" мне в первой же ссылке выдал: "Software architecture is those decisions which are both important and hard to change"
51. grandsystems 11.03.19 11:21 Сейчас в теме
Глеб, просто отличная статья! Можно дать название плагинов к Confluence (планировщик и рисовальщик), а также подробнее немного про бота для Slack (тоже плагин или сами сделали)?
AlexK_2012; +1 Ответить
52. glebushka 235 01.04.19 16:28 Сейчас в теме
(51)
1. Confluence - RoadMap Planner Macro (встроен), схемы бизнес-процессов draw.io
2. Slack - используем сервис geekbot.io Если речь об интеграции с Jira - то тут делали сами. Планируем в течение нескольких месяцев выложить на продажу на Atlassian Market.
grandsystems; +1 Ответить
53. DAV 03.04.19 11:34 Сейчас в теме
В качестве примера эффективного применения Scrum можно привести доработку программного обеспечения для управления марсоходом Spirit. Там была интересная ошибка. Марсоход находился на расстоянии 200 миллионов километров от Земли, и в его ПЗУ был баг.

А можно поподробнее, где тут скрам?
Оставьте свое сообщение

См. также

Как правильно купить 1С Промо

Управление проектом v8 1cv8.cf Бесплатно (free)

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

23.03.2018    13714    0    raiml    27    

Отраслевые чудеса

Управление проектом v8 1cv8.cf УУ Бесплатно (free)

Про отраслевые конфигурации

сегодня в 00:00    95    0    1c-intelligence    1    

Автоматизация управления закупками: специфика проектов, методология работ или "как не наступить на грабли"

Управление проектом v8 ERP2 УУ Бесплатно (free)

В этой статье речь пойдет об автоматизации закупочной деятельности. Причем не о том, как настраивать рабочие места, документы и реквизиты в 1С:ERP. А о том, что на самом деле обычно нужно компании, когда она заявляет об «автоматизации процессов закупок». И о том, как правильно подойти к этой самой автоматизации, чтобы проект не стал «вечным долгостроем», а внутренние заказчики (руководство компании, руководители отделов и департаментов) получили действительно полезный результат. Подробнее тему автоматизации МТО можно изучить на курсе //infostart.ru/public/1201558/

06.04.2020    2791    0    1СERP    4    

Внедрение 1С:ERP и 1С:КА - одна тестовая база для всех

Управление проектом v8 ERP2 КА2 Россия Бесплатно (free)

Параллельно с настройкой РСБУ на практике продолжается доработка правила переноса, доработка конфигурация и моделирование упр. учета, меняется НСИ. Четко разделить эти этапы во времени у нас не получалось. Возникает ситуация, когда специалисты и ключевые пользователи должны видеть актуальные данные переноса, работать в актуальных настройках, желательно в одной базе, при этом не мешая друг другу. В статье приведен наш взгляд на оптимальное решение в этой ситуации.

03.04.2020    1452    0    Egenee    0    

Такие разные франчайзи. Часть вторая: Особенности реализации крупных проектов, Глава 2. Проектная технология при внедрении «1С:ERP» Промо

Управление проектом v8 ERP2 Бесплатно (free)

Очередная статья о бизнесе франчайзи 1С. Здесь мы постараемся рассказать о том, какой подход используется при относительно крупных проектах, в частности, при внедрении «1С:ERP», дадим описание этапов проекта, укажем, какие риски имеет каждый этап работ, расскажем, уместны ли при внедрении «1С:ERP» такие модные методики, как Agile, автоматизированное тестирование и пр. Автор статьи Андрей Мироненко.

24.04.2017    29081    0    1СERP    85    

Опыт внедрения/разработки продуктов 1С

Управление проектом v8 1cv8.cf Россия Бесплатно (free)

В настоящей статье хочу поделиться своим опытом внедрения проектов, связанными с реализацией решений на платформе 1С. Скажем так, немного о наболевшем.

16.01.2020    5646    0    BraunAlex    11    

Проблемы интеграции 1С: ERP с негибкой системой производственного учета

Обмен данными 1С Управление проектом v8 ERP2 Бесплатно (free)

Данная статья описывает трудности интеграции 1С: ERP с негибкой внешней системой производственного учета. Статья поможет консультантам/менеджерам проектов обойти стороной те грабли, с которыми познакомились мы.

14.01.2020    3104    0    user1042803    5    

Почему можно начать внедрение ЕРП с регламентированного учета и что нам мешает это сделать?

Управление проектом Бухгалтерский учет v8 ERP2 1С:Франчайзи, автоматизация бизнеса Россия БУ Бесплатно (free)

В этой статье постараемся разобрать риски запуска ЕРП с регламентированного учета и обосновать возможность такого запуска.

25.09.2019    8561    0    Praktika_resheniy    15    

Организация эффективной техподдержки 1С внутри компании Промо

Управление проектом v8 1cv8.cf Бесплатно (free)

Как сделать общение с пользователями эффективным, правильно организовать работу программистов 1С и перестать быть "шестируким Шивой"

10.03.2015    37107    0    adapter    36    

Как внедрить 1С:Документооборот в условиях хаоса

Управление проектом Документооборот и делопроизводство Документооборот и делопроизводство v8 ДО УУ Бесплатно (free)

Не всегда проекты можно внедрить по заранее спланированному алгоритму. Скорее, даже никогда проекты не удается выполнить по универсальному плану: в каждой конкретной ситуации есть свои сложности и свои проблемы. Опытом внедрения 1C:Документооборот в отсутствии описанных процессов и утвержденной структуры предприятия на конференции поделилась руководитель отдела автоматизации торговой сети РЕМИ Марина Лимонтова (г. Владивосток).

21.08.2019    12258    0    limm28    14    

Внедрение конфигурации 1С:Государственные и муниципальные закупки 8 по технологии контрольного примера

Управление проектом v8 1cv8.cf Государственные, бюджетные структуры Россия Бесплатно (free)

Внедрение конфигурации 1С:Государственные и муниципальные закупки 8 с помощью технологии контрольного примера. Коротко рассмотрен состав работ и целесообразность использования этой технологии в конкретном случае: ФЗ-223 и неполное использование функционала 1С:ГиМЗ.

22.05.2019    4419    0    2ncom    10    

Корпоративный мозг на 1С и Python

Управление проектом v8 1cv8.cf Бесплатно (free)

Перед вами краткая инструкция, как можно быстро начать digital-трансформацию компании с помощью нейронных сетей на 1С, а также с использованием, в качестве дополнения, ресурсов Python.

17.05.2019    22897    0    user995065    74    

Как не нужно "запускать" проекты 1С Промо

Управление проектом v8 УПП1 Оптовая торговля, дистрибуция, логистика Пищевая промышленность Бесплатно (free)

Описываю мою практику работы над проектами совместно с компаниями Франчайзи. И рекомендации по работе с такими проектами.

24.02.2013    102169    0    axxell    132    

Где теряется эффективность?

Управление проектом Личная эффективность v8 1cv8.cf Бесплатно (free)

Общее понятие об эффективности командной работы. Где она теряется, где ее ищут, и почему ничего не получается.

03.05.2019    6359    0    1c-intelligence    13    

Особенности реального внедрения 1С:ТОИР

Управление проектом Бухгалтерский учет v8 1cv8.cf Машиностроение и приборостроение Россия Бесплатно (free)

Часть 1. Учет объектов ремонта. Интеграция ТОИР с учетной системой. Планирование ремонтов.

29.03.2019    10312    0    Aprsoft    3    

Git + 1С. Часть 2. Реализация Git workflow в 1С-разработке по шагам

Инструментарий разработчика Управление проектом v8 1cv8.cf Бесплатно (free)

В этой части мы рассмотрим наиболее распространённую схему workflow при групповой разработке с использованием Git. Как приступить к доработке по поставленной задаче; исправить ошибку, обнаруженную на этапе тестирования; отправить свой код на слияние в предстоящий релиз; и т.д. Постараемся охватить большинство задач, составляющих основной цикл разработки

28.01.2019    15568    0    stas_ganiev    28    

Начало автоматизации (Часть 1) Промо

Управление проектом v8 1cv8.cf 1С:Франчайзи, автоматизация бизнеса Россия Бесплатно (free)

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

30.04.2011    24159    0    milkers    86    

Выбор программы 1С

Пользователю системы Интеграция Управление проектом v8 1cv8.cf Россия Бесплатно (free)

Данная статья является своеобразной точкой отсчета для тек, кто размышляет на тему автоматизации бизнес-процессов своей компании. Для тех, кто только начинает свое знакомство с линейкой программных продуктов фирмы 1С. Мы рассмотрим упрощенный процесс выбора программного продукта применительно к тому или иному направлению учета.

16.01.2019    7947    0    itworks    22    

Как правильно выбрать поставщика услуг 1С

Управление проектом v8 Россия Бесплатно (free)

Для того, чтобы внедрение нового программного продукта (либо сопровождение уже имеющегося) прошло гладко и безболезненно для компании, необходим достойный поставщик услуг 1С. Официальные партнеры 1С, фрилансеры, специалисты 1С в штате собственной организации - рассмотрим все варианты через призму специфики различных сегментов бизнеса.

14.01.2019    5032    0    itworks    14    

Код по цене пачки пельменей и сорок бочек скрама

Управление проектом Практика программирования v8 Бесплатно (free)

Быстрый код по цене пачки пельменей и сорок бочек скрама пятому столику.

10.01.2019    10735    0    Alex_Japanese_Student    143    

УПП: Хроники малобюджетного внедрения (Часть 3) Промо

Управление проектом Производство готовой продукции (работ, услуг) Производство готовой продукции (работ, услуг) v8 УПП1 Россия Бесплатно (free)

Можно ли внедрять УПП на небольших фирмах с небольшими затратами? Это попытка рассказать об итерационной технологии внедрения на живом конкретном примере. Один раз в неделю Заказчик присылает свою базу и вопросы по ней, на один час автор связывается со IT-специалистом клиента по Skype и консультирует его. Прошло два месяца. Результаты перед вами.

10.09.2012    29283    0    PAVI    34    

Вы как хотите, а я сделал

Управление проектом v8::Бизнес-процессы 1cv8.cf Бесплатно (free)

Хвастаюсь системой управления задачами

28.12.2018    11380    0    1c-intelligence    18    

Как получить сервер разработки под 1С в Azure на 80% дешевле

Управление проектом v8 Россия Бесплатно (free)

Разговоров про облака в ИТ-индустрии очень много в последнее время. Часто споры сводятся к тому, как правильно считать стоимость владения.

05.12.2018    5099    0    zhogov    15    

Мой опыт: Внедрение ERP системы

Управление проектом v8 1cv8.cf Бесплатно (free)

Здравствуйте, уважаемые. Хотел здесь поделиться своим опытом внедрения, и выводами, к которым пришел.  А именно, акцентировать внимание на совершенных мной ошибках. Возможно, этот опыт будет полезен тем, кому предстоит что-то где-то внедрять. Особенно, если это большой проект.

03.12.2018    6845    0    dinopopyys    21    

Есть 2 подхода к внедрению информационных систем. На примере 1С УПП 8 Промо

Управление проектом Техническое задание v8 УПП1 Россия Бесплатно (free)

С детальным ТЗ? Или без серьезного ТЗ? Какой лучше? И где успех более вероятен?

26.01.2012    51876    0        54    

Git + 1С. Часть 1. Как подключиться к команде разработки и начать использовать Git

Инструментарий разработчика Управление проектом v8 1cv8.cf Бесплатно (free)

Первая статья из цикла инструкций по работе с Git в 1С-разработке. Рассмотрим, как настроить рабочее место, как получить свою "копию" проекта для разработки и приступить к полезным действиям. Все примеры будут изложены в рамках трёх практических кейсов: 1. Моя команда дорабатывает типовую конфигурацию, использует приватный репозиторий на BitBucket, в котором версионируются внешние отчеты/обработки, расширения конфигураций и правила обмена; 2. Я участвую в стартап-команде, которая разрабатывает свою конфигурацию с использованием Git и GitLab; 3. Я принимаю участие в развитии OpenSource-продукта на GitHub как заинтересованный разработчик (контрибьютор).

18.10.2018    57827    0    stas_ganiev    73    

Как проектировать отчетность

Техническое задание Управление проектом Управленческие v8 УУ Бесплатно (free)

Эта статья написана по итогам мастер-класса для руководителей проектов и аналитиков, в рамках перехода на продуктовый подход к разработке. В ней мы постарались ответить на вопрос: "Как снизить риск потери доверия к данным информационной системы со стороны топ-менеджмента, грамотно выстроив процесс проектирования и разработки отчетности?"

16.10.2018    8634    0    weissfeuer    2    

"Гнем" Waterfall

Управление проектом v8 ERP2 Бесплатно (free)

В прошлой статье (https://infostart.ru/public/898904/) мы поговорили о проблематике разных методик управления проектами – традиционный Waterfall и ныне модный Scrum. Но каких-то конкретных рекомендаций пока не дали. В рамках этой статьи поговорим о том, как же синтезировать эти подходы в то, что можно использовать в работе. Статья построена на примерах из практик ВЦ «Раздолье». Автор статьи директор по развитию ВЦ «Раздолье» Андрей Мироненко.

04.10.2018    7809    0    1СERP    9    

Диалог с клиентом. Правда vs ложь. Промо

Управление проектом Управление взаимоотношениями с клиентами (СRM) Управление взаимоотношениями с клиентами (СRM) v7.7 v8 1cv8.cf 1cv7.md Россия Бесплатно (free)

Как оценить работу и стоит ли говорить всю правду клиенту? Где та золотая середина, которая поможет «настроить» крепкие деловые отношения исполнителя с заказчиком?

02.01.2012    24456    0    Yury1001    238    

Проектирование архитектуры и модификация программных продуктов как технология в сложных проектах системной интеграции и автоматизации на базе 1С: СППР

Управление проектом Интеграция СППР v8 1С:Франчайзи, автоматизация бизнеса Бесплатно (free)

Как сделать проектирование функциональной архитектуры ПО технологией. Цель - устранить ряд типовых проблем на сложных проектах. Как использовать для решения этих задач 1С система проектирования прикладных решений (СППР). Статья полезна для директоров франчайзи, системных интеграторов, руководителей проектов, архитекторов и консультантов.

03.10.2018    14802    0    roman72    19    

Место гибких методов управления (Agile) в практике 1С

Управление проектом v8 ERP2 УХ Бесплатно (free)

Всякое описание тех или иных методик управления проектами является достаточно малоценным, если мы ведем речь об абстрактных проектах. Одно дело – проект строительства дома, другое проект автоматизации. Но даже этого недостаточно – автоматизация бывает весьма разной – делаем ли мы систему «с нуля» или адаптируем готовое решение под конкретного заказчика, сколько заказчиков у данной системы – один или множество и пр., пр., пр.. В итоге даются некие универсальные принципы, которые на практике бывают мало применимы и даже вводят людей в заблуждение. Попробуем поговорить о конкретике - но сразу предупреждаем что это субъективный взгляд на проблему от лица ВЦ "Раздолье". Автор статьи директор по развитию ВЦ "Раздолье" Андрей Мироненко.

05.09.2018    9876    0    1СERP    3    

Управление отделом разработки с помощью "1С:СППР"

Управление проектом СППР v8 Бесплатно (free)

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

20.08.2018    14611    0    pau74    11    

CI/CD для 1С - миф или реальность?

Управление проектом v8 Бесплатно (free)

Разберём плюсы и минусы применения практик CI/CD с учетом ограничения технологической платформы 1С:Предприятие.

02.07.2018    21440    0    comol    54    

А стоит ли затевать? Или каких результатов можно достигнуть, автоматизировав производство?

Управление проектом Производство готовой продукции (работ, услуг) Производство готовой продукции (работ, услуг) v8 ERP2 1С:Франчайзи, автоматизация бизнеса Россия УУ Бесплатно (free)

Ранее в проектной деятельности мы часто сталкивались с ситуацией, когда предприятия в первую очередь автоматизируют бухгалтерский учет, управление финансами компании, бюджетирование, и мало кто начинает проекты по автоматизации производства.

29.06.2018    7502    0    Aprsoft    1    

Управление проектами внедрения 1С:ERP

Управление проектом v8 ERP2 Бесплатно (free)

Тема статьи - «Управление проектами автоматизации 1С:ERP». В этой фразе хотелось бы поставить ударение на 1С:ERP. Почему? - Потому что 1С:ERP – это достаточно сложный комплексный продукт. - Проекты, которые мы делаем, зачастую охватывают все отделы и службы предприятия. - Здесь, в отличие от того же УПП, требования немного меняются – речь идет уже не об учете, а о планировании, об управлении ресурсами, что само по себе является более сложной темой. Об этом я и постараюсь рассказать.

21.06.2018    15519    0    andironenko    16    

История одного проекта ERP

Управление проектом v8 ERP2 Бесплатно (free)

Любопытная история одного проекта ERP, успешного - с одной стороны, провального - с другой.

02.05.2018    8548    0    papche    32    

Автоматизация торговой деятельности как путь к лидерству на рынке

Управление проектом v8 ERP2 Оптовая торговля, дистрибуция, логистика Россия Бесплатно (free)

В настоящей статье мы поделимся опытом автоматизации торговой деятельности и постараемся показать, как с помощью автоматизации повысить эффективность компании.

27.12.2017    9328    0    Aprsoft    0    

Внедрение 1С: ERP. Подготовка к внедрению. Внимание к человеческим ресурсам

Управление проектом v8 ERP2 Бесплатно (free)

«1С:ERP Управление предприятием 2» – современное программное решение для построения автоматизированных систем управления деятельностью предприятий, компаний. Невысокая стоимость владения и возможность получения существенного экономического эффекта стимулирует предприятия на её использование. Но необходимость внедрения автоматизированных систем управления иногда вызывает у руководства компаний тревогу. Хорошо, если в компании есть опытные специалисты, которые уже внедряли ERP на своих прошлых местах работы или имеют опыт его использования. Но таких на рынке труда пока немного. Поэтому руководители, которые решают проблемы повышения эффективности деятельности компании и интересы которых непосредственно затрагивает автоматизация систем управления, задаются вопросами: как подступиться к реализации и как разобраться в сложной «компьютерной игрушке»?

04.09.2017    16825    0    user742600    5    

Разбор полетов, или как на Партнерском форуме ругали 1С:Управление холдингом и что из этого вышло

Управление проектом v8 УХ Россия Бесплатно (free)

На партнерском форуме 1С один из партнеров разместил пост, в котором подверг критике реализацию продукта 1С:Управление холдингом в целом и команду разработки в частности.

02.08.2017    24737    0    WanGoff    73    

Экспериментальный проект «первая международная типовая»

Управление проектом v8 Бесплатно (free)

Большинство пользователей, разработчиков и партнеров привыкли видеть продукты на Платформе "1С:Предприятие" только на русском языке. Но для зарубежных рынков они не подходят. С какими проблемами сталкиваются специалисты по автоматизации предприятий за пределами русскоязычных стран, и как их удается решить, в своем докладе на Infostart Event 2016 рассказал исполнительный директор дочернего предприятия Фирмы "1С" в Бухаресте Алексей Снитковский.

16.07.2017    20724    0    Snitkovski    105    

Внедрение автоматизированной системы управления работами в сервисной компании

Управление бизнес-процессами (BPM) Управление проектом Производство готовой продукции (работ, услуг) Производство готовой продукции (работ, услуг) v8 ERP2 1С:Франчайзи, автоматизация бизнеса Россия УУ Бесплатно (free)

В статье рассматривается пример того, как мы создавали автоматизированную систему управления работами в сервисной компании. В начале мы провели анализ бизнес-процессов заказчика, которые существовали только в головах его ключевых исполнителей. Единый документооборот в сервисной компании отсутствовал, каждый руководитель подразделения вел свои данные в отдельных Excel файлах, на границах подразделений возникала потеря информации и документов, процедура управления работами превращалась в постоянный кошмар для руководителей. Для успешного решения задачи необходимо было провести предварительную серьёзную подготовку. В результате этой работы мы разработали методику, в которой подробно описали бизнес-процессы, определили оптимальный порядок действий, установили порядок передачи ответственности от исполнителя к исполнителю и порядок контроля выполнения работ. После этого внедрение автоматизированной системы стало обычным «делом техники».

29.06.2017    12031    0    Soliton    2    

Особенности внедрения 1С: WMS логистика. Управление складом

Управление проектом Учет ТМЦ Учет ТМЦ v8 1cv8.cf УУ Бесплатно (free)

«1С: Предприятие 8. WMS Логистика. Управление складом» является одной из востребованных программ, применяемых для автоматизации системы управления складами. Вместе с тем, wms логистику Управление складом нельзя рассматривать как панацею от всех проблем на складе. Без такой автоматизации вполне могут обойтись предприятия, у которых площадь складов не достигает 1000 м2, которые имеют относительно небольшой товарный перечень (до 100 SKU) или это товар, который имеет сравнительно невысокую скорость оборачиваемости.

27.04.2017    13260    0    user742600    6    

Автоматизация предприятий с проектным позаказным производством на 1С:ERP

Бухгалтерский учет Управление проектом Производство готовой продукции (работ, услуг) Производство готовой продукции (работ, услуг) v8 ERP2 УУ Бесплатно (free)

Внедренческий Центр "Раздолье" продолжает цикл статьей по автоматизации разных видов бизнеса. Очередная статья посвящена управлению предприятием, которое выполняет проектные/позаказные работы. Автор статьи Мироненко Андрей, руководитель проектов компании.

03.03.2017    17934    0    1СERP    5    

Концепция автоматизации многопрофильного Холдинга в системе АУБ на платформе 1С

Техническое задание Управление проектом Финансовый учет и бюджетирование (FRP) Управление холдингом (CPM) Учетная политика Бухгалтерский учет Управленческий учет (прочее) Финансовый учет и бюджетирование (FRP) Управление холдингом (CPM) Учетная политика v8 Россия УУ Бесплатно (free)

Это схема и обоснование концепции системы АУБ (Автоматизация Управления Бизнесом, авторская разработка) для автоматизации многопрофильного холдинга на платформе 1С. Система изначально проектировалась для многопрофильного холдинга, что определило особенность ее концепции - три уровня автоматизации. Система АУБ не является готовым решением, это определенная концепция (видение, подход) к автоматизации управленческого учета и расширяемый базис наработок реализованных в этой концепции. В конкретном проекте автоматизации, с учетом специфики управления предприятием, делается индивидуальная «функциональная сборка» с использованием готовых, существенно модифицируемых и заново разрабатываемых подсистем. Таким образом, концепция и расширяемый базис наработок системы АУБ, представляют своего рода конструктор, из которого компонуется решение в конкретном проекте, при этом заново разрабатывается лишь функционал, отражающий новую специфику. На практике концепция использовалась, например, в отраслевом решении для производства ЖБИ и добычи нерудных материалов.

02.03.2017    17878    0    aaw    3    

Проектное внедрение прав доступа в системах 1С

Техническое задание Управление бизнес-процессами (BPM) Управление проектом v8::Права 1cv8.cf Бесплатно (free)

Для крупных предприятий я рекомендую разрабатывать "Техническое задание на права доступа в системе 1С Предприятие 8". Данная работа сопровождается комплексным подходом по аналогии проектного внедрения. Рассмотрим порядок работы, переход от исследования к ТЗ и критерии упрощения документации.

17.01.2017    17055    0    Gavrik    4