Agile — всё по этой теме для программистов


Оглавление (нажмите, чтобы открыть):

AGILE – гибкая система управления проектами

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

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

Метод Agile: определение и краткая история

Как бы непривычно это ни звучало, но серьезно разрабатывать программное обеспечение и управлять проектами начали уже в 70-х годах прошлого века. Именно в 1970 году американский ученый-компьютерщик Уинстон Ройс составил документ, называвшийся «Управление развитием крупных программных систем». В нем он приводил критику последовательной разработки, указывая на то, что разработка программного обеспечения не должна походить на работу сборочной линии (как, например, делается в автомобильном производстве), где новые детали по очереди добавляются в последовательные фазы.

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

На основе этого в 90-х удалось создать комплекс гибких методов разработки ПО, способных заменить сложные и трудоемкие методы. Происходило это так:

  • В 1991 году появился метод быстрой разработки приложений RAD
  • В 1994 году появился метод разработки динамических систем DSDM
  • В 1995 году появилась платформа (фреймворк) гибкой разработки Scrum
  • В 1996 году появилась гибкая методология разработки Crystal Clear, а также экстремальное программирование XP
  • В 1997 году появилась итеративная методология разработки ПО FDD

Все вместе эти методы объединились под общим названием гибких методов разработки ПО.

Четыре года спустя – в 2001 году в штате Юта (США) на курорте Snowbird собрались семнадцать разработчиков программного обеспечения. В результате обсуждения методов разработки был опубликован «Манифест о гибкой разработке программного обеспечения Agile» (в переводе с английского понятие «agile» означает «подвижный», «проворный» или «быстрый», но в большинстве случаев его переводят именно как «гибкий»). Он и задал темп всей дальнейшей работе над созданием ПО.

Манифест Agile

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

  1. Люди и их взаимодействие важнее, чем процессы и инструменты
  2. Рабочее ПО важнее, чем документация
  3. Клиенты и сотрудничество с ними важнее, чем контракт и обсуждение условий
  4. Готовность к внесению изменений важнее, чем первоначальный план
  1. Удовлетворять клиентов, заблаговременно и постоянно поставляя ПО (клиенты довольны, когда рабочее ПО поступает к ним регулярно и через одинаковые промежутки времени)
  2. Изменять требования к конечному продукту в течение всего цикла его разработки
  3. Поставлять рабочее ПО как можно чаще (раз в неделю, в две недели, в месяц и т.д.)
  4. Поддерживать сотрудничество между разработчиками и заказчиком в течение всего цикла разработки
  5. Поддерживать и мотивировать всех, кто вовлечен в проект (если команда мотивирована, она намного лучше справляется со своими задачами, нежели команда, члены которой условиями труда недовольны)
  6. Обеспечивать непосредственное взаимодействие между разработчиками (возможность прямого контакта способствует более успешной коммуникации)
  7. Измерять прогресс только посредством рабочего ПО (клиенты должны получать только функциональное и рабочее программное обеспечение)
  8. Поддерживать непрерывный темп работы (команда должна выработать оптимальную и поддерживаемую скорость работы)
  9. Уделять внимание дизайну и техническим деталям (благодаря эффективным навыкам и хорошему дизайну команда проекта получает возможность постоянного совершенствования продукта и работы над его улучшением)
  10. Стараться сделать рабочий процесс максимально простым, а ПО – простым и понятным
  11. Позволять членам команды самостоятельно принимать решения (если разработчики могут сами принимать решения, самоорганизовываться и общаться с другими членами коллектива, обмениваясь с ними идеями, вероятность создания качественного продукта существенно возрастает)
  12. Постоянно адаптироваться к меняющейся среде (благодаря этому конченый продукт будет более конкурентоспособен)

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

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

Ключевые моменты в применении Agile

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

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

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

Особое внимание нужно уделить руководителю проекта. Его нельзя назвать человеком, раздающим указания налево и направо. Руководитель здесь выступает скорее в роли лидера, который задает направление и определяет правила сотрудничества и работы. Другими словами, Agile-управление является адаптируемым.

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

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

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

Если же мы разделим все время, отведенное на проект, на несколько спринтов, получим конкретное их количество; пусть их будет 15. Каждый спринт длится, к примеру, две недели. Вот как раз в течение этих двух недель (времени, отведенного на спринт) участники каждый день встречаются для обсуждения процесса и прогресса.

Ежедневные встречи не должны превышать 15 минут. Организуются они для того, чтобы каждый член команды дал себе же ответ на три вопроса:

  • Что я делал вчера?
  • Чем я буду занят сегодня?
  • Что мешает мне работать?

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

  1. Четко обозначается значение проекта
  2. В процессе реализации активно участвует клиент
  3. Общий объем работ выполняется пошагово
  4. Ориентироваться следует на конкретный результат
  5. Численность одной рабочей группы: от 7 до 9 человек

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

Примеры: правительство Новой Зеландии, правительство Нигерии, Норвежский пенсионный фонд, компания Return Path (программное обеспечение), компания Oreo (производство печенья), компания Aviasales (крупнейший поисковик авиабилетов), компания Hewlett-Packard (крупнейшая американская IT-компания), «Сбербанк» (наверное, знаете, что это).

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

Популярные методы управления проектами

Существует немало методов проект-менеджмента, которые применяются разными современными компаниями. Но самыми известными и востребованными среди них по праву считаются Scrum (Скрам) и Kanban (Канбан).

Метод Scrum

Среди всех методов системы Agile Scrum отличается тем, что делает основной упор на качественный контроль рабочего процесса. Впервые описавшие его японские специалисты по стратегическому менеджменту Хиротака Такуэти и профессор в области научно-технических знаний Икуджиро Нонака называют метод «подходом в рэгби», где Scrum является «борьбой за мяч».

Метод заключается в том, что разработка проекта разделяется на спринты, по окончании которых клиент получает улучшенное ПО. Спринты строго фиксируются по времени, и могут длиться от 2 до 4 недель. Рабочий процесс в одном спринте включает в себя несколько стадий:

  • Определяются объемы работы
  • Каждый день проводятся 15-минутные встречи, чтобы члены команды могли скорректировать свою работу и подвести промежуточные итоги
  • Демонстрируются полученные результаты
  • Спринты обсуждаются для поиска удачных и неудачных решений и действий

В большинстве случаев Скрам применяется в работе со сложным ПО и для разработки продукта с использованием инкрементных и итеративных методов. Благодаря ему серьезно повышается производительность команды и сокращаются временные затраты на достижение цели.

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

Метод Kanban

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

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

В отличие от Скрам, Канбан обрел популярность намного позже, но это ни в коей мере не умаляет его достоинств и не делает менее эффективным. Метод полезен как в IT-области, так и в бизнес-сфере.

Это лишь примеры основных методов управления проектами, основанных на Agile. Но не стоит пренебрегать и другими методами, такими как PRINCE2, Lean, Six Sigma, XP, CCPM, ECM, Waterfall и другие. К тому же у Аджайл, наряду с преимуществами, есть и некоторые недостатки.

Плюсы и минусы Agile

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

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

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

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

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

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

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

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

Внедрение Agile

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

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

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

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

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

Заключение

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

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

Как использовать Agile и Scrum для управления проектами

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

Для чего внедрять гибкие методологии

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

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

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

  • Нет нужды составлять длинное ТЗ — вместо этого формируется гибкий список задач на основе желаний клиента.
  • Бюджет гибкий — если деньги закончились, заказчик все равно получит работающий проект, пусть и с меньшим количеством функций.
  • Меньше бюрократии — нет нужды согласовывать сразу всю документацию по проекту, достаточно получить одобрение руководителя по одному вопросу. Разработка других задач в это время не прекращается.

Agile — это подход к разработке большого проекта. Философия, которая позволяет создавать продукт с постоянно меняющимися требованиями.

Начните с бэклога

