Визуализация фич Vanessa Automation в StoryMapper

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

Методология - Методология управления разработкой - Agile (XP, SCRUM, Канбан)

bdd VA StoryMapper

Описан процесс визуального упорядочивания коллекции feature-файлов в виде карты пользовательских историй. Используется инструмент гибкого управления требованиями StoryMapper.

Введение

Те, кто следит за развитием проекта Vanessa Automation, могли заметить, что в релизе 1.2.030 появились изменения в feature-файлах, связанные с задачей "Адаптация feature-файлов проекта VA для использования в StoryMapper". В своём большинстве эти изменения такого вида:

Закономерный вопрос: что это за теги и зачем они нужны?

В наших предыдущих статьях ([1], [2]) упоминался StoryMapper - инструмент для организации feature-файлов в виде карты пользовательских историй. В статье [2] он использовался для организации разработки по методике BDDSM, в [1] предлагалось использовать его для упорядочивания своего репозитория feature-файлов. В этой статье мы хотим продемонстрировать, как можно использовать StoryMapper для упорядочивания ваших фич, так чтобы их было удобно и наглядно демонстрировать вашему руководству или стейкхолдерам.

По согласованию с @Pr-Mex (aka Леонид Паутов) мы решили провести такое упорядочивание на примере очень большой коллекции feature-файлов (порядка 700) из ветки develop репозитория Vanessa Automation. Цель данного действия: визуализировать и тем самым повысить прозрачность и понимание того, как работает Vanessa Automation. На сегодняшний день feature-файлы VA распределены по тематическим папкам, но их распределение носит отражение технического подхода к их написанию (регрессионное тестирование), а не точки зрения пользователя или возможного нового контрибьютора. Составление карты историй позволит поменять перспективу рассмотрения feature-файлов и взглянуть на них под пользовательским углом.

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

 

Выбор UF

Первый этап упорядочивания - это составление скелета карты пользовательских историй. Скелет в StoryMapper состоит из двух уровней: UF (Usage Flow) и UA  (User acivity). Верхний уровень - это некие крупные блоки пользовательской активности, которые мы ожидаем от продукта. В случае VA и её feature-файлов нужно понимать, что не все фичи относятся к пользовательской активности по своей техногенной сущности, соответственно и UF будут не всегда о пользователях.

Итак, мы выделили ряд UF, которые описывают пользовательский опыт взаимодействия с VA, другие, в которых будут содержаться фичи с библиотечными шагами и с особенностями реализации Gherkin, вспомогательные технические фичи, которые в VA используются как макеты данных для учётных задач (данные для тестирования), и отдельный UF для (пока) неклассифицированных фич.

Напомню, что в самом начале процесса все фичи репозитория будут лежать в первой колонке под UF0 - поскольку они ещё ни к чему не привязаны.

 

Составление UA

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

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

 

Разнесение фич под UA

Из предыдущего раздела уже понятно, что UA формировались по ходу разнесения фич. Основная цель, которую мы преследовали на первом этапе - это сделать так, чтобы под UF0 не осталось ни одной фичи. Чтобы все они стали классифицированными, а  уж потом можно переподчинять их согласно реальному предназначению. То есть к текущей версии карты пользовательских историй я пришёл за 4 итерации упорядочивания. Во-первых, вынес все фичи из-под UF0, во-вторых, отделил реальные фичи от служебных, которые используются как макеты, в-третьих, пересмотрел подчинённость фич пользовательским активностям, и в-четвёртых, получил результаты выполнения сценариев и, соответственно, увидев те фичи, которые реально выполняются на CI-контуре, убрал вспомогательные фичи с экспортными сценариями в "UF11 Прочее".

Конечно, не обошлось без трудностей. Надо понимать, что StoryMapper работая с feature-файлами, ориентирован не на название файла, а на название фичи, то есть тот текст, который идёт после ключевого слова "Функционал/Функция". Поскольку за уникальностью этого значение в репозитории никто не следил (а за неимением соответствующего инструментария это делать достаточно проблематично) получались ситуации, когда фича вроде бы уносилась из-под UF0, но после отправки изменений в git - возвращалась обратно. В результате пришлось провести работу по унификации названий фич, что на текущем этапе вылилось в добавление цифр в конце названия. В дальнейшем нужно будет либо слить эти фичи в одну, либо дать им более осмысленное название.

 

