Никита Филиппов: «100% Agile» | Конференция

11 августа, в 15:50 прошла конференция: 100% Agile http://conf.404fest.ru

На вопросы наших пользователей отвечал Никита Филиппов — это он придумал слоган «Атжайл акбар».

Никита фанатично предан Agile. Он длительное время работал в качестве Product Owner. После создал со своим партнером, Асхатом Уразбаевым, компанию «ScrumTrek». На данный момент, это единственная успешная компания в России продающая Agile, решающая проблемы компаний путем улучшения процессов.

Никита тренировал такие известные вэб-проекты, как Хабр, Auto.ru, Badoo и множество других софтверных компаний.

На данный момент он с уверенностью может сказать: «Я могу сделать вам 100% работающий Agile, и вы увидите на сколько лучше, качественнее и быстрее может работать ваша компания!»

Никита о конференции:

Всем спасибо за вопросы. Понятно, что управление разработкой по Agile не так популярнo, как тренды в интернете, вопросы маркетинга и т.д. Но хочется сказать, что уже сейчас люди все больше и больше задумываются о том, как «правильно» строить разработку. 2 года назад все задавали вопросы: «Что это? Зачем это нужно?». Сегодня все подругому. Вопросов не много, но все интересные, и я постараюсь ответить на них с максимальной пользой для вас. Всем, кому интересна тема Agile, могут поглядывать в наш блог, а так же участвовать в бесплатных семинарах сообщества AgileRussia, на которых я всегда присутствую. Всем спасибо и удачи! Увидимся на конференции 404 в сентябре!

Дима Фитискин, организатор конференции:: Свои вопросы Никите я задал еще в кулуарах конференции РИТ-2008. И, вернувшись к работе, мы почти сразу начали внедрять скрам в команде разработчиков и технологов нашей студии. Не скажу, что мы сильно преуспели в этом, полноценный скрам у нас и на сегодняшний день не получается. Но даже при этом мы ощутили серьезные улучшения в работе. Надеюсь, ответы на вопросы помогут вам не сделать тех ошибок, которые сделал я в процессе внедрения скрама.

Константин Дранч: Никита, приходилось ли тебе после компании «Онтел» сталкиваться с особенными до неприличности кружками в офисе?

Никита Филиппов: Ах, Онтел, Онтел… если честно компании в которых я работал после имели свой неповторимый колорит :) Так что да, приходилось!

Александр Савицкий: Никита, привет. Скажи, допустимо ли вносить какие-то изменения в принципы Agile после его внедрения в команде? Насколько эта система гибка? Иными словами, можно ли убавлять или, напротив, добавлять к этому достаточно сложному процессу свои «фишки», методы, правила и, вообще, как-то кастомизировать, затачивать под себя?

Никита Филиппов: Александр, спасибо за вопрос. Начну с того, что процесс Agile крайне легкий, если вы работали по RUPу или водопаду, вы сразу все поймете.

Agile — это процесс, процесс должен работать на благо бизнеса.
Принципов Agile не так много (практик больше): Итеративность, Инкрементальность + манифест: Люди важнее, чем процесс; Рабочий код важнее, чем идеальная документация; Сотрудничество с заказчиками важнее, чем написание контракта. Реакция на изменения важнее следованию плана. Вот принципы, я думаю мало кто с ними не согласиться.
Что касаемо практик, есть инструмент — Scrum, мы его внедряем как шестеренку, не добавляя и не убирая ничего лишнего (потому что убирать уже нечего — пару митингов и коллективная работа), пока команда не научится сама управлять процессом. Вы можете убрать митинги, вы можете отказаться от доски, но вы не можете это сделать если у вас нет ретроспективы. Ретроспектива, как раз то единственное и наиболее важное в процессе, что позволяет вам принимать решения и искать проблемы. Другой вопрос, если вы находите проблемы и не решаете их — это конец всему… причем в любой работе, бизнесе, процессе.

