Agile технология




Содержание страницы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Эджайл

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

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

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

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

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

Скрам

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Agile/Scrum для начинающих. Что такое гибкая методология?

Что такое Agile и Scrum?

Что такое Agile?

В переводе с английского языка «agile» означает «живой, подвижный», но переводят его чаще как «гибкий». В отрасли разработки программного обеспечения этот термин появился в начале 2000-х годов, когда в штате Юта был издан «Манифест гибкой разработки ПО». С тех пор под «agile» понимают набор подходов по «гибкой» разработке программного обеспечения.

Суть agile-подхода изложена в «манифесте», но для заказчика ее можно коротко сформулировать так:

  • разработка ведется короткими циклами (итерациями), продолжительностью 1-4 недели;
  • в конце каждой итерации заказчик получает ценное для него приложение (или его часть), которое можно использовать в бизнесе;
  • команда разработки сотрудничает с Заказчиком в ходе всего проекта;
  • изменения в проекте приветствуются и быстро включаются в работу.

В настоящее время agile-принципы используются в работе десятки тысяч команд по всему миру.

Краткое видео о том, что такое Scrum (english).

Что такое Scrum?

Scrum — это одна из нескольких методологий гибкой разработки ПО:

    • Scrum
    • Lean
    • Feature Driving Development
    • Extreme Programming

Scrum процесс на одном листе

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

Артефакты в Scrum

В скрам используется всего четыре артефакта:

  • Product Backlog
  • Sprint Backlog
  • Sprint Goal
  • Sprint Burndown Chart.

Я рекомендую вам посетить наш тренинг «Scrum для проектных команд«. Тренинг помогает изучить Scrum-процесс от начала и до последних нюансов.

Product backlog:

  • Это список всех требований, которые нужно сделать по проекту. Когда в Backlog’e нет требований, проект считается завершенным.
  • Все требования описаны по единому шаблону, который называют User Story (пользовательская история).
  • Требования составлены так, что очевидно и понятно, какую ценность они представляют для пользователя
  • Требования отсортированы по приоритетам, которые пересматриваются каждый спринт.

На снимке ниже представлен Backlog проекта. Команда проекта выбрала 2 требования в Sprint#3.

Project Backlog (JIRA)

Sprint backlog:

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

Sprint Backlog — это обязательство команды: что они должны выполнить за ближайшие 2 недели. Каждое требование разделено на задачи, которые представлены на Kanban-доске.

Kanban Доска в Спринте

Sprint Goal

  • это краткое описание того, ради чего выполняется данный спринт.
  • цель на спринт помогает команде принимать обоснованные решения.

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

Sprint Burndown Chart

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

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

Burndown диаграмма в Jira

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

Роли в Scrum

В скрам используется всего три роли:

Роль Product Owner

  • формулирует требования
  • приоритезирует требования
  • корректирует приоритеты на каждом спринте
  • несет персональную ответственность за ценность требований для рынка/пользователей
  • отвечает за взаимодействие с рынком
  • только один человек

Product Owner — это представитель подразделения, которое владеет разрабатываемым продуктом. Например в банке это может быть Департамент карточных продуктов. Правильно определить Product Ownera не просто, т.к. эта роль требует сочетания следующих качеств:

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

В некоторых случаях допустимо назначить более одного человека на роль Product Owner. Но в этом случае необходимо назначить среди них «главного», который будет авторизовать требования в Bcaklog’e и лично расставлять приоритеты.

Роль Scrum Master

  • следит за корректным применением принципов Agile и процессов (ритуалов) Scrum
  • организует работу команды и обеспечивает её всем необходимым
  • защищает команду, несёт ответственность за её эффективность
  • только один человек.

Очень сложная роль. В классическом project management есть Руководитель проекта. В Scrum такая роль не предусмотрена. Лучшим синонимом роли Scrum Master будет «администратор». Скрам Мастер организовывает работу команды проекта, но не вмешивается в её работу.

  • Скрам мастер не назначает людей на задачи — это делает сама команда;
  • Мастер не заставляет людей делать работу — это ответственность команды;
  • Мастер не указывает Product Owner какие требования он должен написать — это работа владельца продукта.

Тем не менее, если скрам-процесс проходит с нарушениями (кто-либо из команды опаздывает на daily-meeting), то мастер должен вмешаться и исправить ситуацию.