Отображение результатов выполнения сценариев

Что ещё интересного есть в StoryMapper, кроме карты пользовательских историй. Цифры в правом нижнем углу показывают количество выполненных сценариев. Поскольку в VA всё фичи зелёные (а разве бывает по-другому?) - то и на карте мы видим только цифры на зелёном фоне. Если бы сценарии падали, или у них были бы не реализованные шаги - то эти цифры также отобразились бы на карте на красном или сиреневом фоне соответственно. Данные о результатах выполнения сценариев берутся из json-файла c результатами выполнения в формате Cucumber. Сопоставление идёт по названию фич и сценариев.

Также в StoryMapper можно увидеть и результаты выполнения сценариев в формате Allure (без необходимости ходить на CI-сервер, либо публиковать результаты каким-то иным образом), что позволяет исследовать результаты выполнения до шагов, а также анализировать скрин-шоты в случае падения того или иного сценария.

Отправка результатов сборок формата Cucumber и Allure в Storymapper осуществляется POST-запросом. На сейчас я взял у Леонида json-файлы после очередной сборки и отправил их вручную. Если к инструменту будет проявлен интерес, и им будут пользоваться на постоянной основе, то можно будет вставить запрос по отправке результатов в сборочную линию VA и результаты выполнения сценариев в StoryMapper будут актуализироваться автоматически.

Также в StoryMapper есть полезная функция по выгрузке результата упорядочивания в Excel, выстраивающая табличную иерархию UF->UA->US->Сценарий.

 

Доступы к StoryMapper

Все манипуляции с feature-файлами происходили в моём форке VA, после очередной итерации я создавал pull-request, разрешал конфликты, VACIbot запускал автотесты - и после удачного прохождения тестов изменения по фичам попадали в ветку develop основного репозитория VA. Ветка develop основного репозитория также подключена к StoryMapper, но в режиме "только чтение". Всем желающим посмотреть на фичи VA под другим углом - добро пожаловать:

URLhttps://app.checkushka.com/storymapper/VAdevelop/

login: VA_user

password: BDDSM2020

 

Ссылки:

  1. Полевые исследования концепции «Documentation as code»
  2. BDDSM-практики, или 50 оттенков желтого

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

Комментарии
В избранное Подписаться на ответы Сортировка: Дата
7. oleynik.dv 152 22.03.20 20:40 Сейчас в теме
(2) в принципе Фёдор уже всё ответил, но я прокомментирую по поводу общего коммита.


В целом, сейчас практикуется такая схема. От общей ветки разработки выделяется ветка для StoryMapper, с которой работает бизнес-аналитик. Последовательность его действий следующая:

1. В StoryMapper он жмёт кнопку Download (эквивалент git pull). При этом все локальные изменения в проекте StoryMapper затираются текущим состоянием ветки в "центральном" репозитории.
2. Бизнес-аналитик работает с картой историй. Создаёт/удаляет/перемещает UF/UA/US, возможно в редакторе StoryMapper вносит изменения непосредственно в фичи.
3. Нажимает кнопку Upload и вводит сообщение коммита. Выполняются команды git add, commit, push. Изменения уходят в "центральный" репозиторий.
4. В клиенте git на рабочей машине выполняет git pull и получает изменения, выполненные в StoryMapper.
5. Работает с фичами в VSC, Sublime, Notepad++, и отправляет изменения в "центральный" репозиторий.
6. При необходимости внести изменения в карту историй возвр. к п.0.
7. Когда доходит до промежуточного результата - мёрджит свою ветку с основной веткой разработки.

