Стоп "Стать agile "!
Три разговора, которые вы должны провести, прежде чем начать
Слишком часто компании ставят перед собой миссию «стать agile», прежде чем по-настоящему понять, что это значит. Трещины начинают проявляться, и ожидания пропускаются, в результате чего все подвергают сомнению ценность «стать agile» и снижают ваши шансы на успех.
Правда в том, что agile работа приведет к более продуктивным командам и более быстрому предоставлению проектов, но только если все смогут договориться о правилах игры. Присоединяйтесь к Хизер Флеминг и Джастину Рисервато из гиганта электронной коммерции Gilt, которые обсуждают, почему достижение консенсуса по принципам гибкой технологии важнее, чем внедрение процесса.
В частности, Хизер и Джастин исследуют ответы на три жизненно важных вопроса, к которым должна быть готова любая команда, прежде чем отправиться в agile путешествие:
- "Но когда ты будешь сделан?" Почему избавление от концепции сроков является самым важным (и самым сложным) разговором, когда становишься agile.
- «Это мой главный приоритет, но я не смогу встретиться с тобой до следующей недели». Что делать, если ваш деловой партнер не может (или не хочет) быть полноправным членом команды.
- «Я просто хочу кодировать. Почему я должен присутствовать на всех этих встречах?» Почему внедрение Scrum не первый шаг к гибкости
СМОТРИТЕ И ИЗУЧАЙТЕ
ВИДЕО
Вопросы & ответы
Здесь Хизер и Джастин выбрали некоторые из главных вопросов сессии ВОПРОСЫ & ОТВЕТЫ этой презентации. Читайте больше, чтобы глубже погрузиться в тактику о том, как применять гибкие методологии.
ВОПРОС 1: Цифровая agile доска против физической agile доски ? Как вы относитесь к ним?
ОТВЕТ 1: Это действительно зависит от настроек вашей команды. Вы все в одном и том же месте? Насколько велика ваша команда? У вас есть место для большой физической доски? Мы проделали обе работы в Gilt, но обнаружили, что по мере роста и расширения до десятков команд agile доски в программном обеспечении JIRA более практичны, чем физические доски. Их проще настраивать и вносить изменения, а также делиться ими с удаленными членами команды. Что нам нравится в физических досках, так это то, что вы просто не можете их игнорировать, они так перед вами. И они являются отличным местом для проведения импровизированных дискуссий о текущей работе или для проведения летучек, если вы делаете это.
ВОПРОС 2: Как вы можете работать с менеджером или клиентом, который не следует или не понимает agile процесса? Иногда я чувствую себя неудачным тренером рабочего процесса.
ОТВЕТ 2: Важно подумать о вашем порядке операций. Если вы пытаетесь работать в agile процессе с людьми, которые не верят в это, то вы немного злитесь. Наиболее важной частью этой работы является достижение консенсуса в философии, прежде чем вы начнете выполнять процесс.
Мы делали это в прошлом, рассматривая конкретные проблемы, которые возникают у команды с текущим процессом, и решали их способом agile. Можете ли вы провести своего менеджера или клиента через реальные проблемы, которые они пытаются решить, и о том, как бы вы подошли к этому в гибкой среде? Можете ли вы взять их постепенно, чтобы стать гибкими, а не в большой смене всего процесса? Затем вы можете постепенно показывать реальные результаты, поскольку команда работает лучше. Короче говоря, используйте Agile подход к Agile. ;)
ВОПРОС 3: Как вы можете внедрить Agile-процесс, когда у проекта фиксированная ставка и / или фиксированный график с установленным списком требований для реализации?
ОТВЕТ 3: Во-первых, невозможно успешно завершить проект с заданным графиком и фиксированным списком требований для внедрения, так есть ли способ заставить всех согласиться с тем, что это фантастическая идея ? Большинство ограничений по срокам и требованиям не являются истинными ограничениями: это только желания. Начните обсуждать, почему вы делаете работу, или какую проблему вы пытаетесь решить. Если вы действительно понимаете цели проекта и причины ограничений, вы можете убедиться, что команда выполняет правильную работу в нужное время. Запись всех требований с датами рядом с ними волшебным образом не заставляет все происходить вовремя.
ВОПРОС 4: У большинства проектов есть дата выпуска релиза, которая обычно сообщается партнерам и клиентам. В этом сценарии единственной предметом переговоров является набор функций (хотя есть некоторые компромиссы по качеству). Как вы работаете в условиях жестких сроков?
ОТВЕТ 4: Мы думаем, что вы ответили на это сами - вы делаете это путем согласования объема. Если вы этого не сделаете, вы правы, что качество пострадает. Думать, что вы можете просто зажать объем независимо от того, что является мечтой - вам нужно убедиться, что ваши команды работают с реальностью, даже если это не то, что люди хотят услышать. Хезер написала короткую запись в блоге на эту тему, которую вы можете прочитать здесь.
ВОПРОС 5: Как, по-вашему, следует изменить способ реализации scrum?
ОТВЕТ 5: Жесткость scrum является нашей самой большой проблемой. Думать, что один высокопредписывающий процесс будет работать для всех команд, независимо от того, над чем они работают и кем они являются, является самонадеянным. Мы видели, как это работает для команд, но scrum - не единственный способ быть agile, и многие команды терпят неудачу с гибкостью, потому что они думают, что им нужно реализовать scrum особым образом со всеми предписанными рабочими ролями, пользовательскими историями, критериями принятия, встречами и артефактами. У Хизер также есть задача с названием «Scrum Master»;)
ВОПРОС 6: Как вы можете предотвратить непосредственное влияние заинтересованных сторон на членов команды?
ОТВЕТ 6: Ну, хорошая заинтересованная сторона - это сам член команды. Так что в идеале привлекай те ключевую заинтересованную сторону в свою команду, чтобы вы все могли работать вместе! Если у вас есть заинтересованные стороны, которые просто бросают вещи за стену своей команде или вмешиваются во время проекта и пытаются изменить все, что важно, чтобы вся команда понимала, что они делают и почему. Поэтому независимо от того, с кем общаются заинтересованные стороны, они получат один и тот же ответ. Вот что делает вас командой, а не коллекцией индивидуалов. Вам нужно много общаться - и убедиться, что все находятся на одной странице и движутся в одном направлении.
ВОПРОС 7: Оцениваете ли вы истории на основе приблизительного порядка величин (в часах) или на основе баллов?
ОТВЕТ 7: Мы делаем оба варианта, однако есть некоторые команды которые вообще не оценивают. Очки великолепны тем, что они более абстрактны и не привязаны к какому-либо конкретному календарному времени. Часы могут быть полезны в качестве перехода, если ваша команда сопротивляется оценке, поскольку она более ощутима. Смысл оценки заключается в том, чтобы уметь определить, является ли ваш спринт слишком тяжелым или слишком легким, и есть ли необходимость отрегулировать его, или оценки действительно бесполезны после запуска спринта. Мы находим, что после того, как вы поработали некоторое время с командой, процесс оценки становится ненужным. Мы все можем посмотреть на работу и довольно легко оценить, является ли это правильным количеством для спринта.
ВОПРОС 8: Какую ценность вы вкладываете в руководителей проектов / менеджеров, обладающих навыками глубокого анализа и знанием продукта, по сравнению с просто координацией встреч между заинтересованными сторонами в сфере технологий и бизнеса для сбора требований?
ОТВЕТ 8: Практически вся ценность :) Координация встреч, ведение заметок и т. д. Не являются специальными навыками. Любой может их сделать. Хотя важно, чтобы они произошли, на самом деле это не самая большая добавленная стоимость, которую вы можете предоставить команде. Если все, что вы делаете, это административная работа, то команда вправе задаться вопросом, почему вы являетесь ее частью. Каждый в PMO в Gilt имеет глубокое понимание соответствующего предмета и инструментов и техники для выполнения работы, и они приносят это с собой в каждую команду, над которой они работают. Многие из нас были инженерами ранее или работали с другими отделами в Gilt и привели с собой уникальную экспертизу.
ВОПРОС 9: В общем, насколько велики команды и какие предпосылки имеют люди в Gilt?
ОТВЕТ 9: В идеале мы хотим, чтобы наши команды были стройными, но достаточно большими, чтобы быть самодостаточными, что позволило бы им продвигаться вперед по проектам без зависимости от других команд. Мы следуем правилу «две пиццы»: команды должны быть в состоянии питаться двумя пиццами. Мы также твердо убеждены в том, что каждый человек в команде приносит с собой набор уникальных талантов, и они должны иметь возможность привнести эти таланты в команду независимо от того, какое у них звание. Так что, если владелец продукта традиционно отвечает за все презентации, но они только теряют от этого и если есть инженер, который отлично разбирается в рассказывании историй и побеждает аудиторию, мы позволим инженеру привнести этот талант в команду. Вы являетесь большим, чем ваша должность!
ВОПРОС 10: Как вы управляете отдельной командой проверки качества (QA), особенно если тестирование может происходить в другом спринте от разработки?
ОТВЕТ 10: Это одна из наиболее противоречивых позиций, которую мы занимаем, но у нас нет отдельной команды QA в Gilt. Мы верим в автоматизированное тестирование на протяжении всего процесса разработки и развертывания. Команды несут ответственность за качество своего кода. Если у вас есть время и опыт для написания кода, то у вас есть опыт и время для написания тестов для него. Передача этого через стену команде QA никогда не показала хороших результатов для нас, и требует много дополнительной документации и времени, чтобы привести команды QA к скорости.
ВОПРОС 11: Если у вас есть команды, которые работают над несколькими «продуктами» одновременно, будет ли это работать так, чтобы все менеджеры по продуктам находились в комнате во время планирования спринта и позволило им определить относительные приоритеты для всех продуктов? Есть другие идеи?
ОТВЕТ 11: Стоп! Очевидно, это не сработает. В команде должен быть собственный менеджер по продукту, и он не должен работать над несколькими продуктами для нескольких менеджеров по продуктам, которые находятся за пределами группы. Кто бы ни выступал в качестве руководителя (ведущего) команды, он должен подойти здесь и четко изложить методологию группы по определению приоритетов, и в каком порядке они будут заниматься выполнением этой работы на основе этой методологии. Это связано с нашей точкой зрения, что «вы должны быть согласованы с вашей методологией, прежде чем сможете начать процесс».
ВОПРОС 12: Я пытаюсь заставить команду маркетинговых креативных сервисов стать agile. У нас есть некоторые продукты в окончательной форме, которые ДОЛЖНЫ быть предоставлены к определенной дате (разработка рекламы для печати в журнале). Как мы вписываем эти проекты в agile структуру?
ОТВЕТ 12: Agile способен справляться с такими ограничениями как эти. Команда должна определить, что должно быть сделано, и когда, и спланировать спринты, соответственно. Agile должен помочь вам уложиться в эти сроки, поскольку он дает вам возможность корректировать свои приоритеты и запланированную работу (объем) каждого спринта. Если вы начнете отслеживать свою скорость, вы скоро сможете определить, собираетесь ли вы выполнить эти сроки раньше, чем позже. Тогда хороший руководитель (ведущий) команды сможет понять о том, что нужно команде, чтобы добиться успеха.
ВОПРОС 13: Разве изменение целей не кажется ползучим?
ОТВЕТ 13: Да, это так, но мы не называем это «расширением области определения [проекта]», потому что мы хотим поощрять изменения во время проекта. Одним из самых больших преимуществ agile философии является то, что она позволяет вам адаптироваться к вещам, которые находятся вне вашего контроля. Если конкурентный ландшафт изменится, или потребности вашего бизнеса изменятся, или появятся новые технологии, вы действительно хотите использовать эту матрицу требований, созданную несколько месяцев назад? Если вы хотите предоставить лучший продукт для своего клиента, примите изменения и используйте его в своих интересах. В Agile нет «расширения области определения [проекта]», » (вставьте здесь уловку джедая).
По материалам Agile Coach "Going agile"