gifts2017

Опыт практического применения методики BDD на 1С. Написание сценариев

Опубликовал Денис Олейник (oleynik.dv) в раздел Программирование - Практика программирования

Эта статья открывает цикл публикаций, в которых я хочу поделиться опытом использования методики BDD при разработке на 1С. В этой статье речь пойдёт о написании сценариев.

Предпосылки

Год назад наша компания находилась в классическом революционном состоянии, но с точностью до наоборот: верхи не хотели жить по-старому, а низы не могли жить по-новому. И вот я как один из представителей верхов находился в поиске «серебряной пули», которая бы позволила нам перейти из естественного состояния типичного 1С-Франчайзи (когда «неуязвимые чувачки» (C) @zevvssibirix говорят заказчикам: «мы сделали то, что вы от нас хотели, а то, что вам не нравится результат – это не наша проблема», когда о результате изменений в рабочей базе клиента мы узнаём утром от разъяренных менеджеров, у которых недостаточно прав для исполнения их обычных операций и т.д. ) в новое технологичное и управляемое состояние. В итоге мы начали обширную кампанию по организационным и технологическим изменениям в том числе и с привлечением сторонних специалистов, а поскольку нет предела совершенству – то кампания эта продолжается и, я надеюсь, будет продолжаться достаточно долго.

В этой статье я хотел бы рассказать о нашей попытке начать вести разработку на 1С с использованием методики BDD – поскольку данная методика (среди прочих технологических и организационных новаций) взята нами за ориентир, как внутренне присущая DSL-языкам (подробнее об этом здесь).

Немного о BDD для затравки

Что мы знаем про BDD? Знаем, что человек по имени Дэн Норт придумал эту методику, как эволюционное развитие TDD, и есть несколько его статей на эту тему (Введение в BDD и Что за User Story ). Знаем, что есть проект Cucumber, Aslak Helesoy и язык формального описания требований Gherkin, есть многочисленные фреймворки для высокоуровневых языков. С Божьей милостью теперь есть и фреймворк для 1С от проекта «SilverBulleters» - VanessaBehavior. Подробнее о BDD можно почитать на хабре или спросить у гугла – методике уже больше 10-ти лет, так что информации накопилось достаточно.

Чего мы не знаем про BDD? Здесь самое интересное. Дело в том, что когда люди говорят о «методике BDD» - они чаще всего говорят о «мечте-идее о BDD». Это как «коммунизм» в прозе Андрея Платонова: все о нём говорят и к нему стремятся, но имеют весьма смутное представление о том, что же это такое. Постараюсь объяснить, в чём тут сложность. Адепты «бихавиоризма» легко пишут кейсы сценариев для калькуляторов и банкоматов – ну что может быть прозрачнее:

Feature Калькулятор

Идеально, не правда ли? Разработка калькуляторов реально вышла на новый уровень…

Dark side of the moon

А теперь давайте перейдём на тёмную сторону луны – поговорим о разработке на 1С. Я какое-то время разрабатывал на 1С, и отчётливо помню, что когда мне было одиноко – я всегда разрабатывал калькуляторы или программировал «змейку» на 1С, и всё время меня мучал вопрос «как это сделать по-правильному?». И как назло от этого увлекательного занятия меня зачем-то отрывали заказчики и требовали странного: каких-то аналитических отчётов, новых документов, изменения существующих документов, сервисных обработок, интеграции и тому подобных «низких» вещей. И я старался поскорее расправиться с этой скукотищей, чтобы вновь с головой погрузиться в загадочный мир калькуляторов и «змеек». Знакомая ситуация? И я понимаю, что мои сотрудники в основном также воспринимают мир. И я должен к ним прийти и сказать: «Ребята, прозрейте! Всё, что вам казалось рутиной и скукотищей, всё что вы делали на скорую руку и сбрасывали тестировать заказчику, всё вот это вот тоже можно делать по-правильному!» Сначала они говорят: «Опять барин на хабре сидел…» Потом видя, что я не отстану: «Сейчас отчётик на компоновке добью – и попробуем». Я им даю мануалы про калькуляторы и банкоматы, они кивают, курят – потом приходят и задают логичные вопросы:

- BDD – прикооольно! Мне тут заказали сделать документ «Отчёт о рабочем времени» в УТ 11, чтобы менеджерам можно было отчитываться о проделанной работе. Как мне это сделать по BDD?

- BDD – крутяк! Мне тут заказали номенклатуру из Excel с картинками загрузить. Как мне это сделать по BDD?

- BDD – отпад! Тут клиентик попросил товары из одного заказа поставщику выборочно перекинуть в другой, причём у него там всё разбито под заказы клиентов, а перебрасывать он хочет сводно по номенклатуре. Как мне это сделать по BDD?

Про товарища, также восхитившегося BDD, и предложившего «обменять УТ 11 с самописным сайтиком одного клиентика», я не буду ничего писать. Просто не буду и всё.

Сценарий «Отчёт о рабочем времени»

Что может быть проще – для начала нужно написать сценарии использования. Это действительно просто (на самом деле - нет). Ну вот возьмём задачу с документом. Начнём!

Отчёт о рабочем дне. Тогда...

Хм… Тогда что? По теории сценарии должны воплощать критерии приёмки. То есть какой конкретный результат должен быть у данного действия? Я как программист честно говоря не знаю. На мой взгляд (как программиста) конечный результат – это записанный документ с информацией менеджера. А вот какой результат ожидает менеджер? Кто об этом должен думать? Программист 1С? Отложим этот вопрос до лучших времён, и вдохновившись статьёй Сергея Георгиевича, включим режим бизнес-аналитика. Итак, предположим документ введён. Что будет дальше с ним делать менеджер? Сам ему предложу. Слушай, менеджер, вот ты отчитался за неделю, каждый день вводил эти долбаные отчёты, и вот пятница, потом выходные пролетели в пьяном угаре, и вот понедельник, башка болит, всё в тумане. Что тебе поможет вспомнить всё? Конечно отчёт о прошлой неделе! Это же очевидно. Строим отчёт по дням и вспоминаем, вспоминаем, вспоминаем… Это великолепно!

То есть сценарий должен заканчиваться отчётом. Менеджер вводит документ за документом, чтобы в итоге построить ретроспективный  отчёт:

Отчет о рабочем дне. Ок

В принципе неплохой прототип сценария… Показываю менеджеру – он счастлив. Как бизнес-аналитик я отработал. Возвращаюсь в режим программиста. Смотрю на сценарий – и он мне не нравится. Он мне не нравится, потому что мне непонятно, что надо делать. Какие должны быть реквизиты у документа, какие из них обязательные, какие нет, какие кнопки должны быть, может нужно какие-то документы привязать (письма, контакты, заказы), про отчёт вообще непонятно. Ну ладно, по ходу додумаю…

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

Cценарий «Загрузка из Excel»

Ну это каждый 1С-ик делал. Сейчас разберёмся. Пишу:

Загрузка номенклатуры из Excel. Аналитик

Очень информативно, правда? А что может ещё расписать бизнес-аналитик для такого сценария, если поведение пользователя в системе будем именно таким? Я как программист должен внести исправления в исходный сценарий, чтобы как минимум указать структуру Excel-таблицы, из которой буду загружать данные. Заметьте, что дальше я как программист предпочту выполнить проверку прочитанной из Excel-файла информации. То есть мне нужно сделать некую промежуточную таблицу, в которую загрузится содержимое файла Excel. И таким образом я проверю, что в файле тоже самое, что и в моей промежуточной таблице. Потом я должен создать номенклатуру и проверить её создание. И это всё я должен выразить на декларативном языке описания требований. В этот момент программисты обычно начинаю роптать. Они говорят про самодокументирующийся код, про то, что запрограммировать будет быстрее, чем писать этот сценарий, и так всё понятно, и вообще Gherkin не нужен…

Итак, обработанный программистом набор сценариев:

Первый:

 

Второй:

 

Третий:

 

Четвертый:

Ну вот это уже сценарии для нормальной разработки! Тут и сторонники TDD скажут, что это похоже на тестовые наборы с ассертами, ну и вообще имеет право на жизнь.

Но и тут есть нюансы. Например, я как бизнес-аналитик смотрю на этот сценарий и спрашиваю: «а это вообще о чём?» Что это такое? «Ну как же?» - отвечу я как программист – «это же тот самый сценарий загрузки номенклатуры, только улучшенный!» Но бизнес-аналитик покачает головой и скажет: «мне будет трудно донести это клиенту, слишком много технических подробностей». Ну и я как зануда добавлю: «а в чём здесь собственно поведение? За этими деревьями строк и таблиц совсем не видно бихавиорного леса». То есть фактически это превратилось в тестовые наборы на Gherkin, а совсем не в описание поведения пользователя. Более того, когда бизнес-аналитик договаривался с клиентом – то зафиксировал договоренности в первоначальном сценарии, а в качестве базы для реализации будет применяться совсем другой сценарий. Я как клиент не могу быть уверен, что в ходе трансформации не было утеряно само зерно моей хотелки – и принимая работу, я как клиент буду неприятно удивлён.

