Agile технологии это




Проекты в сфере data science и разработка соответствующих продуктов командой data scientists требуют использования эффективных методик. Одной из таких методик является эджайл (agile).

Для чего применяется методология Agile?
  • Ускорение вывода продукта на рынок. Если вы хотите что-то сделать быстрее, нужно делать это в соответствии с Agile. Очень простой пример. Есть две компании, у них примерно одинаковый бизнес. Одна пишет ТЗ, затем проектирует систему и рисует дизайн — это водопадная модель, на разработку которой может уйти несколько месяцев. Во второй компании, работающей по Agile, к этому времени может быть уже запущен сайт, выпущено ПО, она начнет зарабатывать деньги и захватывать рынок, что самое главное.
  • Управление изменениями в приоритетах. Это, пожалуй, весьма болезненная проблема практически для всех компаний. Если вы делаете проект, который длится хотя бы несколько месяцев, то у вас обязательно поменяются требования. Конечно, если это не софт, например, для спутника или марсохода. Хотя даже спутникам и марсоходам обычно заливают свежую версию софта, когда они прилетают в точку назначения. Если говорить про коммерческую разработку, то проблема в том, что программисты, аналитики и дизайнеры, никогда не знают, что нужно не только заказчику, который им платит, но и пользователям. Обычно все подходят к вопросу так: пока пользователь не попробует функционал сайта или приложения, вы не знаете, нужен он или нет.
  • Улучшение взаимодействия между IT и бизнесом. Это головная боль, особенно для крупных компаний, ведь у бизнеса периодически меняются требования, каждый говорит на своем языке. В результате стороны друг друга не понимают.

Ответом на все эти вызовы явился Манифест гибкой разработки ПО.

Манифест гибкой разработки

Он состоит из нескольких частей. Первая часть называется «Ценности» (Values). Это четыре «взвешивания»:

  • Если вы хотите построить гибкий процесс, вам нужно взаимодействовать и общаться между собой. В чем это выражается — рассмотрим ниже на примере Scrum. При этом вы можете (и обязательно будете) использовать какие-то инструменты и процессы, например, трекеры — JIRA, Redmine и т.д. Но ваша работа должна опираться на различные митинги, встречи и взаимодействие, а не на настройки трекеров или TFS (если говорить про Microsoft стэк).
  • Работающий продукт, который мы делаем, намного важнее, чем документация по нему. Выше был приведен пример с двумя компаниями: у одной имеется готовый продукт, который можно дать пользователям, заказчику, захватив рынок; а вторая пишет ТЗ, рисует макеты и т.д. Вся эта документация, которую пользователь не может применить по причине не готовности продукта, не приносит ценности этому пользователю. Если мы научимся работать, минимизируя эти шаги, либо делая их небольшими кусочками, то у нас получится более гибкий процесс.
  • Сотрудничество и взаимодействие с заказчиком важнее жестких контрактных ограничений. Обычно подписывается договор, в котором указано, что к конкретной дате за определенную сумму разработчик обязуется выполнить оговоренный объем работ. Естественно, к договору прикладывается ТЗ. То есть фиксируется время, объем работ и сроки. Это называется Fixed Price. Такой подход не очень хорош, если вы хотите работать на долгосрочную перспективу и быть гибкими. В этом случае правильнее выстраивать партнерские отношения с заказчиком. Если говорить про контрактные оформления, то обычно это выливается в контракты по схеме «время — материалы», когда разработчику просто оплачивается потраченное время. Самое главное, что здесь начинается поиск партнерства и ситуации Win-Win, когда побеждает и заказчик, и его подрядчик.
  • Готовность к изменениям во взвешивании со следованием первоначальному плану.

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

12 принципов Agile

Ценности влекут за собой 12 принципов Agile :

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

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

Итак, у нас получается пирамида, состоящая из четырех ценностей, на которых выстроено 12 принципов.

Таким образом, можно использовать такой принцип и методологию agile в data science командах и проектах.

Гибкая методология разработки Agile

Гибкая методология разработки (англ. аgile software development) — это концептуальный каркас, в рамках которого выполняется разработка программного обеспечения.

Требования к программному обеспечению очень изменчивы в процессе его создания. Для этого продукт и система его создания должны быть гибкими для своевременных изменений и учета новых требований.

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

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

  • планирование,
  • анализ требований,
  • проектирование,
  • кодирование,
  • тестирование,
  • документирование.

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

