Верно, нагрузка возрастет, но не значительно. Из моего опыта: за внедрение, ведение и актуализацию обычно отвечают 1—3 человек (в зависимости от размера команды). Если у вас такая небольшая команда, думаю ведение документации может быть не особо необходимым, но да — всё зависит от специфики проекта.
Если прочитать статью, можно заметить такие моменты:
Сопротивление команды ... Не всем членам команды нужно писать ADR, только опытным разрабам, за которыми и стоит окончательные решения... показать реальные преимущества, начать с малого, использовать простой шаблон
---
Осознанное применение ... Важно применять ADR осознанно, избегая превращения его в бюрократическую обязанность для всех членов команды.
---
Перегрузка информацией ... Документировать только главные / важные / основные решения
Я понимаю ваши опасения по поводу возможной бюрократии при внедрении ADR и усложнения работы команде и прошу в статье учитывать это. Цель этого процесса — облегчить в результате работу команды, а не усложнить её.
Спасибо за ваш отзыв и интересный комментарий! Вы подняли очень важные вопросы.
Но поразило, что это делал не менеджер, А САМ РАЗРАБОТЧИК. Что делал менеджер???
Действительно, акцент в статье сделан на действиях разработчика и некоторые моменты могут быть "притянуты за уши". Возможно, создается впечатление, что ответственность (как минимум за анализ) перекладывается на разработчика. К тому же пример выбран не в пользу собирательного образа менеджера :)
С другой стороны в реальности у нас могут быть такие ситуации:
Нет аналитиков: В небольших командах (или где не принято "держать" аналитиков) сотрудники часто берут на себя дополнительные роли (что не обязательно плохо, об этом ниже). Т.е. нет людей, которые могут до начала реализации точно просчитать что и как будет работать и к чему это приведет.
Технический контекст: Когда задача требует глубокого понимания технических деталей, вклад разработчика в анализ и планирование может быть неоценим.
Продуктовое мышление: Поощряется, когда разработчики думают не только о коде, но и о влиянии своей работы на пользователей и бизнес.
Декомпозиция и оценка: Технические нюансы сильно влияют на структуру задачи и время её выполнения. Вряд ли менеджер сможет с высокой точностью выполнить это без мнения разработчика.
Это не означает, что менеджер не выполняет свою работу. Скорее, это пример тесного сотрудничества, где каждый вносит свой вклад согласно своим сильным сторонам.
И конечно, самое главное правило - система должна быть продана в команде, и использоваться всеми без исключения. Если кто-то не следует правилам - страдает вся система.
Полностью согласен. Эффективность любой системы зависит от последовательности её применения всей командой. При этом даже если не все готовы принять такой подход целиком, отдельный разработчик всё равно может извлечь пользу и упростить разработку на своем уровне, применяя эти принципы в своей работе.
Спасибо за ваше мнение! Буду рад продолжить обсуждение, если у вас есть дополнительные мысли по этой теме.
P.S. да, сперва решил ответ подготовить, а потом уже одобрить комментарий) Поэтому не обращайте внимания на короткое время ответа.
Не могу посоветовать каких-то конкретных книг, которые были посвящены декомпозиции (либо не знаю, либо декомпозиция в книгах идёт скорее как смежная тема и не раскрывается), но мне как-то попадалась статья на Хабре, которая довольно интересно раскрывает этот вопрос (в комментариях тоже интересно).
Согласен, и наверное стоило раскрыть этот момент подробнее.
В идеале, сложности при составлении задачи — это отсутствие информации или уверенности в решении. Тогда уже стоит провести либо проводить исследования, либо обсудить ту же постановку с компетентными в вопросе коллегами (лучше даже с теми, кто эту задачу и будет выполнять). Но да, это тоже может занять время.
Поэтому я за то, чтобы писать достаточно полное описание. Ни больше, ни меньше.
Сделал правки, спасибо за помощь @mclander@DmitryOlkhovoi
Разумно. Позже обновлю статейку, что материал больше подходит для внешних редиректов. И про History API упомяну.
Спасибо. К сожалению, History API не позволяет делать редиректы на другие домены.
Приветствую.
Верно, нагрузка возрастет, но не значительно. Из моего опыта: за внедрение, ведение и актуализацию обычно отвечают 1—3 человек (в зависимости от размера команды). Если у вас такая небольшая команда, думаю ведение документации может быть не особо необходимым, но да — всё зависит от специфики проекта.
Если прочитать статью, можно заметить такие моменты:
Я понимаю ваши опасения по поводу возможной бюрократии при внедрении ADR и усложнения работы команде и прошу в статье учитывать это. Цель этого процесса — облегчить в результате работу команды, а не усложнить её.
Спасибо за ваш отзыв и интересный комментарий! Вы подняли очень важные вопросы.
Действительно, акцент в статье сделан на действиях разработчика и некоторые моменты могут быть "притянуты за уши". Возможно, создается впечатление, что ответственность (как минимум за анализ) перекладывается на разработчика. К тому же пример выбран не в пользу собирательного образа менеджера :)
С другой стороны в реальности у нас могут быть такие ситуации:
Нет аналитиков: В небольших командах (или где не принято "держать" аналитиков) сотрудники часто берут на себя дополнительные роли (что не обязательно плохо, об этом ниже). Т.е. нет людей, которые могут до начала реализации точно просчитать что и как будет работать и к чему это приведет.
Технический контекст: Когда задача требует глубокого понимания технических деталей, вклад разработчика в анализ и планирование может быть неоценим.
Продуктовое мышление: Поощряется, когда разработчики думают не только о коде, но и о влиянии своей работы на пользователей и бизнес.
Декомпозиция и оценка: Технические нюансы сильно влияют на структуру задачи и время её выполнения. Вряд ли менеджер сможет с высокой точностью выполнить это без мнения разработчика.
Это не означает, что менеджер не выполняет свою работу. Скорее, это пример тесного сотрудничества, где каждый вносит свой вклад согласно своим сильным сторонам.
Полностью согласен. Эффективность любой системы зависит от последовательности её применения всей командой. При этом даже если не все готовы принять такой подход целиком, отдельный разработчик всё равно может извлечь пользу и упростить разработку на своем уровне, применяя эти принципы в своей работе.
Спасибо за ваше мнение! Буду рад продолжить обсуждение, если у вас есть дополнительные мысли по этой теме.
P.S. да, сперва решил ответ подготовить, а потом уже одобрить комментарий) Поэтому не обращайте внимания на короткое время ответа.
Конечно, немного вырвал из контекста, но поймал дикий флешбэк. Больше сказать нечего, это всё.
Спасибо за интерес!
Не могу посоветовать каких-то конкретных книг, которые были посвящены декомпозиции (либо не знаю, либо декомпозиция в книгах идёт скорее как смежная тема и не раскрывается), но мне как-то попадалась статья на Хабре, которая довольно интересно раскрывает этот вопрос (в комментариях тоже интересно).
Ну или можно почитать что-то более собирательное.
Если кто-нибудь из читателей знает хорошие материалы — пишите в комментариях, тоже буду рад изучить!
Постарался описать свой кейс для наглядности, но в целом да — стоит пользоваться только тем, что окажется полезно в команде.
Совершенно верно, предоставил шаблоны чтобы было удобно скопировать в свои формы/шаблоны багтрекера)
А насчёт автоматизации можно написать и нагуглить ещё немало статей, тема довольно обширная. За ссылочки и тулзы спасибо :)
Согласен, и наверное стоило раскрыть этот момент подробнее.
В идеале, сложности при составлении задачи — это отсутствие информации или уверенности в решении. Тогда уже стоит провести либо проводить исследования, либо обсудить ту же постановку с компетентными в вопросе коллегами (лучше даже с теми, кто эту задачу и будет выполнять). Но да, это тоже может занять время.
Поэтому я за то, чтобы писать достаточно полное описание. Ни больше, ни меньше.