Хватит «переходить к agile»!

Три беседы, с которыми необходимо ознакомиться, перед тем как переходить к действиям

Martin Suntinger Martin Suntinger
Просмотр тем

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

Правда заключается в том, что гибкость увеличивает продуктивность команд и позволяет быстрее поставлять проекты, только если все согласятся с правилами игры. Присоединяйтесь к обсуждению Хизер Флеминг и Джастина Ризервато из компании Gilt — гиганта электронной коммерции — о том, почему важнее достижение консенсуса в отношении принципов agile, а не внедрение процесса.

В частности, Хизер и Джастин анализируют ответы на три жизненно важных вопроса, которые должна рассмотреть любая команда, прежде чем начинать agile-путешествие.

  • «А когда будет выполнена работа?» Почему избавление от концепции сроков сдачи является самым важным (и самым сложным) при переходе к работе по методологии agile.
  • «Это мой основной приоритет, но я не смогу встретиться с вами до следующей недели». Что делать, если ваш бизнес-партнер не может (или не хочет) быть полноправным членом команды.
  • «Я хочу просто писать код. Почему я должен присутствовать на всех этих собраниях?» Почему внедрение scrum не является первым шагом в переходе на agile.

Смотрите и учитесь

Вопросы и ответы

Хизер и Джастин выбрали некоторые главные вопросы, прозвучавшие на сеансе вопросов и ответов к этой презентации. Читайте далее, чтобы подробнее узнать о тактиках применения agile-методов.

Вопрос 1. Цифровая agile-доска или физическая agile-доска? Какова ваша точка зрения по этому поводу?

Ответ 1. Это всецело зависит от конкретной команды. Вы все находитесь в одном месте? Насколько велика команда? У вас есть место для большой физической доски? У нас в компании Gilt используются обе, но мы обнаружили, что по мере роста и расширения до десятков команд agile-доски в Jira Software оказываются более практичным решением, нежели физические доски. Они удобнее, когда требуется настраивать, вносить изменения, а также делиться с удаленными участниками команды. Физические доски нам нравятся потому, что их сложно игнорировать, поскольку они находятся перед вами. И они отлично подходят для проведения импровизированных дискуссий о текущей работе или стендапов, если у вас это принято.

Вопрос 2. Как вы работаете с менеджерами или клиентами, которые не следуют процессу согласно методологии agile или не понимают его? Иногда мне кажется, что я — отвратительный тренер по рабочим процессам.

Ответ 2. Важно продумать порядок действий. Если вы пытаетесь работать по agile-процессу с людьми, которые не верят в него, вы несколько забегаете вперед. В этой работе важнее сначала достигнуть общего согласия в философии, а не переходить к выполнению процесса. Ранее мы рассматривали конкретные проблемы, которые возникают у команды с текущим процессом, и применяли для их решения agile-подход. Можете ли вы подробно рассказать своему менеджеру или клиенту о реальных проблемах, которые они пытаются решить, и о том, как бы вы подошли к решению этой проблемы с точки зрения agile-методологии? Можете ли вы постепенно подводить их к гибкости, не меняя весь процесс? Так, шаг за шагом, можно показывать реальные результаты улучшения работы команды. Короче говоря, используйте agile-подход к процессу перехода к agile. ;)

Вопрос 3. Как внедрять agile-процесс, если проект имеет фиксированную стоимость и (или) четкий график с установленным списком требований для реализации?

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

Вопрос 4. Большинство проектов имеют дату релиза, которая обычно сообщается партнерам и клиентам. В этом случае можно лишь договориться о наборе возможностей (либо несколько снизить качество). Как вы работаете в условиях жестких крайних сроков?

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

Вопрос 5. Как, на ваш взгляд, следует изменить способ реализации scrum?

Ответ 5. Самой большой проблемой scrum является его жесткость. Думать, что один строго регламентированный процесс будет работать для всех команд, независимо от того, над чем они работают и кем они являются, слишком самонадеянно. Мы видели, как подход scrum работает для некоторых команд, но это не единственный подход в agile, и многие команды не могут внедрить agile-методику разработки, потому что они думают, что им нужно реализовать scrum особым образом со всеми предписанными рабочими ролями, пользовательскими историями, критерии приемки, совещаниями и артефактами. У Хизер также есть публикация под названием Scrum Master (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 нет «неконтролируемого расползания границ проекта» (здесь можно использовать уловки джедаев).

Up Next
DevOps