Scrum — это метод управления проектами, он входит в философию Agile. Ключевое отличие от классической, водопадной схемы создания ПО заметно сразу — для начала разработки не нужно техническое задание.

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

Лайфхак — обратите внимание на столбец Приоритет на примере. Используйте не привычный список 1, 2, 3, 4. Попробуйте четырехзначные цифры — так вы сможете просто добавить строку между ними и выставить подходящий приоритет. Например, между 1 000 и 2 000 напишите 1 050.

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

Внедряйте спринты

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

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

Дело в том, что люди плохо считают процессы в абсолютных величинах. Сложно сказать, сколько часов что займет. Поэтому в Scrum используется относительная оценка. За основу берется простая функция, которую все оценивают одинаково — например, понятно, что ее сделают за час. Остальные тикеты вычисляются так — «это мы будем делать раз в пять дольше по времени».

Сделайте список версий продукта — от ПО с минимумом функций до полностью реализованного. Укажите к каждой версии прогноз по сроку выполнения.

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

Распределите роли в команде

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

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

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

Люди, которые непосредственно создают и тестируют код.

К разработчикам есть несколько требований:

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

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

Контролируйте процессы

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

Контролируйте работу команды с помощью двух scrum-показателей:

  • Focus Factor — коэффициент, который показывает, сколько задача должна была выполняться по плану, а сколько вышло в итоге. Так оценивается «концентрация» команды над проектом.
  • Velocity — производительность. Поможет спрогнозировать количество задач, которые команда сможет взять в следующем спринте — в зависимости от количества готовых тикетов в прошлом. Velocity = Focus Factor * Оценка новых задач.

Организуйте работу команды

В Scrum от сотрудников требуется минимальная отчетность. Каждый день человек должен ответить на три вопроса:

  • Что сделано вчера?
  • Что будет сделано сегодня?
  • Какие есть проблемы и препятствия для выполнения задач?

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

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

Все идеи должны быть измеримы — например, «Ребята, давайте добавим серверов». Предложение просто работать лучше — не идея.

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

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

Первый спринт команда всегда «факапит», потому что слишком оптимистично смотрит на дедлайны и задачи. Второй — берет очень мало задач и делает больше. Третий — снова плохая оценка, но уже чуточку лучше. Потом все выравнивается. Это рабочий процесс.

Демонстрируйте проект

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

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

Изучите инструменты для контроля

Работать по системе можно даже на бумаге. Отлично подходит и таблица в Google Docs. Создайте свою рабочую область вручную или попробуйте специальные сервисы:

  • Trello — подходит для маленьких проектов, быстро и удобно.
  • Scrumban — есть разные доски, вложенные задачи и подзадачи. Удобно для средних и маленьких проектов.
  • Jira — есть версионность, удобно для больших и долгих задач. Поддерживает массу типов разработки. Попробуйте, она вам понравится.

Чек-лист — как начать использовать Agile и Scrum на проекте

  • Научиться вести бэклог и расставлять приоритеты.
  • Проводить спринты.
  • Формировать стабильную и постоянную команду, решать трудности, растить внутри группы scrum-мастера.
  • Контролировать работу с помощью диаграммы сгорания проекта.
  • Организовать работу — каждый день интересоваться делами команды, проводить ретроспективу и закладывать время на тикет с запасом.
  • После каждого спринта демонстрировать проект.
  • Изучить инструменты и найти самый удобный.

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

Просто о сложном: agile-разработка

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

Что было до аджайла

До гибкой разработки все диджитал и IT-компании создавали продукты целиком. Например, в студию обращался заказчик и говорил, что он хочет сайт. Студия отвечала, что не может начать работу без исчерпывающего технического задания. Заказчик вздыхал, садился за бумагу, писал ТЗ на сто страниц, пытаясь по пути не упустить ничего важного. Команда принимала техзадание, закрывалась у себя в студии, работала 2 месяца и показывала результат. После тестирования и правок сайт запускали.

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

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

Agile Manifesto

Со временем разработчики стали тестировать и изменять продукт во время работы. Так появились новые техники, которые назвали гибкими. В 2001 году 17 представителей профессии собрались в горной деревне штата Юта, покатались на лыжах и заодно обсудили свои подходы к разработке.

Итогом встречи стал «Манифест Аджайла», в котором излагались основные принципы, выводы и целая философия гибкого программирования. Сейчас эту философию широко практикуют не только в диджитал-среде, но и в любой другой. Вот 4 основных ее положения:

  1. Люди и взаимодействие важнее процессов и инструментов.
  2. Работающий продукт важнее исчерпывающей документации.
  3. Сотрудничество с заказчиком важнее согласования условий контракта.
  4. Готовность к изменениям важнее следования первоначальному плану.
Мастер Йода рекомендует:  NLP как стать специалистом по обработке естественного языка

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

Как команды работают по аджайлу

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

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

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

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

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

Кое-что еще

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

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

Процесс работы по Scrum: спринты, циклы разработки, standup-митинги

Канбан-доска: карточки перемещаются по колонкам-этапам

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

Какому продукту точно нужен аджайл?

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

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

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

Agile-методология в России: 4-х летний опыт управленца

Однажды в Россию на завод по сбору автомобилей знаменитой корпорации Тойота приехал топ-менеджер.

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

В основе всего лежала agile методология. Но то что он увидел на совещании повергло его в шок…

Планерка происходила следующим образом. Генеральный директор слушал доклад руководителей департаментов, делал себе пометки.

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

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

Так прошло минут 15. И тут директор с криком “Демократия кончилась, теперь снова диктатура!” начал раздавать распоряжения, который подчиненные стали усердно записывать в свои ежедневники.

Гость из Японии от увиденного смог вымолвить всего одну фразу: “Но это же не agile управление проектами.

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

Я уж не говорю про идеи на планерках…”. На что генеральный ответил: “Да, это не принципы аджайл! В России такие гибкие методы не работают!”.

Ну не работают они…

Скорей всего у Вас тоже в голове сейчас крутится вопрос: “Что же это за загадочная такая фраза?”.

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

Виноваты программисты

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

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

  1. Идея;
  2. Техническое задание;
  3. Создание дизайна;
  4. Программирование;
  5. Тестирование;
  6. Запуск итоговой версии.

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

В результате при создании дизайна или программировании, новые идеи просто приходилось игнорировать.

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

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

А также стали запрашивать обратную связь от заказчика еще до сдачи ему финального продукта.

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

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

Чтобы привести все подходы по управлению проектами (а к тому моменту их накопилось уже более десятка) к единому знаменателю, вся команда основателей (17 человек), которые разработали и внедрили различные “гибкие методы”, собрались вместе.

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

Именно это собрание в горной деревушке Сноубёрд в феврале 2001 года и считается зарождением методологии agile (кто-то даже называет это философией).

Поскольку в большинстве своем эти люди были программисты, то результатом собрания был выпуск “Манифеста гибкой методологии разработки программного обеспечения” (по английски Agile Manifesto) и принципов Аджайла.

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

Коротко и по делу

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

  1. Люди и взаимодействие важнее процессов и инструментов;
  2. Работающий продукт важнее исчерпывающей документации;
  3. Сотрудничество с заказчиком важнее согласования условий контракта;
  4. Готовность к изменениям важнее следования первоначальному плану.

Принципы, упоминающиеся в манифесте Agile. Просто прочтите, поймёте чуть дальше.

  • Удовлетворение клиента за счёт ранней и бесперебойной поставки ценного программного обеспечения;
  • Частая поставка рабочего программного обеспечения (каждый месяц или неделю, или ещё чаще);
  • И много еще подобных.

“Что за чушь я только что прочитал? Ни слова не понял!”. Думаю у Вас такие сейчас мысли.

Скажу честно, что такое Agile как методология (а также что написано в манифесте) я сам понял далеко не сразу, книги и статьи давали поверхностное описание, пока я не увидел всё это на практике.