С другой стороны, если у вас сложный бизнес процесс, например, разработка систем безопасности, да, вам приходится наращивать выше Agile-процесса несколько уровней сбора требований, делать более сильное тестирование продукта и так далее…
Если вы стартап или компания размером в 10 разработчиков — вам достаточно наладить коммуникации.
Объединяя вышенаписаное, ответ: Да, кастомизировать можно и нужно, Agile — адаптивный процесс. Другое дело, 10 раз подумайте, чтобы что-то менять. Scrum — это набор бестпрактис, и я даже не знаю, что оттуда можно выкинуть. Добавить — да, но выкинуть — не знаю.

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

Никита Филиппов: От внедрения сложно отказаться, если оно начато.
Да, конечно были такие случаи. Отчасти, по причине не опытности — каждый должен сделать н-ошибок, чтобы понять, что он делает не так. В профессиональной, тренерской деятельности, случаи очень редки, основные причины: Политика и попытка решить с помощью Agile проблемы, которые находятся в области развития продукта. Приведу два маленьких примера:

Вы внедряете Agile: бизнесу нравится идея, команде нравится, тех. диру не нравится — конфликт интересов. Начальник сделает все, чтобы у вас не получилось добиться успеха.
Компания принимает решение внедрить Agile, внедряет. Команда работает отлично, но бизнес все равно недоволен, ругает команду и «Их Agile», команда в ответ говорит: «Сами не знаете, чего хотите». Agile есть, проблема не решается, так как в компании проблема с концепцией продукта, а не с разработкой.

Иван Крюков: И еще интересно, как ScrumTrek построен с точки зрения продаж. Вы ищите клиентов, или они вас находят. Какие методы продвижения своих услуг применяете. Услуга же не простая.

Никита Филиппов: ScrumTrek есть и он работает. Работает хорошо. Чтобы не открывать больших секретов скажу так: Мы рассказываем про Agile, и люди нас находят. Иногда читают блог, иногда слушают на конференциях, иногда просто задаются целью разузнать про Agile и находят нас. С другой стороны, наш бизнес — это бизнес рекомендаций, нельзя заниматься «эффективными» процессами и делать это плохо, поэтому нас рекомендуют компании, которые до этого с нами работали.

Денис Ермаков: Аджаил акбар, Никита! Расскажите, как вы стали неофитом Гибкости? Что вас подтолкнуло туда и зацепило? мм

Никита Филиппов: Здравствуйте, Денис, интересный вопрос.
Все очень просто. После того как я умудрился поработать «никак»(code&fix), поработать по водопаду, дойдя до максимальной формализации процесса, я наткнулся на Agile и попробовал его :). Это стало мне интересно. Оказалось, что несмотря на то, что написано в книжках (а там все легко и просто), внедрение — это работа с людьми и адаптация процесса под каждую компанию (дело достаточно сложное). Я понял, что это не только вкусно, но и полезно. Поэтому познакомившись с Асхатом Уразбаевым, решил создать компанию ScrumTrek.

Александр Фитискин: Привет, Никита. У меня такой вопрос: если команда всячески сопротивляется внедрению базовых аспектов скрама (утренних совещаний, использования доски) и считает, что это лишняя трата времени или это просто что-то ненужное, как ее можно приучить к этому? Есть какие-то ловкие методы для непослушных?