Функции Scrum Master’a существенно шире, но чтобы пояснить их все нужна отдельная статья. Пишите в комментариях, если таковая нужна.

Team (команда проекта)

  • кросс-функциональная
  • взаимозаменяемая
  • самоорганизующаяся
  • с фиксированным составом (в ходе спринта)
  • 4-10 человек.

Команда отвечает за разработку продукта итерациями (спринтами). Команда определяет самостоятельно:

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

Команда НЕ принимает решений:

  • какие требования являются приоритетными — это делает Product Owner.

На снимке ниже команда проекта проводит обязательный «ритуал» — Daily Meeting (см. ниже).

Команда проводит «ритуал» Daily Meeting

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

Ритуалы (процессы в Scrum)

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

Ритуалы в скрам это:

  • Sprint Planning Meeting
  • Daily Meeting
  • Sprint Review
  • Retrospective

Sprint Planning Meeting (встреча по планированию спринта)

  • выполняется всей командой перед началом спринта
  • команда выбирает требования из Product Backlog и формирует Sprint Backlog
  • если требуется учесть взаимосвязи между операциями, то это делается здесь
  • команда декомпозирует требования на задачи (tasks)
  • каждая задача проходит оценку в трудозатратах или универсальных единицах
  • во время встречи Product Owner отвечает на вопросы команды.

Встреча, которая проводится перед началом каждого спринта. Структура встречи:

  • представление и пояснение Product Owner’ом списка требований
  • вопросы со стороны команды
  • /рекомендуется перерыв/
  • декомпозиция требований на задачи (tasks)
  • оценка задач по методу Planning Poker.

Встреча простая по сути, но крайне сложная по содержанию. В начале проекта может занимать 5-6 часов. И только после 3-4 спринта встреча становится более оперативной и длится 2-3 часа. Крепитесь.

Daily Meeting (ежедневная встреча команды).

Из названия понятно, что встреча проводится ежедневно. Основные принципы:

  • проходит ежедневно и только в одно и то же время;
  • встреча проходит только стоя;
  • поэтому длительность встречи не более 15 минут;
  • чтобы успеть каждый должен ответить всего на 3 вопроса: что я делал вчера, чем я занимаюсь сегодня, какие есть проблемы?

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

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

Встреча команды эффективно проводить напротив Kanban доски, на которой отражены все задачи спринта.

Kanban Board во время спринта

Sprint Review — сдача спринта Product Owner

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

Ценность Scrum для обычного заказчика во многом состоит в том, что результат работ (плохой или отличный, не важно) будет продемонстрирован в любом случае. Это знает и команда и Product Owner и другие заинтересованные лица. Если команда не проводит демонстрацию (иное название Sprint Review), то это дискредитирует все преимущества гибких процессов.

  • команда зачитывает требования из Sprint Backlog
  • по каждому критерию приемки происходит демонстрация полученных результатов
  • каждый вопрос со стороны Product Owner’а записывается, чтобы иметь возможность ответить на них позже
  • каждое новое требование Product Owner’a выписывается, чтобы позже включить его в Product Backlog.

На встрече могут присутствовать любые сотрудники организации или просто заинтересованные лица. Важно, чтобы право голоса имели только участники Scrum процесса (Produt Owner, Team, Scrum Master).

Никаких презентаций в PowerPoint на встрече, если вы правильно меня поняли!

Retrospective

Ритуал, который направлен на обмен опытом внутри команды. Встреча проводится после Sprint Review. На встрече присутствует вся команда и Scrum Master. На встрече может присутствовать Produt Owner, если считает нужным.

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

  • какие решения должна принять команда, чтобы сделать процесс более предсказуемым?
  • какие проблемы мешают команде выполнять взятые на себя обязательства?
  • как улучшить взаимодействие с Product Owner’ом?
  • какие ошибки совершает команда и почему.

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

Почему появился Agile?

Теперь немного слов о том, как и зачем появился этот подход? История возникновения этого подхода стала ответом на запросы отрасли:

  1. Заказчик не может сформировать четкие требования к ПО;
  2. Новые технологии усилили конкуренцию и потребовали оперативного применения в бизнесе;
  3. Заказчики и разработчики ПО не удовлетворены процессом взаимодействия.

#1 Заказчик не может сформировать четкие требования к ПО

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

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

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

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

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

#2 Новые технологии усилили конкуренцию и потребовали оперативного применения в бизнесе

