Цитаты из книг автора «Дэвид Андерсон»

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

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

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

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

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

Но мы сможем ответить им, что у нас есть заранее оговоренный WIP-лимит и его надо уважать. Система к тому времени, вероятно, будет полной, и согласие взять дополнительный элемент будет означать превышение WIP-лимита. Поэтому наш ответ должен звучать так: «Мы охотно взяли бы новую работу, потому что понимаем, как она важна для вас. Но вы ведь знаете, что у нас есть заранее оговоренный WIP-лимит.

Если в команде десять разработчиков и вы сможете договориться о двух заданиях, одновременно выполняемых одним человеком, то получаете в итоге WIP-лимит на команду, равный 20.

Обязательства в Канбане предполагают, что все в цепочке создания ценности заботятся о производительности системы: количестве и каче­стве выпускаемых программ, частоте релизов и времени их выполнения. Канбан просит партнеров по цепочке создания ценности придерживаться концепции подлинной деловой гибкости и соглашаться на совместную работу по ее достижению. Это существенно отличает Канбан от более ранних agile-подходов к разработке ПО.

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

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