Если на претензию об избыточности технических нюансов можно ответить «интегральным сценарием» либо многоуровневым (вложенным) сценарием, то что делать с бихавиорным дуализмом или дуалистичным бихавиором мы ещё для себя не решили.

Интегральный сценарий даёт возможность ссылаться на другие сценарии feature-файла, либо экспортированные сценарии других feature-файлов в той же папке и вложенных в неё:

Многоуровневый (вложенный) сценарий позволяет превратить сценарий в древоводиную структуру с использованием тэга @tree:

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

Вот как это выглядит в VanessaBehavior:

Сценарий в VanessaBehavior

Резюме

Какие вопросы я хотел осветить, а точнее – поднять для обсуждения:

  1. Внезапно BDD – это не о программировании, а о бизнес-анализе. Кто из ваших сотрудников будет этим заниматься? Программисты, которые мыслят объектами метаданных? Методисты, которые мыслят жёлтыми книжками?
  2. Какой должна быть степень детализации проработки сценария бизнес-аналитиком, и где та грань, когда сценарий будет уже понятным программисту, но ещё не потеряет своей семантической нагрузки?
  3. Как бизнес-аналитику писать сценарии, чтобы программист реально ими пользовался, а не выбрасывал их и переписывал на такие, чтобы ему удобно было разрабатывать?
  4. Как объяснить бизнес-аналитику, что ему больше не надо описывать функционал, а нужно описывать поведение пользователя? Не превращать каждый сценарий в описание внутренней логики программы при нажатии кнопки, а фокусироваться на критериях приёмки.
  5. Насколько это корректно заставлять человека-непрограммиста описывать требования заказчика с использованием формального языка? Если роли БА и программиста выполняются одним человеком – то проблем нет, а если у нас проект и команда, тогда как?
  6. Как повлияет на скорость разработки/внедрения составление сценариев бизнес-аналитиком до программирования?
  7. Как использовать BDD на проектах внедрения, когда львиная доля – это типовой функционал 1С? Обкладывать сценариями типовой функционал?

 

Темы, которые я хотел бы затронуть в следующих статьях этой серии:

  1. Как поставить применение BDD на поток в проектах внедрения 1С?
  2. С чего начинается сценарий? Предварительная работа с требованиями заказчика.
  3. Как организовать регрессионное тестирование внедряемых типовых конфигураций с использованием сценариев поведения пользователей.

 

Отдельно хочу поблагодарить за содействие в написании статьи:

@allustin – главный идеолог команды «Серебряная пуля»

@Pr-Mex – автор фреймворка Vanessa-Behavior

Пообщаться со всеми нами на тему "BDD и 1С" можно здесь.

См. также

Подписаться Добавить вознаграждение

Комментарии

1. Виталий Попов (Сурикат) 03.07.16 21:51
По прочтению статьи родилось несколько вопросов. Возможно я поторопился, задавая их =) Все-таки это только начало =)
1. Какое у вас покрытие кода тестами? Все-таки написание тестов для проверки ряда алгоритмов будет занимать приличное время, особенно по началу. И не всегда возможность автоматического воспроизведения тестового сценария оправдана...
2. Как вы организовываете базу для тестирования? Сами набиваете необходимые данные на чистой базе? Или есть своя база для каждого теста?



2. Алексей Лустин (lustin) 03.07.16 22:08
(1)

1. тестов в BDD нет. Тесты в TDD - соответственно и покрытие считается другое.
2. раз тестов нет - то нет и базы для тестирования. Есть база для проверки поведения... и внезапно, заполнение базы, это блин также поведение системы. Она же не из воздуха заполняется.

это если коротко.
3. Денис Олейник (oleynik.dv) 03.07.16 22:16
(1) Сурикат, на первый вопрос чётко ответил Алексей )
Ответ на второй я попробую оформить отдельной статьёй, чтобы так сказать не расплескать.
4. Алексей Лустин (lustin) 03.07.16 22:18
(3) Денис - нужно наверное обновить скриншот с behavior. Час назад выпущен релиз 1.0
5. Денис Олейник (oleynik.dv) 04.07.16 09:03
(4), подправил картинку, правда статья ушла на модерацию и вылетела из показа, ну да ладно - уже на месте.
6. Леонид Паутов (Pr-Mex) 04.07.16 10:51
Спасибо за статью!
Дам свои варианты ответов на поставленные вопросы, кратко.

1.Внезапно BDD – это не о программировании, а о бизнес-анализе. Кто из ваших сотрудников будет этим заниматься? Программисты, которые мыслят объектами метаданных? Методисты, которые мыслят жёлтыми книжками?
BDD начинается в отделе аналитики, потом идёт в отдел разработки, потом идёт в отдел качества, потом идёт к техническим писателям (для создания документации). Заниматься будут все )))

2. Какой должна быть степень детализации проработки сценария бизнес-аналитиком, и где та грань, когда сценарий будет уже понятным программисту, но ещё не потеряет своей семантической нагрузки?
Фича файл проходит несколько итераций на своём пути.
Сначала он содержит минимум деталей (И документ записался, И документ провелся). Затем она обрастает нужными деталями. Нужными как для бизнеса, так и для технарей.
Где находится баланс - как обычно, где-то посередине. Команда его найдёт с опытом.


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

4. Как объяснить бизнес-аналитику, что ему больше не надо описывать функционал, а нужно описывать поведение пользователя? Не превращать каждый сценарий в описание внутренней логики программы при нажатии кнопки, а фокусироваться на критериях приёмки.
Надо сказать ему: "Коля, теперь тебе надо описывать поведение пользователя!"
А если серьёзно, то это вопрос обучения и готовности человека к изменениям.


5. Насколько это корректно заставлять человека-непрограммиста описывать требования заказчика с использованием формального языка? Если роли БА и программиста выполняются одним человеком – то проблем нет, а если у нас проект и команда, тогда как?
Gherkin - язык, конечно, формальный - но очень простой. Он так и был задуман, чтобы его понимали все участники процесса.


6. Как повлияет на скорость разработки/внедрения составление сценариев бизнес-аналитиком до программирования?
Классический вопрос по скорости разработки, при использовании методик BDD, TDD и т.д.
На мой взгляд, корректней говорить о циклах разработки.


7. Как использовать BDD на проектах внедрения, когда львиная доля – это типовой функционал 1С? Обкладывать сценариями типовой функционал?
Отличный вопрос. Было бы круто, если бы типовые конфигурации были покрыты фича файлами из коробки!

Итого: очень круто видеть 1С-Франчайзи, который применяет такие технологии в реальности! Браво!
RainyAugust22; serge_focus; hawk911; Mos; JohnyDeath; 1ceo_2015; zqzq; kraynev-navi; +8 Ответить
7. Яков Коган (Yashazz) 04.07.16 11:39
Позволю себе несколько нарушить сферичность этого вакуумного коня: а у Вас есть конкретные успешные примеры проектов "от и до" с активным применением перечисленного? А то уж больно заумью "бизнес-аналитической" отдаёт...
8. Денис Олейник (oleynik.dv) 04.07.16 13:17
(7), спасибо за ваш вопрос. Примеры проектов есть, и в них применялись и сценарии, и сервера сборок и отчёты о качестве в allure формировались, но о них не в этой статье. Изначально я хотел её разместить в рубриках "Управление проектами" и "Техническое задание", но модератор решил, что это о теории программирования.
Может быть поэтому Вам как практикующему разработчику статья показалось "бизнес-аналитической" заумью - она действительно не о программировании.

У меня встречный вопрос: а как у Вас ставятся задачи на разработку, в каком формате пишутся спецификации, как происходит приёмочное тестирование? Это те вопросы, которые я бы хотел обсуждать в рамках этой статьи.
9. Денис Олейник (oleynik.dv) 04.07.16 14:03
(7) , ещё добавлю. Я хотел поделиться тем, что действительно вызвало затруднения. Нет проблем программировать шаги сценариев, или использовать библиотечные шаги из VanessaBehavior, нет проблем в разработке функционала, по которому сценарии отработают, нет проблем в организации регрессионного тестирования - это мы сделали, и это работает.

