Методология scrum: Мини-справочник и руководство по Scrum / Хабр

Все что нужно знать про Scrum. Гибкие методологии.

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

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

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

Что такое Scrum

Scrum – гибкая методология разработки или гибкий управленческий фреймворк (т.е. структура) с акцентом на качество процессов.

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

Как работает Scrum

Как Scrum устроен на самом деле смотрите ниже.

Пока это выглядит как китайская грамота, поэтому предлагаю посмотреть на отдельные части и разобрать каждый элемент структуры. Очень рекомендую книгу Бориса Вольфсана “Гибкие методологии” именно она легла в основу данного материала (часть картинок оттуда).

Структура Scrum

Давайте посмотрим из каких элементов состоит Scrum.

Роли

• Владелец продукта (product owner/manager). Ставит задачу, определяет приоритеты по задачам, взаимодействует с заказчиком.
• Скрам-мастер – человек, который отвечает за процессы внутри команды, координирует работу, следит за внутренней атмосферой. Планирует спринт, организует скрам митинг, участвует в демонстрации результатов в конце каждого спринта.

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

• Команда – 7±2 человек, которые реализуют требования владельца продукта.

Артефакты

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

Процессы

• Планирование спринта. Команда со скрам-мастером планирует план работ на будущий спринт, то есть составляет беклог спринта (список) задач.
• Обзор спринта. Демонстрация инкремента продукта после каждого спринта. Команда показывает рабочую функциональность владельцу продукта (и заказчику по запросу), а тот, в свою очередь, вносит изменения в требования, если они необходимы.
• Ретроспектива. Обзор прошедшего спринта с целью улучшения процессов. Команда, скрам-мастер и владелец продукта обсуждают прошедший спринт, делают выводы, думают над тем, что можно было бы улучшить.
• Скрам митинг. (см.определение выше в блоке “Роли”)
• Спринт. Как правило двухнедельный этап времени, в течении которого команда успевает разработать готовый для демонстрации функционал.

–

Простите, что прерываю чтение. Присоединяйтесь к моему telegram канал. Свежие анонсы статей, развитие digital продуктов и growth hack, там все. Жду вас! Продолжаем…

–

Пример Scrum

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

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

Выбираем, для примера, важную задачу или историю пользователя (user story) в рамках создания сайта: “Регистрация клиента/пользователя”. И раскладываем ее на более мелкие части. Формируем беклог продукта.

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

На практике, историй пользователя (типа “Регистрация пользователя”) гораздо больше. Сервис/продукт может включать множество таких историй, поэтому приоритезация строится сверху вниз, слева направо. В верхней левой части располагаются самые важные user story (Активность) и самые важные задачи.

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

Понятно, что управлять такой “махиной” в реальном времени просто невозможно, поэтому для удобства работы, вся эта стена переезжает в специальный софт/программу (Jira, Trello, Redmine и прочие трекеры управления проектами). Там вы можете назначать ответственных за задачи и исполнителей, изменять статусы задач и прочее.

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

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

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

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

Ретроспектива: анализ спринта

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

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

Как расставлять приоритеты

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

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

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

Оценка историй пользователей внутри беклога

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

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

Например, в нашем сервисе есть история пользователя “Регистрация пользователя”. Мы берем ее за образец и даем ценность в один бал или один story point (так его называют в гибких методологиях). Каждый участник команды пишет свою оценку к остальным историям пользователя в списке с учетом задачи, которую взяли за образец и отдает ее скрам-мастеру.

В примере выше “Фото галерея с довольными клиентами”  стоит 0,5 story point, то есть по сложности она в 2 раза меньше нашей эталонной истории “Регистрация пользователя”. Все оценки участники команды ставят анонимно, можно на стикерах писать и переворачивать.

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

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

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

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

Можно ли применять Scrum не только в разработке

И да и нет. До того, как я начал понимать, что означают эти 5 букв (Scrum), часть принципов уже использовал в работе. Планирование, с помощью различных инструментов и выстраивание своего так называемого “спринта задач” уже было.

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

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

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

Когда применять Scrum

В основном в небольших проектах и старт-апах. Можно и в больших, типа Mail.ru, но там должна быть определенная свобода действий и отдельные функциональные команды со своим владельцем продукта. Не забывайте, что Scrum про гибкость и изменения. Команды не должны быть больше 7±2 человек, иначе невозможно будет эффективно организовать коммуникации.

Нюансы

Если вы решили внедрить Scrum у себя в проектах, то учитываете следующие нюансы:

• Нет ориентации на клиента. Не все заказчики будут готовы к определенным стандартам Scrum.
• Не учитывается система реагирования на риски. Команда может заложить какое-то доп.время на выполнение задач, но при сильных отклонениях от плана, система встанет.
• Команда и человеческие качества. Так как упор сделан на самоорганизующуюся команду, то все участники должны обладать высоким уровнем ответственности и соответствующей мотивацией. Создание такой команды, очень сложная задача.
• Скрам-мастер. Человек отвечающий за процессы и мотивацию команды, должен чувствовать всех участников и связи внутри группы. Это редкий специалист, которого также тяжело найти на рынке.

Завершим

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

Читайте также:

Великолепный ролик от Николая Дроздова и Huawei. Обязательно смотреть!

Вконтакте

Facebook

Twitter

Google+

Загрузка…

стоит ли прогибаться под изменчивый мир?

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

История появления Scrum

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

• определение требований к проекту;

• планирование операций от начала и до конца;

• написание кода;

• тестирование.

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

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

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

1. Люди важнее инструментов.

2. Качество продукта важнее документации.

3. Взаимодействие с заказчиком важнее контракта.

4. Готовность к изменения

Scrum — нюансы применения в распределенной команде / Хабр

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

Важные книги по Скрам