Поэтому я сэкономлю Вам огромное количество времени и расскажу коротко и по делу.

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

Данный подход очень сильно напоминает мне декомпозицию, за исключением одного. В декомпозиции не учитывается вовлеченность всей команды.

На примере всё ясно

Чтобы Вам было проще всё понять, на примере хлебозавода я покажу разницу.

Для этого я сначала расскажу о заводе, у которого нет методологии, а потом о заводе, который внедрил этот метод управления. Переходим к примеру.

Обычный хлебзавод в России

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

Но, как правило, такие идеи возникают не от желания потребителей, основанных на маркетинговых исследованиях, а на желании самого директора.

После исследований технолог разработает хлеб на свой вкус и приносит его директору.

Он пробует новый продукт и решает – наградить технолога словами “Молодец. Держи бублик” или сказать “Нет. Переделывай”.

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

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

Agile-хлебзавод в России

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

К созданию продукта привлекут не только технолога и маркетинг, но и продавцов, логистов, поваров/кондитеров и … даже реальных покупателей.

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

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

ВНЕДРЯТЬ ИЛИ ПОСЛАТЬ

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

Что в результате хорошо скажется на продажах, сэкономит массу времени и отведёт от ошибок.

Однако, при прочтении первой половины статьи можно сделать вывод, что agile методология подходит только для айти-компаний.

Но это в корне не верно. В России эту методологию активно использует:

  • Банк “Альфа-банк”;
  • Сеть пиццерий “Додо пицца”;
  • Бухгалтерский сервис “Кнопка”.

И если с “Альфа-банком” все понятно, большая компания, у них есть ресурсы и люди для внедрения инноваций в свою систему.

То с “Додо пицца” и “Кнопка” всё намного интереснее, ведь компании небольшие. И по моему мнению именно одним из факторов их успеха стал этот подход.

В результате внедрения аgile Вы можете получить массу плюсов (о минусах позже), которые помогут Вам стать компанией-лидером на рынке. И вот одни из этих привилегий:

  1. Благодаря применению “гибких” подходов возрастает качество получаемых результатов;
  2. Результаты получаются гораздо быстрее и эффективнее за счет чего экономится время и затраты;
  3. Компания лучше адаптирована к изменениям (даже непредвиденным) и конкуренции;
  4. Создание проектов происходит более планируемо и контролируемо;
  5. Компания может создавать продукты, которые будут ждать и покупать их потребители.

Внутренняя работа

Единственный вопрос, на который я долго искал ответ, как же тогда происходит работа в agile-компании.

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