Главная проблема - это низкий уровень культуры бизнес-анализа. Возможно я скажу крамольность, но в 1С-Бизнесе люди такого класса вообще редкость. Есть РП, есть методисты, есть программисты. Есть водопад с тоннами ТЗ и техпроектов, есть ТБР с анкетами и интервью. А вот люди, которые могли бы мыслить в терминах "требование клиента - критерии приёмки - разработка - тестирование" есть ли они? Люди, которые практикуют целеориентированное проектирование?
10. Леонид Паутов (Pr-Mex) 04.07.16 15:19
(9) oleynik.dv, всегда приходится с чего-то начинать. Эти технологии только приходят в 1С мир, поэтому (на данный момент) такого специалиста приходится выращивать/обучать.
11. С К (kraynev-navi) 04.07.16 15:40
Очень доступно, спасибо автору. Очень хочется продолжения из анонсов.
12. Яков Коган (Yashazz) 04.07.16 17:31
(9) oleynik.dv,
А вот люди, которые могли бы мыслить в терминах "требование клиента - критерии приёмки - разработка - тестирование" есть ли они? Люди, которые практикуют целеориентированное проектирование?
Таких людей, если рассуждать массово, и нет, и не может быть, и не должно быть. 1С - проблемно-ориентированное от начала до конца, это концепт и модус операнди, это стиль мышления и работы, организации и целеполагания. И это не низкий уровень культуры, а иная плоскость эффективности. Иная длина цикла/спринта, иной горизонт планирования. Степень хаотизации/формализации другая. Будь иначе, за последние 5-10 лет всё уже б выглядело, как Вы описываете.
13. Алексей Лустин (lustin) 04.07.16 18:31
(12) Yashazz,

проблемно-ориентированное от начала до конца


А проблему озвучьте ? На решение какой проблемы ориентирована 1С ?
14. Денис Олейник (oleynik.dv) 04.07.16 19:30
(12) , я с Вами не соглашусь. 5-10 лет назад потребности рынка были таковы, что требовались быстрые и за счёт быстроты эффективные решения, без оглядки на устойчивость и качество - больше изменений, ещё больше! Если возникали коллапсы - то мы с ними героически боролись, и бизнес за это платил, считая что мы по одну сторону баррикад. Такой вот был, как вы говорите, модус операнди.

Сейчас же я наблюдаю другую тенденцию: бизнес не готов платить дважды. Требуя всё ту же скорость решений, они фильтруют запросы в сервис-деске по типу "Ошибка" и говорят - за это мы платить не будем, мы за это уже платили, а вы своими "обновлениями" это взяли и испортили.
И я понимаю, что "как раньше" уже нельзя, и у меня вопрос: как нам обеспечивать высокое быстродействие, не теряя в качестве? Я вижу так, что только за счёт повышения технологичности и максимальной автоматизации рутинных процессов. Поэтому неизбежно нужно обращаться к общепринятым IT-практикам. Адаптировать их к 1С-реалиям и применять.
Когда мы сейчас говорим бизнесу о том, что у нас есть монитор качества разработки и мы не допустим в production изменения, если в allure не светится радужный единорог - они смотрят на нас умными глазами и говорят: это очень интересно.

Если Вы знаете более простой и дешёвый путь - было бы интересно услышать Ваше мнение. Я в данном случае достаточно прагматичен, если есть более оптимальное решение из соотношения цена/качество - тогда конечно Agile, BDD, CI, allure всё это зря.
DonAlPatino; JohnyDeath; nixel; Bronislav; CheBurator; 1ceo_2015; Pr-Mex; sorb; +8 Ответить 1
15. Сергей (Che) Коцюра (CheBurator) 05.07.16 02:18
Спасибо за статью
Связно изложено и последовательно
Ставновится яснее

Как все происходит у меня
Есть некий посыл а типа сделайте вот типа такого или тут у вас плохо
Ладно, иду пытаю одних что такое хорошо
Выслушал
Сформировал мнение
Иду пытаю вторых
Ибо все пробоемы на стыках
Выслушал
Сформировал мнение
Имею два мнения
Они друг с другом дружат очень плохо
Хожу как передаст и склеиваю лоскуты в одеяло
Вроде выстроилось илеологически
Набросал в уме крупными блрками
На уровне связей блоков вроде все должно быть ок
Начал лепить по принципу сверху вниз
Что получилрсь то и получилось
Приемки и тестов по сути никаких нет
Потому что ни один из формулировавших задачу так и не сформулировал задачу
А сформулировал свое частное видение своего счастья
Котрое никак не клеится со счастьем других
Итого сам типа тестирую
Сам загоняю в продакшен
Кушайте то что есть ибо так понял и так сделал
Не нравится - пишите мессаджи
... Мессаджи приходят обычно только в первые день два если вылезли большие грабли
Грабли которые вылезли потом типа тут у вас неправильно потому что.. Ответ даю обычно такой - это не озвучивалось вами при обсуждениях, так что ешьте что есть сейчас - будет время - может поправлю
kuzyara; TreeDogNight; PAVI; MaxDavid; ZOMI; alest; Yashazz; Mos; Геннадий164; +9 Ответить 2
16. Сергей (Che) Коцюра (CheBurator) 05.07.16 02:30
(14) проблем куча
Я бы с удовольствием ходил бы и на gerkin писалформализовывал поведениетребования
Только кто ж мне даст программера который напрограммит это все? Итого сам себе и бизнесаналитик и программер - причем и первый и второй так себе

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

Проблема в ресурсах. Както я не вижу готовности мелкосреднего бизнеса на отдел одноэсников из трех человек фот давать больше чем на отдел продаж из шестисеми человек. Может я в неправильных конторах работаю.

Франчей поубивать бы
Вот эти описанные технологии как раз бы проталкивать как обязательный стандарт разработки у франчей, а то у мну лавочник сорок штук отдал и по факту я уже три глобальные ошибки выловил - и что делать? Самому все писать? Умру...

Понятно что здорово
Понятно что имеет смысл это только когда отдел разработки наверное человек пять
А что делать в мелких компаниях?
Где извратов вагон а ресурсов коробочка? Смайл
Непонятно!
MaxDavid; Сурикат; +2 Ответить 2
17. Пишу код как картины (yurii_host) 05.07.16 08:29
Полезный материал. Спасибо
18. Денис Олейник (oleynik.dv) 05.07.16 09:38
(15) отличный кейс ;-). Из моей практики в таких вещах помогают конкретные примеры. Для того, чтобы на них выйти нужно задать заказчикам один казалось бы простой вопрос:
как вы будете проверять, что я сделал, то что вы хотели?

Важно формулировать его именно так. Именно с этого вопроса можно выходить на BDD. Не "как это должно работать" и не "что должна делать программа" - это выход на функционал и тупик. Если заказчик не может сформулировать, как он это будет проверять - то вы совершенно спокойно ему говорите: вы сами не знаете, что хотите, откуда же мне знать, что я должен вам сделать? Это страховка от дурацких "pet features" и собственно те самые критерии приёмки. Даже без Геркина это будет полезно. Когда есть пример - и разработанный вами функционал позволяет его реализовать, значит вы сделали то, что хотел заказчик. Если после сдачи работ внезапно заказчик кричит, что ничего не работает - вы спрашиваете: как вы проверяете? И снова от него должен пойти тестовый пример. Если этот тестовый пример не противоречит тому, который вы получили до разработки - значит ваш косяк, и вы чините всё бесплатно. Если противоречит - то вы говорите: позвольте, но...

Для себя мы установили, что тестовый пример должен содержать три раздела:
- входные данные
- описание действий
- выходные данные

С одной стороны такая формулировка не ограничивает формализацией полёт мысли бизнес-аналитика, с другой стороны это даёт чёткий выход на BDD c его Given-When-Then для последующего написания сценария.

Подробнее о работе с требованиями постараюсь написать в следующей статье.
kuzyara; moralex2k; A_Max; endym; TreeDogNight; ZOMI; new_user; RomanRomans; voneska7; VladimirL; Berckk; sorb; dalgaso2010; mindcannon; CheBurator; Man4kin; 1ceo_2015; JohnyDeath; Pr-Mex; Mos; +20 Ответить
19. Сергей Погодин (spogo) 05.07.16 10:03
Материал классный, спасибо автору и "серебряной пуле", давно слежу за всем, что у них происходит.
Вообще, народ, если кто не был ни разу на Infostart Event, очень советую, после посещения будете хотя бы смотреть в правильную сторону.
Сам пока не решусь начать делать всё "по правильному", поэтому пока посижу послушаю, развесив уши.
Ещё раз спасибо.
20. Евгений Сосна (pumbaE) 05.07.16 10:50
(19) spogo, начните с описания требований, не обязательно превращать все в код, но уже это даст понятие что же вы все-таки делаете.
Даже если один в поле воин как (15), главное вовремя менять шляпы и по другому задавать самому себе вопросы.