• Джефф Сазерленд: Революционный метод управления проектами.
• Эрик Рис: Бизнес с нуля. Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели
• Роберт Фитцпатрик: Спроси маму: Как общаться с клиентами и подтвердить правоту своей бизнес-идеи, если все кругом врут

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

Важные книги не про Скрам

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

• Максим Батырев: 45 татуировок менеджера.
• Михаил Хазин, Сергей Щеглов: Лестница в небо. Диалоги о власти, карьере и мировой элите.
• Роберт Грин: 48 законов власти.

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

Особенности Скрам

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

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

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

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

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

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

Насколько точно надо придерживаться правил Скрам?

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

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

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

Не забывайте о том, что многое, что является вполне естественным и не требующим объяснения для американского читателя, не является таковым для российского. Многие практики, эффективные на западе, совершенно не работают у нас. Это может быть обусловлено, помимо различий в культуре и законодательстве, например, довольно большой властью американского работодателя над работником. Работодатель в США может очень быстро уволить сотрудника, а увольнение там может означать потерю страховки, способности платить по счетам, потери собственности, даже нищите. У нас же увольнение иногда ничего не меняет, да и уволить иногда не удается. Отсюда и разное отношение к работе, компании, начальнику, конкуренции, саморазвитию, корпоративной культуре. Отсюда возникают разное понимание одного и того же текста, разное применение одних и тех же методов.

Доски со стикерами

Не могу пройти мимо этого явления. Если команда находится в одном офисе, может быть это и неплохое решение, поскольку позволяет общаться всем членам команды лицом к лицу. Кроме того, митинги у доски проходят стоя, что должно помогать избегать длинных собраний. Однако, информация, написанная на стикерах от руки плохо читаема и непонятна новым членам команды. К стикеру нельзя приаттачить файл, добавить описание или ссылку. Непонятно на кого назначена та или иная задача. Да, на стикерах можно указать идентификаторы тикетов Jira, но это не решает проблему. Часто можно заметить, что возле доски собирается более 20 человек, при том, что классическая Скрам команда должна иметь в своем составе не более 9 человек. Во время проведения таких собраний образуются небольшие группы сотрудников по интересам или специализации, которые начинают независимые совещания, мешая друг другу. И такие совещания, как показывает практика, не проходят быстро, несмотря на то, что проводятся на ногах. На доске часто можно увидеть вместо трех — пяти столбцов целый десяток и больше. Но самое неприятное в наличии доски — это отсутствие единого источника правды, т.е. существуют одновременно как доска так и dashboard в Jira. Пора прекратить пользоваться досками. Ниже я приведу описание митинга, который подойдет как для офисной, так и для распределенной команд.

Роли членов команды

Роли членов команды могут быть, например:

• Product Owner
• Scrum Master
• Business Analyst
• Software Architect
• Software Analyst
• UI / UX / Web Designer
• Html Developer
• Front End Developer
• Back End Developer
• Full Stack Developer
• DB Developer
• DBA
• Quality Assurance
• DevOps Engineer
• и т.д.

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

Вариант команды в реальных условиях

Предположим, у нас небольшой стартап с ограниченным бюджетом, и мы не можем себе позволить по одному или более человеку на каждую роль. Вакансии опубликованы на upwork, собеседования проводят SM и SA. Для найма членов команды вы можете воспользоваться рекомендациями из моей статьи «Онлайн тестирование — вы серьезно?». Сформированная команда состоит из следующих удаленных сотрудников (взято из реального проекта):

• Product owner (PO), он же Business Analyst. Концентрируется на продукте, взаимодействует с заказчиками и инвесторами, знает бизнес-процессы. Определяет приоритет реализации той или иной фичи. Отвечает за финансы, переводит деньги (зарплату) членам команды в соответствии с выставленными счетами за период.
• Scrum master (SM), частично Business Analyst, Software Analyst. Концентрируется на команде, решает организационные вопросы, назначает встречи, обеспечивает соблюдение ритуалов Скрам, формирует бэклог, создает стори и назначает исполнителей, утверждает (approves) затраченное время членов команды, утверждает счета на оплату услуг каждого из членов команды.
• Software Architect (SA), он же Team Leader для разработчиков, DevOps, DBA. Администрирует серверы, среды, GitLab, Jira, Confluence, Jenkins, корпоративную почту, Zoom, VPN, выделяет или блокирует доступы.
• Web Designer (дизайнер) на неполный рабочий день. Дизайн интерфейса с использованием Photoshop, Zeplin, Invision, Figma.
• HTML Developer (верстальщик) на неполный рабочий день. Несмотря на то, что знание HTML и CSS является обязательным для Front End Developer / Full Stack Developer, это не всегда обеспечивает высокое качество верстки. По этой причине в команду приглашаются профессиональные верстальщики, которые трансформируют дизайн в шаблоны, применяемые в дальнейшей разработке фронта.
• Senior Full Stack Developer (разработчик) на полный рабочий день, он же DB Developer. Из-за ограниченного бюджета не всегда есть возможность нанять фронтиста и бэкенд разработчика. На начальном этапе и для запуска MVP будет вполне достаточно одного Full Stack Developer-а. Кроме того, скорость команды на начальном этапе может быть такой, что одного разработчика вполне будет достаточно. В дальнейшем можно увеличивать команду, нанимая специалистов на разные роли.
• QA на неполный рабочий день. На начальном этапе можно обходиться без привлечения профессиональных тестировщиков, но по мере разрастания системы они становятся просто обязательными.

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

Процесс

Каждый день проводится стендап (короткий митинг на 15 минут не более), на котором присутствуют все члены команды. Каждый из членов команды кратко отвечает на два вопроса “над каким тикетом работаю” и “что меня блокирует”. Все митинги проводятся по возможности через Zoom или другую систему, позволяющую видеоконференции с демонстрацией экрана. Для митингов, тренингов и деловых встреч создаются специальные тикеты. Это мотивирует SM к сокращению длительности митингов. Если митинги длятся дольше чем 15 минут, значит SM что-то делает неправильно.