SCRUM — одна из гибких методологий разработки ПО. Впервые была использована в 1993 с целью улучшить продуктивность команды разработчиков, сделав упор не на качественно определенный, а на качественно контролируемый процесс разработки.

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

Преимущества этого подхода:
  • За очень короткий промежуток времени project manager и все члены команды могут оценить статус проекта.
  • Все возникшие проблемы решаются очень быстро так как доносятся до всех участников проекта (среди которых потенциально есть компетентные в данном вопросе люди).
  • Сотрудники учатся слушать других, понимать их, а также четко выражать свои собственные мысли.
  • Участники проекта учатся ставить перед собой реальные задачи и отвечать за статус их выполнения.

В результате заказчик в любой момент видит выполненный этап разработки и может своевременно корректировать исходные характеристики продукта.

Методология Agile

В современном менеджменте «гибкую» модель управления рассматривают в трёх разных контекстах, которые (каждый по-своему) и определяют, что такое Agile.

Содержание статьи

Три объёма значения Agile

В первом, более узком значении, этот термин стал с начала 2000-х использоваться в сфере разработки программного обеспечения, когда в американском штате Юта, на горном курорте, собрались отраслевые специалисты, чтобы обсудить методики и практики создания программных продуктов, востребованных конечным потребителем. Результатом той встречи стал Манифест (Agile Manifesto) разработки программных продуктов, с 12-ю принципами, которые, в первую очередь, касались узкой сферы деятельности авторов, но потенциально могли быть распространены и на некоторые другие бизнес-проекты.

Во втором, более широком, значении термина принципы Agile применяются к ведению почти любого бизнеса и в качестве составляющих используются, например, в концепции «бережливого стартапа» (Lean Startup). В этом значении под Agile-моделью (Agile Model) понимают следование гибкой методологии развития проекта, проходящей по характерной схеме в несколько шагов.

  1. Работа над проектом ведётся итерациями – короткими циклами (спринтами). (В случае с разработкой программного обеспечения продолжительность этих циклов составляет от 1 недели до 1 месяца).
  2. По завершении каждого цикла выходит продукт, который уже можно применять в бизнесе. Для программного обеспечения таким продуктом может стать приложение или только его часть, однако даже «сырой» софт уже можно и нужно пробовать в деле.
  3. Продукт проверяется заказчиком или пользователями, которые поддерживают с разработчиками постоянную обратную связь. Клиентоориентированный подход применяется в течение всего проекта (всех итераций).
  4. Любые замечания быстро включаются в доработку, а изменения, позволившие сразу по ходу подправить разработку продукта, – приветствуются, поскольку это позволяет не накапливать глобальные ошибки системы.

В третьем, ещё более широком значении, Agile – это часть модели управления, применяемого на заводах «Toyota» и теперь – одна из базовых составляющих менеджмента почти любого успешного производства. Основы Agile в этом контексте схожи с основами понимания технологии в других контекстах.

Быструю обратную связь в настройке конечного формата производства на заводах «Toyota» обеспечивал любой рабочий, который мог стать инициатором остановки конвейера и автором корректировок по донастройке производственного цикла. В масштабах всего производства Agile-трансформация может повлечь за собой переналадку производственной деятельности в целом, если продукт становится результатом живого отклика на текущие потребности клиента. Так, если фабрика выпускала пластиковые тазы, а обратная связь с клиентом демонстрирует потребность в вёдрах, то быстрая адаптация с параллельной корректировкой нюансов (формы ручки, величины, цвета) будет как раз в стиле Agile management (если соблюдены и остальные принципы).

Принципы Agile-управления

Agile в управлении проектами как модель управления бизнес-процессом применяется тысячами команд во всём мире, и везде присутствуют следующие отличительные черты этого подхода:

  1. Решающее значение для настройки продукта имеет потребитель и степень его вовлеченности в создание результата.
  2. Для принятия решения команды должны быть высокоэффективными и сплочёнными.
  3. Поэтапная и цикличная работа становится основой процесса. Проект делится на мелкие части, которые завершаются к определённому сроку до завершения проекта в целом.
  4. Фокус оценки результативности направлен на частые представления промежуточных состояний проекта.
  5. В работе коллектив опирается на закон Парето, по которому 20% усилий дают 80% эффективности, что позволяет не доводить каждый отдельный цикл до совершенства перед представлением результата потребителю. Продукт совершенствуется естественным образом с каждой новой итерацией.
  6. Предполагается обязательное завершение одного этапа перед переходом к следующему.

