Prg67.ru

Онлайн вебинары
0 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Agile методология в менеджменте

Agile методология в менеджменте

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

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

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

Вы наверняка слышали такие термины как SCRUM, Crystal, DSDN, Extreme programming – все это подмножества множества Agile, есть и другие agile-методики, которые упоминаются не так часто.

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

Как возник Agile

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

На тот момент в ходу был метод «водопада» (waterfall) – последовательной разработки программного продукта из шести стадий:

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

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

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

Гибкие методы появлялись органично в ответ на условия конкуренции:

  • если нет определенности в отношении финальных параметров продукта, не нужны жесткие спецификации – используем список пожеланий к продукту (back-log), который может меняться и дополняться по мере развития проекта;
  • если данные о требованиях рынка противоречивы, и единственное решение – как можно быстрее показать конечному клиенту или начать продавать, то делим продукт на части, которые сразу можно использовать или выпускаем MVP – минимальный жизнеспособный продукт (minimum viable product).
  • если сроки «жмут», надо поставить график перед лицом, а для наглядности заменить его доской «Канбан» (см. также про бережливое производство ). И так далее.

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

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

О принципах Agile четко и ясно

Все основные принципы гибкой разработки изложены в одном документе – Манифесте (Agile Manifesto, 2001). Выше я уже несколько раз упоминал отдельные принципы, лежащие в методологиях объединяемых Agile.

  1. Люди и взаимодействие важнее процессов и инструментов – акцент на людях и отношениях между ними, как основном факторе успешности проекта. Люди руководят и применяют необходимые им процессы и инструменты, а не работают под управлением заранее принятого регламента. Именно поэтому agile-методики предполагают отбор в команду мотивированных профессионалов, с универсальными навыками. Тогда не потребуется внедрять изощренные методы поощрений и штрафов, люди смогут подменять другу друга, участвовать в дискуссии о продукте осознанно и эффективно. Взаимодействие между членами команды может строиться с помощью любых удобных инструментов, но не документов, регламентов и инструкций.
  2. Работающий продукт важнее исчерпывающей документации – менять, адаптировать, корректировать легче то, что уже существует и работает, а не то, что подробно и исчерпывающе описано в бумагах. Сначала надо сделать что-то простое и работающее, чтобы затем, оценив и апробировав сделанное, внести коррективы или отказаться от реализованного в пользу иного варианта исполнения. Но в итоге либо продукт есть и работает (пусть и требует корректировок, дополнений и доработки), либо есть проверенная гипотеза, от которой надо отказаться. В противном случае в большинстве случаев будет реализован проект, точно соответствующий описанию на бумаге, но не соответствующий рынку, производству, и главное реальным нуждам клиента.
  3. Сотрудничество с заказчиком важнее согласований условий контракта – в сложившейся реальности заказчик – а им может быть и соответствующее подразделение внутри компании – не всегда может четко сформулировать требования к продукту, зачастую у него есть только профиль клиента и проблема, с которой тот сталкивается. Заказчик может оценить реализованный продукт с точки зрения соответствия его ожиданиям, но не формализовать их. Ему легче потратить время и деньги на версии продукта, чем на всестороннее и исчерпывающее описание, причем такое описание может оказаться более дорогим, трудоемким и затратным по времени, чем гибкая разработка. Методом оптимизации в данном случае как раз и будет сотрудничество с заказчиком, вовлечение его в работу проектной команды.
  4. Готовность к изменениям важнее следованию первоначальному плану – это, наверное, самый противоречивый постулат. С одной стороны легче и проще менять все по ходу реализации, с другой — процесс такой разработки может затянуться на неконтролируемое время и привести к неожидаемым результатам.

Ключевые принципы гибкой разработки, изложенные в Манифесте:

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

Читать еще:  Менеджер под каждый сервис

