ПиццаСофт 
Тендеры и лиды
Информация
Два наиболее популярных пути в Agile — Scrum и Kanban. В нашей работе мы придерживаемся Scrum. О том, как его внедряли можно почитать здесь.
Оба подхода гибкие и могут принести пользу команде разработки, но применяются они в разных сценариях. Kanban помогает улучшить любые процессы, его легко начать применять для проектов и продуктов, которые уже разрабатываются. Scrum чаще используется в продуктовой разработке и помогает команде в условиях неопределённости.
Наш первый бэклог
Scrum изобрели Кен Швабер и Джефф Сазерленд, которые подсмотрели за работой американских военных и пришли к выводу, что основа успеха заключается в качественном командном взаимодействии. Сам термин позаимствован у регбистов и в переводе с английского означает «схватка».
Фреймворк Scrum предполагает работу в рамках «спринта» — итерации длительностью 2 недели. Список задач на спринт формируется перед его началом и должен быть выполнен полностью к концу периода. Каждый раз по завершении спринта команда проводит ретроспективу спринта — анализирует ситуацию для повышения эффективности и в том числе решает, нужно ли включать незавершённые задачи в следующий спринт.
Чаще задачи в Scrum оцениваются в Story Points (SP), которые отражают сложность работы. Спринт формируется исходя из оценки всех задач. К концу периода становится ясно, сколько SP выполнила продуктовая команда.
Scrum позволяет работать над частями продукта итеративно, чтобы быстро тестировать их на рынке, выпускать новые фичи и получать обратную связь от пользователей.
Фреймворк лучше всего работает для небольших команд до 8 человек. Scrum изначально не подразумевает сложной многоуровневой иерархии команды — в нём выделяется лишь несколько ключевых ролей.
В процессе работы команда синхронизируется на ежедневных встречах — дейли, где каждый участник информирует остальных о статусе выполнения задачи. У нас это утренние 15-митнутные созвоны по телемосту.
Целых 205 спринтов, а это на минуточку восемь с половиной лет мы вели бэклог в Excel! За это время накопилось множество мелочей, которые со временем наклыдывались друг на друга. Где-то мешали, а местами вводили в заблуждение. Прямоугольники (куда были помещены задачи) раскрашивались разным цветом в попытке создать более менее удобную визуализацию. Скрам-мастера порой забывали переключать статусы у задач, потому что они терялись в полотне текста. Вся необходимая информация в таблице не умещалась на одном экране и приходилось постоянно крутить горизонтальную полосу прокрутки, то вправо, то влево.
Бэклог в Excel
При использовании Scrum участники проекта обычно отслеживают состояние продукта и взаимодействуют внутри команд с помощью доски.
Доски в Яндекс Трекере
Задачи в трекере представлены в виде карточек, которые распределены по колонкам в зависимости от статуса.
Карточки с задачами в Яндекс Трекере
Кроме того, на доске доступны инструменты, которые могут помочь в работе. Например, там можно планировать спринты.
Нажав на спринт вверху страницы, можно отобразить только входящие в него задачи.
Мы поговорили с руководителем Проектного офиса и по совместительству менеджером проектам Даниилом Огнивиным о новой системе ведения бэклога.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13492 тендера
проведено за восемь лет работы нашего сайта.
Почему решили перевести бэклог из Excel в Яндекс Трекер?
Потому что Excel — это не система управления разработкой. Он может использоваться для маленького штата из нескольких разработчиков, но не более.
— В Excel нет нормального жизненного цикла задач.
— Отсутствует прозрачность и удобство для бизнеса.
— Нет никакой автоматизации, метрик, показателей.
Яндекс Трекер закрывает все эти потребности, но также, конечно, имеет и минусы:
— Требует дисциплины и обучения команды.
— Платный.
Всё новое всегда вызывает сопротивление. Как прошёл переход на Яндекс трекер и как он отразился на работе команд?
Сопротивление, конечно, было — это нормальная практика при вводе новых и сложных инструментов.
Мы работали с командами, помогали в настройке, доносили цель — сделать удобную и прозрачную систему для всех.
На первых этапах внедрения присутствовал хаос и неопределенность. Сейчас же по отзывам разработки — система действительно удобная, процессы уже наладили, занимаемся улучшением и экспериментами.
Чем история отличается от задачи?
История — это бизнес-единица. Продуктовая задача с понятным результатом и ценностью.
Задача — обычно часть истории. Это конкретная техническая работа для разработчика. Она может не иметь ценности отдельно, но является важным кусочком цельной истории при декомпозиции.
Если история — это «мы строим дом», то задачи — это залить фундамент, провести электричество, покрасить стены.