p.s.: заказчиком может ведь быть не только конечный пользователь, но и ваш внутренний перфекционист, говнокодер и т.д.
21. Яков Коган (Yashazz) 05.07.16 12:18
(15), (16) CheBurator, прям-таки на 146% поддерживаю. В реальной жизни всё так и есть. Где-то там какие-то заумные аббревиатуры, красивые доклады, эффектные презентации (статьи вот на ИС с кучей плюсов), а отдельно от всего этого - реальная работа, живое удовлетворение конкретных нужд и потребностей конкретных заказчиков, внутренних и внешних. Просто работа. Как всегда - с никакущими ТЗ, размытыми пожеланиями, дикими сроками, скверным оборудованием, неграмотными юзерами, тупо-агрессивным и самоуверенным руководством. Как всегда - с жуткими косяками конфигураций и терпимыми косяками платформы. Как всегда - когда нужно всё, сразу, вчера и с волшебными кнопками. И ещё - очень часто бывает, что приходят такие все из себя грамотные, умные, знающие - теоретики. Сшибают кучу бабла. Не делают по внедрению нихрена. А потом фирма, помучившись энное время, берёт своего штатника и он долго и старательно пилит конкретику, и тогда хоть что-то начинает работать. Вот оно по жизни-то как, господа в галстуках. И иначе не будет. Не перевоспитаете вы заказчиков, и не надейтесь. Никакую культуру им не привьёте. А живущим в нынешней схеме разработчикам эти ваши BDD - как автослесарю Михалычу теория фордовского конвейера.

И ещё.
Хорошо когда новый проект с нуля и можно попробовать запилить все по правильному с самого начала,
. Знаете, я за последний год наблюдал, как увешанные сертификатами, регалиями и опытом люди организовали и продвигали проект с нуля. Ну, если выражаться цензурно, то... Теория обнаружила трогательное несовпадение с практикой чуть более, чем полностью. И кончилось всё скандалами с заказчиком, бардаком в проектном управлении и авральной разработкой. И когда это уже далеко не первый случай, в т.ч. наблюдаемый дистанционно, с участием разных людей, твердивших про умные кейсы и прочая, то уже начинает казаться, что не ноги конькобежцу мешают, и не в бобине дело.
MaxDavid; ZOMI; petrov42; pmb17; pisarevEV; +5 Ответить 3
22. Никита Грызлов (nixel) 05.07.16 13:31
(21) Yashazz,

Типичный Yashazz. :)
sorb; lustin; +2 Ответить 1
23. Алексей Лустин (lustin) 05.07.16 13:32
(22) вяло как то сегодня - бывало больше
24. Евгений Сосна (pumbaE) 05.07.16 13:36
(21) Много текста, а вывод - только мастер Левша без образования может подковать блоху, а то что она прыгать перестанет, так то ничего страшного ближе к людям будет, приземленней.
Но какие-бы не были претензии к образованию, но без теории только напильником сможешь доработать, а построить новое нет.
25. Федор Латыпов (1ceo_2015) 05.07.16 13:43
(16) CheBurator, (21) Yashazz, пришла пора сказать правду. Все это конечно дорого ,долго и бессмысленно.
Смысл использования новой технологии конечно был не в этом.
Это было нужно для закрытия вакансии носильщика табуреток.
https://www.youtube.com/watch?v=0RY9u_mSDcU&feature=youtu.be&t=32m51s
на 32 минуте 53 секунде.

Надеюсь теперь можно расслабиться и продолжать работать по-прежнему ;) Ждем нового сотрудника в нашем уютном офисе.

А если серьезно : а как вы считаете потери , вызванные бесплатной работой или замедлением скорости поставки ценности заказчику?
Сколько бесплатной работы делается потом, через месяц или два после выполнения нечеткого пожелания чтобы все заработало?
Сколько стоит потеря доверия от заказчика? Рынок то у нас гадски сжимается. А нового привлечь вместо этого разачаровавшегося это дорого очень. С ним и поговорить надо, и посмотреть что за бизнес, и рассказать какие мы классные. А в это время можно было 10 старым лояльным уже много чего хорошего предложить. Но не получается - им же косяки закрываешь свои же прошлые.

Ну и давайте теперь вот эти суммы потерь сравним с:

1. стоимостью задавания вопросов: "Чтобы что?", "как вы будете проверять работу?" , "как я пойму что я сделал работу правильно?"
2. стоимостью оформления требований заказчика в виде карты целей и пользовательских историй
3. стоимостью внедрения методики проверки качества этих историй

Если 1+2+3 > потерь - то конечно нафик это все нужно.

Если меньше - ну есть повод подумать.
TreeDogNight; +1 Ответить 1
26. Геннадий Николаев (genayo) 05.07.16 13:50
(25) Расскажите хотябы одну суксесс стори, что, где и как разрабатывалось по данной методике, и сколько от этого выиграл бизнес? Это будет намного полезнее мантры "делайте так - и будет хорошо"
pm74; Yashazz; +2 Ответить 2
27. Яков Коган (Yashazz) 05.07.16 14:04
(23) lustin, ну занят я сегодня, занят) Я вот спросил о конкретике - автор изящно, как ему казалось, ушёл от ответа. Хочу "историю успеха" с пруфлинком.
28. Яков Коган (Yashazz) 05.07.16 14:12
(24) pumbaE, ткни мне пальцем, какая теория в 1С привела к успеху? Может, внедрение Agile в ЗАО "1С" привело к улучшению качества платформы 8.3? Что-то не заметно. Может, какая из общих теорий проектирования, моделирования, коллективной разработки итд привела к ясности и простоте кода конфигураций? Или к удобствам конфигуратора? Или какая теория эргономики привела к удобству интерфейсов? Ну, пример в студию!
29. Евгений Сосна (pumbaE) 05.07.16 14:25
(28) Yashazz, привело ли к улучшению качества платформы? Отвечаю, да привело, раньше мы год, полтара ждали новый релиз платформы, потом полгода собирали все косяки и только тогда говорили "ну теперь можно обновляться", при этом косяки в релизах как были так и остались, но их исправления приходилось ждать по году, сейчас уже можно сказать, что срок сместился до полугода - имхо це успіх.

Бух 3.0 мне по юзабилити значительно больше нравиться, чем 2.0.
Разве разработчики типовых работают по новым методам? По новому они не работают, соответственно и нет ожиданий, по ясности и простоты кода в типовых конфигурациях.
Удобство конфигуратора - тут нечего сказать, т.к. лечат они нарывы, а не болезнь в целом, и тут никакие TDD и BDD и отжал не помогут, если на входе не поступает адекватных задач.
30. Евгений Сосна (pumbaE) 05.07.16 14:35
(26) прочтите, то что после слова Резюме находится в статье, какие вопросы хотел бы автор поднять для обсуждения и какие темы в дальнейшем осветить.
Ну и уточните какой бизнес должен выиграть: бизнес разработчика(программиста), бизнес клиента, бизнес организации ...
31. Яков Коган (Yashazz) 05.07.16 14:36
(29) pumbaE,
при этом косяки в релизах как были так и остались, но их исправления приходилось ждать по году, сейчас уже можно сказать, что срок сместился до полугода
Темпы исправления старых косяков выросли на некоторую величину, да. Темпы создания новых выросли в разы. Позорище под названием 8.3.7, думаю, все видели. Багтрекер 1С тоже все видели: "исправлено 5, не исправлено 217". Це успiх, чи шо?

Бух 3.0 мне по юзабилити значительно больше нравиться, чем 2.0.
Это личная вкусовщина, нравится или нет. А вот когда форма не влезает на экран и её постоянно приходится прокручивать туда-сюда, это просто беспредел. Когда кнопка из-под мышки уезжает, сообщения невозможно нормально прочитать, размеры не запоминаются, поля микроскопического размера и здоровенные пустоты рядом - это так теория организации интерфейса велит?

По остальному - ну, была ж такая попытка, СППР называлась... Там даже типа ER-диаграммы были)) И где это всё?
32. Денис Олейник (oleynik.dv) 05.07.16 14:52
(27) Yashazz, я знаю одну историю про галстук и человека по имени Михаил с грузинской фамилией.
Меняю эту историю на success story. Идёт? ;-)

На самом деле проблем с успехом и историей нет. Постараюсь выделить время и оформить статью.
33. Алексей Лустин (lustin) 05.07.16 14:54
(26) genayo, а зачем Вам "история успеха" ? я без троллинга... я просто хочу понять: что это поменяет. ?

(28) извините, но 1С - это фирма, её внутреннюю подноготную пусть сам и публикуют (что они уже и начали делать на Хабре). Что касается "мира 1С" - то тут вопрос лучше задавать самому себе, если считаешь себя его представителем. Я ваши слова читаю как "теория проектирования , моделирования, коллективной разработки мне никак не помогла, поэтому ну её нафиг".
34. Яков Коган (Yashazz) 05.07.16 15:23
(32) oleynik.dv,
На самом деле проблем с успехом и историей нет. Постараюсь выделить время и оформить статью.

знаете, уже изрядное количество "бизнес-консультантов" на ИС отговорилось именно такой формулировкой, так что неоргинально отмазываетесь)) Лишь раз потом ссылка и статья воспоследовали...

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

а зачем Вам "история успеха"
а когда вас заказчик просит рассказать об успешных проектах, вы ему так же отвечаете?
35. Яков Коган (Yashazz) 05.07.16 15:25
(33) lustin, красиво пытаетесь подменить направление беседы. Не пойдёт. Не "вы читаете, как". Вы очень как-то ловко читаете)

