Comments 19
Есть идея создать инструмент для написания и поддержки ТЗ. Который будет частично перекрывать по функционалу то, что описано в статье. Будет включать в себя удобство как в Google Docs, версионирование как в Git и подсветку изменений как в Diffchecker. Эдакое ТЗ с удобным просмотром истории изменений. С меня бэкенд, но 80% работы там на фронте. Есть тут желающие контрибьютить свободное ПО?)
Сделать Google Docs в свободное от работы время? Ну да, ну да)
так есть же markdown и git
Да, формат удобнее всего Markdown. Git хорошая вещь, но менеджеры с ним не работают, это слишком специализированный инструмент. На фронте будет editor.js, сохраняться в базу с комментарием о причинах правки, автором, датой правки, автоинкрементации версии. Затем будет страница типа /?from=1.23&to=1.24, которая в удобном виде подсветит разницу между 2мя версиями, как в DiffChecker. В публичном доступе ТЗ будет выглядеть, как любая типичная документация. А под капотом - крутые фичи, облегчающие жизнь компании. Больше никаких неактуальных ТЗ, никаких правок мимо ТЗ, никаких забытых договоренностей, никаких белых пятен в логике.
notion, confluence, wiki gitlab'а/bitbucket'а/github'а - тысячи их))
Вы хотите опенсорсный редактор документов с сохранением историеи на php и js?
Похоже на Confluence.
Не слишком ли усложнено? Написали требования, повесили на стеночку, шаг вправо, шаг влево - расстрел. Если возникает непонятка - на консультацию к старшим.
Хотя... в больших проектах без этого наверное никак.
Как бы вы ни относились к Rails, в этом фреймворке на полную работает потрясающий принцип convention over configuration
Да ладно. Фреймворков много, а я - один. И конвеншены везде свои. Я за то, чтобы было понятно, что код делает с минимальной (идеально без) подготовкой. Обилие соглашенческой магии этому не способствует.
Думаю, имеются в виду разумные соглашения, которые исходят скорее из архитектуры или предметной области, чем из левой пятки фреймворка.
С Rails не знаком, но гугл говорит, что там соглашения вида "when you have a User model in your application then Rails assumes that it is defined in the file at app/models/user.rb", что достаточно логично, и не требует особой подготовки.
Делали без ADR, более упрощенно:
1) Выработали план, по которому принимаем соглашения на уровне стека
2) Выработали подход по плану. Назначался ведущий, который готовил и принимал последующие вопросы и пункты к обсуждению, согласовали формат обсуждений и оповещений об изменениях.
3) Раз в неделю собирались стеком и шли по плану.
4) В ходе обсуждений задавались конкретные вопросы и фиксировались результаты обсуждений в виде рекомендаций или обязательных правил. Фиксировались на странице вики в формате markdown, об изменениях оповещались участники процесса.
5) В параллеле с вопросами стека применили похожую схему к процессам в команде (git-flow, ревью, детализация, тестирование, практика релизов).
6) При дальнейших действиях в команде ее участник уже имел справочную информацию в виде документов, на которые можно опираться при принятии решений.
7) Попробовали нововведения в бою, настроили механизм отладки соглашений, запустили переодический пересмотр.
8) Автоматизировали лишь спустя какое-то время, и далеко не все. Потому что некоторые правила требовали достаточно весомых затрат на автоматизацию.
9) Запустили таким образом кросс-командные соглашения.
Это, конечно, все потребовало очень много времени на согласования и настройку продуктивной атмосферы для принятия решений, но в итоге получили прозрачные процессы. Если кратко резюмировать, то это дорого, и не везде применимо. Но стоит того.
Интересно, конечно. С одной стороны у нас аджайл с его принципами
Люди и взаимодействие приоритетнее процессов и инструментов .
Сотрудничество с заказчиком важнее согласования условий контракта
Работающий продукт важнее исчерпывающей документации
...
С другой стороны мы вводим формализацию и инструменты для ее автоматизации.
P.S.: Кстати, если смотреть на контрактную разработку то корпоративным заказчикам по факту важнее именно ценности справа, а не слева, хоть они и требуют чтобы их команды работали по аджайлу. Единственный принцип корпоративного аджайла это "прикрытие своей задницы важнее всего остального".
Так это не противопоставление. Это фраза не про то, что не должно быть процессов, она про то, что процессы надо адаптировать под свою команду, а не копировать жёстко практики. Люди важнее, но у нас же всё равно есть какой-то процесс, так? Этот процесс может быть осмысленным, а может быть и нет. Вот я и предлагаю осмыслять и фиксировать осмысление.
Ответ простой: пишешь код в проект — не поленись его почитать и сверь конвенции по которым он написан с тем, что ты в него добавляешь. Все)
Фиксация соглашений в команде