Вы можете зарегистрироваться по ссылке https://app.checkushka.com/register.php, и я вам подключу демо-проект, связанный с репозиторием на гитхабе. Там можно будет пощёлкать, потаскать и посмотреть на коммиты в гитхабе.
Vladimir Litvinenko; +1 Ответить
6. 1ceo_2015 22.03.20 19:12 Сейчас в теме
(5)
(5)
Часто даже работа ведётся с неверсионируемыми Word-документами или в неком подобии 1С:Документооборота, что создаёт понятные проблемы.


storymapper собственно и создавался как средство структурирования произвольной документации заказчика в критерии приемки функционала.

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


(5)
Вот например этот момент тоже можно было бы осветить.


Если совсем коротко description эпика:

как заказчик я хочу улучшить UF (критерии успешности которого у меня уже прописаны и измеряются) до таких-то показателей.

ну и исходя из этого формируем список изменений Критериев Приемки (они же сценарии) или добавляем новые. В конце итерации смотрим на изменение показателей. и делаем новые гипотезы о развитии компании.
5. Vladimir Litvinenko 2532 22.03.20 18:44 Сейчас в теме
(3)
Спасибо за ответы. Действительно интересно.
Будет интересно - можем сделать демо или вебинар по методике.

Думаю для этого нужно собрать большее количество интересующихся темой. Жаль, что публикация вышла в выходные, из-за этого она может не привлечь достаточное внимание коллег. Демо наверное не стоит - это лучше для заказчиков/покупателей системы )) А вот вебинар именно по методике фиксации и структурированию задач, особенно в связке с Jira, я бы с удовольствием послушал и на платной основе.

Понимание как это делать правильно может впоследствии от многих граблей избавить. Да про методику, упрощающую BDD, было бы полезно больше узнать.
Естественно это требует изменения способа работы с заказчиком и требованиями и не со всеми это удается сделать.

Вот например этот момент тоже можно было бы осветить. Границы применимости.

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

То есть интересен вопрос не только границ применимости с заказчиком, но и процесса перехода к этим подходам самой команды разработки/проектной команды.
3. 1ceo_2015 22.03.20 13:39 Сейчас в теме
(2)
Вот если можно было отредактировать несколько фич, а потом разом сделать коммит - это было бы классно. Но в этом случае что делать в случае конфликта? Кажется что в этом случае имеет смысл связывать StoryMapper с неким "локальным" репозиторием.


Так и сделано. Просто у вас доступ readonly.



Соответственно связь изменения репозитория требований к программному продукту с задачами на изменение программного продукта в жире есть (если в коммите указать номер задачи - он появится в этой задаче и в битбакете)



Таким образом можно увидеть список задач и их статус в связке с фиче-файлами репозитория требований к проекту.

Возвращаясь к первому вопросу про более сложные конструкции связей систем управления требованиями и систем управления задачами. Если коротко: такие штуки сложно поддерживать.
Связки Epic - UA US-story использовались нами еще со времен использования Speclog в качестве базовой системы накопления требований. Красиво и прозрачно на первой стадии проекта, страшно и криво на последующих стадиях)). Да и смысл связки сомнителен по причине отсутствия в ней бизнес-целей. Для них приходится городить более высокий уровень абстракции.

Мы используем (и настойчиво рекомендуем остальным на проектах внедрения Jira+StoryMapper) следующую конструкцию: Epic для фиксации бизнес-целей и задачи типа баг и стори в эпике для декомпозиции на понятные для команды разработчиков объемы работы.
Это позволяет привлечь бизнес к структурированию и работе с требованиями, ускорить поставку бизнес-ценности и избежать выполнения ненужной работы.
Естественно это требует изменения способа работы с заказчиком и требованиями и не со всеми это удается сделать.
Такая связка позволяет реверс-инжинирингом собрать разрозненные таски в один бизнес-проект с понятными бизнес метриками. StoryMapper в таком случае выступает пространством для общения бизнес-заказчиков и разработчиков.
На самом деле это тема для отдельной статьи или даже цикла. В рамках комментария описать такое сложно. Будет интересно - можем сделать демо или вебинар по методике.
Прикрепленные файлы:
Vladimir Litvinenko; +1 Ответить 1
2. Vladimir Litvinenko 2532 21.03.20 23:47 Сейчас в теме