Ещё раз: я задал конкретные вопросы, верно? Верно. Вопросы отнюдь не риторические. Вот и просьба отвечать на них в меру своего имхо, а не передёргивать и не выкручивать в сторону, кому что помогло. Я про себя и свой опыт ничего не писал, я задал вопрос. Ответьте или не тролльте.
36. Геннадий Николаев (genayo) 05.07.16 15:32
(33) Странный вопрос. Будет понятно, что данный подход - не теоретические умствования, а успешно зарекомендовавшая себя (в области 1С) методика.
37. ash (ashvik) 05.07.16 16:04
(31) СППР например здесь
http://1c.ru/news/info.jsp?id=21592
Как минимум заставили разработчиков 1С:Совместно вести проекты в СППР.
38. Леонид Паутов (Pr-Mex) 05.07.16 17:11
(36) genayo, Тут наверно имеется ввиду, что эти методики давно известны во всём мире, информации по ним вагон и всё это замечательно переносится в мир 1С.
39. Денис Олейник (oleynik.dv) 05.07.16 17:51
(34) Yashazz, я же не бизнес-консультант ) Вроде написал предысторию, ну и по ссылкам из профиля тоже никто не запрещает ходить. Зачем мне, как вы изящно выразились, отмазываться?
Наоборот - меня консультировали, я воспользовался, получил некий опыт - и делюсь им. Заметьте, что весь тон статьи выдержан в критическом русле. Я же не доказываю с пеной у рта, что BDD - панацея, зачем же Вы мне (и всему сообществу) доказываете обратное и требуете каких-то доказательств успешности? Я пробую, мне нравится - делюсь опытом. Если кто-то ещё пробовал и хочет обсудить - я только за. Вы же не пробовали?

Эту статью, @Pr-Mex не даст соврать, я готовил довольно долго, потому что к подаче материала отношусь достаточно ответственно. Следующая тоже появится не быстро. То, что следующие статьи будут, я сразу анонсировал. Поставить приоритет на "success story" - Ok. Что ещё надо?
40. Dima Neumoichev (Ndochp) 05.07.16 19:07
СС нужна хотя-бы для того, чтобы было понятно, дает ли БДД + Докер+сервер сборки+стат анализ кода + хЮнит для 1С выхлоп, сравнимый с затратами на них.
А уже потом можно разбираться, дает выхлоп вся эта связка или можно выкинуть более трудозатратную ее часть, например БДД.
А до СС это просто предложение убить с месяцок 100% загрузки одного-двух человек разово + замедлить разработку новых фич в 1,5-2 раза на постоянной основе в обмен на обещание снижения затрат на поддержку.

Опять же, раз "Внезапно BDD – это не о программировании, а о бизнес-анализе.", то первый вопрос не столько "Кто из ваших сотрудников будет этим заниматься?" Аналитики будут, это понятно. Если на проекте программист класса "внедренец", то он. Если выделенный аналитик, то он, тут все просто.
Важнее - а как мы продадим эту непонятную древовидную структуру заказчику? Про существование ГОСТ на ТЗ по АС знают все, даже если номер не помнят. А вот сценарии, особенно в режиме "вы нам подпишите интегральный сценарий, но на самом деле там еще внизу куча параметров, но вам их знать не обязательно" надо продавать указывая на успешные истории.
41. Геннадий Николаев (genayo) 05.07.16 19:20
(38) Это вы говорите - переносится. Я пока не знаю, расскажите мне...
42. Алексей Лустин (lustin) 05.07.16 20:02
(35) как показала практика использования - заказчики делают по другому.

.
включаю режим мутного менеджера


Заказчики лично звонят, пишут, говорят:

* так дальше нельзя
* у нас какой-то дурдом
* можно по другому ?

из последнего письма "Нас задолбали наши 1С-ники, мы готовы их всех нахер уволить или лишать зарплаты за баги в продуктиве (с)" (прямая цитата)

мы говорим можно и показываем как - высылаем материалы

* дальше мы подписываем NDA - соглашение о неразглашении исходников, доступов и методических материалов.
* дальше начинается классический проект "Имплементация инженерных практик"

опять же как показывает практика заказчиками могут стать только 2 типа людей:

* люди которые понимают сколько они сейчас теряют на времени простоя систем на 1С и на времени возврата на доработку
* люди которые понимают что ИТ издержки нужно постоянно снижать, за счёт автоматизации процессов производства ИТ.

Как видно - основными заказчиками в итоге становятся "Руководители ИТ", которые либо только пришли в компанию, либо инициировали процесс оптимизации внутренних ИТ процессов.
О чём кстати Денис тонко в заголовке намекнул - он то один из руководителей, причем как видно технический.

Результатом таких проектов становится постановка процесса "Автоматизированный релиз-менеджмент" внутри ИТ отдела. Там же не только BDD, а например code-review, TDD, CI-CD и т.д., и внезапно DevOps.

.
выключаю режим мутного менеджера


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

Мне вообще странны такие формулировки - вы искренне считаете что все люди которые активно работают тут:

* https://github.com/silverbulleters/vanessa-behavior/network/members
и тут
* https://github.com/xDrivenDevelopment/xUnitFor1C/network/members

Это прям гики и используют это потому что им так хочется ? И вообще они все ужасно неээфективны и неуспешны ? И работают они все в "серебряной пуле" и вообще...

Если честно - в этом году я принципиально против публикаций отзывов о реальном внедрении и реальных результатов. По двум причинам:

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

Что касается холиваров - я так понимаю ни (35) ни (36) не поняли главного.
Автор статьи насколько я помню является одним из руководителей производственного процесса внутри 1С:Франчайзи. Франчайзи коллеги !!!
И они уже работают по BDD.
И это уже история успеха - "Франчайзи работающий по проектам 1С с помощью инженерных практик"

И так на всякий случай напомню - вот эта вот фича, не абстрактная https://youtu.be/5E_wqiNu6T4
Там светится наименование контрагента который внедрял УТ ;-) (0) Извини Денис - но вы сами спалились. Неужели никто не обратил внимание на абревиатуру ОМПК ;-)

Но на сегодня мне удобней сказать следующее:

* (35) BDD - это конечно же умозрительная технология, никому не помогающая. Нигде не работает. И вообще она не нужна.
* (36) 1С - компания которая ничего не улучшает, все у ней падает, платформа отстой. Эргономика плохая. И вообще 1С не нужна - всем срочно писать ERP на PHP.

Для интересующихся 2 новых скриншота из того чем мы сейчас заняты в части эффективности производственных процессов

* автоподстановщик шагов для VSCODE - для более удобной коллективной разработки https://habrastorage.org/files/a01/6ce/af3/a016ceaf312b484198fdd3ea59c017d2.png
* математический расчёт технического долга - для планирования задач по оптимизации https://habrastorage.org/files/819/e51/6ae/819e516ae0154e92b10f2a2d8278a383.png
TreeDogNight; Man4kin; Bronislav; JohnyDeath; oleynik.dv; +5 Ответить 3
43. Алексей Лустин (lustin) 05.07.16 20:14
(40) Ndochp, напомню по стандартам должны быть 2 этапа:

* приемосдаточные испытания - "BDD run"
* валидация требований и системы созданной по ним - "Make AutoInstruction"

Сейчас это все делают вручную, и в основном хитрят и пропускают эти этапы.Напомню что всё что вы указали - как раз и сокращает затраты на эти этапы. Потому что они проходят автоматически. Больше могут вам рассказать ребята из КРОКа, если захотят. Насколько я вижу по активности на github - они после практических апрельских занятий внедрили у себя эту технологию.



44. Евгений Мартыненков (JohnyDeath) 05.07.16 22:14
(42) место хранение последних скринов как бы намекает на новую статью в популярном IT-ресурсе. Ждем новых холиваров на другой площадке )
45. Евгений Мартыненков (JohnyDeath) 05.07.16 22:29
Автору большое спасибо за статью. С удовольствием прочитаю и остальные публикации на эту тему.
46. Сергей (Che) Коцюра (CheBurator) 05.07.16 22:51
Бизнес должен дорасти
Когда затраты на поддержание и внедрение этих технологий будуи меньше получаемых в результате профитов - тогда и взлетит

Мне gerkin - по крайней мере то что я посмотрел в вебинарах и статьях типа этой - вызывает крайне положительные чувства, потому что это не протворечит моему чувству прекрасного, а наоборот очень близко к нему.

Но я сейчас пытаюсь представить какую-нибудь задачу из более менее немелких, которую я мог бы запустить по этой технологии и выпадаю в осадок, просто потому что я понимаю что внедрение такой технологии приведет меня к реорганизации всего процесса общения итгруппы и остальных подразделений причем я предвижу что период согласования будет неимоверно удлинен, а период разработки ничуть не меньше. И при этом еще нужно понять нужно ли заказчику качечтво ДЕЙСТВИТЕЛЬНО? Или ему нужно удовлетворение текущих сиюминутных потребностей? Пока вижу в основном второе, и в первую очередь потому сто куча еонтор работает безо всяких стандартов и регламентов. А работать так как в статье - это надо чтобы понимание о необходимости использования стандартов и внятных технологий было не только у меня но и у моих заказчиков-подразделений