Колонки в проекте в Jira (вариант):

To do  |  In Progress  |  Code review  |  QA  |  Demo ready  |  Done

Предположим, что члены команды живут в разных часовых поясах от Екатеринбурга до Чикаго. Оптимальным временем для митинга может быть, например 15:00. SM запускает трансляцию своего экрана через Zoom, открывает dashboard проекта в Jira. Затем SM включает фильтр тикетов како-го либо из членов команды, при этом становятся видны тикеты только этого члена команды.

Этот сотрудник кратко рассказывает о своих тикетах в колонке In Progress и о трудностях, с которыми он сталкивается, о том, что его блокирует. Далее SM переключает фильтр на другого сотрудника. SM следит за тем, чтобы выступления членов команды были короткими. В моем случае я настоял на отдельном тикете для списания времени, потраченного на митинги, и спустя 2 недели SM сильно сократил длительность митингов, посчитав их стоимость. Если у кого-либо возникают вопросы, требующие дополнительного обсуждения, то они обсуждаются на отдельном митинге, время которого определяет SM. Создание любого митинга сопровождается рассылкой приглашения в персональный календарь каждому из участников. Использование календаря избавляет участников от необходимости пересчета времени проведения митинга в локальное время. Выявив и обсудив все проблемы, возникшие на данный момент, SM принимает меры по их устранению, координируя действия всех членов команды.

Разработка ведется поэтапно спринтами по 1 или 2 недели. Результатом каждого спринта является промежуточная версия системы с некоторым новым функционалом (фичами). SM создает, запускает и закрывает спринты.

SA конфигурирует билд и деплой на тестовый стенд из какой-либо ветки Git, которую можно условно назвать dev. Ветка dev заблокирована для прямых коммитов, возможен только Merge request (MR). Разработчик делает MR, если уверен, что качество и завершенность фичи достаточны для использования конечными пользователями. Недоделанные фичи в dev не попадают, MR не создается.

PO и SM согласуют требования, собирают все необходимые материалы в Confluence, создают спецификацию. Гибкие методы отодвигают документацию на второй план. Я сталкивался как с системами, где нет никакой документации, так и с системами, где ее настолько много, что в этом океане информации ничего невозможно найти. Ситуация с обилием документации усугубляется примитивностью поискового движка Confluence. Оптимальным решением является компактная спецификация. Она представляет собою страницу в Confluence, в которой есть схематичное изображение интерфейса (mockup) с отметками и выносками. Под изображением находится описание функционала и поведения каждого элемента, отмеченного на схеме. В тексте есть ссылки на релизы и тикеты в Jira. В нижней части страницы идет обсуждение в комментариях.

Перед началом спринта SA формирует бэклог, создает новые стори и добавляет их в будущий спринт, назначает разработчиков на каждую стори. Разработчики разбивают стори на подзадачи, определяют Estimate (приблизительное прогнозируемое время разработки) в часах и минутах. Полученное суммарное время подзадач определяет количество Story points из расчета 1 Story point = 6 часов. Далее тимлид распределяет стори по разработчикам исходя из расчета 8-12 Story points на разработчика на спринт. SM запускает спринт.

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

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

Разработчик создает ветку в Git по имени тикета стори, например MVP-123. По завершении каждой подзадачи разработчик записывает в Jira фактическое затраченное время на каждую из подзадач. В качестве TimeSheet рекомендую Tempo. По окончании отчетного периода (2 недели или 1 месяц), разработчик запрашивает утверждение отработанных часов у SM, формирует счет на оплату, отправляет его SM. Когда все задачи в стори готовы, разработчик перемещает все тикеты (стори и подзадачи) в столбец Code review. При этом разработчик создает MR своей ветки в dev, копирует ссылку на него и помещает в комментарии к тикету стори, назначает тикет на ревьювера (сеньора или тимлида). Изменение исполнителя сопровождается его оповещением по электронной почте.

Когда тимлид заметил новые тикеты в Code review он изучает MR и, если находит недостатки, пишет их в комментариях в GitLab, перемещает тикеты назад в столбец In Progress. Разработчик дорабатывает код, добавляет комментарий в GitLab (или в другой системе), нажимает Resolve discussion в комментариях, переносит тикеты в Code review. Особенностью GitLab является невозможность добавления нескольких ревьюверов. Это часто бывает необходимым, если изменения затрагивают, например, как фронт, бек, так и базу данных. В BitBucket такая возможность есть.

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

В некоторых ситуациях, многочисленные MR, даже в случае удачного слияния, приводят к невозможности сборки или невыполнимости части unit тестов. Иногда это становится известно после того, как одна из сред перестала работать, что блокирует, например, QA. То есть тимлид может провести ревью и принять MR, но это не гарантирует успешность сборки или выполнения unit тестов. Для решения этой проблемы, например, в GitLab есть возможность настройки Development Pipeline. По сути это автоматическая сборка и тестирование коммита, который указан в MR. Код ревью выполняется только после успешного выполнения Development Pipeline. Если Development Pipeline “падает” с ошибкой, разработчик, сделавший MR, устраняет ошибку и делает дополнительный коммит.

Тимлид принимает код и принимает MR, при этом происходит автоматическая сборка и деплой на тестовый сервер. Тимлид переносит код в столбец QA.

QA приступает к тестированию новых изменений в соответствии со спецификацией. QA создает программы ручного тестирования. В случае неудачного тестирования, тикет переводится в столбец In Progress — возвращается на доработку, либо создается баг-тикет в Jira, который SM назначает на какого-либо из разработчиков. После того, как тестирование завершено успешно, тикеты переводятся в Demo ready и, впоследствии, фича демонстрируется на еженедельном Demo митинге. Если фича принимается, тикет переводится в Done.

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