К середине 90-х разрабатываемое ПО было в основном десктопным и его требовалось устанавливать на каждый отдельный компьютер (например, MS Word). С появлением веб-приложений внедрение новой функциональности стало происходить быстрее: требовалось развернуть приложение только на сервере и все пользователи получали к нему доступ. Эта инновация серьезно усилила конкуренцию между компаниями: тот, кто применил новую технологию раньше других – выигрывает рынок и клиентов.

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

#3 Заказчики и разработчики не удовлетворены процессом взаимодействия

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

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

При этом agile не отказывается от формулирования требований. Заказчик (в agile — владелец продукта, product owner) предъявляет требования в упрощенном виде и на сценариях работы пользователей.

Резюме

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

Scrum — методология управления проектом

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

Что такое Scrum?

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

Зачем она нужна?

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

Где она применяется?

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

Технология Agile

Методология Agile Scrum является ветвью основы технологии, которую мы с вами рассматриваем. Но если обычный Scrum представляет компании как иерархию и только иногда создает ситуации для равных прав, то новое дополнение к ней исключает все возможные разделения, так как его основа заключается в единстве. Говоря простым языком, в таких случаях команды предоставлены сами себе, без верхушки власти и надзирательства. Agile Scrum – это самоуправляемая команда, где все равны и нет боссов, где каждая идея ценится и обсуждается, где все решается путем совместного голосования. Думаете, что таких компаний нет? Вы ошибаетесь, так как примеров полно, особенно в Японии. Также такой методологией пользуются некоторые отделы компании Google. Также стоит отметить, что в случае использования Agile Scrum создается атмосфера полного доверия и понимания, именно при таких условиях видно, кто действительно одержим идеей достичь успеха, а кто просто числится в компании.

Технология Meetings

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

Технология Demo

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

Технология Retrospective

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

Где обучают?

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

Что может дать?

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

Agile/Scrum

Дату уточните у администрации

Курс читается 2-3 раза в неделю

Описание курса:

После изучения курса Вы сможете:

  • Понимать, что такое Agile, его мировоззрение, ценности и принципы
  • Активно применять XP, Kanban в организации разработки программного продукта
  • Построить эффективный процесс разработки или улучшить его в команде/проекте по Scrum

Программа курса:

Знакомство с Agile

  • Виды жизненных циклов проектов, их плюсы и минусы
  • В каких проектах хорошо работают agile-подходы
  • Специфика и эффект гибкого проекта
  • Бизнес-кейс проекта и выбор подхода к его организации (практика)
  • Обзор сертификаций по agile/scrum

Agile мировоззрение

  • Быть и делать agile: правильный подход к применению agile
  • Что такое «гибкое мировоззрение»
  • Agile manifesto: ценности и принципы гибких подходов
  • Оценка гибкости компании (практика)

Виды гибких практик

  • Основы экстремального программирования
  • Организация проекта по канбану
  • Обзор скрам-фреймворка

Практика скрама

  • Фундаменты и ценности скрама
  • Ролевая модель в скраме
  • Артефакты скрама
  • 5 ключевых событий в скраме
  • Деловая игра (скрам-лего)

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

  • Принципы двусторонней коммуникации
  • Модель эффективности коммуникаций
  • Организация рабочего пространства
  • Работа с виртуальной командой
  • Модель командной динамики
  • Оценка скорости работы команды (velocity), диаграмма сгорания работ
  • Деловая игра (скрам-лего — продолжение)

Транзиция роли руководителя в скраме

  • Транзиция роли руководителя проектов
  • Практика лидерства через служение
  • Эмоциональный интеллект и гибкие навыки
  • Скрам и организационные препятствия
  • Постоянные улучшения

4 уровня планирования скрам-проекта

  • Подготовка бэклога продукта: пользовательские истории, приоритеты, высокоуровневая оценка
  • Дорожная карта развития продукта
  • Планирование релизов, скрам покер
  • Планирование первой итерации
  • Принципы проведения ежедневного скрама
  • Чеклист по организации скрам-процесса
  • Деловая игра (скрам-лего — завершение)

Подводим итоги

  • Открытый тест от Scrum.org
  • Сессия вопросов и ответов
  • Закрытие курса

Минимальные требования:

  • Базовые знания о методологиях, методах, способах разработки программного обеспечения
  • Наличие собственного ноутбука для занятий в аудиториях

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