«Гибкий» подход стал базовым для целого ряда методологических практик, которые отличаются между собой, но включают идеи Agile: Scrum, Kanban, Lean, Crystal и др. Методология Scrum, например, практически всегда рассматриваются в связке с Agile как единая система управления проектами по разработке программного обеспечения.

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

  • Product backlog предполагает формирование списка требований, созданного по единому шаблону (User Story) и отсортированного по приоритетам. Если требований нет, проект завершается.
  • Sprint backlog – это требования ближайшего спринта (этапа), разделённые на задачи без возможности добавлять новые требования в течение спринта. Обязательство на ближайший этап, взятые командой с типом управления Agile, записываются на доске (т. н. Kanban).
  • Sprint Goal – общая цель спринта – ориентир при принятии альтернативных решений.
  • Sprint Burndown Chart – «диаграмма сгорания». Она показывает насколько продвинулась команда в течение этапа.

Формат Agile-управления проектами подходит не всем и не всегда. Государственные структуры, деятельность которых базируется на неизменном законодательстве и консервативна по своим целям и реализации, не нуждаются в такой оптимизации.

Характерные ошибки внедрения Agile и недостатки подхода

Тот же фактор, который считается в одних случаях сильной стороной подхода, в других может приводить к возникновению проблем. Так «гибкость» нередко становится причиной размывания фокуса. При отсутствии методологической основы возникает потеря ориентиров, и подмена первичного вторичным. Для предотвращения подобных «перекосов» используют готовые методологии или собственные разработки, более строго регламентирующие содержание и последовательность операций по ходу воплощения проекта. Тем не менее, и в этом случае в Agile-management возможны ошибки.

К распространённым ошибкам внедрения относятся следующие:

  1. Ограничение командной свободы со стороны руководства. Руководитель проекта не всегда готов отпустить команду, дав ей самостоятельно решать, что делать. Для эффективной работы необходимо реальное расширение возможностей и прав каждого участника процесса. Руководство не должно ставить мелкие задачи исполнителям и проверять выполнение каждого действия. Но иногда право решения передаётся исполнителю частично и в ограниченном виде, что снижает эффективность общего процесса.
  2. Отсутствие доверия внутри команды и старые привычки. При внедрении подхода Agile в уже сложившихся коллективах с классической иерархией команде сложно бывает отказаться от патерналистских установок. Даже сознательно соглашаясь с новыми правилами игры, работники реализовываются в рамках ранее сформированных навыков взаимодействия. Чтобы изменить навыки, такие коллективы проходят специальные тренинги работы в команде. Но и это не застраховывает от мелких конфликтов. Нововведения редко проходят абсолютно гладко. Считается, что, в среднем, до 30% персонала так и не переходят на новый формат работы, что влечёт либо проволочки, либо серию увольнений.
  3. Нарушения в обратной связи. Иногда обратную связь от клиентов могут просто игнорировать, мотивируя это тем, что клиент хуже знает, что ему на самом деле надо. Тут важно отдавать себе отчёт в том, что именно заказчик – заинтересованная сторона.
  4. Недостаточное тестирование. Иногда тестирование прекращают после запуска первой рабочей версии продукта. Так же минуют стадию обсуждения в конце итерации.
  5. Отсутствие у топ-менеджеров чёткого понимания целей внедрения новой системы с гибким подходом и отсутствие методологий. Как правило, цели с цифрами заменяются лозунгами или слоганами (например, «Быть всегда впереди конкурентов»), а вместо методологий описываются идеи, а не операции.
  6. Внедрение подхода на одном участке. Для эффективности обычно советуют переформатировать деятельность всех сфер компании, начиная с бухгалтерии и отдела продаж и заканчивая производством и маркетингом.
  7. «Остывание». Процесс перехода на новую систему работы может занять несколько месяцев. Иногда нужно произвести переоборудование (установить новые станки или ПО и обучить сотрудников), иногда – полностью изменить тип мышления в рамках рабочего процесса. Поскольку со временем люди устают от перемен, процесс перехода на новую модель начинает надоедать на полпути. Теряется мотивация, а с ней уменьшается и вероятность успешного внедрения.
  8. Разочарование после первых итераций. Иногда после первых этапов исполнители просто недовольны результатом, но нередко это недовольство выливается в неконтролируемое стремление довести продукт до почти идеального состояния. А правильное совершенствование продукта происходит именно в процессе многократной шлифовки с разделением на соответствующее потребностям число итераций. Частично это решается грамотным планированием, при котором пропускная способность одной итерации одной командой оценивается адекватно (без пере- и недооценки).