PO и SM определяют набор фич (стори), которые попадут в тот или иной релиз, планируют дату релиза. Перед релизом QA осуществляют регрессионное тестирование. В момент релиза создается специальная ветка в Git и замораживается для изменений. Изменения релизов возможны в исключительных случаях и производятся через бэкпорты. Бэкпорт — специальный процесс внесения изменений в релизные ветки. В некоторых компаниях для бэкпортов создаются специальные команды.

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

Что необходимо для работы (вариант)

• Пространство Slack
• Корпоративная почта в домене компании / стартапа (желательно, но не обязательно). Почта может быть настроена таким образом, что все письма будут перенаправляться на личные почтовые ящики членов команды.
• Zoom
• Jira и Confluence, размещаемые либо на собственных серверах, либо облачных.
• Серверы dev, test, prod сред как собственные так и арендуемые, как физические, так и виртуальные.
• Система контроля версий, например GitLab или BitBucket.
• Jenkins или Bamboo, или какая-либо еще система автоматической сборки и деплоя.
• VPN для доступа к средам и каким-либо серверам.

По возможности Slack, Jira, Confluence, Gitlab (или Bitbucket), Jenkins (или Bamboo) должны быть интегрированы друг с другом.

Учет времени

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

Хороший разработчик Self motivated (самомотивирован), стремится сделать больше в единицу времени, опережая estimate сроки, повышать свой авторитет, увеличивать шансы стать сеньором, тимлидом, иногда шансы на получение опциона. Он активен, генерирует идеи, непрерывно изучает новые технологии, дорожит своим временем. Если в команде не отлажены процессы и разработчик простаивает без задач, если разработчик выполняет работу, которая никому не приносит пользы, если работа никак его не развивает, то он начинает ощущать, что тратит драгоценное время своей жизни впустую. Как результат, он уходит на другой проект. Скрам позволяет разработчику избежать прожигания жизни, помогает самореализоваться, ощутить свою причастность к важному делу.

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

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

Иногда бывает, что скорость разработчика оценивается путем сравнения предварительно оцененного времени и фактически затраченного. То есть если разработчик опережает оценки, то его поощряют и наоборот. Считаю, что такая оценка должна использоваться как неточная, ориентировочная, второстепенная. Предварительная оценка времени (estimate) может быть сделана только приблизительно. Более точная оценка может быть сделана только в том случае, если подобные задачи решались многократно, однако повторяющиеся задачи встречаются нечасто. Даже обладая большим опытом и высокой точностью прогнозирования времени выполнения, вы не будете застрахованы от неожиданностей. Например, применение многократно использованной в других проектах библиотеки, оказало непредсказуемое влияние на систему, причем баг проявляется во время выполнения, и логи ни о чем не говорят. Если нет готового решения на StackOverflow, можно превысить Estimate в несколько раз. Надо понимать, что Estimate — это грубая оценка, которая может использоваться как ориентир. Превышение разработчиком Estimate, и если оно не является систематическим, не должно приводить к критике со стороны руководства.

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

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

Пусть удаленный разработчик оценил задачу в 2 часа, а выполнил ее за 1 ч 33 мин и записал это фактическое затраченное время в Tempo, перевел тикет в Code review и взял в работу следующий. Возникает вопрос, можем ли мы доверять разработчику, ведь он мог сделать эту задачу за 15 минут, а остальное время уделить онлайн играм или даже другим проектам? Ответ — да, можем доверять. Самое главное, на что должен обращать внимание SM, являются ли сотрудник эффективным, являются финансовые затраты на сотрудника приемлемыми в единицу времени. Обеспечивается ли такая скорость команды, которая позволит запустить MVP до окончания взлетной полосы стартапа. Во-первых, точные временные затраты на выполнение той или иной задачи да еще и при заданном уровне качества просто физически невозможно определить. У одного разработчика уйдет на это 2 часа, а у другого 15 минут, поскольку многое зависит от опыта и способностей. Кроме того, в любом проекте есть старожилы и новички. Старожил найдет решение за считанные минуты, в то время как новичок может потратить несколько дней на исследования. Во-вторых, разработчик может искать решение не только в момент написания кода, но и в любое нерабочее время. Идея может посетить человека совершенно неожиданно и в любой момент. Оценивать качество полученной идеи и ее реализации простым учетом времени, потраченного на кодирование, неэффективно. Это одна из причин низкой эффективности применения трекеров времени — разработчик работает не только в момент непосредственного написания кода. Ко всему, трекеры времени вносят элемент недоверия, превращают творческий процесс в каторгу.

Если SM не уверен в правдоподобности фактически списанного на задачу времени, он может заглянуть в GitLab и сопоставить изменения кода, сделанные по этой задаче, со списанным временем. Разработчик не может списать 2 часа за 2 строчки кода. Если SM не разбирается в программировании, он может пригласить эксперта для оценки реалистичности списанного времени, например SA. Как бы тами ни было, адекватный разработчик не будет списывать лишнее время, поскольку понимает, что реалистичность может быть проверена, а испорченную репутацию и доверие потом не восстановить.

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

Вернемся к разработчику, который выполнил задачу за 1 ч 33 мин и приступил к следующей. При этом, он списал за первую задачу 2 ч как было в Estimate. SM сможет легко определить, что интервал времени между переводом задачи в статус In Progress и Code review существенно меньше, чем списанное время. То есть факт приписки может быть легко установлен, обращать внимание разработчика на этот факт или нет, SM определяет сам. Конечно, разработчик может переводить задачи в те или иные статусы в точном соответствии со списанным временем, несмотря на то, что он не работал так много. Или он может переводить в In Progress сразу несколько тикетов, чтобы время начала работ было как можно более ранним — надо договориться о последовательном переводе тикетов в работу. В любом случае, не стоит беспокоиться! Напомню, для SM намного важнее польза, которую этот человек приносит за потраченные на него деньги в единицу времени. SM в любой момент может исключить любого члена команды из проекта, но это может привести к непредвиденным затратам на поиск и адаптацию нового члена команды, взятого взамен уволенному.

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

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