Пипл в том числе и злесь испытывает имхо большой скептицизм
Нужен проект доминикана
Реальная задача которая несделана и которая нужна еомуто
И с нуля до финиша - полный реплртаж из лаборатории
Вживую
Дом2 в миниатюре в варианте ФранчТоп или ФрилансГууд

Короче
Чувствую что реально должно быть здорово, но здорово опасаюсь все это припенять на практике
1cWin; MaxDavid; zqzq; alest; Yashazz; genayo; +6 Ответить 1
47. Сергей (Che) Коцюра (CheBurator) 05.07.16 23:07
Я сегодня хорошую девочку до слез довел
Проводили цепочку регламентного процесса от заявки покупателя до реализации и отгрузки со склада только в отличие от реальности прогоняли воздух. Примерно пятьшесть ключевых точек - на каждом бздынь лбом об ошибку/блокировку процесса - потому что то это не выполнено, то это не заполнено И так далее
Я как представлю что у этих людей я буду выпытывать и строитьописывать по gerkin - да меня нахрен пошлют - потому что ответ на каждый вопрос пораждает дветри альтернативы и на каждыую либо надо дать ответ либо поставить блокировку - ибо дырки оставлять нельзя - и мне скажут не сношайте мозг сделайте что нам надо вы что тупой ре можете понять...?

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

Да, если вы конторв работающая по проектам на внешних клиентов - да, можно выставлять клиенту все как есть

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

Короче опять у меня все мутно и непонятно
Неправильные у меня клиенты
И я мутный
Alien_job; +1 Ответить
48. Сергей (Che) Коцюра (CheBurator) 06.07.16 07:28
Вопрос: у вас на проекте человек который ходит по пользователям-заказчикам и пишет с ними на gerkin что хочется получить - это выделенный человека? Он занимается только этим или еще чем-то в рамках проекта?

Если возможно - напишите состав команды проекта и кто какие роли выполняет и какие ресурсы тратит при этом?
49. Геннадий Николаев (genayo) 06.07.16 08:15
(42) Грамотно впариваете, респект.
50. Александр Белов (AlexWhite) 06.07.16 09:52
Спасибо за статью, подпишусь на обсуждение :-)
51. Яков Коган (Yashazz) 06.07.16 10:36
Пруфлинка так и не увидел. Красивые общие слова, элегантное увиливание от конкретики. Делаю вывод: впариваете фуфло и не хотите отвечать за базар.

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

Мутные мы, CheBurator, мутные, что поделаешь. Непроцарапанные. И клиенты у нас тёмные, и сами мы быдлокодеры)

p.s. представил, как я где-нибудь на собеседовании, на вопрос об успешных своих работах, ляпнул бы нечто вроде "ну, я об этом не рассказываю, чтобы вызвать чувство зависти итд". Или на корпоративном сайте, где все нормальные компании гордо публикуют свои достижения, красовалось бы подобное. Смешно, не находите? Смешно и глупо.
52. Геннадий Николаев (genayo) 06.07.16 11:08
Пришла тут одна крамольная мысль - если мы имеем высококлассных руководителей проектов, бизнес-аналитиков, грамотных пользователей, понимающих что и зачем они делают, крутую продвинутую продуктивную методику - нафига тогда 1С?
53. Геннадий Николаев (genayo) 06.07.16 11:15
(51) Ну не надо быть таким категоричным, это не фуфло конечно, вполне приемлемая методика. Просто у этих сильвербуллетных такая манера впаривания оригинальная. Если всю привнесенную ими шелуху отбросить, успешное применение возможно. Другой вопрос, что оценить преимущества над традиционными методиками разработки весьма проблематично на настоящий момент...
54. Dima Neumoichev (Ndochp) 06.07.16 11:16
(43)
Сейчас это все делают вручную, и в основном хитрят и пропускают эти этапы.

Вот, а вы предлагаете не хитрить, и, соответственно стоимость этих этапов увеличить. Плюс еще, чтобы выйти на автоматизацию этих этапов ухнуть кучу ресурсов предварительно.
Если УЖЕ есть БДД и геркин, то при помощи Ванессы можно сократить затраты на эти этапы. А если нету, то переписать ТЗ (а его ведь все равно писать, бумажка с подписью-печатью нужна) в Ванессу это как бы не дороже, чем посадить стажера, чтобы он провел руками один раз все по цепочке делая скриншоты раз в 15 секунд. Вывести это в документ ворд, и дальше приемочные тесты и валидация - головняк и затраты заказчика. (а танцы с Ванессой - наш).

Я понял, что мне напоминает БДД - налоговый учет в чистом виде. Некая альтернативная техническому заданию (БУ ;) система учета (требований к функционалу), которая дает нам упрощение одного из моментов разработки (дает подсчитать налог на прибыль).
Но остальные то моменты сильно проще не становятся. Плюс возникнут ВР и ПР, без них никуда - или что-то реализовано, но нет в фичах (типа обработки замены значения) или описано, но пока там заглушка. И исправлять ее не приоритетно.

В общем, я уже вижу прибыль от хЮнит, но про БДД в условиях плывущих хотелок заказчика в итерационном стиле "ну вы принесите, я посмотрю, скажу что исправить" (причем как интерфейсно, так и алгоритмически) у меня пока сомнения.
55. Яков Коган (Yashazz) 06.07.16 11:25
(53) genayo, это я изобразил нормального руководителя мелкосреднего бизнеса, которому не удалось запудрить мозг эффектными презентациями. Я ведь прекрасно понимаю, что при стечении ряда факторов вышеизложенное превращается в действительно неплохую, местами весьма результативную схему работы с инструментарием. Но выглядит это в большинстве случаев, увы, как впаривание фуфла.
56. Яков Коган (Yashazz) 06.07.16 11:34
(46) CheBurator, мы ведь все помним, чем кончился проект Доминикана))) Ещё "Битву франчайзи" можно)
Целиком согласен с тобой. Есть итеративно выражаемые сиюминутные хотелки, понимания нет и не предвидится.
57. Алексей Лустин (lustin) 06.07.16 12:09
(55) я не знаю кого вы там изобразили, но со словами "фуфло" и "базар" вы можете идти в пешие прогулки. Мир 1С квадратный - я вам напомню эти слова при случае.
58. Алексей Лустин (lustin) 06.07.16 12:12
(54) Ndochp, все инженерные практики - есть ответ на определённую боль. Берёте любую в соответствии с вашей болью. xUnit тоже хорошо.
59. Федор Латыпов (1ceo_2015) 06.07.16 12:52
(51) Yashazz, а что вам впаривают?
Денис CTO во франче. Поделился опытом внедрения технологии. Причем достаточно объективно. И про ириски и про риски написал. Задачи впаривать вам технологию нет. В наших прайсах продажи технологии внедрения по BDD не значится. Писать саксесс стори только для того , чтобы потрясти общественность неинтересно. Кроме того саксесс стори для покупателя она не равна саксесс стори для коллеги по цеху. Для покупателя это отчет о качестве в аллюр весь такой зеленый и красивый, это отчет о количестве ошибок в системе и приятной техподдержке.Это скорость внедрения функционала. И т д.
А для коллег по цеху это совсем другая история: это про шаблоны документации по проекту, это про себестоимость проекта,, это про возможность вернуться к проекту без потери контекста и легко вернуть заказчика в конструктив.
А для программистов , которых хочешь привлечь на работу это третья история. Про то как можно формализовать поток хаоса от заказчика, про то как можно ускорить разработку за счет инженерных практик и т д
Так вам какую историю и зачем? Если есть клиенты и - пишите. С удовольствием присоединимся к продаже со своими историями. Естественно за деньги. Если нужно оптимизировать процессы - это вообще не к нам. Это к консультантам. Если хотите работать у нас по технологии и вам интересно впахивать в три раза больше чтобы научиться новым технологиям и получать удовольствие от создания красивых и функциональных продуктов - рады видеть в команде.

Еще раз повторюсь: сей пост не является рекламой тренингов, продуктов, консалтинга и прочих коммерческих ересей.Это приглашение к объективному обсуждению плюсов и минусов. С серебряными пулеметами 1Сервис дружит. Но проценты от их продаж мы не получаем. Да на многие подходы у нас диаметрально противоположные взгляды. В одном мы сходимся точно - в отрасли бардак и с этим что-то надо делать.
Всем удачи и хорошего остатка рабочего дня ;)
ZOMI; kuntashov; Bronislav; Man4kin; Pr-Mex; JohnyDeath; spogo; Berckk; nixel; lustin; +10 Ответить 1
60. Яков Коган (Yashazz) 06.07.16 13:05
Ну хорошо. Попытаюсь объяснить, почему такие публикации вредны. Потому, что некто, недостаточно полно, точно и глубоко представляющий себе детали (а дьявол именно в них), начитавшись подобного, немедля рванёт это всё внедрять, применять и вообще наносить пользу направо и налево. Само по себе это толково, но любую толковую идею можно изуродовать, в т.ч. буквально-доскональным сверх-старательным применением. И последствия будут ужасны. И разгребать их точно не тому, кто придумал концепт.

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