Никита Филиппов: Давайте так, вопрос специфичный, я напишу свои предположения, ибо лечить через телевизор умел только Кашпировский, дальше нужно смотреть на команду и на процесс.
1) Команда не хочет прводить DSM — симптом того, что команда не видит ценности в митингах: нет общих задач, митинг имеет формат «статус митинга». Agile, в первую очередь, командная разработка — команда работает над чем-то одним вместе, а не каждый в команде занимается своим проектом.
Нежелание использовать таскборд, выливается из тех же причин. На доске для каждого из группы разработчиков нет ничего интересного, там только «моя» задача и другие. В этом случае, доска и митинги — это способ контроля работы продукт овнером(а это не его забота).
Попробуйте, сфокусировать разработку на меньшем количестве проектов в итерацию (количество разработчиков / 2 = кол-во проектов). Появится повод для синхронизации, появится потребность в кросфункциональности, повыситься качество. Нужно будет немного поработать с ожиданиями заказчиков. Но, как правило, в скорости вы не упадете. Качество поднимется, появиться самоорганизация.
Вариант второй — пробуйте Kanban — хорошо работает при конвейерной разработке. Например, разработка сайтов на отработанной цмске. Эффект не такой классный как при работе в Scrum, но наша то задача делать максимум в существующих условиях. Возможно ваш максимум — это канбан.

Александр Фитискин: У нас в команде использование пробковой доски «по книжке» не отражает реальной ситуации (параллельных проектов довольно много, задач по ним еще больше). Как правильно использовать доску в этом случае, есть ли какие-то готовые заточенные под такие случаи методики?

Никита Филиппов: Нужно понять, это десять проектов, пять или сто? Длинна итерации — неделя, две или месяц? Боюсь, проблемы вытекают из вопроса про ненужные митинги и таксборд. Лечите не симптомы, а саму причину болезни. Иcходя из практик Lean, быстрее и логичнее строить разработку последовательно, то есть, иcходя из потребностей бизнеса, выстроить разработку так, чтобы за итерацию делать не 10 проектов, а 5. От этого у вас будет меньше переключения контекста разработчика от проекта к проекту (что приводит к потере времени до 30%). С заказчиками поработать с ожиданиями и не работать над 10 проектами одновременно. 10 — это оверхед для сознания человека, невозможно хорошо работать.
И еще, ТаксБорд — инструмент для кооперативной работы разработчиков, чтобы ей пользовались нужно, чтобы работа была кооперативной :), иначе, таскборд — опять же статус-инструмент для менеджера.

Александр Фитискин: Что нужно сделать, сказать, показать команде, чтобы утренние совещания из формы допроса «Что ты сделал вчера и что ты сделаешь сегодня?» перешли в форму беседы «Я вчера сделал … и …, а сегодня сделаю …, и кажется я не успею в спринт …»?

Никита Филиппов: Отпустите вожжи, учтите то, что я написал в предыдущих ответах на ваши вопросы.
Не трогайте команду, пусть она провалится, пусть проведут ретроспективу и выяснят «что нужно сделать, чтобы больше не проваливаться» самостоятельно.
Чтобы небыло допроса, нужно чтобы его никто не проводил. Цель митинга — поделиться важной информацией с командой: Правки в коде, проблемы, которые влияют на результаты итерации, просьба о помощи. Это возможно, если все в «одной упряжке», общие проблемы, и их можно решить внутри команды. P.O. сидит и работает с заказчиками, требованиями и приоритетами — команда сама решает проблемы (не сразу, но будет)

Use Pull, not Push.

Александр Фитискин: Как следует проводить демо в конце спринта, если менеджер (в роли Product Owner'a) видит процесс и продукт по ходу его реализации и в курсе всех тонкостей? Что демонстрировать, кому и в какой форме?

Никита Филиппов:
0) Цель демонстрации: сдача работы, получение обратной связи, обзор итерации целиком.
1) P.O. занимается во время итерации тем, что работает с ожиданиями заказчиков, требованиями и приоритетами. Возможно если он много времени тратит на команду, он плохо работает с требованиями (это оооочень сложная работа).
2) Даже если Менеджер видит результаты работы внутри итерации, demo нужна:
а) для команды, чтобы показать/посмотреть, чтобы было сделано за итеацию.
б) Демонстрация и это процесс сдачи работы командой всего спринта.
в) на демонстрацию может прийти заказчик (внутренний/внешний).
г) Не все, что работает внутри спринта, работает в конце: здесь показываете не «формочку», а целиком работающую фитчу.

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