Финансовые отношения

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

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

Agile и Scrum на практике: вопросы скрам-мастеру | GeekBrains

Что такое Agile, как проводят скрам-собрания в российских и международных компаниях, кто такой Scrum master и какие функции выполняет.

https://d2xzmw6cctk25h.cloudfront.net/post/1957/og_image/116cd6af043c0da9c731ff7ad9026dda.png

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

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

— Владимир, какие курсы вы сейчас ведете в GeekUniversity и GeekBrains?

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

— В каких компаниях и командах вы занимались разработкой и практиковали Agile и Scrum?

— Я не любитель часто менять работу: в 2007 году пришел в компанию, которая разрабатывала ПО для ритейловых сетей. В этой компании мало кто знал про Agile, и когда команда столкнулась с проблемами, мы стали анализировать ситуацию и искать решение. В итоге пришли к необходимости использовать Scrum. Сейчас работаю в DXC Technology — тоже по скраму. 

Уточню, что Scrum — это не методология и не технология, а фреймворк, как утверждают авторы скрам-гайда Ken Schwaber и Jeff Sutherland. На русский язык тяжело перевести, что такое фреймворк, поэтому говорят «методология». На самом деле это контейнер с правилами, который каждая компания и команда заполняет своими процессами. Я бы сказал, что скрам — это набор правил и рекомендаций. 

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

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

— В чем ключевые особенности взаимодействия в командах, применяющих Agile?

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

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

— Чем еще занимается скрам-мастер?

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

— Чем на практике отличается применение методологии Agile в разных компаниях (российских и зарубежных) и командах? Какие факторы влияют на эти различия?

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

— По вашему опыту, когда Scrum работает лучше всего и какие у него противопоказания?

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

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

— Когда в феврале этого года в блоге вышла небольшая статья про Agile, у одного читателя возник вопрос: есть ли в Scrum место «причесыванию кода» — рефакторингу и «выпиливанию костылей»? Или в погоне за новыми запросами пользователя трудно найти на это время?

— Интересно, что в твиттере недавно появилось на эту тему сообщение от автора принципов SOLID, Роберта Мартина, или Дядюшки Боба, как зовут его в сообществе. Он посоветовал при оценке задачи закладывать в нее рефакторинг и написание тестов. Считаю этот совет очень разумным и полезным. 

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

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

— К сожалению, начинающие разработчики, да и не только они, часто пренебрегают написанием автотестов. Как проверить код? Только тестированием. Это можно сделать вручную либо написать автотест — кусок кода для проверки другого кода. 

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

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

— Работаю по Scrum в компании DXC Technology. Почитайте, чем она занимается. Не уверен, что это компания топовая, но международная — точно. 

Как связана архитектура с Agile? Я не понимаю. Это как сравнивать зеленое с круглым. 

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

— Есть ли в Agile механизм защиты продукта от перегрузки лишними функциями из-из «хотелок» пользователей? Или это за рамками подхода?

— За рамками. За этим следит владелец продукта: он ведет backlog (список задач) и расставляет приоритеты. Любая «хотелка» должна быть проанализирована.

— В каких ситуациях уместно так называемое экстремальное программирование (XP)? Был ли у вас такой опыт?

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

Если заказчик недоступен, в скраме его замещает владелец продукта. Мне кажется, чем больше элементов экстремального программирования вы применяете, тем качественнее продукт. XP — это работа без стрессов, а не наоборот. 🙂

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

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

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

— Как выглядит спринт в команде Android-разработчиков? Что чаще всего идет не так и что при этом может сделать мастер?

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

В каждой команде — свои проблемы. Это может быть внутренняя коммуникация, назойливое руководство или еще что-то. С подобными препятствиями помогает бороться скрам-мастер. К слову, сейчас наша команда работает на Java, C#, Golang, Python и Angular (TypeScript).

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

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

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

— Насколько понимаю, Аgile ориентирован на опытных специалистов, которые умеют брать на себя ответственность. Когда в команду приходит Junior, которого предстоит многому научить, он еще не полностью вовлечен в проект. Что, кроме собственного желания сотрудника, влияет на скорость вовлечения? Как этому способствует скрам?

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

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

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

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

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

— Спасибо за ответы! Интересно было узнать мнение человека, который не первый год в теме Agile и знает изнутри, как работает Scrum.

Кто эти люди? Зачем я им нужна? и другие проблемы скрам-мастера / Хабр

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

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

Сложности

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

Отсутствие авторитета

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

Тень бывшего мастера

От сравнений никуда не деться. Если до моего появления что-то работало плохо, и после моего прихода ничего не изменилось, возникали запросы: «У нас слишком сложный планнинг, давай сделаем уже что-нибудь с ним!». В случае, когда что-то было удобно для команды, например, физическая доска на дейли, а после появилась я и сказала: «Мне неудобно, давайте менять!», команда не понимала, зачем это необходимо.

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

Коммуникация с командой

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

Синдром волонтера

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

Способы решения

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

Решать проблемы поэтапно

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

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

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

Я решила убить физическую доску, заменив её на таблицы в Wrike, где довольно удобно представлена основная информация о задаче. Через некоторое время статусы задач стали обновляться каждый день, потому источником правды была не доска, а сами задачи! Решать вторую проблему даже не пришлось.

Аргументировать любое изменение

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

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

Изучить поведение авторитета

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

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

Найти единомышленников

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

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

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

А что дальше?

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

Скрам

