Командировка — это всегда что то новое. В этот раз я буду постигать науку быстро и хорошо работать. Учителя шведы.
Кратко суть: «Think better — write faster». Очень хорошо подходит для небольших команд.
Первый день начался с двух митингов.
Первый митинг был посвящен техническим деталям предстоящего проекта. Все они были разделены на области, например так:
Каждая область содержит несколько задач.
Второй митинг был вводным лекцией в то, как мы будем работать.
Важным ресурсом является время. Нам сказали сразу: «Времени у вас почти нет, и права на ошибку тоже».
Все мы были поделены на команды. Команды деляться по принципу сходства экспертизы. Например, я хорошо знаю продукт1, мой сосед знает продукт2, его сосед знает продукт1. Так первая команда это я и сосед соседа, вторая команда — мой сосед. Такое разделение — небольшой отдход от концепции SCRUM.
SCRUM предполагает следующее:
1. Все люди в команде знают все.
2. Любой может сделать работу своего соседа.
Такой подход необходим для быстрого выполнения поставленных задач. Сам проект предполагает наличие «workpackages» (продукт) и «features» (функциональности или просто фичи). Продукт должен быть закончен до определенной даты. Что бы все успеть — менеджер делит этот период на спринты.
Спринт — это короткий отрезок времени, за который должны быть сделаны фичи. Спринт нельзя растянуть, можно только выбросить или заменить другим. Если команда опережает план, можно добавить спринт. Спринты можно менять местами. Тоесть — это как бы маленький проект, на выходе дающий конечный продукт.
Так как планирование ведется в реальном времени, менеджер и команда должны знать статус выполнения работы. Для этого каждый день они собираются ровно на 15 минут, и каждый отвечает на 3 вопроса:
Митинг проводится обязательно стоя. Как нам сказали, это что бы люди не растекались по стульям и были в тонусе.
Митинг организует SCRUM Master (как он выбирается — не знаю.) Его задача решать проблемы в команде и задавать направление.
Сам процесс работы делится на два этапа:
Последнему отводится чуть ли ни главная роль. Фича не считается завершенной, пока она не протестирована, и тесты не прошли успешно.
Тестирование проводится ежедневно всех продуктов, включенных в проект.
Еженедельно, всей системы. Еженидельное тестирование показывает, как наши продукты работают в связке с продуктами других проектов.
Так же каждый дизайнер обязан протестировать свою фичу (написать тесты и прогнать их) перед тем как мержить в главную ветку проект.
Одна из моих ролей в команде, как раз, отвечать за тестирование. Для меня это новый и интересный опыт.
Кратко суть: «Think better — write faster». Очень хорошо подходит для небольших команд.
Первый день начался с двух митингов.
Первый митинг был посвящен техническим деталям предстоящего проекта. Все они были разделены на области, например так:
- Системные улучшения
- Продукт1
- Продукт2
- Адаптация
Каждая область содержит несколько задач.
Второй митинг был вводным лекцией в то, как мы будем работать.
Важным ресурсом является время. Нам сказали сразу: «Времени у вас почти нет, и права на ошибку тоже».
Все мы были поделены на команды. Команды деляться по принципу сходства экспертизы. Например, я хорошо знаю продукт1, мой сосед знает продукт2, его сосед знает продукт1. Так первая команда это я и сосед соседа, вторая команда — мой сосед. Такое разделение — небольшой отдход от концепции SCRUM.
SCRUM предполагает следующее:
1. Все люди в команде знают все.
2. Любой может сделать работу своего соседа.
Такой подход необходим для быстрого выполнения поставленных задач. Сам проект предполагает наличие «workpackages» (продукт) и «features» (функциональности или просто фичи). Продукт должен быть закончен до определенной даты. Что бы все успеть — менеджер делит этот период на спринты.
Спринт — это короткий отрезок времени, за который должны быть сделаны фичи. Спринт нельзя растянуть, можно только выбросить или заменить другим. Если команда опережает план, можно добавить спринт. Спринты можно менять местами. Тоесть — это как бы маленький проект, на выходе дающий конечный продукт.
Так как планирование ведется в реальном времени, менеджер и команда должны знать статус выполнения работы. Для этого каждый день они собираются ровно на 15 минут, и каждый отвечает на 3 вопроса:
- Что я сделал?
- Что я буду делать?
- Есть ли у меня проблемы?
Митинг проводится обязательно стоя. Как нам сказали, это что бы люди не растекались по стульям и были в тонусе.
Митинг организует SCRUM Master (как он выбирается — не знаю.) Его задача решать проблемы в команде и задавать направление.
Сам процесс работы делится на два этапа:
- Реализация функциональности
- Тестирование
Последнему отводится чуть ли ни главная роль. Фича не считается завершенной, пока она не протестирована, и тесты не прошли успешно.
Тестирование проводится ежедневно всех продуктов, включенных в проект.
Еженедельно, всей системы. Еженидельное тестирование показывает, как наши продукты работают в связке с продуктами других проектов.
Так же каждый дизайнер обязан протестировать свою фичу (написать тесты и прогнать их) перед тем как мержить в главную ветку проект.
Одна из моих ролей в команде, как раз, отвечать за тестирование. Для меня это новый и интересный опыт.