На примере калькулятора для анализа проекта:

  • по завершении первого спринта вычисляется NPV в Microsoft Excel – все основные формулы работают, ошибок нет, выдается только финальная цифра – рассчитанный NPV;
  • по завершении второго спринта NPV рассчитывается также как по итогам первого спринта, но добавляется функциональность – комментарий о полученном значении, расчет IRR и других критериев – для более полной картины;
  • по завершении третьего спринта на основе разработанной в первых двух спринтах логики и формул, выверенных и согласованных с заказчиков текстов готовится десктопная версия продукта;
  • по завершению четвертого спринта готовится мобильная версия продукта и… вуаля! Продукт готов к использованию для задач заказчика.

Области применения Agile

Agile в своем максимальном объеме применим и эффективен при создании продуктов, которых:

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

Таким образом, применение agile-методов оправданно в следующих сферах бизнеса:

  1. Программное обеспечение для массового сегмента, в том числе мобильные приложения, игры и т.п.
  2. Стартап-проекты – это идеальная почва для внедрения гибких методологий.
  3. Интернет-порталы и СМИ.
  4. Медицинские проекты – тело человека до сих пор в значительной мере «терра инкогнита», что создает высокую долю неопределенности в медицине.
  5. Образовательные продукты и проекты. Если мы говорим о чем-то новом, а не о компиляции старых методов и практик, то образовательные проекты – стартапы на неизведанной территории, все ищут новые методы цифровой эпохи на замену старым технологиям индустриального мира.
  6. Консалтинг – любой проект в этой сфере требует применения большинства принципов Agile Manifesto. McKinsey однозначно используют методику соответствующую указанным принципам.
  7. Разработка финансовых и страховых продуктов (индустрия финтех), так как финансовые компании сегодня, это в большой степени ИТ-компании, а финансовый продукт уже стал в значительной степени ИТ-продуктом или применяет результаты работы ИТ-проектов/продуктов.

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

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

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

Agile

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

История зарождения Agile

Изначально термин Agile относился к ИТ-индустрии и употреблялся в контексте гибких методологий разработки программного обеспечения: экстремального программирования (XP), Crystal Clear, DSDM, Feature driven development (FDD), Scrum, Adaptive software development, Pragmatic Programming, быстрая разработка приложений (RAD) и других адаптивных методов, суть которых состоит в ускорении процессов создания продукта путем микропланирования, коротких производственных циклов и оперативного реагирования на изменения. Ключевой смысл этих Agile-практик отражен в манифесте гибкой разработки программного обеспечения (Agile Manifesto), который был выпущен инициативной группой программистов в феврале 2001 года в американском штате Юта [1]. Эта дата считается началом повсеместного распространения эджайл как практики управления проектами и организации бизнес-процессов не только в ИТ-отрасли, но и в других прикладных областях. Дополнительным драйвером развития Agile-подходов является микросервисная архитектура приложений, когда весь проект состоит из набора независимых слабосвязанных модулей, которые взаимодействуют друг с другом через открытые API-интерфейсы [2]. Популярность облачных технологий (SaaS-, PaaS-, IaaS- и других сервисных моделей) также стимулирует распространение эджайл.

Гибкость против жесткости: Agile vs Waterfall

В отличие классического Project Management (PM), когда проект жестко регламентирован заранее установленными требованиями (контрактами), Agile предполагает быстроту реагирования, а также гибкую адаптацию к внешним и внутренним изменениям. Это достигается с помощью итеративной разработки продукта и эффективного межличностного общения. В водопадной (каскадной) модели PM, которая считалась стандартом де-факто, проект состоит из функциональных задач, где каждая последующая работа четко регламентирована и начинается строго после окончания предыдущей, например, тестирование начнется только после того, как написан весь код. Жесткая определенность и обилие регламентирующей документации обусловливают длину производственного цикла. При этом продукт считается готовым лишь после выполнения всех этапов [3].

Waterfall — водопадная (каскадная) модель разработки ПО

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

Гибкая разработка ПО серией итераций

Основные идеи и принципы

4 ключевые идеи Agile сфокусированы на гибкости и адаптивности этого подхода:

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

Ключевые идеи Agile

Эти идеи раскрываются в 12 принципах Agile Manifesto [1]:

  1. работающий конкурентоспособный продукт, удовлетворяющий заказчика — лучший показатель прогресса и измеритель эффективности;
  2. оперативная и бесперебойная поставка продукта, удовлетворяющего заказчика;
  3. адаптивность продукта к новым требованиям, которые могут повысить его ценность и конкурентоспособность (возможность внесения изменений на любом этапе разработки);
  4. простота и прозрачность технических решений, документации, процессов и инструментов, чтобы не создавать лишней работы;
  5. частая поставка функционирующего продукта (раз в месяц/неделю или ещё чаще);
  6. постоянный темп работы всех участников проекта на протяжении всего его срока;
  7. минимизация организационных и информационных барьеров, лучший путь передачи информации — это личный разговор лицом к лицу;
  8. тесное и ежедневное общение исполнителей с заказчиком в течении всего проекта;
  9. мотивация участников проекта и обеспечение их всеми необходимыми условиями работы, поддержкой и доверием;
  10. самоорганизация и самоконтроль команды проекта;
  11. непрерывное улучшение профессиональных компетенций команды проекта;
  12. систематический анализ и постоянный поиск возможностей оптимизации командной и индивидуальной работы.
Читать еще:  Что должен уметь делать менеджер

Главные принципы Agile

Преимущества и недостатки

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

Недостатки Agile являются прямым следствием его достоинств:

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

Главные преимущества эджайл

Методы и средства реализации

Наиболее популярными Agile-подходами считаются Scrum (скрам) и Kanban (канбан).

В Scrum над проектом работает команда профильных технических специалистов (например, аналитик, программист, тестировщик, администратор) вместе с владельцем продукта (product owner) и модератором (scrum-мастер). Product owner аккумулирует бизнес-требования, соединяет команду исполнителей с заказчиком и следит за развитием проекта. Scrum-мастер управляет процессом организации разработки по Agile-принципам: проводит общие собрания (meetings, митинги), мотивирует и поддерживает команду.

В Scrum рабочий процесс делится на равные периоды от 1 до 4-х недель (спринты), в зависимости от проекта и команды. Перед стартом каждого спринта на митинге формулируются его задачи, а в конце обсуждаются результаты. Краткосрочность и измеряемость спринтов позволяет эффективно управлять проектной деятельностью, не перегружая участников проекта авралами [4].

Спринты в Scrum

В отличие от Scrum, в команде канбан отсутствуют роли владельца продукта и модератора, а процесс разработки делится не на универсальные спринты, а на стадии выполнения задач («Планируется», «Разрабатывается», «Тестируется», «Завершено»). Жизненный цикл задачи отображается на канбан-доске, физической или электронной. Такая визуализация делает рабочий процесс открытым и понятным для всех участников, что особенно важно в Agile, когда у команды нет одного формального руководителя.

Канбан, как и другие практики бережливого производства, пришедшие из Японии, направлен на достижение баланса и выравнивание нагрузки исполнителей. Эффективность работы оценивается по среднему времени жизни задачи, от начальной до конечной стадии. Если задача прошла весь путь быстро, то команда проекта работала продуктивно и слаженно. Иначе – необходимо решать проблему: искать, где и почему возникли задержки и чью работу надо оптимизировать [4].

Задачи на Канбан-доске

Сегодня наблюдается некоторое слияние Scrum и Kanban, например, канбан-доски стали практически обязательным элементом популярных систем управления проектами (Jira, Trello, Битрикс.24, Basecamp, Мегаплан и т.д.), которые, в том числе, поддерживают методологию скрам [5].

Где, как и кем используется Agile

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

  • рост от продажи устройств на 45%;
  • сокращение сроков запуска рекламных кампаний в 2 раза;
  • рост плановой ежемесячной выручки от разработки продуктов на 20%;
  • в 1,5 раза больше запущено рекламных кампаний по направлению В2В.

Гибкие практики управления также активно применяются и в банковском секторе. Например, за год в проектном офисе ЦентроБанка в 2 раза увеличилась скорость достижения результатов, повысилась вовлеченность сотрудников, улучшилась прозрачность и управляемость изменений [7]. Подобным опытом делится Райффайзен-Банк [8] и Сбербанк [9]. Предприятия нефтегазовой промышленности также активно используют Agile для повышения эффективности своих бизнес-процессов, открывая новые офисы и выстраивая работу филиалов по адаптивным принципам [10]. Кроме того, в рамках государственных проектов цифровизации, идеи и принципы эджайл используются в бюджетных и правительственных организациях [11]. В частности, правительство Новой Зеландии, Норвегии и США изучали методы Scrum для внедрения в своих министерствах [12].

Опыт внедрения Agile в компании Ticketland

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

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

Попытки создать идеальную систему управления данными начались еще в середине девяностых годов прошлого века. Даже ФБР попыталось придумать что-то новое для замены каскадной модели управления (Waterfall), но, потратив600 млн долларов, отказалось от этой затеи. Почему же за10 лет так ничего и не удалось сделать? Проблема была в самой методике работы «по каскадам» (ступеням), когда следующий этап запускается только после того, как реализован предыдущий: если останавливался один из этапов, то замирал весь проект.

В 2001 году появился «Манифест гибкой методологии разработки программного обеспечения» (англ. Agile Manifesto), и ситуация изменилась. За счет итерационной модели удалось наладить непрерывную работу всех участников проекта, и проклятье Waterfall исчезло. А пример ФБР и выброшенных на ветер600 млн долларов научил всех.

С помощью старых подходов нельзя решать современные задачи.

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

Что было

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

Проблемы, которые предстояло решить:

  • Устаревшее программное обеспечение, заменить которое казалось практически невозможным из-за сложной работы сервиса.
  • «Сакральные» знания о проекте сосредоточены в руках нескольких сотрудников. Это делало их практически незаменимыми: когда люди уходили, компания сталкивалась с трудностями.
  • Низкая скорость разработки и низкое качество продуктов.
  • Отставание от конкурентов в технологическом плане и потеря ключевых клиентов.
  • Текучка среди разработчиков. Молодые специалисты зачастую уходили, не проработав в компании даже года. Это проблема всего рынка.

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

Читать еще:  Программа сервис менеджер

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

Что такое Agile?

Agile — это гибкая методология в разработке ПО. В ее основе лежит4 принципа:

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

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

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

Что сделали

Расстались с руководителями

Они оказались не нужны в чистом виде. Им нужно было или быть разработчиками, или становиться Product Ownerʼами.

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

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

Например, сервис отчетов, которым пользуются клиенты компании, устарел; решили создать новый и красивый. Раньше руководитель мог отдать приказ: сделайте новый сервис отчетов. Но теперь в компании стали работать иначе. Сперва Product Owner обсуждает с клиентами разные гипотезы — например, как может выглядеть новый сервис отчетов. То есть осуществляет сбор пожеланий пользователей.

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

Ввели обсуждение ретроспектив

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

Договорились о процессах и технологиях

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

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

Предложения стали оценивать в деньгах

То есть если разработчики говорят, что надо работать над фичей, они должны объяснить, как эта фича принесет компании деньги.

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

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

Установили3 принципа найма новых людей в команду

Мотивация

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

Насколько вписывается в ценности компании

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

Достаточно ли у него знаний, навыков

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

Внедрили кросс-дисциплину t-shape

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

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

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

Обучили Product Owner

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

Ключевые навыки Product Owner:

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

Внедрили пользовательские истории

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

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

Начали использовать микросервисы

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

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

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

Ссылка на основную публикацию
Adblock
detector