• Знать методологию скрама (принципы, ценности, роли, артефакты)
• Помогать в формировании беклога
• Организовать работу команды по скраму (итеративность и инкрементальность процесса, командные события)
• Помогать команде рефлексировать и работать над улучшением процессов (например, с помощью ретроспектив)
• Уметь фасилитировать встречи

Менеджмент

• Помогать при командном планировании
• Организовать работу команды в соответствии с целями спринта
• Помогать в приоритезации задач, обеспечивать прозрачность приоритетов
• Выявлять проблемы в работе команды
• Отвечать за артефакты скрама и командные инструменты: backlog, встречи, итоги обсуждений

Личностные навыки

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

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

Восемь самых популярных книг по Agile, Scrum и Kanban / Блог компании Leader-ID / Хабр

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

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

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

Как растет спрос на гибкие методологии

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

Начнем с Agile:

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

А тут разбивка по месяцам. Особенно впечатляет пик в апреле, во время самоизоляции:

Ну а в июне уже чувствуется сезонный спад активности.

По Scrum — похожая ситуация, где по годам наблюдается даже более быстрый рост:

Хотя по месяцам цифры достаточно ровные:

А вот с Kanban все скромнее: пять мероприятий в 2019 году и три — за первые пять месяцев 2020 года.

Далее мы решили оценить, насколько активность в «Точках» соответствует общим тенденциям роста интереса к Agile-тематике.

Мы взяли яндексовский WordStat и посмотрели динамику числа запросов по соответствующим ключевым словам за последние полгода:

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

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

Итак, возьмем статистику по количеству книг с упоминанием наших терминов по году издания. Получается вот такая картина:

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

В поисках правильных критериев оценки

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

Вот так выглядит один из субъективных рейтингов, который нам встретился:

Лучшие книги по Agile, Scrum и Kanban, по версии одного из экспертов

В итоге после объединения различных списков из разных источников удалось собрать шорт-лист из 22 книг. Как понять, какие из них наиболее полезные?

Вариант 1: посмотреть рейтинг книг по отзывам на сайтах, посвященных книгам. Их можно найти, например, на Litres.ru, Livelib.ru, Ozon.ru. Есть также сайт Bookmate.com, где пользователи отмечают, какие книги они прочитали, и оставляют рекомендации. Для нас интересно количество этих рекомендаций.

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

Рейтинг книг на основании оценок пользователей специализированных сайтов

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

Продолжаем искать более объективные метрики.

Вариант 2: посмотреть на популярность книг по числу запросов в Яндексе и количеству страниц, на которых эти книги упоминаются.

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

Рейтинг книг на основании количества упоминаний

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

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

Итак, мы выбрали для себя пять метрик, по каждой из них отсортировали книги. Затем 10 лучшим в каждом чарте присвоили по 1 баллу. Если значение метрики одинаковое у 10-й и 11-й книг, даем баллы обеим. Суммируем баллы и сортируем по их возрастанию.

Метрики, на которых остановились мы: рейтинг Livelib как самый полный, упоминания на сайте HSE, количество запросов в апреле, количество страниц с книгой в Яндексе и… Вот здесь мы решили использовать еще один интересный параметр — количество пользователей, прочитавших книгу на Bookmate, так как он показался более наглядным, чем количество положительных оценок.

Вот что получилось:

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

Кратко расскажем о каждой из них.

1. Джефф Сазерленд. Scrum. революционный метод управления проектами

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

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

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

2. Канбан и «точно вовремя» на Toyota. Менеджмент начинается на рабочем месте

Это перевод учебных материалов специалистов компании Toyota к семинарам по производственной системе из далеких 1970-х годов. Как Сазерленд по Scrum является своеобразным «евангелием», так и эта книга стала точкой отсчета для Kanban-подхода.

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

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

3. Майк Кон. Agile: Оценка и планирование проектов

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

«Подход многих руководителей проектов можно представить как «планирование, планирование, планирование — выполнение». Agile-подход — это «планирование — выполнение — адаптация», «планирование — выполнение — адаптация». Чем выше неопределенности проекта, тем важнее применение agile-подхода для успеха».

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

4. Дженнифер Грин, Эндрю Стиллмен. Постигая Agile

Этот объемный труд (450 страниц) включает в себя описание всех основных agile-методологий: Scrum, Kanban, Lean и XP (eXtremal Programming). Книга легко читается, методологии даются несколько поверхностно, в обзорном режиме.

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

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

5. Хенрик Книберг. Scrum и XP: заметки с передовой

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

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

Книга небольшая, в сети можно найти перевод, сделанный энтузиастами из Agile Ukraine.

6. Борис Вольфсон. Гибкое управление проектами и продуктами

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

«Закон Паркинсона: любая работа увеличивается в объеме, чтобы заполнить все отпущенное на нее время».

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

7. Майк Кон. Scrum: гибкая разработка ПО

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

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

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

8. Дэвид Андерсон. Канбан. Альтернативный путь в Agile

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

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

Стоит обратить внимание, что здесь Kanban рассматривается в разрезе разработки ПО, что делает книгу полезной именно для ИТ-продуктологов, разработчиков и руководителей проектов.

Согласны ли вы с нашим топ-8? Какие книги еще маст-хэв для тех, кто изучает Agile? Если вам есть чем поделиться или покритиковать, пишите в комментариях — этим вы поможете другим в поиске знаний и добавите себе кармы.

Где Agile ужасен, особенно Scrum / Хабр

Гибкость — без сомнения хорошая вещь, и в манифесте Agile есть смысл. По сравнению с хрупкой практикой под названием «водопад», Agile заметно лучше. Тем не менее, на практике гибкие подходы часто наносят глубокий вред, и в действительности вряд ли здесь уместна дихотомия Agile/Waterfall.

Я видел, как множество вариантов Agile, называемых Scrum, реально убивают компанию. Под «убивают» я имею в виду не «ухудшение культуры», а скорее когда акции компании падают почти на 90% за два года.

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

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

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

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

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

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