Вот это красота! Да и не только красота, но и удобство. Как минимум для просмотра и навигации.

В статье Полевые исследования концепции «Documentation as code» одним из направлений развития указано
какая-то интеграция с Jira

Интересно, получилось что-то в этом направлении?

Разделение действительно очень напоминает иерархию/декомпозицию в Jira на проекты, эпики и истории.
Здесь могла бы быть связь UA или UF = эпик, фича = история. Или UF = эпик, UA = история, фича = подзадача. Что больше бы подошло для ситуации, когда по одной истории происходят уточнения и доработки реализуются через отдельные задачи и подзадачи. Для каждого проекта или продукта могла бы быть отдельная страница в StoryMapper. То есть напрашивается ещё один уровень абстракции/организации - "продукты" или "проекты". Так понимаю сейчас это уже реализовано за счет разделения на отдельные подкаталоги для разных проектов вроде storymapper/VAdevelop.

По юзабилити инструмента:
Кажется было бы удобно, если бы окно View/Edit можно было закрывать по клавише Esc. Для закрытия окна реализовано аж два элемента - крестик справа вверху и кнопка Close справа внизу. Но при последовательном просмотре множества фич оба варианта одинаково неудобны - далеко тянуться мышкой и целиться. На автомате рука несколько раз нажимала клавишу Esc, которая сейчас ничего не делает.


Также интересно помещение изменений в репозиторий. Согласно той же схеме в статье на Хабре StoryMapper связан с гит-репозиторием двунаправленно.


То есть в ряде случаев предполагается редактирование фич прямо через него, также как и через Visual Studio Code. Но в таком случае как происходит коммит?

В Visual Studio Code коммит можно сделать согласованно - после согласованного изменения нескольких фич, или например фичи и экспортного сценария, от которого она зависит. А как здесь при работе через веб-интерфейс? Ведь в этом случае при закрытии окна изменения надо сохранить, прежде чем переходить к другой фиче. И судя по всему в этом случае изменение должно приводить к отдельному коммиту. Удобно и правильно ли это?

Вот если можно было отредактировать несколько фич, а потом разом сделать коммит - это было бы классно. Но в этом случае что делать в случае конфликта? Кажется что в этом случае имеет смысл связывать StoryMapper с неким "локальным" репозиторием. А в случае возникновения конфликта предлагать перейти к нему и вручную разрешить возникшие противоречия.

Или я слишком заморачиваюсь и продукт пока далёк от использования в такой роли?
1. Pr-Mex 130 21.03.20 15:25 Сейчас в теме
Интересно про реверс инжиниринг активностей пользователя.
Vladimir Litvinenko; 1ceo_2015; +2 Ответить
Оставьте свое сообщение

См. также

Самые честные истории про внедрение Agile на практике

Agile (XP, SCRUM, Канбан) Бесплатно (free)

Есть сообщество в Facebook'е и Инстаграм, которое публикует жизненные комиксы про внедрение гибких технологий на практике - Comic Agile.

01.04.2021    2022    MariaTemchina    17    

Ищем паттерны в сценарных тестах. Практика - Фреймворк Тестирование 3.0

Тестирование и исправление Сценарное тестирование Бесплатно (free)

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

29.03.2021    758    ivanov660    0    

Hello world в Vanessa-ADD bddRunner

Сценарное тестирование v8 Бесплатно (free)

Минимальный пример на Vanessa-ADD bddRunner без теории. При написании использовались: 1С 8.3.10.2753, Vanessa add 6.6.5.

24.02.2021    440    kirinalex    0    

Как бороться с соблазном объять необъятное, или Канбан-система в проектах 1С

Agile (XP, SCRUM, Канбан) Бесплатно (free)

На первом онлайн-митапе в Санкт-Петербурге Мария Темчина рассказала участникам митапа о принципах работы Канбан-системы в проектах 1С. Как выбрать инструмент для работы по Канбану, с чего начать при внедрении, и какие игры помогут освоить эту систему.