Сергей Лифшиц: Какие три книги про Agile вы бы могли охарактеризовать как: «классика», «взгляд с другой стороны» и «любимая». Может быть какая-то одна достойна всех трех эпитетов.

Никита Филиппов: Давайте так. MUSTREAD: Agile Development with Scrum, User Stories Applied, Agile Estimating and Planning. Для тех кто понял теорию, но не хватает смелости для практики: Scrum and XP from the Trenches Любимой книги нет, так как опыт описанный в этих книгах никак не описывает особенности работы по Agile и по Agile в России. Скорее всего такая книжка будет вскоре выпущена нами — она и станет любимой, как эссенция нашего опыта.
Сам больше читаю книги по управлению продуктом в Agile, так как это мне ближе и, как практика показывает, Agile дает возможность решать проблемы, но они, зачастую, выше разработки — в продукте, требованиях, маркетинге. Все это имеет особый отпечаток, если вы это делаете в Agile-компании. Cейчас на столе: Innovation Games: Creating Breakthrough Products Through Collaborative Play.

Александр Павлов: Расскажите, как у вас появилась идея заниматься улучшением процессов

Никита Филиппов: Все очень просто, все как в лучших историях о том «как вы решили сделать бизнес?» Я и Асхат, занимались этим в компаниях, работая там fulltime. Оказалось, что это не только нам нравится, но и требуется многим компаниям — так соединилось приятно с полезным!

Алексей Варников: Agile команды являются самоорганизовывающимися. Это подразумевает, что над ней нет «Коммандара», который отдает четкие приказы. Бывает в таких коллективах встречается переизбыток личностей с лидерскими качествами, либо напротив большинство пассивно наблюдают за происходящим. Я говорю о тех случаях, когда мы переводим проект на Agile рельсы и у нас нет возможности подбирать команду с нуля. Какие можно использовать методы уравновешивания коллектива без радикальных увольнений?

Никита Филиппов: Сразу заметка: Agile подход и ретроспективы (reflexion — команды) учат тому, что конфликты это хорошо, но конфликты хорошо, когда их решают конструктивно.
Лидерство это не плохо, как правило, agile позволяет наоборот всем раскрыть свои лидерские способности. Мы называем это ситуационным лидерством, когда в зависимости от активностей в команде разные люди ведут всю команду, кто-то по коду и архитектуре, кто-то по фасилитации (ускорению процесса принятия решений), кто-то по дизайну и продукту.
Поэтому из практики можно выделить два случая.
1) Много ярких людей, которые в agile-фреймворке, учатся разграничивать лидерство, делая его как раз ситуационным. Лучшие качества на благо команды.
Второй вариант, один яркий и пару-тройку тихих. Что достаточно часто бывает; психология разработчика зачастую интровертна, и приходится наоборот вытягивать их на разговор. Agile, в частности Scrum, обладает практиками, которые позволяют работать с такми людьми: коллективная ответственность, митинги для команды, а не для менеджера, коллективное планирование, ретроспективы и демонстрации позволяют развить коммуникативные навыки разработчика и смещать фокус на коллективное принятие решения.
Увольнения отменять нельзя, но это после того, как вы понимаете, что у этого человека в днк прописана не исполнительность и аутичность. Есть Супер-программисты, которые отлично работают в одиночку — дайте им отдельное задание.

Алексей Варников: Знаешь ли ты успешные примеры в мировом масштабе по объединению классического ANSI PMBoK и SCRUM? Вопрос возник в связи с ситуациями, когда конечный заказчик требует видимость соблюдения всей нормативной документации, но при этом его мало волнует как организован сам процесс разработки.