Scrum — худший вариант, с глупостью двухнедельных «итераций». Это вызывает ненужное беспокойство о микрофлуктуациях производительности человека. Нет абсолютно никаких доказательств, что такой подход действительно ускоряет или улучшает разработку в долгосрочной перспективе. Он просто заставляет людей нервничать. Многие в бизнесе думают, что это хороший подход, потому что работа «идёт быстрее». Я в IT-индустрии уже десять лет, как менеджер и как рабочая пчела. Это неправда.

1. Бизнес-ориентированная разработка.

Agile часто подают в сравнении с «водопадом». Что такое водопад?

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

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

У меня смешанные мнения о названиях должностей вроде «старший» и «директор», и тому подобное. Они имеют значение, и я сам, вероятно, не приму должность ниже уровня директора, но я ненавижу их значение. Если вы посмотрите на Scrum, он специально лишает прав старших, самых способных инженеров, потому что здесь они обязаны придерживаться установленных процессов (работа только над созданными задачами, 5-10 часов в неделю на планёрках). Эти процессы спроектированы для людей, которые начали программировать месяц назад.

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

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

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

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

В конечном счёте, Agile (как практикуется) и Waterfall — формы бизнес-ориентированной разработки, и поэтому ни одна из них не подходит для разработки качественного ПО или мотивации сотрудников.

2. Подчинённое положение молодых.

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

Проблема с двухнедельными итерациями Agile (или «спринтами») и пользовательскими историями заключается в том, что нет стратегии выхода. Там нет варианта «Нам не придётся больше это делать, когда мы достигнем [X]». Предполагается, что эта система навсегда: ориентированные на бизнес митинги никогда не исчезнут. Архитектура, НИОКР и развитие продуктов уходят из работы программиста, потому что не вписываются в атомизированные «истории пользователей» и двухнедельные спринты.

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

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

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

Такая культура наталкивает на мысль, что программирование — это ребячество, от которого нужно избавиться к 35 годам. Я не согласен с таким мнением. На самом деле, я думаю, что это вредная мысль. Мне 30 с небольшим, и я чувствую, что только начинаю хорошо программировать. Преследование старших программистов только потому что они достаточно опытны, чтобы знать, что этот гибкий/scrum-процесс не имеет ничего общего с информатикой и что он не добавляет ценности — это ужасная идея.

3. Слишком краткосрочный подход, что глупо и опасно.

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

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

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

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

4. Он не имеет никакого отношения к построению карьеры.

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

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

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

5. Цель определить низкие показатели, но при этом неприемлемо высок уровень ложноположительных результатов.

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

В дебатах о гражданских свободах часто упоминается распространённая ошибка: аргумент «нечего скрывать». Некоторые любят утверждать, что вторжение в частную жизнь, скажем, правоохранительными органами, не является проблемой, потому что они сами не преступники. Эти люди упускают несколько ключевых вещей. Например, что законы меняются. Спросите любого, кто был евреем в Центральной Европе в 1930-х годах. Даже для респектабельных людей состояние слежки — это состояние тревоги.

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

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

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

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

Часто от внедрения Agile/Scrum страдают лучшие сотрудники, потому что R&D эффективно устраняется. Одержимость краткосрочными «итерациями» или спринтами означает невозможность опробовать нечто новое, рискованное.

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

6. Пьяный эффект.

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

С точки зрения менеджера, который не знает, как работает программное обеспечение, это может показаться приемлемым компромиссом: несколько «примадонн» уровня 7+ покинут корабль под парусом Дивного Нового Scrum, зато 3-ки и 4-ки станут вполне приемлемыми 5-ками. Проблема в том, что разница между программистами 7 и 5 существенно больше, чем между 5 и 3. Если вы потеряете своих лучших людей и своих лидеров (которые необязательно находятся на руководящих ролях), то небольшое повышение уровня некомпетентных, для которых предназначен Scrum, не приносит пользы.

Scrum и Agile играют в то, что я называю предвзятостью к смене статуса. По сути, многие люди судят о своих успехах или неудачах не объективно, а исходя из субъективных изменений в статусе. Убедить программиста уровня 5 согласиться на зарплату программиста уровня 3 в стартапе (в обмен на долю в стартапе) психологически расценивается не как потеря денег, а как серьёзная прибавка в статусе.

Agile/Scrum и культура дискриминации по возрасту в целом касаются получения наиболее впечатляющей статусной прибыли, а не фактической экономической прибыли. Её можно достичь, как правило, путём найма людей, которые принесут наибольшую ценность (даже если вы предлагаете на 50% выше рыночной ставки, потому что лучшие программисты стоят в 10-30 раз больше их рыночной ставки).

Люди, которые меньше всего осведомлены о том, какой социальный статус они «должны» иметь — это молодёжь. Вы найдете 22-летнего программиста уровня 6, который думает, что у него уровень 3 и который согласится на Scrum, но 50-летний уровень 9, вероятно, знает, что у него 9 и может неохотно принять условия уровня 8,5, но точно не опустится до 3 или даже 6. Поиск статусной прибыли, конечно, бесполезен. Эти пункты ничего не значат. Вы выигрываете в бизнесе на разнице в доходах и расходах, а не на разнице в бессмысленных пунктах статуса. Может быть, существует целая индустрия в привлечении инженеров 5-го уровня, расценивая (и оплачивая) их как 4, но в нынешних рыночных условиях гораздо выгоднее нанять 8 и относиться к нему как к 8.

7. Нечестная реклама.

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

Решениям вроде Scrum есть своё место: очень ограниченное, временное. Нечестно говорить, что оно работает везде и на постоянной основе.

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