12.02.2021    2259    MariaTemchina    17    

Практика применения DevOps. Тестирование

DevOps Сценарное тестирование Vanessa Automation СППР v8 1cv8.cf Бесплатно (free)

В третьей части мастер-класса «Практика применения DevOps» на конференции Infostart Event 2019 Inception выступила Светлана Попова. Она рассмотрела возможности использования двух инструментов тестирования от фирмы «1С» – «Сценарного тестирования» и связки СППР и Vanessa Automation, и рассказала про плюсы и минусы каждого из этих вариантов.

11.12.2020    3160    SvVik    0    

Что почитать про Agile для чайников?

Управление проектом Agile (XP, SCRUM, Канбан) Бесплатно (free)

Продолжаю рубрику “Письма в редакцию”. Ко мне иногда обращаются с вопросом - вот, я, мол, совсем не представляю, что такое Agile…

03.12.2020    3315    MariaTemchina    9    

Управление в стиле Agile. Как создать самоуправляемую команду в ИТ проекте

Agile (XP, SCRUM, Канбан) Автоматизация ИТ-компании Бесплатно (free)

Про Agile только на конференциях Инфостарта сказано уже так много, что, кажется, сложно кого-то удивить. Но руководителю компании Rodionov consulting Денису Родионову это удалось, потому что он в своем докладе на Infostart Event 2019 Inception рассказал не только сухую теорию, но и примеры из собственной практики.

25.09.2020    2252    denislan    0    

Стыд и Скрам: взгляд глазами собственника из IT-шников

Управление проектом Agile (XP, SCRUM, Канбан) 1С:Франчайзи, автоматизация бизнеса Бесплатно (free)

Не все, кто употребляют понятия Agile и Scrum, понимают, что они означают. О том, насколько в реальном мире автоматизации бизнеса на платформе 1С применимы гибкие подходы к разработке ИТ-продуктов на конференции Infostart Event 2019 рассказал основатель и соучредитель группы компаний WiseAdvice Иван Тягунов.

18.09.2020    3147    IvanAT1981    3    

Тестирование серверного поведения с Vanessa Automation

Vanessa Automation v8 Бесплатно (free)

Обзор модуля "ИнициаторДанных" (версия VA 1.2.034), пример скрипта

14.09.2020    1696    unichkin    14    

Интеграция с Трелло. Готовый код

Обмен данными 1С Интеграция Agile (XP, SCRUM, Канбан) v8 Бесплатно (free)

Код основных действий, интеграция с API Трелло.

19.08.2020    3637    Yashazz    14    

Придет владелец продукта и решит все вопросы бизнеса!

Agile (XP, SCRUM, Канбан) Бесплатно (free)

Практически во всех крупных проектах есть отдельная роль – владелец продукта. Все чаще ее выполняют аналитик либо представители бизнеса, но насколько эффективно они работают, мало, кто задумывается. О том, что должен делать Product Owner, и какие ошибки чаще всего совершают такие специалисты, на конференции Infostart Event 2019 Inception рассказал управляющий партнер и Agile Coach компании Scrumtrek Иван Селеверстов.

24.07.2020    3158    iseleverstov    0    

Vanessa, видеоинструкции для web-клиента

Vanessa Automation v8 1cv8.cf Бесплатно (free)

Vanessa-Automation. Использование видеоинструкций в web-клиенте.

01.06.2020    3107    SvVik    1    

Молчание "best practices": тестовые и эталонные данные, структура и связность, падения и новая функциональность, и другие неудобные вопросы к сценарному тестированию

Рефакторинг и качество кода Сценарное тестирование v8 Бесплатно (free)

Непонимание некоторых базовых вопросов мешает программистам начать применять инструменты тестирования в процессе разработки для 1С. Как разобраться в терминологии и интегрировать процесс тестирования в разработку 1С-решений на конференции Infostart Event 2019 Inception рассказал руководитель отдела разработки компании C.T.Consultants Решитко Дмитрий.

