Внедряем процессы
Бывает так, что работают внутри компании несколько групп, выпускают то, что должны выпускать. Но вдруг, одна из этих групп лажает (ну бывает, релиз прошел не совсем гладко, багу упустили или просто не учли, что изменение «тут» повлечет за собой косяк «там»). Если повезет, то из-за этого может подняться громкая буча и с лозунгами «С этим надо что-то делать» или «Давайте сделаем так, что бы подобное никогда не повторялось» начинает строить процесс с большой буквы П.
Сразу скажу, я не против процессов. Я против процессов, которые построили не подумав, с единственной целью построить процесс и наладить конвеерное производство артефактов в виде write-only документов.
Итак, какие неприятности нас подстерегают при попытке построения процесса (типа формализованного Release Management, Change Management или еще что угодно Management)?
Беда 1: Ложная экономия.
Предположим, мы ведем высоко-итеративную разработку и делаем N релизов в неделю. При этом исторические данные говорят, что мы факапим с вероятностью P, после чего тратим Q времени на разгреб факапа.
Внедрение процесса не сделает значение P=0. В лучшем случае оно его уменьшит (что еще не факт), скажем, до величины P’. Так как вероятность факапа не станет нулевой, нам все равно придется тратить время Q’ на разгреб факапов, но при этом следование процессу неизбежно повлечет за собой затраты T в виде накладных расходов.
Также будем считать, что на времени разработки D процесс релиза никак не сказывается (для простоты трудозатраты на разработку фич для каждого релиза считаем постоянным).
После внедрения процесса выход команды (число фич в неделю) будет равно:
N`=N*(D+Q*P)/(D+P`*Q’+T)То есть, при условии
Q*P < P`*Q’+T
Выход команды снизится.
Если формулы читать не удобно, то давайте с цифрами. Предположим 1 из 10 релизов мы факапим (P=0.1), после чего тратим Q=1 час на разгреб этой прелести. За неделю нам удается отрелизится 10 раз (наша группа живет именно в таком ритме). То есть матожидание трудозатрат на разгреб факапов - 1 час.
Хорошо, теперь нам выдали процесс, уменьшающий вероятность факапа в 2 раза, но при это приходится тратить 0.25 часа на релиз. Таким образом матожидания времени на разгреб факапов у нас стало 0.5 часа, но за это мы платим 2.5 часа.
Итого 2 часа чистого убытка.
Кстати, если основной целью ставилось уменьшение числа факапов, то легко можно легко построить процесс с достаточно большим T, но с P=P`, и Q=Q` (то есть, ни трудозатраты на разгреб факапа, ни их вероятность не меняются. Такой процесс легче всего построить). В этом случае, как ни странно, число факапов изменится и составит:
N`=P*N/(1+T/(D+P*Q))
Формула говорит о том, что если процессные накладные расходы будут сравнимы с трудозатратами на разработку, то естественным образом, без всяких изобретательств мы уменьшаем число факапов в 2 раза! Шикарно?
Беда 2: Риск срыв потока
Если внедряется формализованный процесс управления релизами и/или изменениями, то неизбежно появляется такой орган, как CAB (Change Advisory Board), CCB (Change Control Board) или еще как-нибудь в этом духе. Этот орган представляет собой группу людей, заслуживших авторитет экспертов и, как правило, находящихся вне контекста. Если релизов или изменений много, то их принято пакетировать, что бы не созывать этот орган по каждому пустяку, а вызывать их раз в неделю для анализа сразу 10 изменений.
Что получаем? Если раньше жизненный цикл фичи выглядел как:
взлабали -> протестировали -> отрелизили -> понаблюдали -> отчитались
То теперь он становится:
Взлабали -> протестировали -> отправили на CCB/CAB -> подождали -> отрелизили ->…
Казалось бы, что в этом плохого? Можно же отправить на CCB/CAB и лабать одновременно? Можно. Но в этом случае орган принимает решение о релизе фичи, которая еще не разработана. В ходе разработки она может немного отклониться от того, как ее утвердили.
Ожидание, вроде как, тоже не беда. Ведь в это время можно делать что-то еще? Можно, но тогда мы получаем затраты на переключение контекста, плюс повышаем объем незавершенного производства. Что не очень хорошо.
Но самое очевидное, так это мы растягиваем время цикла и уменьшаем его эффективность. В итоге то, что от запроса до релиза раньше требовало 2-3 дня, теперь потребует минимум неделю, из которых половину времени эта задача будет просто ждать. Кому как, но мне, верующему в Lean, ожидание кажется таким же грехом как и простое рас3.14здяйство.
Беда 3: Cover Your Ass Engineering
Иногда, участников CCB/CAB может обуять желание прикрыть свой зад или немножечко самореализоваться. Как результат, могут возникнуть предложения переделать все, что бы оно удовлетворяло Великой Архитектуре/Политики Безопасности/Корпоративным Стандартам/Заветам Ильича. Иногда такие предложения осмысленны, а иногда не очень:
- Итак, что ваша система будет делать?
- Она будет облегчать жизнь девочкам из бухгалтерии. Раньше они получали напечатанные отчеты от расчетчиков, а теперь мы сделаем им веб-сервер, откуда они все будут скачивать сами
- Веб-сервер! Это же не секьюрно! Согласно политике безопасности, доступ для получения отчета должен быть одноразовым. Обновление доступа производится при личном обращении в отдел расчетчиков и подписывается на бумаге их начальником. По-другому никак нельзя…
В общем, строить общие правила жизни сложное занятие. Местами неблагодарное… Ведь помимо этих бед есть еще и другие, такие как "равнение на самого слабого", "инструмент купили, а про процесс забыли"... Какие еще беды вы встречали?
Сразу скажу, я не против процессов. Я против процессов, которые построили не подумав, с единственной целью построить процесс и наладить конвеерное производство артефактов в виде write-only документов.
Итак, какие неприятности нас подстерегают при попытке построения процесса (типа формализованного Release Management, Change Management или еще что угодно Management)?
Беда 1: Ложная экономия.
Предположим, мы ведем высоко-итеративную разработку и делаем N релизов в неделю. При этом исторические данные говорят, что мы факапим с вероятностью P, после чего тратим Q времени на разгреб факапа.
Внедрение процесса не сделает значение P=0. В лучшем случае оно его уменьшит (что еще не факт), скажем, до величины P’. Так как вероятность факапа не станет нулевой, нам все равно придется тратить время Q’ на разгреб факапов, но при этом следование процессу неизбежно повлечет за собой затраты T в виде накладных расходов.
Также будем считать, что на времени разработки D процесс релиза никак не сказывается (для простоты трудозатраты на разработку фич для каждого релиза считаем постоянным).
После внедрения процесса выход команды (число фич в неделю) будет равно:
N`=N*(D+Q*P)/(D+P`*Q’+T)То есть, при условии
Q*P < P`*Q’+T
Выход команды снизится.
Если формулы читать не удобно, то давайте с цифрами. Предположим 1 из 10 релизов мы факапим (P=0.1), после чего тратим Q=1 час на разгреб этой прелести. За неделю нам удается отрелизится 10 раз (наша группа живет именно в таком ритме). То есть матожидание трудозатрат на разгреб факапов - 1 час.
Хорошо, теперь нам выдали процесс, уменьшающий вероятность факапа в 2 раза, но при это приходится тратить 0.25 часа на релиз. Таким образом матожидания времени на разгреб факапов у нас стало 0.5 часа, но за это мы платим 2.5 часа.
Итого 2 часа чистого убытка.
Кстати, если основной целью ставилось уменьшение числа факапов, то легко можно легко построить процесс с достаточно большим T, но с P=P`, и Q=Q` (то есть, ни трудозатраты на разгреб факапа, ни их вероятность не меняются. Такой процесс легче всего построить). В этом случае, как ни странно, число факапов изменится и составит:
N`=P*N/(1+T/(D+P*Q))
Формула говорит о том, что если процессные накладные расходы будут сравнимы с трудозатратами на разработку, то естественным образом, без всяких изобретательств мы уменьшаем число факапов в 2 раза! Шикарно?
Беда 2: Риск срыв потока
Если внедряется формализованный процесс управления релизами и/или изменениями, то неизбежно появляется такой орган, как CAB (Change Advisory Board), CCB (Change Control Board) или еще как-нибудь в этом духе. Этот орган представляет собой группу людей, заслуживших авторитет экспертов и, как правило, находящихся вне контекста. Если релизов или изменений много, то их принято пакетировать, что бы не созывать этот орган по каждому пустяку, а вызывать их раз в неделю для анализа сразу 10 изменений.
Что получаем? Если раньше жизненный цикл фичи выглядел как:
взлабали -> протестировали -> отрелизили -> понаблюдали -> отчитались
То теперь он становится:
Взлабали -> протестировали -> отправили на CCB/CAB -> подождали -> отрелизили ->…
Казалось бы, что в этом плохого? Можно же отправить на CCB/CAB и лабать одновременно? Можно. Но в этом случае орган принимает решение о релизе фичи, которая еще не разработана. В ходе разработки она может немного отклониться от того, как ее утвердили.
Ожидание, вроде как, тоже не беда. Ведь в это время можно делать что-то еще? Можно, но тогда мы получаем затраты на переключение контекста, плюс повышаем объем незавершенного производства. Что не очень хорошо.
Но самое очевидное, так это мы растягиваем время цикла и уменьшаем его эффективность. В итоге то, что от запроса до релиза раньше требовало 2-3 дня, теперь потребует минимум неделю, из которых половину времени эта задача будет просто ждать. Кому как, но мне, верующему в Lean, ожидание кажется таким же грехом как и простое рас3.14здяйство.
Беда 3: Cover Your Ass Engineering
Иногда, участников CCB/CAB может обуять желание прикрыть свой зад или немножечко самореализоваться. Как результат, могут возникнуть предложения переделать все, что бы оно удовлетворяло Великой Архитектуре/Политики Безопасности/Корпоративным Стандартам/Заветам Ильича. Иногда такие предложения осмысленны, а иногда не очень:
- Итак, что ваша система будет делать?
- Она будет облегчать жизнь девочкам из бухгалтерии. Раньше они получали напечатанные отчеты от расчетчиков, а теперь мы сделаем им веб-сервер, откуда они все будут скачивать сами
- Веб-сервер! Это же не секьюрно! Согласно политике безопасности, доступ для получения отчета должен быть одноразовым. Обновление доступа производится при личном обращении в отдел расчетчиков и подписывается на бумаге их начальником. По-другому никак нельзя…
В общем, строить общие правила жизни сложное занятие. Местами неблагодарное… Ведь помимо этих бед есть еще и другие, такие как "равнение на самого слабого", "инструмент купили, а про процесс забыли"... Какие еще беды вы встречали?