Автор темы предлагает нам светлое будущее и методы его построения. А я вижу, что практика применения этих методов выглядит как мрачное вчера и безысходное сегодня. С августа 2015 и по сей момент вижу, аккурат последствия следования таким методикам. А учитывая, что сторонники "светлых идей" не приводят ни одной "истории успеха" (спасибо хоть не стремятся причинять добро и горды этим), всё это для подавляющего большинства сообщества должно восприниматься как минимум ооочень скептично.
61. Геннадий Николаев (genayo) 06.07.16 13:28
(59) Ой спасибо, солнцеликие, что снизошли до нас, сирых и убогих. Раз не хотите ничего рассказывать значит так надо, не будем более вас тревожить. Что касаемо впаривания - лучше всего оно работает, когда непонятно, что это впаривание... Да, и к автору статьи вопросов никаких нет, он какраз обещает рассказать историю...
62. Яков Коган (Yashazz) 06.07.16 13:42
Хотя есть и плюсы. Чем больше народу на эти грабли встанет (само или с помощью франчей), тем больше работы разгребать последствия)))
63. Сергей Погодин (spogo) 06.07.16 14:21
(60) Yashazz,
Автор темы предлагает нам светлое будущее и методы его построения.


Читайте прямо, а не по диагонали, автор ничего никому не предлагает, а лишь делится своим опытом и наблюдениями.
herfis; kuntashov; Pr-Mex; JohnyDeath; 1ceo_2015; +5 Ответить
65. Леонид Паутов (Pr-Mex) 06.07.16 15:05
(60) Yashazz, Все эти идеи давно известны, по сто раз применены и разобраны.
TDD известен с начала 2000-х https://ru.wikipedia.org/wiki/%D0%A0%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0­%BA%D0%B0_%D1%87%D0%B5%D1%80%D0%B5%D0%B7_%D1%82%D0%B5%D1%81%­D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5

Первый фреймворк для работы с BDD (Jbehave) вышел почти 10 лет назад http://jbehave.org/reference/stable/release-notes.html

По-моему давно пора признать что QA в 1С нужен также как и в других областях IT. "Бах бах и в продакшен" - устраивает далеко не всех.
66. Rom Shpakoff (Lancelot-2M) 06.07.16 15:15
Какой только ереси не выдумают люди вместо старых добрых технических заданий и технических проектов. Я, конечно, понимаю, что рынок диктует... Но давайте уже различать мелкого клиента с мелкими задачами - для такого и БА не нужен, достаточно только программиста. И крупного богатого клиента с большими запросами, деньгами и сроками - тут уже нужна серьезная документация да с UML и прочими плюшками, а не эти бдды, которые упомянутый юмл не заменят, а время сожрут. Сильвер булет? - не верю! (с)
Светлый ум; dg15000; Yashazz; +3 1 Ответить 3
67. p m (pm74) 06.07.16 15:31
(0) программирование в 1с это , в 90% доработка уже существующего кода и приходится находится в тесных рамках концепции предложенной начальным разработчиком и это накладывает сильные ограничения на всяческие методики
68. Александр Белов (AlexWhite) 06.07.16 16:49
(66) Lancelot-2M,
которые упомянутый юмл не заменят

а как вам упомянутый юмл помогает в проверке, работает ли сдаваемое решение корректно или с ошибками? :-)
1ceo_2015; nixel; +2 Ответить
69. Яков Коган (Yashazz) 06.07.16 17:24
(65) Pr-Mex, давность известности методики ничего не значит. Масса открытий/изобретений сделана существенно раньше, чем обрела практическое применение.
Значимы только опыт применения, желательно успешный, и люди, готовые сами пройти путь от "ясделия" до нормального проекта и продукта. А я за 15 лет наблюдений на эту тему видел только сперва умные рассуждения, а потом в кусты и досвидания. Практика - критерий истины. Нет практики - сами понимаете.
70. Александр Алёхин (new_user) 06.07.16 18:35
(66) Lancelot-2M, вы не знаете ни BDD ни поговорки "о вкусе устриц можно судить только тогда когда их попробуешь". Если что в BDD есть пользовательские истории и сценарии как и в UML.
71. Александр Алёхин (new_user) 06.07.16 18:38
72. Алексей Лустин (lustin) 06.07.16 18:56
(71) И это он еще не знает, что нормальные люди генерируют UML в ТЗ автоматически ;-) по итогам прототипирования - например как тут http://start1c.blogspot.ru/2014/01/uml.html
mickey.1cx; JohnyDeath; +2 Ответить
73. Rom Shpakoff (Lancelot-2M) 06.07.16 21:05
Да, о бдд я сужу только по этой статье - невкусная устрица. Вот пришлют мне такое в разработку (я уж не говорю заставят самому написать) - вот прям комок в горле.
По поводу автогенерации юмл - знаю, генерят и код по схемам и наоборот, но для меня главная ценность в наглядности схем - сдобренная обстоятельным попунктным описанием очень хороша в техпроекте или тз.
А если вспомнить о необходимости тестирования, то мне нравятся сценарии/протоколы тестирования, и я не об автотестах, а о ту-ду и чек-листах.
74. Александр Алёхин (new_user) 06.07.16 21:13
(73) Lancelot-2M, в университете на первом курсе можно рассказывать что ТЗ = Функционал = Ожидания заказчика, но не здесь)
75. Леонид Паутов (Pr-Mex) 06.07.16 21:17
(74) new_user, ТЗ - это Точка Зрения :-)
Alien_job; +1 Ответить
76. Rom Shpakoff (Lancelot-2M) 06.07.16 21:40
А я про это и не рассказываю, я всего лишь о приемлемой лично мне форме постановки задачи) и о неприемлемой)
77. Александр Алёхин (new_user) 06.07.16 22:12
(76) Lancelot-2M, ОК, если ты используешь UML и знаешь BDD только с этой статьи я попробую тебе объяснить. Представьте что кто-то знающий UML прочитал книгу Эванса "Предметно-ориентированное проектирование" и ему понравилась идея что заказчик тоже должен участвовать в процессе и у заказчика и разработчика должен быть единый язык. Потом этот абстрактный кто-то взял из UML пользовательские истории, сценарии и шаги и объединил их с идеями из книги Эванса. Вот тебе и BDD, не верь что тебе не хватит гибкости чтобы понять это, раз ты используешь UML. Чувак, ты как ребенок который боится моря, но когда поймет что это круто за уши не оторвешь) Смелей!))
78. Евгений Мартыненков (JohnyDeath) 06.07.16 22:13
(73) Lancelot-2M,
А если вспомнить о необходимости тестирования, то мне нравятся сценарии/протоколы тестирования, и я не об автотестах, а о ту-ду и чек-листах.

Т.е. после выполнения какой-то задачи вы прогоняете руками весь чек лист.
Потом появляется новая задача и новый чек лист. После окончания выполнения второй задачи вы прогоняете первый и второй чек лист. Так?
И сколько чек листов у вас сейчас для вашей любой конфигурации?
79. Леонид Паутов (Pr-Mex) 06.07.16 22:36
(78) JohnyDeath, Ага, и вдобавок мы вспоминаем что мы всё-таки автоматизаторы и рутину надо автоматизировать. И тут и появляются волшебные буквы CI и CD. Т.е. автоматизация проверки качества (те самые чек листы) и автоматизация развёртывания.
80. Евгений Мартыненков (JohnyDeath) 06.07.16 22:42
(79) Pr-Mex, погоди. Мне интересно как человек вообще это делает, если автотесты ему не нравятся, но нравятся сценарии/чекл-листы/списки.
Скорее всего просто прогоняется одна маленькая выполненная задача вручную единожды при сдаче и забывается. В конфигурациях же нет никаких взаимосвязей между объектами и модулями ;)
81. Rom Shpakoff (Lancelot-2M) 06.07.16 22:44
О, услышали про чек-листы и почему-то вспомнили про цикличность разработки) Лично у меня нет сейчас мегапроектов, а сколько-нибудь сложные задачи я свожу к ту-ду листу и параллельно с разработкой дополняю его чем-то вроде чек-листа - и это не образец работы над большими проектами, но отличие только в том, что соответствующие листы должны быть разработаны кем-то типа БА и включены в тз и техпроект заранее.
И еще - вот в этой статье бдд практически и сведено к совокупности ту-ду и чек-листов, только в форме, которая жрет мой когнитивный ресурс, который я бы предпочел тратить по прямому назначению.
82. Сергей (Che) Коцюра (CheBurator) 07.07.16 01:35
Дайте мне ваши конфиги которые проходят эти все ваши автоматические проверки и чеклисты
Я их на предметном уровне как тупой юзер тыкать буду, есть мнение что будут ломаться Мной на раз
??

