Володарь железного града

Метод критической цепи способ управлять проектом через распределение времени и ресурсов с поправкой на возможный форс-мажор. Суть МКЦ: разбить работу над проектом на этапы; понять, кто будет выполнять задачи; предупредить сотрудников, что скоро стартует работа над проектом, и объяснить, что им предстоит делать; определить, сколько времени в теории займет проект в целом; уменьшить полученное время вдвое и озвучить это как дедлайн для сотрудников; увеличить на четверть изначальное расчетное время и озвучить этот срок заказчику; назначить для сотрудников контрольные сроки для каждого этапа проекта.

Плюсы и минусы Waterfall

Плюсы:

Наличие инструкций и правил по всему процессу. Работа начинается с подробного анализа требований и того, как будет реализован проект. Планы, этапы и процессы утверждаются заранее, фиксируются в документах и вопросов не вызывают. Исполнителю нужно просто им следовать.

Определенность в сроках. Стоимость продукта и сроки сдачи проекта рассчитаны и утверждены в самом начале и не меняются в процессе.

Отсутствие дополнительных трат на коммуникацию в команде. Даже если придет новый разработчик, понять задачу и приступить к работе получится быстро: для всех процессов есть описанные правила.

Минусы:

Отсутствие гибкости. Невозможно предусмотреть все проблемы в проекте заранее. Из-за жесткой последовательности этапов недочеты станут известны только в конце проекта, придется делать дополнительные этапы и начинать работу заново, а это новые затраты и лишние рабочие часы (частично устранено промежуточным независимым тестированием)

Заказчик не допускается до разработки и тестирования. Он не может комментировать макеты или прототипы и видит результат только в конце проекта. (устранено в системе ГГГ так как корректировкой занимается архитектур проекта и архитектур систем контроля проектов)

Если изменились требования Проблемы всплывают только при тестировании. Сделать часть работы и сразу протестировать или совместить разработку и тестирование, чтобы найти уязвимости, нельзя. Тестирование начинается после окончания разработки, поэтому часто недостатки обнаруживаются слишком поздно. (требования закладывается изначально, косяки ГГ известны, сложность подпроектов и подсистем невелика проблема не стоит остро, в случае изменения архитектур и координатор корректируют весь проект, ограничений по бюджету, резервам, нет)

Случаи когда Waterfall подходит проекту

Вы четко знаете, какой продукт нужно получить в итоге. У вас много времени и ресурсов на проект. Вам нужна детальная документация по всем процессам разработки. Создание вашего продукта строится на строгой последовательности этапов. Большая часть работы над проектом — на удаленке. ГГ использовал не совсем чистый водопад, а дополненный моделями: параллельный метод выполнения работ и каскадная модель с обратными связями.

Как работает Scrum

Создание списка задач. Составьте список действий, которые необходимо выполнить для достижения целей.

Планирование спринтов у гг Шаги. Выберите задачи из тз, с которыми команда справится в течение короткого временного интервала (обычно от одной до четырех недель). Сложные задачи разбивайте на более простые, чтобы было легче контролировать их выполнение.

Разработка и тестирование. Основной акцент — на создании работоспособного продукта, который можно продемонстрировать. Ежедневные планерки. Команда проводит короткие встречи, на которых каждый участник докладывает о своем прогрессе: над чем работал, какие проблемы возникали и как их получилось решить.

Демонстрация результатов. В конце спринта команда проводит презентацию продукта.

Ретроспектива. По окончании спринта команда обсуждает, что получилось хорошо, а что плохо. Это помогает учиться на ошибках и постоянно совершенствоваться.

Повторение. После ретроспективы готовятся к следующему шагу. Команда выбирает новые задачи из тз, планирует следующий спринт, и цикл начинается вновь.

Ежедневно вся команда собирается не более чем на 15 минут. Цель встречи — услышать от каждого участника ответ на три вопроса:

Что я сделал с прошлой встречи? Что я буду делать сегодня? Что мешает выполнению задачи?

На основании этих микроотчетов Scrum-мастер (координатор) старается понять, так ли идет рабочий процесс и как можно помочь команде преодолеть препятствия.

Команда использует доски, пространство которых разделяется на части, отражающие стадии работы над продуктом. Их количество может варьировать, но обязательно включает в себя три составляющих (слева направо):

запланированные задачи; задачи в активной работе; выполненные задачи.

Доска — это визуальное отображение рабочего процесса на разных стадиях. С ее помощью каждый член команды может контролировать свою работу и следить за проектом. Удаленная координация осуществляется через телеграфные коды. Философия

Постоянное самосовершенствование и самообучение команды.

Автономность. Каждый участник несет ответственность за свою часть работы и за общий результат.

Кроссфункциональность. Наличие в команде людей с разными навыками делает ее самодостаточной.

Внедрение и обратная связь. После всех спринтов — релиз. Заказчик и архитектор, корректор дают обратную связь, на основе которой команда дорабатывает продукт.

Чем Scrum отличается от Kanban (у ГГ система Родова) — структурированный подход с заданными этапами создания продукта, а Kanban — сбалансированный, основная цель которого — обеспечить всех членов команды одинаковым количеством работы. В Scrum предусмотрены организованные периоды работы с задачами на период. В Kanban новые задачи могут появляться в любой день. Scrum-команды работают в течение заданного отрезка времени, а в Kanban задачи поступают непрерывно и больше подходя для производства.

Основная разница между Scrum и Канбан — в длине итераций. В Scrum итерации — 2 недели, в Kanban задачи можно «подсовывать» хоть каждый день.

Kanban дает больше гибкости, если под гибкостью понимать частоту смены приоритетов. Вчера исполнитель сделали новую схему, а сегодня получили данные из мастерской и узнали, что она не работает так, как было задумано. Координатор просит переделать схему, и послезавтра мы пробуем новую деталь.

В варианте Scrum от ГГ задачи оценивают в баллах. Без оценки не получится сформировать спринт: ведь нам нужно знать, успеем ли мы сделать задачи за 2 недели. Через 2 недели мы получаем ценную статистику — сколько часов команда смогла сделать за сприн. Velocity — это индекс в баллах, производительность команды за один спринт. Этот параметр позволяет координатору предсказать, где команда будет через 2 недели.