При всех сложностях внедрения гибкого подхода в целом он эффективнее традиционных «неповоротливых» производств, если речь идёт о быстром создании нового клиентоориентированного продукта. Пока традиционное производство вязнет в бюрократических проволочках, Agile-подход обеспечивает естественное движение сразу после запуска проекта.

Scrum и Agile для чайников

Комментарий Котиков

Для начала. Scrum и Agile — в чем разница? Если коротко, Agile — это философия, семейство гибких подходов к разработке ПО. Scrum — один из таких подходов. У него есть братик — Kanban. Он тоже подход, используемый в Agile.

На этой неделе я прошла двухдневный тренинг по Agile/Scrum (произносится «эджайл» и «скрам»). По гибким методологиям разработки программного обеспечения написано много заумной и не очень литературы, многое я читала. Но только после двухдневного погружения в тему у меня наконец собралось базовое понимание предмета, из которого я пишу эту заметку.

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

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

Принципы скрама можно применить совершенно ко всему: например, к работе над творческим продуктом. Это, конечно, не «канонический эджайл», скрам-евангелисты будут скрежетать зубами, зато ваши процессы будут двигаться бодрее. Шашечки или ехать?

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

Эджайл

(англ.agile —«проворный, шустрый, сообразительный»)

Концепция гибкости:

Подставьте свой вид деятельности вместо слова «разработка» — и эти принципы станут близкими и понятными.

«Работающий продукт — основной показатель прогресса», «простота как искусство минимизации лишней работы» и «люди и взаимодействие важнее процессов и инструментов» — правда, звучит разумно?

Книжку «Открывая организации будущего» Фредерика Лалу я читала совсем недавно. Вполне бодрый подход ко всем отраслям на свете

Скрам

(англ. scrum — толкотня в борьбе за мячик в регби)

Тут стоит напомнить, что это моя личная и субъективная точка зрения на скрам. Здесь я размышляю о применимости элементов скрама как в творческих проектах, далеких от IT, так и в индивидуальной работе (скажем, над блогом). Много точных деталей для этого придется упустить; я стараюсь сохранить простоту текста и не перекормить читателя терминологией.

Жесткость скрама заключается в структуре. Есть некий набор подходов, работающих вместе лучше, чем по отдельности. Вытащить что-нибудь и заиспользовать вам, я надеюсь, никто не запретит.

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

Если вы работаете в команде, скрам предписывает всем участникам процесса стремиться к взаимозаменяемости, к способности «подхватить» провисающую задачу, если сосед заболел, к обмену навыками и коллективной ответственности за продукт. Индивидуализма в скраме мало. Решения принимаются коллективно (по строгим принципам), никто не может надавить и заставить выбрать другое решение, если команда уверена, что остановилась на верном.

Иметь такую уверенность в скраме не страшно, поскольку каждый марш-бросок длится ровно один спринт (четкий отрезок времени, обычно от одной до четырех недель). После того, как спринт закончился, наступает момент анализа: а как мы его прошли? Что можно было бы сделать еще лучше в следующий раз?

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

Команда в скраме

Стандартный размер скрам-команды — 7 плюс-минус 2 человека. То есть от пяти до девяти. Бывает скрам-масштабирование: можно из 25 команд состроить систему работы над гигантской задачей. Но основная единица скрама — команда.

В каждой команде есть:

  • участники (в случае IT — разработчики, кто эти семь человек у вас — решите сами)
  • продакт оунер (product owner, владелец продукта). Его роль: понимать рынок и пользователя, формулировать задачи на языке бизнеса и пользователей, держать в голове осознание того, в каком направлении должны развиваться ценность и польза, придумывать и отбирать задачи для развития продукта. Что-то вроде руководителя продукта (не команды).
  • скрам мастер (scrum master, скрам-евангелист). Его роль: следить за процессом, наблюдать за внутренней жизнью команды, мотивировать людей, устранять препятствия. Что-то вроде тренера.
    Вокруг команды есть пользователи и стейк-холеры (stakeholders, заказчики). К этим людям продакт оунер ходит советоваться.

Устройство спринт

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