У этой команды не будет чёткого менеджера, поэтому вы выберете лидера (например, “Scrum Master”) и дадите ему полномочия. Вы не хотите, чтобы он был официальным «менеджером людей» (так как он должен быть максимально беспристрастным). Поскольку кризис носит краткосрочный характер, карьерные цели отдельных лиц могут быть приостановлены. Это считается «спринтом», потому что люди должны работать так быстро, как могут, чтобы решить проблему, и потому, что им будет разрешено вернуться к своей обычной работе, как только спринт закончится. Кроме того, в такой чрезвычайной ситуации вам нужно дать понять, что никто не оценивается индивидуально. Основное внимание уделяется миссии и только миссии.

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

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

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

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

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

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

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

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

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

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

Что такое Scrum?

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

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

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

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

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

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

Разработка Scrum: что задействовано?

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

Методология

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

.

этапов методологии Scrum, которые помогают в гибком процессе SDLC: 5 ключевых шагов

Фреймворк

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

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

Прежде чем продолжить Scrum, мы должны поговорить об основных ролях, задействованных в процессе:

• Владелец продукта. Он заботится об интересах конечного пользователя.
• Мастер схватки должен координировать весь процесс.Другая задача — убедиться, что Scrum используется правильно. Он также проводит встречи Scrum .
• Scrum-команда. Разрабатывает продукт. Его основные задачи — программирование, анализ, тестирование и т.д.

Вот основные этапы процесса разработки, из которых состоит Scrum.

Фазы Scrum Модель

Шаг 1. Создание бэклога продукта

Журнал невыполненных работ — это список функций, которые необходимо реализовать в процессе разработки.Он упорядочен по приоритету, и каждый его элемент называется Пользовательская история . Каждой пользовательской истории присваивается уникальный идентификатор. В приведенном ниже списке показано, как могут выглядеть эти истории. Это фактические требования к продукту, которые были реализованы в процессе разработки программного обеспечения XB Staff Manager:

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

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

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

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

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

Шаг 2. Планирование спринта и создание бэклога спринта

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

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

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

Шаг 3. Работа над Спринтом. Скрам встречи

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

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

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

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

Например, Atlassian JIRA (https://www.atlassian.com/software/jira).

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

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

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

JIRA также позволяет создавать эти диаграммы:

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

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

Шаг 4. Тестирование и демонстрация продукта

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

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

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

Шаг 5. Ретроспектива и планирование следующего спринта

Основная цель

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

Заключение

Основные отличительные черты Scrum — гибкость и постоянный прогресс.В основном это обеспечивается постоянным общением и тесным сотрудничеством между заинтересованными сторонами на каждом этапе. На этапе планирования спринта product owner общается со scrum-командой. Они определяют, как они могут разделить существующие пользовательские истории на несколько задач.

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

.

Узнайте о Scrum Framework и Agile

Обратите внимание, что следующая информация получена от интеллектуальных лидеров наших сертифицированных тренеров Scrum и сертифицированных Agile-коучей, а также из других авторитетных источников, включая Agile Manifesto и версию Scrum Guide от ноября 2017 года. ^TM

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

Scrum опирается на кросс-функциональные команды для доставки продуктов и услуг за коротких циклов , что позволяет:

• Быстрая обратная связь
• Постоянное совершенствование
• Быстрая адаптация к изменениям
• Ускоренная доставка

Понимание потока Scrum

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

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

Преимущества использования Scrum

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

Scrum помогает бизнесу:

• Более быстрые инновации
• От идеи к реализации быстрее
• Повышение уровня удовлетворенности клиентов
• Повышение морального духа сотрудников

.

What is, Process, Artifacts, Sprint

• Home

• Testing

  • • Back
    • Agile Testing
    • BugZilla
    • Cucumber
    • Database Testing

    9000 9000 J4000 Тестирование базы данных

    9000 Тестирование базы данных

    9000

    • Назад
    • JUnit
    • LoadRunner
    • Ручное тестирование
    • Мобильное тестирование
    • Mantis
    • Почтальон
    • QTP
    • Назад
    • 00050005000500050005

    000 RPM

    SoapUI

    • Управление тестированием
    • TestLink

  • SAP

    • • Назад
      • ABAP
      • APO
      • Начинающий
      • Basis
      • BODS
      • BI
      • BPC
      • CO
      • Назад
      • CRM
      • Crystal Reports
      • QMO

      Заработная плата

      • Назад
      • PI / PO
      • PP
      • SD
      • SAPUI5
      • Безопасность
      • Менеджер решений
      • Successfactors
      • Учебники SAP
    • 8

    Apache

    • AngularJS
    • ASP.Net
    • C
    • C #
    • C ++
    • CodeIgniter
    • СУБД
    • JavaScript
    • Назад
    • Java
    • JSP
    • Kotlin
    • Linux
    • Linux
    • Kotlin
    • Linux

    js

    • Perl
    • Назад
    • PHP
    • PL / SQL
    • PostgreSQL
    • Python
    • ReactJS
    • Ruby & Rails
    • Scala
    • SQL

    000

    0004 SQL

    • UML
    • VB.Net
    • VBScript
    • Веб-службы
    • WPF

• Обязательно учите!

  • • Назад
    • Бухгалтерский учет
    • Алгоритмы
    • Android
    • Блокчейн
    • Business Analyst
    • Веб-сайт сборки
    • CCNA
    • Облачные вычисления
    0005
    • COBOL 9000 Compiler
      0005
      9000 Встроенный COBOL 9000 Дизайн 9000
      • Ethical Hacking
      • Учебные пособия по Excel
      • Программирование на Go
      • IoT
      • ITIL
      • Jenkins
      • MIS
      • Сетевые подключения
      • Операционная система
      • Назад

      Управление проектами Обзоры

      • Salesforce
      • SEO
      • Разработка программного обеспечения
      • VB A

    • Big Data

      • • Назад
        • AWS
        • BigData
        • Cassandra
        • Cognos
        • Хранилище данных

        HBOps

        HBOps

        • MicroStrategy

    .