Комментарии 8
Мне вот всегда интересно то, что происходит на границах Agile-команды, а не внутри. Допустим, владелец продукта говорит "мне нужно, чтобы фича Х отрабатывала на 8 секунд быстрее, тогда за год на уменьшении тормозов контора сэкономит Y*100000 рублей".
Члены команды анализируют свой продукт и получается, что силами разработчиков (оптимизацией кода) можно ускорить на 2 секунды, а для реализации оставшихся 6 нужно перейти на Full-flash СХД.
А дальше? Отдел закупок тоже работает по Agile и быстро покупает? Или работает по-старинке и тянет резину (конкурсы там какие, сбор КП и т.д.)? Или как?
В итоге через некоторое время многие команды плюют на Agile и работают на его подобии адаптированной к реалиям.
Многие аджайл коачи топят за самоорганизацию, в том числе и в выборе процессов внутри команды, скрам, канбан, скрамбан и т.п. Но это не всегда сочетается с видением менеджмента, который может хотеть, чтоб все команды гребли в такт. Т.е. в идеале от аджайла не уходят, если целью остается работающий продукт и работа над тем, что действительно важно в данный момент.
А написан он так "криво" потому что спринты, неправильная оценка трудозтарат, внезапные срочные задачи и дедлайны заказчиков взятые с потолка, т.к. при заключения договора не было все четко зафиксировано, плохой кодревью и т.п.
Дедлайны - это уже, по определению, не аджайл, так же как заключение fixed-price договоров. Спринты - всего лишь механизм для переоценки приоритетов.
Если руководство не понимает, зачем им аджайл, то он не полетит, и недовольными останутся все.
Зависит от компании. Аджайл - про то что можно сделать здесь и сейчас. В стартапе не проблема решить подобный вопрос в течении дней-недель, в то время как в энтерпрайзе на согласование могут уйти многие месяцы, даже если все команды живут аджайлом, так как бюджеты по отделам на текущий год уже спланированы.
Вопрос: почему об этом не заботится владелец Продукта? По разным причинам. Например, здесь и сейчас он не думает об этом или у него недостаточно компетенций (так иногда бывает), которые как раз есть у agile-коуча
Другими словами это не отдельное направление agile-коучей, а просто помощник владельца Продукта. Зачастую Product Owner может быть и владельцем бизнеса и совладельцем бизнеса и высокопоставленным менеджером, которому доверяет спонсор, или просто высокопоставленным менеджером, чья недостаточная квалификация в agile никак не может поспособствовать на то, чтобы заменить его другим. Поэтому бывает нужен ему помощник, более технический.
Но называть это целой отдельной карьерной областью...
Итак, agile-коуч — это специалист, который приобщает к ценностям компании и помогает бизнесу расти. Его задача привносить гибкость в текущую рутину.
Что-то из разряду "эффективные менеджеры обучают успешному успеху". Кто не учится - тот не хипстер.
Вся статья пропитана духом "посмотрите, мы менеджеры тоже хотим хорошо кушать".
А для пущей важности тупо используются термины которые лень переводить: agile, coach, facilitaion, последнее слово вообще русскому уху воспринимается как маст**бация. В общем-то статья как раз об этом.
Перезагрузка рабочего процесса руками и глазами Agile-коуча