Никита Филиппов: Да, конечно, наверное тебе известна система оценки качества «развитости» процессов CMMI. Сейчас множество докладов и статей на тему CMMI 5 и Scrum.
Чуть глубже в суть проблемы:
Вы используете Agile, потому что это эффективно, но заказчику(государство, оборонка и так далее) пофиг, им нужно (жизненно важно), чтобы все документальные артефакты были отработаны/соблюдены. Как это выглядит на практике? У вас есть Agile-проецесс в идеале, легковесный, быстрый, гибкий. Вам нужно писать отчеты, фанкспеки и так далее… Вы начинаете наращивать эти артефакты (куда деваться), заказчик требует — вы пишите. Ни каких проблем.
Суть в том, что Agile (в разработке) и избыток документации (наверху для заказчика) — это лучше, чем просто избыток документации и водопад.
Добавлю, что по скрам разрабатывали систему(софт) бомбометания одного из последних американских бомбардировщиков. Значит, возможно существовать с высокой формализацией и делать хороший софт итеративно и инкрементально.

Сергей Сергеев: Видно, что не слишком популярная и сложная тема для участников конференции. Что вы можете посоветовать для углубления в улучшение процессов, большое ли значение имеет специфика команды или построение процессов в целом для всех очень схожа, есть ли бесплатные иструменты для методик, которые вы популяризируете, насколько реально самостояельно внедрять подобные методики, либо же наличие команды, внедряющей и обучающей подобные методики — обязательно? Какие бы методы конкуретны вы бы назвали? где эти методы могли бы применяться более успешно, чем ваша?

Никита Филиппов: Вопрос большой и непонятный до конца. Отвечу на то, что понял :)
1) Бесплатные инструменты на блоге нашей компании можете посмотреть в дайджесте статью на сравнение всех известных тулов. + Мы активно рекомендуем ипользовать проект devprom.net.
2) Внедрять всегда можно, реально и нужно. Мы помогаем добиваться наилучших результатов. Внедрение со стороны всегда сложнее, чем изнутри.

Алексей Варников: Предположим я, как Руководитель проекта решил операться на Scrum в процессе разработки ПО. «Scrum-масетром» себя назначить я не могу. Кроме того, в этом случае команда по привычке будет продолжать видеть в моем лице руководителя и ожидать распоряжений. По результатам голосования на эту роль был выбран один из разработчиков, обладающий необходимыми качествами личности. «Владелец продукта» — исполнительный директор компании, по его инициативе был начат проект, он разработал концепцию.

Что остается делать мне, кроме как написать заявление на увольнение? Влиться в команду разработки на равных и программировать плечем к плечу с коллегами? У меня не аналитический склад ума, вдобавок, я планирую карьеру совсем в другом направлении.

Вот и остается либо выбрать себе роль «Scrum-масетра», либо отказаться от затеи переходить на Agile.

Никита Филиппов: Как правило, такие вопросы решаются несколькими способами:
1) На самом деле исполнительный директор компании — это заказчик. Этот человек не может постоянно управлять требованиями согласовывать приоритеты и так далее. Это фултайм работа. Поэтому вы становитесь «владельцем продукта», который занимается разработкой требований, является прокси-заказчиком, так как директор не может быть все время погружен в разработку.
2) История часто встречается в таком ключе: «я тех. директор, раньше я управлял разработчиками, теперь они подчиняются менеджеру, а что мне делать?» Классически технический директор в компании с agile-подходами занимается вопросами people management'a — развитие карьеры сотрудников, аттестация, занимается вопросами формирования и найма отдела — это важная работа.
3) Исполнительный директор — PO. Вы помощник, аналитик.
Не надо никуда увольняться — Внедряйте Agile Удачи!

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

Никита Филиппов: Вопросы внедрения и работы в промышленности охватывает Lean (Software Development), а так же подходы работы с KanBan доской. Там нет итераций, но есть другие метрики и способы контроля. Для внедрения отлично подходит.

Дима Фитискин:: Вопросов было немного, но все они оказались достаточно объемными. Спасибо всем участникам за интересные вопросы и Никите за такие подробные ответы. На этом наша конференция подошла к концу.