Полезно как можно быстрее познакомить новичка с юнит-тестированием. Конечно, не стоит принуждать сразу же вести разработку по TDD. Сначала пускай дампит, а после этого пытается тестировать, то что написал. Это приучит строить код с низкой связностью.
Для компании 3 девелопера + 1 тестировщик:
Pull: 3; Анализ: 1; Проектирование+Разработка+Review: 2; Тестирование: 1
Ошибки у нас правятся на лету, я описал это дело в подразделе «возвраты». Мы стараемся на период тестирования сильно не нагружать одного из девелоперов (обычно ответсвенного по фиче), чтобы тот был всегда готов быстро исправить найденные дефекты.
Вообще, некоторые выделяют на доске «красную дорожку», в которую попадают самые горячие внеплановые фичи. У нас такой необходимости нет.
Абсолютно нет ) Это может делать каждый из разработчиков. Да и вообще, процесс деплоя максимально автоматизирован и не требует каких-то специфических навыков.
Понятие спринт было введено товарищем исключительно для объяснения процесса замера скорости исполнения. Мы не используем этого понятия в работе. PO выставляет срок, к которому он хотел бы иметь определенный набор функционала. Мы оцениваем фичи и выдвигаем вердикт — да, нет. Если «нет», то происходит корректировка желаний PO =)
1. 2. Естественно, есть области в которых некоторые сильнее. Но мы стараемся максимально наладить обмен знаниями: каждый с радостью берет задачу, в которой он недостаточно сведущий, проводятся постоянные презентации архитектур, инструментов и т.п. Таким образом у нас размываются рамки ролей.
3. 3:1
4. Пока исключительно web
От scrum у нас осталась практика оценки бэклога — каждая фича оценивается в относительных сторипоинтах (у нас это идеальные дни). PO устанавливает дату очередного релиза. Строим burndown график: по оси X откладываем время, а по оси Y поинты. Получаем идеальную скорость разработки, которая позволит зарелизится вовремя. Покончив с какой-либо фичей, мы отмечаем на графике сколько поинтов осталось к текущей дате и видим отклонение от идеального плана. Обычно системы управления проектами позволяют автоматически строить такие графики. Мы используем Pivotal — и он справляется с этой задачей великолепно )
И что же, вы запускаете тесты на продакшн базе?
KANBAN AND SCRUM — MAKING THE MOST OF BOTH (чуть выше ссылка от dimasol)
Хенриг Книберг
SCRUM AND XP FROM THE TRENCHES
Pull: 3; Анализ: 1; Проектирование+Разработка+Review: 2; Тестирование: 1
Ошибки у нас правятся на лету, я описал это дело в подразделе «возвраты». Мы стараемся на период тестирования сильно не нагружать одного из девелоперов (обычно ответсвенного по фиче), чтобы тот был всегда готов быстро исправить найденные дефекты.
Вообще, некоторые выделяют на доске «красную дорожку», в которую попадают самые горячие внеплановые фичи. У нас такой необходимости нет.
3. 3:1
4. Пока исключительно web