29.05.2020    4628    grumagargler    14    

Почему Scrum не работает в проектах 1С

Управление проектом Agile (XP, SCRUM, Канбан) Бесплатно (free)

Более точная формулировка заголовка, пожалуй будет такой -  Почему Scrum в чистом виде плохо работает в проектах внедрения продуктов 1С.

18.05.2020    11753    MariaTemchina    33    

Тестирование: Отлаживаем и тестируем REST интерфейс 1С с помощью SoapUI

Сценарное тестирование v8 Бесплатно (free)

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

03.02.2020    5989    ivanov660    4    

BDDSM-практики, или 50 оттенков желтого

Методология управления разработкой Vanessa Automation ИТ-компания 1С:Франчайзи, автоматизация бизнеса Бесплатно (free)

В статье описаны практические результаты применения методики BDDSM на отдельно взятом РЕАЛЬНОМ проекте поддержки.

26.12.2019    9655    Mistress_A    28    

Vanessa Automation + СППР

Vanessa Automation СППР v8 Бесплатно (free)

Vanessa Automation. Использование автоматизированного тестирования в СППР.

07.11.2019    14308    SvVik    14    

Vanessa, улучшаем инструкции

Vanessa Automation v8 1cv8.cf Бесплатно (free)

Vanessa Automation умеет делать хорошие инструкции, давайте посмотрим, какие инструменты для этого есть.

30.10.2019    10391    OPM    12    

Vanessa, хочу все и сразу

Vanessa Automation v8 Бесплатно (free)

Vanessa Automation это инструмент для тестирования прикладных решений на платформе 1С, но он/она может больше, чем только тестирование.

11.10.2019    12149    OPM    36    

Agile в проектах 1С: где-то между невозможно и неизбежно. Часть вторая

Управление проектом Agile (XP, SCRUM, Канбан) Бесплатно (free)

Некоторое время назад я публиковала статью, где начала разбираться, что следует из Agile-манифеста на практике, и каковы сильные и слабые стороны происходящего. В одну статью всё не поместилось, и сегодня попробую закончить эту тему. 

06.09.2019    6422    MariaTemchina    10    

Agile в ИТ-проектах: где-то между невозможно и неизбежно

Управление проектом Agile (XP, SCRUM, Канбан) Бесплатно (free)

Приглашаем к дискуссии по мотивам прошедшего вебинара на тему "Agile и не Agile"

15.08.2019    7321    MariaTemchina    40    

Scrum: серебряной пули не существует

Управление проектом Agile (XP, SCRUM, Канбан) Бесплатно (free)

Гибкие методологии набирают популярность среди команд разработчиков. Но применять их в том варианте, который предлагается первоначально, не всегда удается. О своем опыте работы по Scrum в условиях, когда нет проектов, рассказал на конференции Infostart Event 2018 Education ведущий разработчик 1С одной из крупнейших торговых сетей Дмитрий Кирилкин.

12.08.2019    5719    dumsik    7    

Как стать контрибьютором Vanessa Automation?

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

Краткая инструкция о том, как помочь проекту VA

15.07.2019    7221    fenixnow    43    

Стыд и Скрам, часть вторая

Управление проектом Agile (XP, SCRUM, Канбан) Бесплатно (free)

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

14.03.2019    12082    MariaTemchina    47    

Разработка и сценарное тестирование с Vanessa-ADD. Отчетность Allure. Автоматизация запуска сценариев

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

Формируем отчетность о результатах выполнения сценариев. Автоматизируем запуск.

26.02.2019    24964    Vladimir Litvinenko    28    

Стыд и скрам - Чему нас учит Scream Guide

Управление проектом Agile (XP, SCRUM, Канбан) Бесплатно (free)

Название "Scream Guide" можно вольно перевести на русский как “Вопль ужаса от того, как Scrum применяют на практике”

12.02.2019    10804    MariaTemchina    20    

Подходы к управлению проектами: границы применимости гибких методологий в проектах внедрения

