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