Natalia Bobrova – Системный аналитик за неделю (страница 2)

3. Нельзя начинать новую карточку, если не сделана предыдущая. Если задача по каким-то причинам не может быть завершена, ее нужно перенести в колонку Blocked и искать другие способы ее завершения.

Главный закон эффективности канбана – «прекращайте начинать, начните заканчивать»

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

–срочный – нельзя откладывать;

–с фиксированной датой – нужно сделать к определенному сроку;

–стандартный – издержки растут пропорционально задержке, желательно сделать вовремя;

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

Преимущества Kanban.

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

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

Повышение эффективности работы. Многозадачность снижает качество работы и замедляет продвижение вперед. Чем больше зависает нерешенных задач, тем чаще приходится между ними переключаться. Метод канбан минимизирует застои, поскольку помогает быстро выявлять слабые места. Это позволяет сокращать время работы над задачей и повышать качество результата.

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

Минусы Kanban.

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

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

Когда и кому нужен канбан.

Выделяют несколько характерных сигналов, которые указывают на возможность и даже необходимость внедрения канбана:

–команда выполняет много однотипных задач, и важным улучшением было бы делать это быстрее;

–участники команды постоянно перегружены – нет времени на улучшение, им бы справиться с имеющейся нагрузкой;

–регулярно срываются дедлайны;

–руководителю кажется, что вокруг хаос – непонятно, кто чем занят и когда поставленные задачи будут выполнены;

–исполнителю непонятно, кто ставит задачи и чьи распоряжения приоритетнее.

Если в команде имеются две и более проблемы из списка – канбан может стать эффективным способом усовершенствовать работу. Что касается бизнеса, то метод применим к любой сфере, где можно выделить этапы и типы работ.

LeSS.

Это фреймворк, позволяющий применить принципы скрама в больших проектах.

Одним из принципов LeSS является «получать большее за счёт меньшего», что значит не создавать бюрократии и обходиться без лишних ролей, процессов и артефактов.

LeSS предлагает два различных фреймворка масштабного Scrum. Большая часть элементов LeSS, связанных с масштабированием, фокусирует внимание всех команд на всем продукте нежели на “своей части” продукта. Глобальный и сквозной (“end-to-end”) фокус, наверное, самые важные и требующие решения проблемы при масштабировании. Вот два фреймворка, которые по сути представляют собой масштабируемый однокомандный Scrum:

–LeSS: до 8 команд (каждая из которых до 8 человек).

–LeSS Huge: до нескольких тысяч человек, работающих над одним продуктом.

Составляющие LeSS :

–Единственный Бэклог Продукта (потому что он для Продукта, а не для команды),

–Единые критерии готовности для всех команд,

–Один Потенциально пригодный к использованию и выпуску Инкремент Продукта в конце каждого Спринта,

–Единственного Владельца Продукта,

–Множество полностью кросс-функциональных команд (без узкоспециализированных команд),

–Общий Спринт.

В LeSS все команды работают в одном общем спринте для создания общего готового к выпуску Продукта каждый спринт.

Отличия LeSS от Scrum.

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

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

Ежедневный Скрам: Это мероприятие также проводится независимо каждой из команд. Однако, для более полного обмена информацией между командами, участник команды А может быть наблюдателем на Ежедневном Скраме команды Б.

Координация: Техники: “Просто поговорить”, “Коммуникации в коде”, “Путешественники”, “Открытое пространство” и “Сообщества”.

Общее уточнение Бэклога Продукта: Возможно проведение короткой и опциональной встречи по общепродуктовому уточнению в бэклога, в котором участвуют Владелец Продукта и представители всех команд. Основное назначение данного мероприятия – это решить каким командам предпочтительнее работать над какими элементами Бэклога, и, соответственно, выбрать эти элементы бэклога для дальнейшего более глубокого уточнения на командной сессии Уточнения Бэклога Продукта.

Уточнение бэклога продукта: Также как и в однокомандном Скраме, LeSS явно требует только проведение однокомандного Уточнения Бэклога Продукта. Но общепринятой и полезной практикой является проведение многокомандного Уточнения Бэклога Продукта. Когда две или более команд проводят уточнение в одном помещении, чтобы усилить обучение и координацию.

Обзор спринта: Помимо единственного Владельца Продукта в этом мероприятии участвуют члены всех команд, потребители/пользователи и другие заинтересованные лица. Для фазы инспекции инкремента продукта и новых элементов бэклога, можно использовать техники “базар” или “научная выставка”: большое помещение с несколькими зонами, в каждой из которых происходит презентация и обсуждение разработанных элементов Бэклога одной из команд.

Общая ретроспектива: Это новое мероприятие, которого нет в однокомандном Скрам, и его цель – улучшить систему в целом, вместо фокусировки на одной отдельной команде. Максимальная длительность этого мероприятия 45 минут на каждую неделю Спринта. В нем участвуют Владелец Продукта, Скрам-Мастера и ротирующиеся представители каждой из команд.

SAFE.

Scaled Agile Framework (сокращенно SAFe) – это методология для работы с командой. Она помогает, используя методы Agile, управлять сложными проектами в больших командах – от 50 человек.

Три уровня управления разработкой в SAFe.

1. Командный уровень

Единица управления на данном уровне – команда, реализующая пользовательские истории из бэклога. Роли на данном уровне такие же, как и в классическом Scrum: Владелец продукта, Scrum-мастер, член команды разработки.

2. Программный уровень

На этом уровне все ресурсы, команды, заинтересованные лица кооперируются вокруг одной важной цели, чаще всего представляющую собой поток создания ценности (Value Stream) или продукт. Синхронизируют свою работу команды при помощи совместных сессий планирования (Program Increment Planning) в начале каждого квартала и демонстрации интегрированного инкремента продукта (System Demos) каждые 2 недели и ретроспективы (Inspect & Adapt) в конце каждого квартала.

Соответственно, все роли и процессы ориентированы на поставку ценных элементов функциональности. Метафорой этого процесса является “Поезд” (Agile Release Train).

ART – это долгоживущая группа команд, заинтересованных лиц и других участников, объединённых общей целью, создающая в едином ритме общее решение или его часть. Длина итераций и частота общего планирования внутри поезда фиксирована.

Управляет «Поездом», соответственно, «Машинист» (Release Train Engineer). Он коучит весь «экипаж» поезда для повышения эффективности работы, взаимодействует с заинтересованными сторонами, фасилитирует общие собрания поезда поставки. Release Train Engineer больше похож на Scrum-мастера, но отвечающего не за одну, а за много команд и их взаимодействие между собой. В терминах PMI «Машинист» соответствует Менеджеру программы по уровню ответственности и исполняемым функциям (The PM role in a lean and agile world).

У поезда также есть главные «пассажиры» –  Представители бизнеса (Business Owners). Это основные заинтересованные лица, которые отвечают за финансовые показатели Поезда. Business Owners – это руководители, которые будут получать выгоду от создаваемого решения, пользоваться им или продавать его.