У вас на проектах разработки есть люди-тестеры?
83. Rom Shpakoff (Lancelot-2M) 07.07.16 02:41
Да бросьте, все у них работает как надо в энтих конфах, и тесты крутые, тут человекочасы считать нуна. Вот 1С, судя по текстам модулей, не может себе позволить такое количество человекочасов на покрытие конфы авто-тестами, я не могу, вы не можете, а они могут - у них клиенты для этого подходят и это уже успех, но дело тут не в "инженерных методиках"
84. Сергей (Che) Коцюра (CheBurator) 07.07.16 07:25
Несомненно и однозначно что предложенный подход/варинт разработки есть движение в правильном направлении хотя бы потому, что
- стандартизация
- автоматизация проверок/тестирования

Это ведет к основному нужному для ИТкоманды результату: устойчивости системы после внесения очередных измененений. Что надо итшнику? Когда в отпуске в доминикане - чтобы не дергали аааа все сломалось аааа...
85. Сергей (Che) Коцюра (CheBurator) 07.07.16 07:27
Ну а то как вести разработку в условиях мутных заказчиков и постоянного изменения и уточнения требований/хотелок - это отдельная песня

И совершенно четко видно - все меньше и меньше на рынке продаж результата, а все больше и больше продаж процесса достижения результата
86. Сергей (Che) Коцюра (CheBurator) 07.07.16 07:35
И тот кто такой процесс сделает контролируемым, устойчивым - тот и выиграет на рынке наших услуг

А вот будут ли все покупать лексусы, или большинство будет ездить на логанах - это вопрос ценовой ниши, качества, и удобства
87. Евгений Сосна (pumbaE) 07.07.16 09:15
(84) CheBurator, ты не прав, отдыхая в Доминикане тебе говорят
аааа все сломалось аааа...
(от обезъяны с гранатой в рабочей базе, тестовый стенд не спасает) ты по привычке на дряном вайфае быстренько исправляешь и потом начинаешь молится, что-бы теперь другое не сломать ибо чеклисты фиг пройдешь вручную, когда рядом море, пляж и т.д.
88. Яков Коган (Yashazz) 07.07.16 09:52
(86) CheBurator, да брось. Контролируемым и устойчивым процесс делается на 80% совершенно другими средствами - управленческими, организационными. А технически - хоть в экселе на коленке. А если в реальной жизни бедлам, так любой супер-инструмент спокойно кладётся под сукно.
В известных мне компаниях - бардак бардаком, только некоторые при этом ещё делают вид, что работают с соблюдением умных теорий.

На нашем рынке услуг выигрывает не тот, кто делает качественно, а тот, у кого круче связи и блат, больше понтовых бумажек-лицензий-сертификатов, наглее лобби в тендерах, ярче реклама и нахальнее продажники.
Народ, ну вы как с Луны свалились, право слово.
89. Евгений Сосна (pumbaE) 07.07.16 09:58
(88) Yashazz, ну все, скатились в мировой заговор торговцев сертификатами и наглых продажников, не дающим простым парням каждый день топтавщим клавиатуру заработать на лапшу.
new_user; 1ceo_2015; +2 Ответить 1
90. Яков Коган (Yashazz) 07.07.16 10:01
(89) pumbaE, опровергните)))

И да, мне как-то поднадоело, что в компанию приходят шибко продвинутые РП, знающие всякие умные проектные технологии, а потом начинаются проблемы на уровне банальных ТЗ и техпроекта, и эти РП сливаются, а "простым парням" в итоге не хватает на лапшу, не то что на всякие доминиканы.
При этом, каждый новый "умник", конечно, поливает последними словами предшественника, ибо носитель истины известно кто.
CheckContragent; +1 Ответить 2
91. Александр Хомяк (logarifm) 07.07.16 10:14
Сценарии это конечно хорошо, но вот как по мне многие не думают в т.ч. и само 1С разрабатывая интерфейс УТ 11. Исходя из книги "Интерфейс" Джеффа Раскина, есть интересные главы по эфективности интерфейса и примеры расчетов по модели GOMS. К сожалению разработчики в даном случае не учитывают моментов пользователя тех кто будет этим всем пользоваться. И например сколько рядовому пользователю надо времени потратить чтобы завести накладную клиенту, как пользователи теряются постоянно отыскиваю среди всей это купы кнопочок и фишечек то что надо ему ......
1ceo_2015; CheBurator; oleynik.dv; +3 Ответить
92. Евгений Сосна (pumbaE) 07.07.16 10:18
(90) Yashazz, это называется разделение труда, которое уже n тысяч лет как сформировалась в обществе и если вы против этого, то вы асоциальный человек и мне нечего с вами обсуждать, т.к. будете рассказывать как простой крестьянин трудится, в грязи колупается, а аграномы с 4мя курсами образования требуют "ты туда не сади, ты сюда сади" и т.д. и т.п.

p.s.: имхо, комменты можно прекрывать, т.к. скатились во флуд.
93. Rom Shpakoff (Lancelot-2M) 07.07.16 10:34
А еще мне эта тема напомнила методики Рона нашего Хаббарда) особенно язык описания задач и результатов этот. Кстати, знаю одну микроконтору по вэбдизайну, которая по хаббарду работает - печальное зрелище)
94. Яков Коган (Yashazz) 07.07.16 10:51
(92) pumbaE, вот эти агрономы и накомандовали, с поворотом рек, поднятием целины, орошением пустынь и мелиорацией болот. Крестьянин от веку больше понимал в практике, чем десяток агрономов, вместе взятых, так нет, даёшь глобальные проекты переустройства природы. Куда это завело Советский Союз, знающие историю да подскажут.

Троллинг насчёт асоциальности элегантен, но мимо, мимо, ибо слишком толсто)

Прикрывать ли тему - решать модераторам) Хотя я полагаю это не флудом, а концептуальной нестыковкой участников.
95. Сергей (Che) Коцюра (CheBurator) 07.07.16 16:34
(87) угу, именно так ;-) правда последние лет пять таких траблов не случалось, но как-то оно неаккуратненько все равно... ;-)
Поэтому основная фраза когда я в очередной раз линяю: "1. Новых схем не изобретать 2. все что можно отложить до моего возвращения - откладывать".
;-)
96. Сергей (Che) Коцюра (CheBurator) 07.07.16 16:38
(88)
Контролируемым и устойчивым процесс делается на 80% совершенно другими средствами - управленческими, организационными.

- неа, это неправильный подход. то что можно сделать и запилить автоматически - должно быть сделано автоматически. Потому как какие бы ты регламенты-инструкции-меры при РУЧНОЙ работе в условиях кучи альтернатив не принимал - НАКОСЯЧАТ!

другое дело, что я категорически против когда организационно-управленческие проблемы пытаются начинать решать на уровне технологий/автоматизации. не, я такие проблемы тоже решаю - но выкатываю большой ценник.
1ceo_2015; +1 Ответить
97. Сергей (Che) Коцюра (CheBurator) 07.07.16 16:43
(90)
И да, мне как-то поднадоело, что в компанию приходят шибко продвинутые РП, знающие всякие умные проектные технологии, а потом начинаются проблемы на уровне банальных ТЗ и техпроекта, и эти РП сливаются, а "простым парням" в итоге не хватает на лапшу, не то что на всякие доминиканы.


эээ не надо смс-колбасинг рассматирвать как тестинг петтинга!

тут все зависит от личного позиционирования.
когда я в проекте как простой исполнитель - но на меня начинаю неявно спихивать организхационно-управленческие проблемы по проекту - я успешно вежливо посылаю наюг (ввиду личных обстоятельств я могу себе это позволить и нифига не боюсь) и говорю прямым текстом - вы хотите чтобы я решал ПРОБЛЕМЫ - не вопрос - давайте обсудим цену. на этом все кончается. так вот один проект уже года два... тянется...

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

так что - РП тоже непросто - у них свой уровень проблем - главное чтобы каждый занималсмя своим делом...
98. ash (ashvik) 07.07.16 17:58
99. Геннадий Николаев (genayo) 07.07.16 19:38
(97) Вот, в том то и дело, что если в команде сильные специалисты, и каждый занимается своим делом - методология не важна, успех будет. Методология нужна, чтобы со средними исполнителями получать приемлемые результаты...
100. Сергей (Che) Коцюра (CheBurator) 07.07.16 22:01
(99) это еще бабушка надвое сказала
Мне кажется что успех больше зависит от того какие ценности/идеи исповедуют члены команды
Могут быть и сильные специалисты а успех не очень
В сложных проектах имхо большую роль играет координация и управление и здесь тоже в е непросто
1ceo_2015; +1 Ответить
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа