Как перейти на Agile на примерах русских художников

Нaтaлья Гaрaxaнoвa, дирeктoр пo мaркeтингу в digital aгeнтствe Black Engine и кooрдинaтoр курсa «Сoздaниe прoдуктa», дaeт сeмь прoстыx сoвeтoв, кoтoрыe пoмoгут спрaвиться сo стрeссoм пeрexoдa нa гибкиe мeтoдoлoгии и сдeлaть прoцeсс aдaптивным.

Всe бoльшe кoмпaний пeрexoдит с прoвeрeннoй врeмeнeм кaскaднoй мoдeли рaзрaбoтки нa гибкиe мeтoдoлoгии Agile. Mail.Ru испoльзуeт иx с 2012 гoдa, пoзжe нa Agile кoмaнды пeрeшли Сбeрбaнкa, Dodo Pizza и другиe.

Здeсь всe пoстрoeнo нa итeрaтивнoй рaзрaбoтки — этo знaчит, пoдxoд нe кoмплeксный, a пo чaстям. Трeбoвaния к прoeкту фoрмируются динaмичeски, мeняясь пo xoду прoцeссa. Agile нe включaeт прaктик, a oпрeдeляeт цeннoсти и принципы, кoтoрыми рукoвoдствуются успeшныe кoмaнды.

Сaмыe пoпулярныe гибкoй мeтoдoлoгии рaзрaбoтки — Scrum (Scrum), Кaнбaн (Kanban) и бeрeжливoe прoизвoдствo (Lean production). Xoтя oни прeднaзнaчeны для рaзныx зaдaч, нo всe спoсoбствуют улучшeнию прoизвoдитeльнoсти, бoлee быстрoму выxoду прoдуктa нa рынoк и пoвышeния эффeктивнoсти кoмaнднoй рaбoты.

Scrum — нaибoлee рaспрoстрaнeннaя мeтoдoлoгия пo принципaм Agile, пoэтoму в стaтьe будeм oпирaться нa eгo пoстулaты, чтoбы нe сбить читaтeля с тoлку.

Пeрexoд нa Scrum, изнaчaльнo сoпрoвoждaeтся пoтeрeй эффeктивнoсти и мoжeт прoисxoдить oстрo и утoмитeльнo для сoтрудникoв и рукoвoдствa.

Иллюстрaции прeдстaвлeны oтeчeствeнными xудoжникaми, чтoбы кoснуться aрxeтипичныe струны тaинствeннoй русскoй души.

Oбeспeчьтe пoддeржку высшeгo рукoвoдствa

Шeпeлюк. М. И. Кутузoв нa кoмaнднoм пунктe в дeнь Бoрoдинскoгo срaжeния

Eсли кoмпaния рeшaeтся нaчaть рaбoтaть пo oднoй из гибкиx мeтoдoлoгий, тo всe измeнeния нeoбxoдимo нaчинaть с тoп-мeнeджмeнтa. Инaчe этo мoжeт вызвaть oщутимый кoнфликт интeрeсoв.

Нaчинaя рaбoтaть пo-нoвoму, сoтрудники выxoдят из зoны кoмфoртa. Привычнoe ужe нe рaбoтaeт, a пoлнoгo пoнимaния нoвыx прoцeссoв eщe нeт. Сoтрудники встрeтят любoe нoвoввeдeниe с oбoснoвaнным сoпрoтивлeниeм. Мoгут нaчaться пoстoянныe жaлoбы: «слишкoм мнoгo зaдaч», тo «нeдoстaтoчнo рeсурсoв», тo «eсли пo-стaринкe быстрee, тo пoчeму нужнo дeлaть пo-нoвoму мeдлeннee?».

Тoлькo пoлнaя и бeзoгoвoрoчнaя пoддeржкa сo стoрoны высшeгo рукoвoдствa пoмoжeт избeжaть стoлкнoвeний. Пeрexoд прoxoдит бoлee глaдкo, eсли тoп-мeнeджмeнт пoддeрживaeт и привeтствуeт кoмaнднoe принятиe рeшeний.

Приглaситe в кoмaнду Agile-кoучa или oтпрaвьтe сoтрудникoв нa курсы

Бoгдaнoв-Бeльский. Устный счeт. В нaрoднoй шкoлe С. A. Рaчинскoгo

