Два дня (первый и второй) были теоретическим введением.
Пришло время увидеть, как всё это на практике.
Прошлая неделя началась с митингов по планированию фич. Закончилась непосредственно работой.
В начале немного расскажу о XPlanner и организации проекта.
XPlanner — open-source тул для учета времени и рисованию красивых графиков для менеджеров, достаточно простой.
Наш проект состоит из трех команд. Каждая должна сделать порядка 10 фич за весь проект и решить несколько внутренних проблем, таких как, автоматизация тестов.
XPlanner не умеет вести учет времени по командам, а для нас это важно. Поэтому пришлось создать три отдельных проекта под каждую. Это дало:
Основной минус XPlanner — негибкая работа с задачами: их перенос из одного спринта в другой превращает некоторые вещи в сумбурный список. Перед началом проекта стоит изучить подобные тулы и выбрать подходящий.
Нашей команде предстояло провести 2 дня на план-митингах. Как показала практика, чем больше народу — тем сложнее договорить о сроках: один считает, что слишком много времени нужно, другой — наоборот, третий вообще не понимает смысла в фиче.
Что бы избежать долгих диспутов, SCRUM предлагает использовать систему карточек с цифрами.
У нас были такие: 2, 4, 8, 12, 16, 20. Плюс карточка с надписью «Слишком много». Оценка времени происходит так:
1. Выбирается фича. Разбивается на задачи. Оценка дается по каждой из задач.
2. Каждый из участников митинга выбирает карточку с количеством часов, достаточным, по его мнению, для реализации задачи.
3. На счет 3 все показывают свой выбор.
4. Если значения сильно расходятся — каждый аргументирует (кратко) свой выбор и выбирают оптимальную оценку.
К концу митинга оценки становятся менее объективными из-за усталости участников, поэтому стоит делать перерывы (лучше походить, а не растекаться по стулу). В команде могут встретиться люди, которые начнут разводить дискуссию на тему: «Что за дурак придумал эту фичу». Таких людей, ИМХО, стоит лишать голоса минут на 30 либо удалять с митинга. В противном случае, время будет потрачено на пустые доказательства — фичу все равно предстоит сделать. Если вы лидер в команде — заставте всех подготовится, иначе может образоваться кучу вопросов: «А что это за ...?».
В среду у нас был первый статус митинг. На нем мы должны были рассказать, что сделали, что будем делать и какие есть проблемы. Участники: команда, менеджер и тех. координатор проекта.
В нашем случае последние активно вклинивались в разговор — запретите говорить всем, кроме команды. Задача менеджеров на этом митинге — слушать и записывать.
После митинга все пошли работать. Тут ничего особенного. Но есть несколько важных моментов:
1. Менеджер должны помнить, что митинг ВСЕГДА имеет цель. Нельзя собирать команду только ради рассказа о текущем статусе проекта — он и так известен. Если вам хочется пообщаться с программистами — позовите их пить чай. Это даст вам плюс к доверию.
Любой митинг без полезной цели ведет к потере времени еще минут на 30 — после скучного рассказа о фигне люди идут пить чай и теряют настрой работать.
2. Не выбрасывать фичи в начале спринта, если даже видно, что не успеете. Это лишняя работа. Также в начале (особенно когда команда еще не сработалась) не ясно какой будет темп. Возможно удастся сделать быстрее. Пусть эти фичи будут как сверх-цель сделать больше и стать лучше. Хорошо, если есть небольшой дух соревнования между командами, но не в команде.
3. Общайтесь с коллегами. О ваших проблемах должны знать все в команде — возможно кто-то уже знает ответ. Хорошо, если вы сидите в общей комнате.
Пришло время увидеть, как всё это на практике.
Прошлая неделя началась с митингов по планированию фич. Закончилась непосредственно работой.
В начале немного расскажу о XPlanner и организации проекта.
XPlanner — open-source тул для учета времени и рисованию красивых графиков для менеджеров, достаточно простой.
Наш проект состоит из трех команд. Каждая должна сделать порядка 10 фич за весь проект и решить несколько внутренних проблем, таких как, автоматизация тестов.
XPlanner не умеет вести учет времени по командам, а для нас это важно. Поэтому пришлось создать три отдельных проекта под каждую. Это дало:
- Возможность видеть динамику в каждой из команд, а не всего проекта
- Избежать «каши» в списке задач (их набралось порядка 50)
Основной минус XPlanner — негибкая работа с задачами: их перенос из одного спринта в другой превращает некоторые вещи в сумбурный список. Перед началом проекта стоит изучить подобные тулы и выбрать подходящий.
Планирование (оценка времени)
Нашей команде предстояло провести 2 дня на план-митингах. Как показала практика, чем больше народу — тем сложнее договорить о сроках: один считает, что слишком много времени нужно, другой — наоборот, третий вообще не понимает смысла в фиче.
Что бы избежать долгих диспутов, SCRUM предлагает использовать систему карточек с цифрами.
У нас были такие: 2, 4, 8, 12, 16, 20. Плюс карточка с надписью «Слишком много». Оценка времени происходит так:
1. Выбирается фича. Разбивается на задачи. Оценка дается по каждой из задач.
2. Каждый из участников митинга выбирает карточку с количеством часов, достаточным, по его мнению, для реализации задачи.
3. На счет 3 все показывают свой выбор.
4. Если значения сильно расходятся — каждый аргументирует (кратко) свой выбор и выбирают оптимальную оценку.
К концу митинга оценки становятся менее объективными из-за усталости участников, поэтому стоит делать перерывы (лучше походить, а не растекаться по стулу). В команде могут встретиться люди, которые начнут разводить дискуссию на тему: «Что за дурак придумал эту фичу». Таких людей, ИМХО, стоит лишать голоса минут на 30 либо удалять с митинга. В противном случае, время будет потрачено на пустые доказательства — фичу все равно предстоит сделать. Если вы лидер в команде — заставте всех подготовится, иначе может образоваться кучу вопросов: «А что это за ...?».
Первый 15-ти минутный SCRUM митинг
В среду у нас был первый статус митинг. На нем мы должны были рассказать, что сделали, что будем делать и какие есть проблемы. Участники: команда, менеджер и тех. координатор проекта.
В нашем случае последние активно вклинивались в разговор — запретите говорить всем, кроме команды. Задача менеджеров на этом митинге — слушать и записывать.
Первые строки кода
После митинга все пошли работать. Тут ничего особенного. Но есть несколько важных моментов:
1. Менеджер должны помнить, что митинг ВСЕГДА имеет цель. Нельзя собирать команду только ради рассказа о текущем статусе проекта — он и так известен. Если вам хочется пообщаться с программистами — позовите их пить чай. Это даст вам плюс к доверию.
Любой митинг без полезной цели ведет к потере времени еще минут на 30 — после скучного рассказа о фигне люди идут пить чай и теряют настрой работать.
2. Не выбрасывать фичи в начале спринта, если даже видно, что не успеете. Это лишняя работа. Также в начале (особенно когда команда еще не сработалась) не ясно какой будет темп. Возможно удастся сделать быстрее. Пусть эти фичи будут как сверх-цель сделать больше и стать лучше. Хорошо, если есть небольшой дух соревнования между командами, но не в команде.
3. Общайтесь с коллегами. О ваших проблемах должны знать все в команде — возможно кто-то уже знает ответ. Хорошо, если вы сидите в общей комнате.