Володарь железного града
Шрифт:
Заказчик не допускается до разработки и тестирования. Он не может комментировать макеты или прототипы и видит результат только в конце проекта. (устранено в системе ГГГ так как корректировкой занимается архитектур проекта и архитектур систем контроля проектов)
Если изменились требования Проблемы всплывают только при тестировании. Сделать часть работы и сразу протестировать или совместить разработку и тестирование, чтобы найти уязвимости, нельзя. Тестирование начинается после окончания разработки, поэтому часто недостатки обнаруживаются слишком поздно. (требования
Случаи когда Waterfall подходит проекту
Вы четко знаете, какой продукт нужно получить в итоге. У вас много времени и ресурсов на проект. Вам нужна детальная документация по всем процессам разработки. Создание вашего продукта строится на строгой последовательности этапов. Большая часть работы над проектом — на удаленке. ГГ использовал не совсем чистый водопад, а дополненный моделями: параллельный метод выполнения работ и каскадная модель с обратными связями.
Как работает Scrum
Создание списка задач. Составьте список действий, которые необходимо выполнить для достижения целей.
Планирование спринтов у гг Шаги. Выберите задачи из тз, с которыми команда справится в течение короткого временного интервала (обычно от одной до четырех недель). Сложные задачи разбивайте на более простые, чтобы было легче контролировать их выполнение.
Разработка и тестирование. Основной акцент — на создании работоспособного продукта, который можно продемонстрировать. Ежедневные планерки. Команда проводит короткие встречи, на которых каждый участник докладывает о своем прогрессе: над чем работал, какие проблемы возникали и как их получилось решить.
Демонстрация результатов. В конце спринта команда проводит презентацию продукта.
Ретроспектива. По окончании спринта команда обсуждает, что получилось хорошо, а что плохо. Это помогает учиться на ошибках и постоянно совершенствоваться.
Повторение. После ретроспективы готовятся к следующему шагу. Команда выбирает новые задачи из тз, планирует следующий спринт, и цикл начинается вновь.
Ежедневно вся команда собирается не более чем на 15 минут. Цель встречи — услышать от каждого участника ответ на три вопроса:
Что я сделал с прошлой встречи? Что я буду делать сегодня? Что мешает выполнению задачи?
На основании этих микроотчетов Scrum-мастер (координатор) старается понять, так ли идет рабочий процесс и как можно помочь команде преодолеть препятствия.
Команда использует доски, пространство которых разделяется на части, отражающие стадии работы над продуктом. Их количество может варьировать, но обязательно включает в себя три составляющих (слева направо):
запланированные задачи; задачи в активной работе; выполненные задачи.
Доска — это визуальное отображение рабочего процесса на разных стадиях. С ее помощью каждый член команды может контролировать свою работу и следить за проектом. Удаленная координация осуществляется
Постоянное самосовершенствование и самообучение команды.
Автономность. Каждый участник несет ответственность за свою часть работы и за общий результат.
Кроссфункциональность. Наличие в команде людей с разными навыками делает ее самодостаточной.
Внедрение и обратная связь. После всех спринтов — релиз. Заказчик и архитектор, корректор дают обратную связь, на основе которой команда дорабатывает продукт.
Чем Scrum отличается от Kanban (у ГГ система Родова) — структурированный подход с заданными этапами создания продукта, а Kanban — сбалансированный, основная цель которого — обеспечить всех членов команды одинаковым количеством работы. В Scrum предусмотрены организованные периоды работы с задачами на период. В Kanban новые задачи могут появляться в любой день. Scrum-команды работают в течение заданного отрезка времени, а в Kanban задачи поступают непрерывно и больше подходя для производства.
Основная разница между Scrum и Канбан — в длине итераций. В Scrum итерации — 2 недели, в Kanban задачи можно «подсовывать» хоть каждый день.
Kanban дает больше гибкости, если под гибкостью понимать частоту смены приоритетов. Вчера исполнитель сделали новую схему, а сегодня получили данные из мастерской и узнали, что она не работает так, как было задумано. Координатор просит переделать схему, и послезавтра мы пробуем новую деталь.
В варианте Scrum от ГГ задачи оценивают в баллах. Без оценки не получится сформировать спринт: ведь нам нужно знать, успеем ли мы сделать задачи за 2 недели. Через 2 недели мы получаем ценную статистику — сколько часов команда смогла сделать за сприн. Velocity — это индекс в баллах, производительность команды за один спринт. Этот параметр позволяет координатору предсказать, где команда будет через 2 недели.
В Kanban же не принято делать оценку. Это опционально, команда решает сама. Здесь нет понятия «скорость работы команды», считается только среднее время на задачу. Время это считается с помощью специального отчета — циклического таймера.
Циклический таймер для задачи = время выполнения задачи минус время начала работы над задачей. Можно сказать что
в Scrum цель — закончить спринт, в Kanban — задачу или так Scrum — это автобус, который останавливается лишь на определенных остановках, где люди выходят группами. А Kanban — это маршрутка: захотел пассажир выйти, попросил водителя и вышел там, где ему нужно.
Преимущества элементов Scrum
Команда работает небольшими этапами, на каждом из которых определяются цели и способы их достижения, что повышает скорость работы. Команда одновременно работает над разными задачами проекта и быстрее достигает желаемой цели. Большие задачи дробятся на мелкие, поэтому удобно вносить корректировки в процессе работы. Благодаря быстрой реакции на изменения и устранения ошибок минимизируются риски. Каждый член команды знает, за что отвечает. Открытый обмен информацией делает работу максимально прозрачной. Ежедневная видимость достижений поддерживает высокий уровень мотивации.