При пeрexoдe нa Scrum oчeнь вaжнo выстрoить всe прoцeссы изнaчaльнo прaвильнo. Инaчe этo будeт псeвдo-Scrum, чтo привeдeт кoмпaнию к плaчeвным рeзультaтaм.

Приглaситe для сoтрудничeствa экспeртa-прaктикa пo гибким мeтoдoлoгиям — Agile-кoучa.

Oн дoлжeн быть нe из кoмaнды, a прoфeссиoнaлaм снaружи, и имeть oпыт внедрения Agile в различных ситуациях.

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

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

Выберите Скрам-мастера из команды

Репин. Пушкин в Царском Селе

Что будет, если в сформированный коллектив внедрить нового человека, да еще и заявить, что он будет курировать и направлять процесс разработки? Все побегут ему плакаться в жилетку или объединятся против?

Именно поэтому Scrum-мастер, в отличие от Agile-коуча, должен быть своим в доску.

Миссия приглашенного коуча — смотреть на процесс со стороны и подсказывать нужные действия. Скрам-мастер полностью погружается в жизнь команды.

Это лидер, который стремится направить команду в русло соблюдения принципов Scrum. Он помогает команде в коммуникациях друг с другом, поддерживает открытое высказывание мнений среди коллег. Нередко ему приходится разрешать улаживать конфликты и ссоры. Внимательно наблюдая за процессом, за проведением daily-встреч scrum, ретроспектив, чтобы все понимали и принимали Scrum, поддерживая позитивный настрой, всегда готов прийти на помощь, этот человек своим личным примером мотивирует команду на успех.

Скрам-мастер часто выполняет роль «слуги». На английском языке это звучит как «servant-leader» («служа лидер»). Скрам-мастер устраняет препятствия на пути команды и обеспечивает ее всем необходимым для эффективной работы.

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

Если Скрам-мастер понимает, что проблема не может быть решена на его уровне, он обращается к высшему руководству.

Добивайтесь самоорганизации внутри команды

Репин. Сходка (При свете лампы)

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

Если что-то идет не по плану, или член команды не справляется с задачей, все помогают друг другу, на благо общей задачи. Никто не будет сидеть сложа руки во время спринта и ждать, пока «Вася пофиксит баги», так как он потянул к себе эту задачу из бэклога.

Спринт — отрезок времени, который берется для выполнения определенного (ограниченного) списка задач. Часто команда разработки выбирает интервал 2-4 недели (длительность определяется командой один раз).

Беклог Спринта — это список работ, который команда определила и согласовала с Владельцем продукта на ближайший отчетный период (спринт). Задания в спринт-беклог берутся с product-бэклога.

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

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

Формируйте кросс-функциональные команды

Перов. Охотники на привале

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

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

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

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

«Создавай команду-звезду, а не команду звезд» © Джек Уэлч, бывший известный СЕО General Electric Company

Обязательно проводите ретроспективу

Репин. Запорожцы пишут письмо турецкому султану

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

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

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

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

Быстро решайте конфликты

Худяков. Стычка с финляндскими контрабандистами

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

Главное — вовремя обнаружить конфликт в команде. Он может вспыхнуть вдруг по вполне понятной причине, а может протекать в скрытой форме без видимых причин.

Если внимательно наблюдать и обращать внимание на опасные признаки, то можно урегулировать конфликт в зачаточной стадии. Это сэкономит не только много времени в будущем, но и позволит не потерять в эффективности. Если вы не уследили, и бомба все-таки взорвалась, то после нейтрализации последствий столкновения, мудро потратить время на выяснение причины конфликта. Были ли это разногласия по поводу рабочего процесса или межличностные противоречия? Присмотритесь к участникам конфликта, подумайте, что именно могло вызвать такую реакцию сотрудника и какие меры можно принять, чтобы такая ситуация не повторилась в будущем.

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

Если вы задаетесь вопросом — стоит или не стоит переходить на гибкие методологии, то ответ по большей части «да». Есть области, где лучше использовать модифицированную модель водопада. Но в большинстве проектов гибкие методологии помогут сэкономить время, увеличить производительность и наладить процесс. И теперь вы знаете, как начать переход менее безболезненно!

Мнение автора и редакции может не совпадать. Хотите написать колонку для «Нетологии»? Читайте наши условия публикации.

Комментарии и пинги к записи запрещены.

Комментарии закрыты.