Вернемся к нашему любимому хлебозаводу. И к их старой задаче – выпустить новый сорт хлеба. Для реализации задачи у них была следующая последовательность:

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

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

  • Тестирование. Все идеи и знания суммируются в тестовый рецепт. Данный рецепт выпекается небольшой пробной партией для получения по нему обратной связи на закрытой дегустации среди обычных покупателей (. ).
  • Сбор обратной связи. Покупатели едят хлеб и высказывают свои пожелания. На основании этого в тестовый рецепт вносятся изменения и доработки. Финал.
  • Эти этапы могут продолжается снова и снова, пока не получается совершенный сорт хлеба, которым будут довольны все: маркетологи, повара, логисты, технологи, продавцы, покупатели и, конечно, сам директор завода.

    Да, теперь все отлично

    Хочу себе

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

    И Вы думаете, что agile это то, что Вам так нужно. Ведь так можно создать что-то новое, поистине инновационный продукт.

    Тогда сразу предупрежу Вас и отвечу на несколько вопросов, которые у Вас есть.

    Это топ-5 вопросов, которые задают себе все собственники, когда видят эту методологию.

    Подходит малому бизнесу? Если Вы не выпускаете постоянно новые продукты или не реализуете постоянно новые проекты, а работаете на “старом”, то с большей долей вероятности НЕТ.

    Легко ли внедрить? Отвечу вопросом на вопрос: А легко выучить иностранный язык? Философию нельзя быстро внедрить в компанию. Ее нужно внедрять пошагово и в течение довольно долгого времени.

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

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

    А это означает исключительно работу в команде и более широкий кругозор.

    Кто должен быть начальником? Прозвучит непривычно, но в agile-компаниях нет начальников.

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

    Не ответил на Ваш вопрос?! На этот случай есть внизу комментарии, напишите его там и я совершенно бесплатно дам Вам рекомендацию. Нам важно, чтобы Вы были на 100% довольны.

    Подводные камни

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

    Их осознают компании только после внедрения. Поэтому заранее “Пожалуйста” за то, что спас Вас от потери денег и времени.

    Аджайл – не инструмент

    Аджайл это даже не методология, хотя я часто называл её так в тексте. Это философия, по которой соглашается жить компания.

    А для внедрения философии в жизнь нужны правила, шаблоны и инструменты. Они называются фреймворками.

    Сюда включается Канбан или Скрам (инструменты управления). О каждом инструменте в дальнейшем мы конечно же напишем статьи, но Вы должны понять, что аджайл это прежде всего философия, принятая в компании.

    Команда

    Для большинства людей в нашей стране (я сейчас говорю про привычный российский бизнес) работа в команде будет непривычна.

    Они привыкли получать индивидуальные указания и отчитываться за их выполнение. Соответственно KPI каждого конкретного специалиста с внедрением аджайл нужно будет отменить.

    И именно команда будет оценивать вклад каждого конкретного специалиста в проект. А это очень сложно, если у Вас не топовые спецы своего дела.

    Чужой нос

    Личного пространства в компании больше нет. Из серии – я к тебе не лезу и ты ко мне не лезь. Этого больше нет.

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

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

    Оплата

    Самое интересное. В аджайл не принято платить людям фиксированную зарплату, так как успех компании зависит от степени участия каждого конкретного сотрудника.

    Оклад если и есть, это больше из серии, чтобы человек не умер с голоду. Всё остальное по результату.

    Текучка

    Она будет, причем существенная. В нашем обществе не принято работать в команде и получать деньги за конкретные результаты (хотя в последнее время ситуация меняется).

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

    Коротко о главном

    Для кого все таки подойдут методы управления проектами agile? Для больших компаний или для маленьких? На самом деле и для тех, и для других.

    Большие компании от них “молодеют”, становятся более подвижными и менее бюрократичными, небольшим же компаниям они дают мощный рывок.

    Ведь Вы перестаете работать по-старинке, а Ваши сотрудники перестают думать (и работать) как большинство Ваших конкурентов.

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

    Но повторюсь, при условии, что Вы постоянно реализуете новые продукты или проекты.

    Казалось бы, актуальность на лицо. Я же предлагаю Вам пойти другим путем. Не рубить с плеча.

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

    Спасибо!

    Наш менеджер свяжется с Вами в ближайшее время!

    Что-то пошло не так

    Попробуйте повторить попытку

    «На данный момент мы делаем ребрендинг сайта и он станет активным в ближайшее время.

    Но Вам же нужно увеличение продаж уже сейчас?! Поэтому заполните форму справа и мы свяжемся с Вами для презентация услуги.»

    1. Общие положения

    1.1. Политика в отношении обработки персональных данных (далее — Политика) направлена на защиту прав и свобод физических лиц, персональные данные которых обрабатывает ИП Жестков Н. В. (далее — Оператор).
    1.2. Политика разработана в соответствии с п. 2 ч. 1 ст. 18.1 Федерального закона от 27 июля 2006 г. № 152-ФЗ «О персональных данных» (далее — ФЗ О персональных данных»).
    1.3. Политика содержит сведения, подлежащие раскрытию в соответствии с ч. 1 ст. 14 ФЗ «Оперсональных данных», и является общедоступным документом.

    2. Сведения об операторе

    2.1. Оператор ведет свою деятельность по адресу 664009, г. Иркутск, ул. Ядринцева, 1/9, 70.
    2.2. Руководитель Жестков Никита Владимирович (телефон +7 (964) 111-8758) назначен ответственным за организацию обработки персональных данных.
    2.3. База данных информации, содержащей персональные данные граждан РоссийскойФедерации, находится по адресу: mailigen.ru, in-scale.bitrix24.ru, mail.yandex.ru, in-scale.ru, vk.com, facebook.com, manychat.com.


    3. Сведения об обработке персональных данных

    3.1. Оператор обрабатывает персональные данные на законной и справедливой основе для выполнения возложенных законодательством функций, полномочий и обязанностей, осуществления прав и законных интересов Оператора, работников Оператора и третьих лиц.
    3.2. Оператор получает персональные данные непосредственно у субъектов персональных данных.
    3.3. Оператор обрабатывает персональные данные автоматизированным и не автоматизированным способами, с использованием средств вычислительной техники и без использования таких средств.
    3.4. Действия по обработке персональных данных включают сбор, запись, систематизацию,накопление, хранение, уточнение (обновление, изменение), извлечение, использование,передачу (распространение, предоставление, доступ), обезличивание, блокирование,удаление и уничтожение.
    3.5. Базы данных информации, содержащей персональные данные граждан РоссийскойФедерации, находятся на территории Российской Федерации.

    4. Обработка персональных данных клиентов

    4.1. Оператор обрабатывает персональные данные клиентов в рамках правоотношений сОператором, урегулированных частью второй Гражданского Кодекса Российской Федерацииот 26 января 1996 г. № 14-ФЗ, (далее — клиентов).
    4.2. Оператор обрабатывает персональные данные клиентов в целях соблюдения норм законодательства РФ, а также с целью:
    — заключать и выполнять обязательства по договорам с клиентами;
    — осуществлять виды деятельности, предусмотренные учредительными документами ИПЖестков Н. В.;
    — информировать о новых продуктах, специальных акциях и предложениях;
    — информировать о новых статьях, видео и мероприятиях;
    — выявлять потребность в продуктах;
    — определять уровень удовлетворённости работы.
    4.3. Оператор обрабатывает персональные данные клиентов с их согласия,предоставляемого на срок действия заключенных с ними договоров. В случаях,предусмотренных ФЗ «О персональных данных», согласие предоставляется в письменном виде. В иных случаях согласие считается полученным при заключении договора или при совершении конклюдентных действий.
    4.4. Оператор обрабатывает персональные данные клиентов в течение сроков действия заключенных с ними договоров. Оператор может обрабатывать персональные данные клиентов после окончания сроков действия заключенных с ними договоров в течение срока,установленного п. 5 ч. 3 ст. 24 части первой НК РФ, ч. 1 ст. 29 ФЗ «О бухгалтерском учёте» и иными нормативными правовыми актами.
    4.5. Оператор обрабатывает следующие персональные данные клиентов:
    — Фамилия, имя, отчество;
    — Тип, серия и номер документа, удостоверяющего личность;
    — Дата выдачи документа, удостоверяющего личность, и информация о выдавшем его органе;
    — Год рождения;
    — Месяц рождения;
    — Дата рождения;
    — Место рождения;
    — Адрес;
    — Номер контактного телефона;
    — Адрес электронной почты;
    — Идентификационный номер налогоплательщика;
    — Номер страхового свидетельства государственного пенсионного страхования;
    — Должность;
    — Фотография.
    4.6. Для достижения целей обработки персональных данных и с согласия клиентов Оператор предоставляет персональные данные или поручает их обработку следующим лицам:
    — менеджер по продажам
    — руководитель проекта
    — менеджер проекта
    — маркетолог

    5. Сведения об обеспечении безопасности персональных данных

    5.1. Оператор назначает ответственного за организацию обработки персональных данных для выполнения обязанностей, предусмотренных ФЗ «О персональных данных» и принятыми в соответствии с ним нормативными правовыми актами.
    5.2. Оператор применяет комплекс правовых, организационных и технических мер по обеспечению безопасности персональных данных для обеспечения конфиденциальности персональных данных и их защиты от неправомерных действий:
    — обеспечивает неограниченный доступ к Политике, копия которой размещена по адресу нахождения Оператора, а также может быть размещена на сайте Оператора (при его наличии);
    — во исполнение Политики утверждает и приводит в действие документ «Положение об обработке персональных данных» (далее — Положение) и иные локальные акты;
    — производит ознакомление работников с положениями законодательства о персональных данных, а также с Политикой и Положением;
    — осуществляет допуск работников к персональным данным, обрабатываемым в информационной системе Оператора, а также к их материальным носителям только для выполнения трудовых обязанностей;
    — устанавливает правила доступа к персональным данным, обрабатываемым в информационной системе Оператора, а также обеспечивает регистрацию и учёт всех действий с ними;
    — производит оценку вреда, который может быть причинен субъектам персональных данных в случае нарушения ФЗ «О персональных данных»;
    — производит определение угроз безопасности персональных данных при их обработке в информационной системе Оператора;
    — применяет организационные и технические меры и использует средства защиты информации, необходимые для достижения установленного уровня защищенностиперсональных данных;
    — осуществляет обнаружение фактов несанкционированного доступа к персональным данным и принимает меры по реагированию, включая восстановление персональныхданных, модифицированных или уничтоженных вследствие несанкционированного доступак ним;
    — производит оценку эффективности принимаемых мер по обеспечению безопасностиперсональных данных до ввода в эксплуатацию информационной системы Оператора;
    — осуществляет внутренний контроль соответствия обработки персональных данных ФЗ «Оперсональных данных», принятым в соответствии с ним нормативным правовым актам,требованиям к защите персональных данных, Политике, Положению и иным локальнымактам, включающий контроль за принимаемыми мерами по обеспечению безопасностиперсональных данных и их уровня защищенности при обработке в информационнойсистеме Оператора.

    6. Права субъектов персональных данных

    6.1. Субъект персональных данных имеет право:
    — на получение персональных данных, относящихся к данному субъекту, и информации,касающейся их обработки;
    — на уточнение, блокирование или уничтожение его персональных данных в случае, еслиони являются неполными, устаревшими, неточными, незаконно полученными или неявляются необходимыми для заявленной цели обработки;
    — на отзыв данного им согласия на обработку персональных данных;
    — на защиту своих прав и законных интересов, в том числе на возмещение убытков икомпенсацию морального вреда в судебном порядке;
    — на обжалование действий или бездействия Оператора в уполномоченный орган позащите прав субъектов персональных данных или в судебном порядке.
    6.2. Для реализации своих прав и законных интересов субъекты персональных данныхимеют право обратиться к Оператору либо направить запрос лично или с помощьюпредставителя. Запрос должен содержать сведения, указанные в ч. 3 ст. 14 ФЗ «Оперсональных данных».

    УТВЕРЖДАЮ
    Н. В. Жестков
    29.06.2020

    Уважаемый пользователь. Любая информация, размещенная на сайте in-scale.ru, предназначена только для свободного изучения пользователями сайта. Администрация сайта прилагает все усилия для того, чтобы предоставить на этом сайте достоверную и полезную информацию, которая отвечает на вопросы пользователей сайта, но в то же время не исключает возникновения ошибок.

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

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

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

    Некоторые ссылки на in-scale.ru ведут к ресурсам, расположенным на сторонних сайтах. Данные ссылки размещены для удобства пользователей и не означают, что Администрация одобряет содержание других сайтов. Кроме этого, Администрация in-scale.ru не несет никакой ответственности за доступность этих ресурсов и за их контент. Это заявление относится ко всем ссылкам, представленным на in-scale.ru, и материалам всех веб-сайтов, доступных через баннеры и ссылки на веб-сайте по адресу in-scale.ru

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

    In-scale.ru не гарантирует возможность приобретения или использования тех или иных товаров или услуг по ценам и/или на условиях, указываемых в рекламных блоках (текстах, баннерах).

    Вы соглашаетесь с тем, что in-scale.ru не несет никакой ответственности за возможные последствия (включая любой ущерб), возникшие в результате каких-либо отношений с рекламодателями и продуктами с in-scale.ru

    Администрация сайта in-scale.ru вправе отказать в доступе к сайту любому Пользователю, или группе Пользователей без объяснения причин своих действий и предварительного уведомления.

    Администрация вправе изменять либо удалять ссылки на информацию, графические, звуковые и прочие данные, размещенные Пользователями на in-scale.ru, без предварительного уведомления и объяснения причин своих действий.

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

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

    Бездействие со стороны Администрации в случае нарушения Пользователем либо группой Пользователей пользовательского соглашения не лишает Администрации права предпринять соответствующие действия в защиту интересов in-scale.ru позднее.

    Все права на материалы, находящиеся на in-scale.ru, охраняются в соответствии с законодательством ЕС и РФ, в том числе, об авторском праве и смежных правах.

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

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

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

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

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

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

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

    Администрация in-scale.ru в любое время вправе внести изменения в Правила, которые вступают в силу немедленно. Продолжение пользования сайтом после внесения изменений означает ваше автоматическое согласие на соблюдение новых правил.

    Данный документ гласит о том, что вы даете свое согласие на то, что ИП “Жестков Н.В.”, команда ресурса in-scale и сам сайт in-scale.ru не несёт ответственность за ошибочно принятые Вами решения по поводу доходов, прибылей, способов ведения бизнеса, продукции тренинг-центра, предоставляемых услуг или других материалов, что размещаются на данном сайте: текстовой, аудио и видео информации.

    Заполняя форму подписки на сайте in-scale.ru, Вы соглашаетесь с политикой конфиденциальности проекта, а также с другими положениями:

    1. Подписчик дает бессрочное согласие на обработку всех персональных данных, предоставленных на домене in-scale.ru

    2. Подписчик не возражает против получения e-mail, смс уведомлений информационного и рекламного характера о предстоящих акциях, изменениях на проекте, иных событиях с домена in-scale.ru или от сообществ vk.com/in_scale, facebook.com/inscalerus

    3. Подписчик может отписаться от информационной рассылки проекта In-scale в любое время по своему желанию при помощи специальной гиперссылки, а также обратившись в службу поддержки по адресу info@in-scale.ru и попросив удалить его контакты адрес из нашей подписной базы.

    После получения администрацией сайта in-scale.ru такой просьбы, e-mail адрес или аккаунт в социальных сетях будет удален из базы в течение 72 часов, кроме выходных и праздничных дней.

    ИП “Жестков Н.В” гарантирует полный возврат средств за приобретенный цифровой продукт по первому требованию клиента.

    Срок гарантийного периода для всех цифровых продуктов составляет 7 календарных дней с момента оплаты.

    Для того, чтобы запросить возврат денежных средств за определенный продукт обратитесь на info@in-scale.ru . Все заявки рассматриваются в течении 72 часов, кроме выходных и праздничных дней.

    Возврат денежных средств осуществляется путём перевода необходимой суммы на один из электронных кошельков (WebMoney, Яндекс.Деньги), либо на карту VISA/MASTERCARD в пределах России. Длительность транзакции – от 1 до 5-х банковских дней после отправки денег.

    Как Agile-менеджмент помог Spotify разработать свою лучшую фичу

    Автор Стивен Деннинг в своей книге «Эпоха Agile. Как умные компании меняются и достигают результатов», рассказывает об основных принципах популярного сейчас Agile-управления. Вот как эти принципы повлияли на Spotify.

    Spotify, быстро растущий шведский сервис музыкального стриминга с аудиторией более 100 млн активных пользователей и 30 млн платных, осознала преимущества Agile-управления в середине 2015 года, а внедрила Agile еще раньше, с момента создания в 2008 году. Тогда она сформировала множество самоорганизующихся команд, полных решимости создавать больше ценности для пользователей сервиса.

    Исходный принцип Agile-менеджмента заключается в том, что расширение инноваций, идущих снизу, будет постоянно и существенно повышать ценность для пользователей и самой компании. Исходя из этого посыла команды Spotify (по состоянию на середину 2020 года в них входили 2500 человек) стремятся узнать все о вас как о слушателе музыки, так и пользователе Spotify. Затем они ищут интересные способы понравиться вам в обоих ипостасях.

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

    Но в марте 2015 года программисты компании Крис Джонсон и Эд Ньюетт пришли к Мэтту Оглу, старшему менеджеру по продукту, человеку с двумя научными степенями в английской литературе и опытом работы в качестве программиста. Их идея оказалась переломной. Они предложили решение проблемы, долгие годы мучившей и Spotify, и другие стриминг-сервисы вроде Pandora и Apple Music, — как помочь пользователям найти музыку по вкусу в каталоге с миллионами песен, не тратя при этом время на прослушивание того, что не нравится?

    В 2013 году Spotify представила новую функцию News-Feed. С ее помощью пользователи могли получить персонализированные рекомендации альбомов и артистов. Это был прогресс, но меломанам по-прежнему приходилось тратить время на изучение рекомендаций и прослушивание ненужной музыки. В 2014 году Spotify представила функцию Discover, которая группировала рекомендации в подборки, как на Netflix, — более простые, чем News-Feed, но по-прежнему требующие усилий со стороны активных пользователей. Исследования показали, что те по-прежнему тратили много времени на прослушивание плейлистов, созданных редакторами Spotify.

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

    Так зародилась невероятно успешная идея Spotify, позже получившая название Discover Weekly. Руководству предложение понравилось.

    Мэтт Огл обсудил с программистами различные возможности его воплощения. Затем новаторы представили идею разработчику, сыгравшему роль «злого полицейского». «Зачем нам нужна эта функция? — спросил он. — Мы и так делаем многое для пользователей! Что в ней такого особенного?» Эти вопросы помогли команде проверить идею путем небольшого эксперимента.

    Spotify уже собирала данные об активных пользователях — около 75 млн человек. Компания также обладала высочайшими возможностями машинного обучения и искусственного интеллекта. Сотрудники уже разработали музыкальные микрожанры и классифицировали по ним всю базу музыки и миллиарды плейлистов. Но самое главное: Spotify внедрила организационную культуру Agile-управления.

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

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

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

    Он вспоминает, как после появления первых плейлистов услышал одну из песен Яна Хаммера, автора трека к телесериалу «Полиция Майами». «Начало было попсовым, затем вступили струнные, — говорил он. — А когда я услышал вокал, то подумал: черт возьми, мы просто обязаны внедрить эту функцию. Мир должен знать об этой песне!»

    Огл и его команда провели другой небольшой эксперимент с участием 1% активных пользователей Spotify — примерно миллиона человек. Вновь реакция была положительной. Удивительно, но 62% респондентов обнаружили в персонализированном еженедельном плейлисте свою «новую любимую песню».

    В результате руководство Spotify решило запустить функцию Discover Weekly для всех пользователей сервиса. Еженедельное расширение масштаба Discover Weekly с 1 млн пользователей до 75 млн на 21 языке в разных часовых поясах оказалось для программистов серьезной задачей.

    Тем не менее, работая в духе Agile, полностью сосредоточившись на цели, команда завершила работу всего лишь за пару месяцев. Когда в июле 2015 года Discover Weekly представили всем пользователям Spotify, успех был ошеломительный. Такого Огл и его программисты даже помыслить себе не могли. Фактически Discover Weekly стала всемирным феноменом. Она способствовала стремительному развитию бренда Spotify и невероятному притоку новых пользователей. Это не просто новая функция — это практически новый бренд, которым пользуются жители других стран.

    Название Discover Weekly не нуждается в переводе на другие языки. Каждый понедельник пользователи Spotify, число которых сегодня перевалило далеко за 100 млн, получают плейлист из 30 песен. Он похож на подарок от талантливого друга-меломана. Он знает ваши музыкальные предпочтения и объехал весь мир, чтобы лично отобрать лучшую музыку. И она вам понравится.

    По словам пользователей, плейлисты Discover Weekly порой пугают их — до того свежими и знакомыми они кажутся. Самая типичная реакция на каждую новинку: «Похоже, Discover Weekly знает меня лучше, чем я сам!». В течение первых шести месяцев песни из плейлистов Discover Weekly были проиграны несколько миллиардов раз. «Если вы самый неизвестный, самый странный музыкант в мире и ваша музыка понравится лишь 20 поклонникам, — говорит Огл, — то мы сможем найти этих 20 человек и связать вас на таком уровне, на каком это не осуществлялось никогда».

    Discover Weekly дает Spotify огромное преимущество перед конкурентами типа Pandora и Apple Music, которые также предлагают обширные каталоги музыки, однако не используют персонализированный подход. Впрочем, в Spotify знают, что нельзя останавливаться на достигнутом: конкуренты вскоре воссоздадут свой Discover Weekly. Работая в духе Agile, Spotify уже обгоняет соперников благодаря инновациям, которые призваны еще сильнее привязать пользователей к любимому сервису. Руководство Spotify знает: сервис выживет, только если продолжать следовать Agile и вводить инновации быстрее конкурентов.

    Материалы по теме:

    Нашли опечатку? Выделите текст и нажмите Ctrl + Enter

    Agile для дедушки: гибкие методологии на простом примере

    Маркетолог Наталья Бабаева об интуитивности Agile и ситуациях, когда необходим Scrum.

    Когда что-то нельзя объяснить просто, невольно начинаешь подозревать неладное. Особенно если для того, чтобы понять что-то, нужно изобрести это заново.

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

    Стоп, Наташа. Не надо думать. Ты прочитала три книги на эту тему, послушала пару двухдневных семинаров, прошла Agile-курс, посмотрела несколько видео и провела несколько стратегических сессий с Agile-тренерами. И пару лет поработала в Scrum-процессе (и это не был настоящий Scrum). Да что ты можешь понимать. Не смей искать ответ на свой вопрос. Записывайся и жди консультации с Agile-тренером.

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

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

    Agile и Scrum — довольно интуитивные вещи, которые важно включать. И вовремя выключать.

    Зовите дедушку и поехали.

    Объясняем дедушке Agile

    Дедушка, представь. Ты молод, недавно женился. Кто-то приютил вас с женой на лето. Но скоро зима, нужно успеть построить дом. Что бы ты сделал?

    Построил бы маленький дом, но с хорошим фундаментом, лишь бы въехать до зимы. Накрыл бы крышу просто, чтобы перезимовать.

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

    Молодец, дедушка. Теперь запоминай:

    • Дом мы будем называть «продуктом». Да, не смейся.
    • Твой домик «лишь бы въехать» — это MVP, «минимальный жизнеспособный продукт». Дом с пристройкой, дом с верандой — это инкременты, новые функции.
    • Ты — Product Owner, отвечаешь за то, каким именно будет дом. Жена — стейкхолдер, заинтересованная сторона. Ее мнение важно, в этом доме ей придется жить.
    • Список будущих функций (пристройка, веранда, второй этаж, хорошая крыша и все, что вам нужно) — это бэклог, описание необходимой работы.
    • Когда вы с женой решаете, что делать дальше, вы проводите бэклог-груминг, заботитесь о том, чтобы спланировать работу.

    А теперь расскажи, как ты строил бы дом.

    Я плохой строитель, зато хороший наладчик, поэтому остался бы работать на заводе. Строить дом я позвал бы брата и дядю Вову. У брата золотые руки, а сосед умный — нарисует, рассчитает. Оба работяги. Соседку попросил бы кормить их три раза в день. И мирить, если поругаются.

    • ​Твой брат и дядя Вова — команда разработчиков дома-продукта. Их сила в том, что они могут заменять друг друга. Они — «Т-образные люди», то есть что-то умеют хорошо, а в остальном готовы помогать друг другу.
    • Ваша соседка — Scrum-мастер. Ее задача — поддерживать работоспособность команды.

    А как бы ты следил, чтобы они делали все правильно? Как узнавал бы, какие стройматериалы им нужны?

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

    Так вот, дедушка:

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

    А как же жена? Ей тоже интересно поучаствовать в строительстве дома.

    Я привозил бы жену раз в две недели. Вдруг и вправду что-то не так.

    Cмотри, что получается:

    • Двухнедельные промежутки между приездами жены — это длина спринта, периода вашей работы над домом-продуктом.
    • Приезд жены — это показы. Лучше планировать работу в спринте так, чтобы каждый раз было что показать.
    • Новоселье — запуск продукта.

    Дедушка, ты только что заново изобрел Agile и большую часть Scrum. Когда нужно сделать что-то быстро и дешево, люди интуитивно изобретают гибкие вещи и методы. Так часто происходило и в прошлом.

    Историческая справка для дедушки

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

    В первый год они строили себе маленькое жилище из дерна ( слоя почвы с корнями растений) с печкой из камней и грязи. Это был их минимально жизнеспособный продукт (MVP). На второй год они сооружали себе домик из грубо отесанных бревен (вторая версия продукта). И только на третий год обычно начиналось строительство настоящего дома.

    У жителей фавел в Латинской Америке времени побольше, зимой тепло. Но они крайне ограничены в деньгах.

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

    Когда у программистов было мало времени и средств, они тоже пришли к гибкости и назвали такой подход Agile («гибкий», «подвижный»).

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

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

    Зачем это нужно

    Дедушка, представь, если бы у тебя было достаточно денег и времени на строительство большого дома?

    Тогда зачем мне так напрягаться. Я нанял бы строительную компанию и заказал дом «под ключ». Мы разработали бы проект, подписали договор. Я приезжал бы на стройку больше из любопытства, ведь большое строительство идет точно по плану.

    Но ведь строить большой дом нужно дольше. Тогда ты не смог бы поселиться в сентябре.

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

    А если бы ты не был уверен, что хочешь жить в доме, а не в квартире?

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

    Выводы для внука

    Дедушка все понял. А внук?

    1. Принципы Agile интуитивны. Если ресурсы ограничены, все мы становимся более гибкими. Я бы добавила к Agile-манифесту один пункт: «Включая Agile, сохраняйте здравый смысл».
    2. Экспериментальному проекту нужен Agile-подход. Если мы не знаем, нужен ли нам продукт или какой он должен быть, лучше строить его по принципам Agile. Даже если есть ресурсы.
    3. Если ресурсов достаточно, а мы точно знаем, чего хотим, то нужно забыть про MVP и Agile и просто строить по рецептам хорошего проектного менеджмента. В таких условиях мы будем переплачивать за Agile, а не экономить. Мы не сможем оптимизировать сроки и расходы по проекту: будем строить три года вместо шести месяцев и заплатим за две крыши вместо одной.

    Материал опубликован пользователем.
    Нажмите кнопку «Написать», чтобы поделиться мнением или рассказать о своём проекте.

    Комментарий удален по просьбе пользователя

    Комментарий удален по просьбе пользователя

    Комментарий удален по просьбе пользователя

    Возьмите меня джуном

    Жду материал «Варим борщ по Agile» для девули-маркетолога.

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

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

    Я не особо силен в Аджайл или Скрам. Все это интересно, но чересчур заморочено и называют казалось бы обыкновенные вещи новыми терминами, указывая на то что ранее все делалось через ж*пу, а тут «по-новому» с заправленными штанами.

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

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

    Мой принцип: найди проблему и накидай несколько вариантов решения. Выбери оптимальное к проблеме и тестируй. По ходу дела, возникают новые решения.

    Таким образом я вывел производство приборов с 50 штук/месяц до 300 штук. Сроки производства варьировались от 6 месяцев до максимально двухнедельных.

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

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

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

    Агил/Скрам надо пробовать и брать лучшее и эффективное под свой проект.

    Комментарий удален по просьбе пользователя

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

    Пробует каждый в меру заинтересованности и потребности.

    Комментарий удален по просьбе пользователя

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

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

    @Голь на выдумки хитра. Вы предпочтете, чтобы вам загородный дом построили за год и сто денег, или попросите копать пока фундамент на сколько денег хватило?

    Хороший пример полного непонимания сути и фактического его понимание в рф — аджайл это по понятиям.

    Важнее != отсутсвие документации. То есть — нехер ссылаться на заведомо тупую запись требования которая фактически противоречива или блокирует/портит/замедляет работу/искажает рабочий продукт, что выявляется на «регулярных проверках» (ретроспективах) где идет моментальная корректировка докумнтации в верную сторону и работа от точки проявления дефекта реальностью в этой документации.

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

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

    Именно в этом и заключается слово «важнее» — то есть приоритетнее, но не отсутсвие живых докуменов по — а) концепции б) архитектурынм требованиям в) рабочим проектированиям г) отчетам по факту прорерок (Это было норм, это хуйня — выпиливаем, потому то и потому то, число подпись) д) фактом «ввода в эксплуатацию» релиза актами / церемониями и прочими формальностями.

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

    В общем аджайл это когда работа идёт «по понятиям», а неаджайл это работа «по закону», «по бумажке».

    бумажка — это документ.

    Ваш ход коллега.

    Спасибо что приоткрыли свой личный тезаурус.

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

    К этому в дополнение погуглите про управление требованиями.

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

    Где-то это прокатывает (много где) — и ваш аджайл (это вы так бардак и неорганизованные работы по созданию систем называете) встает в копейку не вам а тому кто это «заказывает».

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

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

    То что вы называете «работать без них по понятиям» как вам в голову взбредет — это и называется бардак или дурдом от степени сложности.

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

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

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

    А выдавать бардак и отсутствтие мыследеятельности и анализа (результатами которой всегда являюстя строгие документы как основы для начала и завершения любых работ) за agile (с вашим личным тезаурусом что такое документ) не стоит — не надо так ))

    Материалы для самостоятельного изучения Agile

    Scrum

    1) Scrum Guide — краткое и ёмкое описание Scrum

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

    Kanban

    2) Настольная игра GetKanban, русифицированную версию которой вы можете приобрести у нас (напишите на info@onagile.ru)

    3) Наш двухдневный тренинг Kanban Method Professional, в котором мы собрали всю необходимую информацию, чтобы вы могли запустить и поддерживать Kanban инициативу у себя в команде.

    Как менеджеру превратиться в Agile коуча/Scrum мастера:

    3) Мой тренингAdvanced ScrumMaster & Agile Coach, где я обучаю искусству выращивания самоорганизованных команд.

    Как проводить ретроспективу:

    2) Онлайн каталог активностей для ретроспектив. Основан на методике описанной в книге (1).

    3) Наш однодневный тренинг по этой теме: Искусство проведения ретроспектив

    Для программистов:

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

    2) Классика: Рефакторинг. Улучшение существующего кода. Вообще, я рекомендую исключительно все книги Мартина Фаулера. Они все отличные, дают правильный mindset.

    Для Product Owner’ов:

    Как придумывать именно то, что нужно людям:

    Это вводная книга, больше идеологическая, чем методологическая. Если не читали — читать обязательно.

    Это уже по сути методичка. Содержит конкретные понятные шаги что нужно делать. Имеет смысл читать только после прочтения первой книги.

    Роль Product Owner в Agile процессах

    Для HR и TOP менеджмента:

    1) Книга Открывая организации будущего. Очень полезна для понимания сути Agile организаций. Много примеров, в том числе не из IT области.

    2) Книга Сердце компании, где рассказывается как выстраивать работу команды ТОП менеджеров

    Масштабирование Agile:

    2) Посмотрите 7-ми минутный ролик про Scaled Agile Framework (SAFe): Для более глубокого погружения в SAFe обращайтесь к первоисточнику

    SCRUM и AGILE. IT-подходы в управлении бизнес-проектами

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

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

    Таким образом, AGILE — гибкая методология разработки программ, которая применима и при разработке и реализации бизнес-проектов. Это понятие было введено в 2001 году американскими программистами в рамках Agile Manifesto, — манифеста методологии адаптации в создании новых продуктов, который выступил альтернативой существовавшим тогда «золотым стандартам» программирования.

    В манифесте выделены основные принципы:

    • Люди и их взаимодействие в команде важнее самых дорогих и прогрессивных процессов и инструментов;
    • Работающий и отвечающий запросам клиента продукт важнее отчетов и полной документации;
    • Понимание с заказчиком важнее строго следования условиям контракта;
    • Открытость для нововведений и изменений важнее самого проработанного плана.

    Из данных основных принципов следуют 12 направлений работы:

    1. Запросы клиента и их удовлетворение за счет эффективной и оперативной работы — главный приоритет разработчика;
    2. Требования к продукту можно изменять на любом этапе разработки, даже в самом конце, поскольку это повышает его качество и конкурентоспособность;
    3. Регулярная поставка продукта в соответствии с временными рамками;
    4. Ежедневное общение с заказчиком на всех этапах реализации проекта;
    5. Привлечение к проекту заинтересованных личностей, мотивированных не только материальным вознаграждением, которым будете доверять.
    6. Личный разговор напрямую – самый эффективный способ передачи информации.
    7. Качественный продукт — лучший измеритель прогресса;
    8. Спонсоры проекта также как пользователи продукта и его разработчики могут работать и общаться в комфортном темпе, без пиковых нагрузок и периодов простоя;
    9. Уделять внимание дизайну, повышать пользовательские качества продукта;
    10. Не усложнять без необходимости, лишняя работа никому не нужна — пользователи и разработчики заинтересованы в простоте продукта;
    11. Самоорганизованная команда создает лучшие продукты, как с точки зрения технических характеристик, так и дизайна и пользовательских качеств;
    12. Командная работа. Повышение эффективности должно регулярно обсуждаться всеми членами команды.

    Понятие SCRUM (англ. scrum — «схватка») пришло из игры в регби, подразумевающее плотное взаимодействие в команде, и было заимствовано компаниями, работающими в сфере IT. Эта концепция представлялась как системный метод управления проектами, применяющийся совместно с принципами гибкой разработки. Эта методология позволяет контролировать гибкую работу команды и следить за качеством реализуемого продукта.

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

    Работа над проектом по принципам «гибкой разработки»

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

    Требования к команде в системе «гибкого управления»:

    Самоорганизация . Команда самостоятельно регулирует собственную работу, устанавливает временные рамки и условия работы в границах «спринта». Руководитель проекта, выступающий мастером SCRUM, не может указывать команде, каким образом создавать продукт.

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

    Функции руководителя команды
    • Руководитель проекта берет на себя роль «скрам-мастера», настраивающего работу самоорганизованных команд.
    • Он отвечает за то, чтобы донести особенности работы до всех заинтересованных лиц, включая тех, кто не входит в состав команды, которым нужно понять, как взаимодействовать с проектом.
    • Проводит обучение команды для улучшения самоорганизации и функциональных навыков.
    • Контролирует связь команды с заказчиками и рынком, собирает обратную связь для повышения ценности компании.
    • Устраняет помехи, препятствующие работе команды.

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

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

    Специально для ЗА ЧЕСТНЫЙБИЗНЕС

    Мнение редакции может не совпадать с мнением автора

    Что такое Agile-подход и зачем он нужен бизнесу?

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

    Agile («аджайл») — слово, которое последнее время звучит из каждого утюга. Но что такое Agile и, главное, зачем этот Agile нужен?

    Если открыть толковый словарь, например, Оксфордский, то можно прочитать там, как минимум, два определения:

    1. Able to move quickly and easily.
    2. Able to think and understand quickly.

    То есть, чтобы быть agile, надо уметь быстро и легко двигаться и быстро соображать. Кажется, довольно полезные качества, особенно в бизнесе. Быстро соображать и быстро реагировать — это именно то, что доктор прописал, для нашего времени, иначе просто не выжить: конкуренты сожрут. В мире всё меньше отраслей, где этих конкурентов, нет. Да ещё скорость копирования практически лишает возможности вывести продукт на рынок и почивать на лаврах. Без способности быстро адаптироваться к изменениям, которую даёт так называемая «методология Agile», выживать всё сложнее.

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

    1. Фокусируют команду на нуждах и целях клиентов.
    2. Упрощают оргструктуру и процессы.
    3. Предлагают работу короткими циклами.
    4. Активно используют обратную связь.
    5. Предполагают повышение полномочий сотрудников.
    6. Имеют в своей основе гуманистический подход.
    7. Не являются конечным состоянием, а, скорее, образом мышления и жизни.

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

    Фокусировка на нуждах и целях клиентов

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

    Самое главное, что фокусировка на клиенте при Agile-подходе появляется не в одной только голове владельца бизнеса (она там и так уже есть), а у всех, кто работает над созданием продукта или сервиса. Каждый участник процесса должен понимать, кто клиент, чего он хочет, какие его проблемы мы решаем своим продуктом, что он любит, чего боится и так далее. Такая всеобщая фокусировка позволяет создавать на порядок более качественные решения. Я неоднократно сталкивался с ситуацией, когда люди, раньше отвечавшие за какой-то маленький кусочек работы, поняв цели клиента, начинали выдавать замечательные идеи, а люди, которые отвечают за разработку продукта, с удивлением за ними записывали. Или — как на групповых сессиях проработки продукта подобные идеи оттачиваются разными людьми и дополняют друг друга, из просто хороших превращаясь в отличные. И, конечно, как они потом реализуются.

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

    Примеры подобных инструментов — Lean Canvas, Impact Mapping, User Story Mapping и другие Agile-методы описания гипотез и процессов.

    Упрощение оргструктуры и процессов

    Один из краеугольных камней Agile — это предельная простота. И оргструктура организации, и процессы, по которым работают люди, и правила должны быть настолько простыми, насколько это возможно. Это позволит людям сфокусироваться на своей работе, на ценности, которую они создают, а не на соблюдении регламентов и правил. Прекрасные примеры такого подхода можно найти во множестве команд, работающих по Scrum — самому популярному способу организации рабочего процесса в Agile. Фактически, все договорённости и правила команды в 10-11 человек, текущие задачи на пару недель, цели, а также стратегические планы легко могут поместиться на 2-3 листа бумаги А0. На одном листе может быть так называемый «бэклог спринта», перечень всего, что команда собирается сделать в ближайшую итерацию. Если повесить такой в помещении, где идёт работа, можно избавить себя от необходимости всё это запоминать. То же самое касается и процессов. Скажем, в Скраме место и время проведения всех встреч жестко фиксируются. Любой участник точно знает, что, например, в понедельник в 10-00 планируется ближайшая итерация, а в пятницу в 17-30 — встреча по улучшению процесса работы.

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

    Примеры упрощения (и уплощения, но это тема отдельного разговора) в Agile — Scrum, Nexus, LeSS (Large-Scale Scrum, или Скрам на больших масштабах), а также сам Agile-манифест.

    Работа короткими циклами

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

    Чтобы подобного избежать, применяется так называемый итеративно-инкрементальный подход, когда:

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

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

    Ещё одно преимущество такого подхода, помимо раннего выхода на рынок и внесения изменений на ранних стадиях работы, — это возможность более точно измерять прогресс. Мы не просто «сделали 15% всей работы», что довольно абстрактно. Мы «сделали 15% функционала», который уже работает.

    Все процессные подходы в Agile имеют короткие циклы, будь то упомянутые ранее Scrum, Nexus, LeSS, SAFe или XP, плюс необходимость работы такими циклами упомянута и в самом манифесте Agile.

    Активное, системное использование обратной связи

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

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

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

    Примеры, опять-таки, есть везде: ретроспективные встречи в Scrum, Kanban, Nexus и LeSS, циклы I&A в SAFe, подход к созданию продуктов Design Thinking, циклы обратной связи в DevOps и т.д.

    Повышение полномочий сотрудников

    Зачем давать больше полномочий, когда можно дать бумажку с инструкцией? Есть, как минимум, три причины это делать.

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

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

    В-третьих, это всё та же скорость. Если человек может сам, на своём месте, никого не спрашивая, решить какую-то проблему, это сокращает время принятия решений. Не надо больше отправлять вопрос «вверх» и ждать ответа от менеджмента. Это преимущество не так заметно, если у вас работает 3 человека, но если вас 30, или 300, или 3000… В больших организациях, построенных сугубо на иерархическом принятии решений, паралич воли может быть довольно частым явлением.

    Популярные способы построения работы в Agile, особенно базирующиеся на фреймворке Scrum, предполагают систему самоорганизованных команд и поощряют лидерство на любых уровнях.

    Гуманистический подход

    Зачем относиться к людям по-человечески? То есть, моральная сторона дела ясна, а какую пользу это принесёт владельцу предприятия?

    Ответ довольно простой. Если создание того, что вы продаёте, не требует умственного труда, а только механический действий — можете не заморачиваться. Просто платите соразмерно сделанной работе, и всё. Но как только в дело вступает мозг работников — придётся считаться с принципами мотивации умственного труда. А они говорят, что для людей важны возможность самореализации, повышения своего мастерства, принесения чего-то ценного в мир, самостоятельности в решениях и ещё ряда факторов. И человек мотивированный (не путать с человеком простимулированным!) будет вкладываться в работу сильнее, и результат будет качественнее и быстрее. Да и в целом, приятная обстановка на работе добавляет желания туда приходить и работать — с этим тоже вряд ли кто поспорит.

    И, что приятно, если копнуть в тот же Скрам, то окажется, что все ключевые факторы мотивации работника умственного и/или творческого труда в него уже включены. В каждой итерации («спринте») мы ставим цель, которой хотим достичь; нам даётся возможность решать, как именно достигать цели; в конце мы смотрим, насколько мы стали лучше (или хуже) работать, чем раньше; видим людей, которые заинтересованы в продукте, и их эмоции от знакомства с ним. Особенно хорошо, если эти эмоции положительные.

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

    Agile — это не конечное состояние, а образ мышления и жизни

    Этот пункт о том, что применение Agile в целом — путь, а не цель. Нельзя «внедрить» Agile и расслабиться. Если вы выбираете этот путь, у вас всегда будет что-то ещё, что можно сделать лучше, какой-то ещё вызов, которому надо ответить, какая-то ещё проблема, которую надо решить, ещё одна высота, которую надо покорить… Это движение бесконечно, потому что нет идеального процесса или продукта, развитие и конкуренция не останавливаются никогда, как никогда не прекращается борьба за выживание в природе.

    И если всё удалось: люди в компании понимают и разделяют ценности и принципы Agile и работают согласно им, — тогда менеджменту не придётся «тащить» на себе любые изменения или «пинать» работников, чтобы они начали что-то делать по-другому. Предприятие станет единым организмом, управление которым будет отнимать меньше сил и приносить больше удовольствия.
    А там, где больше удовольствия от работы, и результат выше. Это касается не только специалистов, но и менеджмента, причём в ещё большей степени.

    На этом наше обзорное знакомство с принципами Agile заканчивается. Какие цели ставятся перед Agile в России и каких реальных результатов достигают компании, переходящие на гибкие методологии, можно узнать, познакомившись с отчётом исследования ScrumTrek об использовании Agile в России от 2020 года.

    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) — что мы делали не самым лучшим образом весь спринт и хотим улучшить далее — о том, КАК мы это делаем.

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

    Добавить комментарий