Управление проектом Waterflow Итеративный подход Agile (XP, SCRUM, Канбан) Бесплатно (free)

В своем докладе Мария Темчина подробно рассказала про то, какие подходы к управлению проектами вообще бывают с точки зрения Project Management Institute, и какие из них применимы при руководстве проектами внедрения 1С.

21.01.2019    9013    MariaTemchina    0    

Разработка и сценарное тестирование с Vanessa-ADD. Установка инструментов. Запись действий пользователя и выполнение сценариев

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

Вторая часть цикла публикаций, посвященных Vanessa-ADD и автоматизации тестирования.

21.01.2019    42844    Vladimir Litvinenko    97    

Черная книга Скрам

Управление проектом Agile (XP, SCRUM, Канбан) Бесплатно (free)

Наблюдения менеджера, разрушившего карьеру бездумным применением Скрам. Рекомендации и предостережения.

26.11.2018    8749    Selikhovkin    4    

[Заметки] Scrum за 5 минут

Agile (XP, SCRUM, Канбан) Бесплатно (free)

Первый опыт создания статьи в сообществе. Немного о Scrum и нашем знакомстве.

20.11.2018    9413    leobrn    11    

Думать некогда, трясти надо - или что такое ретроспектива в Agile

Управление проектом Agile (XP, SCRUM, Канбан) Бесплатно (free)

12-ый принцип Agile-манифеста, как известно, гласит: "Каждый раз в конце заранее определенного интервала времени команда размышляет, как повысить результативность своей работы, и затем вносит коррективы в процессы." Попробуем разобраться, как это стоит, а как не стоит делать на практике. 

13.11.2018    11005    MariaTemchina    16    

Приоритизировали, приоритизировали, да не выприоритизировали...

Управление проектом Agile (XP, SCRUM, Канбан) Бесплатно (free)

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

30.10.2018    8594    MariaTemchina    47    

Построение высокоэффективной Agile-команды

Управление проектом Управление командой Agile (XP, SCRUM, Канбан) Бесплатно (free)

Меня зовут Асхат Уразбаев, я из компании ScrumTrek. Наша компания помогает внедрять Agile, Scrum, Kanban – гибкие методологии и гибкие подходы. К миру 1С я совсем не принадлежу, но в прошлом я, тем не менее, программист – занимался разработкой на самых разных языках программирования. Помимо основной деятельности у меня было несколько технологических стартапов, в которые я был так или иначе вовлечен. И сегодня мы поговорим о том, как сделать так, чтобы команда была крутой и эффективной.

08.10.2018    8112    askhatu    15    

Канбан в условиях российской действительности

Управление бизнес-процессами (BPM) Управление проектом Agile (XP, SCRUM, Канбан) Россия Бесплатно (free)

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

08.08.2018    25379    MariaTemchina    64    

Почему Agile превращается в Тяп-ляп. Кто виноват и что делать?

Управление проектом Agile (XP, SCRUM, Канбан) Бесплатно (free)

В моей практике довольно много историй, когда компании, решившие внедрять гибкие методологии, начинали за здравие (Agile), а кончали за упокой - Do & Fix (делаем, как бог на душу положит). Попробуем разобраться, почему так происходит.

27.07.2018    13852    MariaTemchina    20    

Можно ли объять необъятное или чем Agile отличается от водопада?

Управление проектом Waterflow Agile (XP, SCRUM, Канбан) Бесплатно (free)

Что общего между управлением парусной яхтой и проектом по внедрению ERP-системы на предприятии? В данной статье я постаралась понятным языком описать разные подходы к проектному управлению, и разобраться при каких условиях та или иная методология может быть полезной при реализации проектов.

23.07.2018    13370    MariaTemchina    43    

Применение Agile-технологий в проектах 1С

Управление проектом Agile (XP, SCRUM, Канбан) Бесплатно (free)

Agile – это одна из методик ведения проектов. О ее практическом применении в проектах 1С пойдет речь в статье.

25.07.2017    18804    kondrat230386    35