Да, это был именно эволюционный путь. Каждый инструмент появился как ответ на конкретные вызовы команды. Расскажу на примерах:
Я начал работать в команде в начале 2022года, тогда было 4 человека (1 middle, 2 frontend + я как аналитик) + PO. В такой маленькой команде всё решалось быстро — собрались на пятиминутный созвон и тут же решили вопрос. Я тогда и аналитику делал, и тестировал, и демо проводил.
Но когда команда начала расти, появились первые сложности. Например, пришел тестировщик — и на первом же демо выяснилось, что функционал немного расходится с требованиями. Потом подключился дизайнер — и оказалось, что стили съехали. Так родилось правило в DoD - "Изменения должны быть протестированы и не ломать существующий функционал (с проверкой аналитика и дизайнера)".
С дейликами тоже вышла интересная история. Сначала мы их проводили в 9 утра или в 9:30(уже не помню), но когда к нам присоединились ребята из других часовых поясов, некоторые пропускали. Чтобы не выяснять причины, на ретроспективе договорились проводить в 11:00. Второй критерий, опоздания на дейлик, иногда можно заработаться и забыть, а почта не включена и уведомление не пришло. Тогда также на ретроспективе договорились сделать бота о напоминаниях и ссылки на онлайн комнату. Также бот не только напоминает о встрече, но и случайно выбирает ведущего — так все остаются вовлеченными.
Большинство этих правил появилось именно так — мы сталкивались с проблемой, обсуждали её на ретро и вместе придумывали решение. Ничего не брали "из книжек" слепо — только то, что реально работало в наших условиях.
Спасибо за вопрос! Действительно, формулировка про "распределение ресурсов" может вызвать недопонимание. Поясню нашу практику:
PO:
Определяет приоритеты и последовательность задач, т.е приносит список задач на планирование.
Утверждает бэклог спринта перед стартом, т.е. могли "перехать" задачи из предыдущего спринта или же лиды направления принесли срочные тех.задачи. Бывают бизнес приоритеты изменяются или требования, которые нужно дополнительно отправить на аналитику. Все финально утверждается PO.
Координирует зависимости между задачами, т.е. последовательность выпуска задач согласно бизнес договоренностям при планировании.
Как я и говорил в статье:
PO не назначает конкретных исполнителей, этим занимается команда на планировании, т.е. любой участник команды может сказать "я хочу взять эту задачу" или же "для тебя есть друга задача она ниже, как ты любишь".
У PO есть свои инструменты, таблицы, графики и тп, но это выходит за рамки статьи и моей экспертизы.
Спасибо за эмоциональный отзыв — вижу, у вас был непростой опыт, и это действительно ценно.
Про «ритуальные пляски» В статье я как раз показываю, как стандартные Agile-практики превращаются в рабочие инструменты — не потому что «так надо», а потому что:
Каждый ритуал (дейли, ретро и т.д.) рождался из реальных проблем нашей команды
Мы в течении многих лет тестировали, отменяли и пересматривали подходы. Я имею ввиду DOR, DOD, ведение встреч и тп.
Сейчас 17 человек работают синхронно без принуждения.
Благодарю вас за пример, однако как мне кажется ключевой вывод другой: проблемы решаются не поиском крайних, а честным разбором причин. Именно для этого мы и используем ретроспективы — чтобы исправлять системные сбои, а не тыкать в конкретных людей.
PO берет задачу в квартал, на планировании spike распределяется на аналитика.
spike задача на аналитика, по решению которой аналитик должен подготовить статью в конфлюенс с подробным алгоритмом разработки для мидл\фронт, примерами запросов на интеграционных стендах, с ТУЗами и тп.
Параллельно дизайнер делает макеты если требуется по задаче. Консультируется и обсуждает клиентские путь в чате дизайна.
На PBR происходит показ подготовленного материала.
Spike не оценивается - задача на исследование, на нее также на доске беклога фиксируем примерное время исполнения.
Похоже на велосипед, зачем придумывать что-то если все уже есть.
Не совсем понятно, зачем создавать отдельное решение
Сейчас многие используют проверенные инструменты для работы с документацией (Markdown, ASCIIDoc), которые легко интегрируются при помощи IDE и Git. Аналитики и так должны быть на одной волне с разработчиками и хранить документацию рядом с кодом.
Похоже, что основная ценность здесь — это красивая обертка над Git для бизнеса, который не знаком с классическими практиками. Хотя перечисленные технологии (OpenAPI, Mermaid, PlantUML, Draw.io) и так входят в стандартный набор многих аналитиков и технических писателей.
Git сам по себе обеспечивает версионность, комментарии, привязку к задачам и многое другое.
Если говорить о бизнесе и ПО, то Confluence уже давно покрывает эти потребности:
Поддержка Markdown (с live-преобразованием),
Десятки макросов для визуализации (диаграммы, таблицы, интерактивные элементы),
Встроенная версионность, интеграция с Jira, гибкие права доступа.
В статье разбираются лишь базовые примеры документации — без сложных вложенностей, условий, перекрёстных ссылок или кастомизированных шаблонов, а как на вашей платформе сделать:
сложные многоуровневые таблицы с разным набором столбцов;
как сделать вложенности в таблицах;
как сделать раскрывающиеся элементы(чтобы не вставлять в текст стать полотно request\response);
как добавить бинарники с версионностью;
как сделать табы на одной странице;
как стилизовать разные элементы;
итп...
Про PlantUML и лишние преобразования
Не совсем понял логику конвертации PlantUML-диаграмм в ваш собственный формат (например, Mermaid). Зачем это нужно, если:
Исходный .puml-файл можно хранить как есть,
При сборке документации рендерить его в нужный формат (SVG/PNG/PDF) — ровно так, как это делают другие генераторы документации .
Сейчас вы добавляете лишний шаг:
PlantUML → ваш формат → финальный рендер.
Это усложняет:
Отладку: как править диаграмму, если она сохранена не в исходном .puml?
Совместимость: как импортировать диаграмму в другие инструменты, если она упакована в ваш формат?
Версионность: diff-ы между версиями становятся нечитаемыми (изменения в бинарном/промежуточном файле vs. чистый текст PlantUML).
Было бы логичнее:
Хранить диаграммы как .puml — это стандарт,
Рендерить их «на лету» при сборке документации.
Или я упускаю какие-то преимущества вашего подхода?
Если говорить из практики, то заметил в вашей статье некоренные решения, а именно:
"публикуются в репозиторий в ветке feature/docs-payment-module ", считаю это неверным, обычно ветки называется фичами(или аналог), потому что добавляет какую-то ценность в продукт, в вашем случае происходит документирование фиче, поэтому правильнее назвать doc/docs-payment-module;
"публикации в master", считаю это неверным, потому что вы не просто добавляете артефакты о документации, вы обновляете приложение, также если потребуется откат фичи которую вы задокументируете, в вашем случае откат доки будет другим pr; поэтому правильнее публиковаться в фича ветку; так же и тестировщики при проверки фичи будут смотреть актуальные изменения; в мастер же обычно публикуют фиксы или техдолги.
Как развернуть платформу?
Было бы полезно увидеть в статье хотя бы схематичное описание:
Какие системные требования
Нужны ли дополнительные сервисы
Есть ли готовые контейнеры (Docker) или развертывание только через ручную сборку
Сейчас это выглядит как «документируйте у нас», но без понимания, сколько ресурсов уйдёт на поддержку самого решения.
Где это уже работает?
Хотелось бы кейсы использования:
Какие компании/проекты внедрили платформу
Какой объем документации она выдерживает (100, 1000, 10 000 страниц)
Были ли проблемы с производительностью при масштабировании
Это добавило бы доверия к инструменту.
Проект интересный, но в статье не хватает конкретики по практическому применению - хотелось бы увидеть примеры реального внедрения и технические требования к развертыванию.
Тем не менее, подход к централизации документации заслуживает внимания - возможно, после доработки платформа действительно упростит жизнь командам, где документирование сейчас организовано плохо.
Главное - продолжать развивать продукт, учитывая обратную связь от реальных пользователей и потребности современных разработческих процессов.
Встроенный AMReminder
Здравствуйте, а есть ли у вас линтеры для проверки структуры или какихто других условий?
Спасибо за вопрос!
Да, это был именно эволюционный путь. Каждый инструмент появился как ответ на конкретные вызовы команды. Расскажу на примерах:
Я начал работать в команде в начале 2022года, тогда было 4 человека (1 middle, 2 frontend + я как аналитик) + PO.
В такой маленькой команде всё решалось быстро — собрались на пятиминутный созвон и тут же решили вопрос. Я тогда и аналитику делал, и тестировал, и демо проводил.
Но когда команда начала расти, появились первые сложности. Например, пришел тестировщик — и на первом же демо выяснилось, что функционал немного расходится с требованиями. Потом подключился дизайнер — и оказалось, что стили съехали. Так родилось правило в DoD - "Изменения должны быть протестированы и не ломать существующий функционал (с проверкой аналитика и дизайнера)".
С дейликами тоже вышла интересная история. Сначала мы их проводили в 9 утра или в 9:30(уже не помню), но когда к нам присоединились ребята из других часовых поясов, некоторые пропускали. Чтобы не выяснять причины, на ретроспективе договорились проводить в 11:00. Второй критерий, опоздания на дейлик, иногда можно заработаться и забыть, а почта не включена и уведомление не пришло. Тогда также на ретроспективе договорились сделать бота о напоминаниях и ссылки на онлайн комнату. Также бот не только напоминает о встрече, но и случайно выбирает ведущего — так все остаются вовлеченными.
Большинство этих правил появилось именно так — мы сталкивались с проблемой, обсуждали её на ретро и вместе придумывали решение. Ничего не брали "из книжек" слепо — только то, что реально работало в наших условиях.
Спасибо за вопрос! Действительно, формулировка про "распределение ресурсов" может вызвать недопонимание. Поясню нашу практику:
PO:
Определяет приоритеты и последовательность задач, т.е приносит список задач на планирование.
Утверждает бэклог спринта перед стартом, т.е. могли "перехать" задачи из предыдущего спринта или же лиды направления принесли срочные тех.задачи. Бывают бизнес приоритеты изменяются или требования, которые нужно дополнительно отправить на аналитику. Все финально утверждается PO.
Координирует зависимости между задачами, т.е. последовательность выпуска задач согласно бизнес договоренностям при планировании.
Как я и говорил в статье:
PO не назначает конкретных исполнителей, этим занимается команда на планировании, т.е. любой участник команды может сказать "я хочу взять эту задачу" или же "для тебя есть друга задача она ниже, как ты любишь".
У PO есть свои инструменты, таблицы, графики и тп, но это выходит за рамки статьи и моей экспертизы.
Спасибо за эмоциональный отзыв — вижу, у вас был непростой опыт, и это действительно ценно.
Про «ритуальные пляски»
В статье я как раз показываю, как стандартные Agile-практики превращаются в рабочие инструменты — не потому что «так надо», а потому что:
Каждый ритуал (дейли, ретро и т.д.) рождался из реальных проблем нашей команды
Мы в течении многих лет тестировали, отменяли и пересматривали подходы. Я имею ввиду DOR, DOD, ведение встреч и тп.
Сейчас 17 человек работают синхронно без принуждения.
Благодарю вас за пример, однако как мне кажется ключевой вывод другой: проблемы решаются не поиском крайних, а честным разбором причин. Именно для этого мы и используем ретроспективы — чтобы исправлять системные сбои, а не тыкать в конкретных людей.
Да, вы абсолютно правы — Spike действительно выпадает из стандартного учёта в story points. Вот как мы с этим работаем:
Пример из практики
Возьмём задачу по переводу приложения на Kubernetes. Такой Spike включает:
Поиск внутренних стандартов компании (инструкций)
Анализ пилотных внедрений (если они были)
Подготовку спецификации для основной задачи (исполнителю)
Как учитываем в capacity
Выделяем под Spike не более 1-2 дней (фиксируем в календаре)
Если Spike сложный — разбиваем на этапы с чёткими критериями завершения
При планировании спринта резервируем 20% времени разработчика на такие исследования
Приоритезация
Если параллельно идут бизнес-задачи — Spike получает статус «Фоновый режим»
Критичные Spike (например, для блокирующих багов) могут временно стать главным фокусом
Спасибо за вопрос.
У нас по процессу как я и описывал.
PO берет задачу в квартал, на планировании spike распределяется на аналитика.
spike задача на аналитика, по решению которой аналитик должен подготовить статью в конфлюенс с подробным алгоритмом разработки для мидл\фронт, примерами запросов на интеграционных стендах, с ТУЗами и тп.
Параллельно дизайнер делает макеты если требуется по задаче. Консультируется и обсуждает клиентские путь в чате дизайна.
На PBR происходит показ подготовленного материала.
Spike не оценивается - задача на исследование, на нее также на доске беклога фиксируем примерное время исполнения.
Здравствуйте, спасибо за комментарий.
Нет, работаем по разному, даже в разных часовых поясах, но например я уже в 9:00 делаю кофе и иду просматривать PR для ревью.
Все очень демократично, рабочий график подстраиваем под себя, но есть договоренность быть на общих встречах.
Интересное приложение, легкое. Чемто похоже на paint.net только чуть продвинутое.
Похоже на велосипед, зачем придумывать что-то если все уже есть.
Не совсем понятно, зачем создавать отдельное решение
Сейчас многие используют проверенные инструменты для работы с документацией (Markdown, ASCIIDoc), которые легко интегрируются при помощи IDE и Git. Аналитики и так должны быть на одной волне с разработчиками и хранить документацию рядом с кодом.
Похоже, что основная ценность здесь — это красивая обертка над Git для бизнеса, который не знаком с классическими практиками. Хотя перечисленные технологии (OpenAPI, Mermaid, PlantUML, Draw.io) и так входят в стандартный набор многих аналитиков и технических писателей.
Git сам по себе обеспечивает версионность, комментарии, привязку к задачам и многое другое.
Пруф1: Пруф2
Если говорить о бизнесе и ПО, то Confluence уже давно покрывает эти потребности:
Поддержка Markdown (с live-преобразованием),
Десятки макросов для визуализации (диаграммы, таблицы, интерактивные элементы),
Встроенная версионность, интеграция с Jira, гибкие права доступа.
В статье разбираются лишь базовые примеры документации — без сложных вложенностей, условий, перекрёстных ссылок или кастомизированных шаблонов, а как на вашей платформе сделать:
сложные многоуровневые таблицы с разным набором столбцов;
как сделать вложенности в таблицах;
как сделать раскрывающиеся элементы(чтобы не вставлять в текст стать полотно request\response);
как добавить бинарники с версионностью;
как сделать табы на одной странице;
как стилизовать разные элементы;
итп...
Про PlantUML и лишние преобразования
Не совсем понял логику конвертации PlantUML-диаграмм в ваш собственный формат (например, Mermaid). Зачем это нужно, если:
Исходный
.puml-файл можно хранить как есть,При сборке документации рендерить его в нужный формат (SVG/PNG/PDF) — ровно так, как это делают другие генераторы документации .
Сейчас вы добавляете лишний шаг:
PlantUML → ваш формат → финальный рендер.
Это усложняет:
Отладку: как править диаграмму, если она сохранена не в исходном
.puml?Совместимость: как импортировать диаграмму в другие инструменты, если она упакована в ваш формат?
Версионность: diff-ы между версиями становятся нечитаемыми (изменения в бинарном/промежуточном файле vs. чистый текст PlantUML).
Было бы логичнее:
Хранить диаграммы как
.puml— это стандарт,Рендерить их «на лету» при сборке документации.
Или я упускаю какие-то преимущества вашего подхода?
Если говорить из практики, то заметил в вашей статье некоренные решения, а именно:
"публикуются в репозиторий в ветке
feature/docs-payment-module", считаю это неверным, обычно ветки называется фичами(или аналог), потому что добавляет какую-то ценность в продукт, в вашем случае происходит документирование фиче, поэтому правильнее назватьdoc/docs-payment-module;"публикации в
master", считаю это неверным, потому что вы не просто добавляете артефакты о документации, вы обновляете приложение, также если потребуется откат фичи которую вы задокументируете, в вашем случае откат доки будет другим pr; поэтому правильнее публиковаться в фича ветку; так же и тестировщики при проверки фичи будут смотреть актуальные изменения; в мастер же обычно публикуют фиксы или техдолги.Как развернуть платформу?
Было бы полезно увидеть в статье хотя бы схематичное описание:
Какие системные требования
Нужны ли дополнительные сервисы
Есть ли готовые контейнеры (Docker) или развертывание только через ручную сборку
Сейчас это выглядит как «документируйте у нас», но без понимания, сколько ресурсов уйдёт на поддержку самого решения.
Где это уже работает?
Хотелось бы кейсы использования:
Какие компании/проекты внедрили платформу
Какой объем документации она выдерживает (100, 1000, 10 000 страниц)
Были ли проблемы с производительностью при масштабировании
Это добавило бы доверия к инструменту.
Проект интересный, но в статье не хватает конкретики по практическому применению - хотелось бы увидеть примеры реального внедрения и технические требования к развертыванию.
Тем не менее, подход к централизации документации заслуживает внимания - возможно, после доработки платформа действительно упростит жизнь командам, где документирование сейчас организовано плохо.
Главное - продолжать развивать продукт, учитывая обратную связь от реальных пользователей и потребности современных разработческих процессов.