Комментарии 6
@LascarDev хорошая практика, пару вопросов:
1/ `Руководитель проекта или тимлид берет задачи из бэклога и добавляет их на доску.` - такое двоевластие работает без побочных эффектов?
2/ `Спорным моментом для нас оказалась запись видео после реализации фичи` - почему отказались в итоге?
Имхо, странным показалось назвать Roadmap-ом тех описание компонента, обычно это всё-таки план работ во времени с какой-то целью и майлстоунами.
Спасибо за вопрос @vlad_bik
У нас есть еженедельные спринты, где мы с руководителем проекта определяем задачи на неделю. Поэтому проблем никогда не возникает, оба в контексте предстоящих задач.
Запись видео по большей части была предназначена для представителя заказчика. Как в итоге оказалось, вполне достаточно демонстрации без записи видео, а разработчикам достаточно документации.
Очевидно что эта методология была придумана для масштабирования производства решений и сокращений затрат. Возможно в этих рамках все работает. Единственный вопрос это качество и поддерживаемость кода и поддержка масштабирования приложения ведь основной штат кодеров это джуны или дешёвые stable разработчики.
@zubrbonasusСпасибо за вопрос.
Мы стартуем разработку с коробки быстрого старта, где наша основная команда заложила всю архитектуру, поэтому изначально с масштабированием и производительностью проблем нет.
У нас есть CodeStyle которому придерживаются все разработчики, а если не придерживаются это видно на Code Review. Мы просто говорим переделывать.
Ну и третье это Code Review. Мы видим в любом случае что пишут стажеры или джуны. Если что то не по нашим стандартам, мы говорим что не так, почему должно быть по другому и говорим что нужно переделать.
Мир сделал очередной оборот вокруг своей оси. Даёшь больше статей про внедрение анти-аджайла.
Опыт внедрения компонентной разработки