Комментарии 6

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

Красивого ответа на этот вопрос нет, но есть несколько направлений.
1. Упоминание необходимости появления артефакта в Confluence прямо в definition of done задачи. Тут, кажется, понятно какие будут последствия.
2. Документация силами QA: тест-кейсы ведутся в JIRA, там описаны шаги проверки работы с системой, а задачи на интеграционное тестирование слинкованы с jira epic, которые, в свою очередь, завязаны на бизнес-описание в Confluence.
3. Роль технического лидера достается периодически каждому члену команды. Большинство ребят получивших хоть сколько-нибудь крупный проект в свои руки склонны фиксировать в confluence, так как без этого дальнейшее согласование тех.решения и подготовка к нарезке на задачи просто не взлетит. Да и делать code review задач, скажем, по изменению конфигурации какой-нибудь стейт-машины при полном отсутствии диаграмм переходов статусов просто невыносимо.

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

Ну а мотивация писать об инцидентах описана в статье. Когда человек разбужен службой поддержки среди ночи, и понимает, что такой инцидент уже был, а никаких следов он не оставил и не может даже посмотреть, что было причиной в прошлый раз, то ему становится очень, очень обидно. Я сам не раз бывал в такой ситуации, от того и стартовал в свое время историю с ведением таблички вида «какой-мониторинг взорвался — линк на задачу в jira — причина возникновения — линк на репозиторий со скриптами для ремонта / запросы в базу для локализации». Когда такое часто повторяется появляется повод найти root cause и поставить задачу на ремонт.
Интересно про Tech crunches, они периодические или как-то по запросу?
Все кто пришел обязательно должен что-то рассказать или только те у кого что-то интересное?
Есть разные: у некоторых команд они проводятся на регулярной основе, и там идёт обсуждение актуальных проблем по технике, иногда пересмотр приоритетов задач в тех.бэклоге. Такие случаются раз в пару недель.
Есть кранчи ситуационные формата «другие команды набегают в нашу систему с пулл-реквестами, давайте-ка проведем централизованный ликбез по общему устройству и архитектуре».
Есть кейсы формата «я принес в админку проекта Vue, и надо бы поделиться с командой».
А нет такой проблемы, что на Tech crunches приходит слишком много людей и это занимает кучу времени?
Если все пришли послушать одного/двух спикеров, то количество людей слабо влияет на продолжительность, а остатки Q&A всегда можно вынести в кулуары по аналогии с выступлениями на конференциях.
То есть у ситуационных встреч обычно есть понятная тема, список вопросов и в итоге это доклад на 30-40 минут + 20 минут на вопросы и ответы.
У регулярных кранчей по сути формат обычной встречи в календаре: что влезло то и обсудили, но приветствуется наличие заранее составленного плана. Это же касается и прочих встреч вроде ретро и 1-на-1 лидов с разработчиками: если есть регулярная встреча и для неё нет понятного списка топиков, то она может пройти впустую.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.
Информация
Дата основания

5 апреля 2011

Местоположение

Россия

Численность

5 001–10 000 человек

Дата регистрации

20 сентября 2018

Блог на Хабре