У продакт оунера есть список идей от бизнеса для осчастливливания пользователей. Он называется «продакт бэклог» (product backlog, список продуктовых идей). В нем идеи отсортированы по важности и значимости.

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

Задача в спринте имеет известный команде вес (известно, сколько времени на неё уйдет), к ней прикреплен исполнитель, она является понятной и важной. Если неизвестно, сколько времени уйдет на задачу, нужно её разбить на более мелкие части.

В начале своей жизни команда всегда плохо планирует. Это объективная реальность. Но она ведет статистику того, что ей удается сделать за спринт, и со временем планирует всё точнее. Ей помогает итоговая встреча спринта — ретроспектива. На ней можно обсудить слабые моменты уходящего спринта и придумать способы делать по-другому.

Обычно в спринт влезает 5 плюс-минус 2 идеи. Если идеи слишком большие, команда их дробит так, чтобы в каждом спринте можно было что-нибудь маленькое, да показать.

В скраме идеи называются юзер-сториз (user stories, истории про пользователей) и формулируются так: «Я как (роль?) хочу (что?) для того, чтобы (зачем?)». Таким образом команда видит не только функциональность, но и смысл её создания, причем для конкретной роли: пользователь, заказчик, покупатель.

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

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

Структура спринта

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

Каждый день есть стендап-митинг (stand up meeting, совещание стоя) на 15 минут. Делать его стоя важно: если кто-то заболтается, остальные красноречиво будут переминаться с ноги на ногу и чесать ухо. Можно использовать какой-то предмет, чтобы говорил в один момент времени только один участник, и передавать его по кругу.

Каждый участник стендапа по очереди отвечает на три вопроса:

  • что я сделал вчера
  • что я сделаю сегодня
  • что меня тормозит

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

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

В конце спринта происходит демо (demo, демонстрация) с показом того, что удалось создать в течение спринта, спринт-ревью (sprint review, обзор спринта) с пересмотром продакт-беклога и разговорами о том, ЧТО мы делаем, а также ретроспектива (retro) — что мы делали не самым лучшим образом весь спринт и хотим улучшить далее — о том, КАК мы это делаем.

«Если бы у меня было восемь часов для того, чтобы срубить дерево, я бы шесть часов потратил на заточку топора». (приписывается лесорубу и президенту Аврааму Линкольну)

Agile, scrum, kanban: в чем разница и для чего использовать?

Главный редактор Rusbase

Если раньше офисы модно было обустраивать «по фэн-шую», то теперь — исключительно «по эджайлу». Agile – это не только цветные стикеры, на которых удобно отмечать ход работы (стикеры, скорее, стоит относить конкретно к подходу kanban). А ведь есть еще и scrum – он тут при чем?

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

Определение

Agile (agile software development, от англ. agile – проворный) – это семейство «гибких» подходов к разработке программного обеспечения. Такие подходы также иногда называют фреймворками или agile-методологиями.

Agile возник в IT-среде, но затем распространился и в другие сферы – от промышленной инженерии до искусственного интеллекта.

Смысл Agile сформулирован в Agile-манифесте разработки ПО: «Люди и взаимодействие важнее процессов и инструментов. Работающий продукт важнее исчерпывающей документации. Сотрудничество с заказчиком важнее согласования условий контракта. Готовность к изменениям важнее следования первоначальному плану».

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

К отдельным agile-подходам относятся scrum и kanban.

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

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

Kanban – это «подход баланса». Его задача – сбалансировать разных специалистов внутри команды и избежать ситуации, когда дизайнеры работают сутками, а разработчики жалуются на отсутствие новых задач.

Вся команда едина – в kanban нет ролей владельца продукта и scrum-мастера. Бизнес-процесс делится не на универсальные спринты, а на стадии выполнения конкретных задач: «Планируется», «Разрабатывается», «Тестируется», «Завершено» и др.

Главный показатель эффективности в kanban – это среднее время прохождения задачи по доске. Задача прошла быстро – команда работала продуктивно и слаженно. Задача затянулась – надо думать, на каком этапе и почему возникли задержки и чью работу надо оптимизировать.

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

Примеры употребления

Один из принципов Agile стоит на личной ответственности человека, а не на отлаживании внутренних процессов.

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

(Из интервью «Ведомостей» с Фрэнком Сосьером, коучем компании Freestanding Agility)

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

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

(Управляющий партнер ScrumTrek Алексей Пименов в статье на Rusbase)