Одна команда одна доска

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



«Один или два»

Допустим, у вас есть команда из 5 человек. Минимальный лимит, который вы захотите установить для каждого, скорее всего будет равен 1. То есть 5 на команду. Но мы помним из прошлой статьи, что низкие лимиты WIP не лучшее решение и, скорее всего, ваши сотрудники будут прохлаждаться. Таким образом, вам кажется, что, возможно лучшим решением будет ввести ограничение в 2 для каждого. Но и это может оказаться не очень хорошей практикой. Потому что если один из элементов будет заблокирован или будет простаивать по какой-то причине, сотрудник может спокойно работать над вторым, не нарушая лимиты. Но ведь вы вводите лимиты не для того, чтобы было удобно работать, вы хотите, чтобы задачи решались, проблемы решались, сотрудники сталкивались с вызовами и принимали их.
Поэтому, возможно, хорошим решением будет ввести ограничение в 8 задач на всю команду, примерно по 1,5 на каждого. С 0,5 задачей работать не очень удобно, поэтому проблемы будут выявляться быстро, а ведь именно это нам и нужно. Возможно, имеет смысл еще сократить число задач и посмотреть на время их прохождения, время появления проблем и их решение и загруженность команды.
Ограничения, указанные в этом примере не так важны, как важно понять сам принцип. Нет четких правил и лимитов на работы, вы сами находите это эмпирически.


«Вместе! Дружно!»

В прошлом примере мы рассмотрели ситуацию, когда у каждого сотрудника есть как минимум одна задача. Но что делать, если у вас коллективная работа? Возможно имеет смысл сделать число задач еще меньше!
Если в прошлый раз мы умножали число задач для каждого сотрудника на 1,5, то теперь мы делим число сотрудников на 1,5. В примере с прошлой командой из 5 человек это даст нам 3 задачи на команду.
Если каждый начнет работать по одиночке, то скоро некоторым членам команды нечем будет заняться. В таком случае им нужно будет самоорганизоваться, скооперироваться и делать работу совместно. А ведь именно это и является признаками agile-команды!

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


«Интервалы -20%»

Для начала определите число задач в неограниченной системе. А как это сделать? Помните, «начните здесь и сейчас»? Прямо сейчас возьмите и посчитайте, сколько задач у вас находится на доске на всех стадиях кроме завершенной. Это и будет число задач в работе в неограниченной системе. А теперь умножьте это значение на два, увеличив таким образом лимит WIP в два раза.
Вы искусственно увеличиваете лимит, потому что в нормальных условиях ни одна команда не сможет достичь его. Таким образом у команды не будет сложности с началом работы и выполнением задач.
И от этого нового порога вы регулярно «отщипываете» -20%. Каждые две недели или месяц, пока не начнут появляться проблемы, скапливаться очереди, возникать узкие места или сотрудники начнут прохлаждаться.

Вводя эту практику вы не только понижаете лимиты работы в процессе, заставляя тем самым задачи проходить быстрее через весь процесс. Вы запускаете тренд постоянной борьбы за улучшение процесса, именно то, что означает «бережливое мышление».
Подход очень хорош тем, что прост во внедрении и позволяет быстро найти нужные ограничения.
Что происходит, когда вы понижаете число задач на 20%? Попробуйте и посмотрите: если не получается, вернитесь назад и подумайте почему это происходит. Что можно сделать по другому, чтобы понизить лимиты задач и при этом сохранить их поток через систему?

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

Made on
Tilda