Что такое scrum и как он работает

Что такое Scrum

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

Однако такое «чисто процессное» определение Scrum не вполне соответствует роли этого подхода в современном управлении (на это и намекает вышеприведенное определение из Scrum Guide 2020). Scrum глубже, чем процессы.

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

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

Артефакты

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

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

2. Бэклог спринта — выбранный на спринт набор элементов бэклога продукта для достижения определённой командой цели спринта с учётом имеющихся знаний и приоритетов.

3. Инкремент — протестированная и работоспособная версия с добавочной ценностью для клиента, которая соответствует критериям завершённости.

Характеристика	Метод исследования	Метрика
Бэклог продукта	Наблюдение за единым местом хранения всех задач, направленных на развитие продукта.	Бэклог продукта отсутствует — 0 баллов. Бэклог продукта имеет вид разбросанных задач — 1 балл. Бэклог имеет вид отфильтрованного списка по предмету — 3 балла. Бэклог единое место хранения всех задач по продукту — 5 баллов.
Бэклог спринта	Наблюдение за единым местом хранения задач спринта, выполнение которых обеспечит выпуск инкремента.	Бэклог спринта отсутствует — 0 баллов. Бэклог спринта имеет вид разбросанных задач — 1 балл. Бэклог имеет вид отфильтрованного списка по предмету — 3 балла. Бэклог единое место хранения всех задач по спринту — 5 баллов.
Инкремент	Наблюдение за фактом выпуска протестированной и работоспособной версии продукта.	Понятие инкремента отсутствует — 0 баллов. Понятие инкремента присутствует, но выпуск работоспособной версии не происходит по факту окончания спринта — 1 балла. Понятие инкремента отсутствует, но выпуск работоспособной версии происходит по факту окончания спринта — 3 балла. Понятие инкремента присутствует, триггером появления служит спринт — 5 баллов.

0–9 баллов — низкий результат, характеризующий сложность существующих подходов в части управления и планирования содержанием работ. Данная сложность может быть причиной увеличения времени ожидания ответа на запрос внутри команды, а также причиной низкой концентрацией на актуальных задачах.

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

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

Что такое методология Scrum и для чего она применяется

Основная область применения технологий Scrum — сфера IT. Использование этой методологии позволяет:

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

• разрабатывать новые и улучшать старые продукты в короткие сроки;

• выпускать продукты и обновления, разрабатывать безопасные среды для их использования, подстраиваясь под изменения рынка;

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

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

Что за сценарий

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

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

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

Но такое сце­нар­ное мыш­ле­ние воз­мож­но не во всех продуктах.

Для про­сто­ты мож­но думать о сце­на­рии так: «Мож­но ли выпу­стить новую вер­сию про­дук­та для поль­зо­ва­те­лей, если реа­ли­зо­вать толь­ко этот кон­крет­ный набор задач?» Если мож­но — услов­но мож­но назвать это сце­на­ри­ем. При­мер с чебу­ре­ком: мы можем выка­ты­вать в меню сна­ча­ла чебу­рек новой фор­мы, потом чебу­рек с новым цве­том, потом новый раз­мер чебу­ре­ка и т. д.

The New New Product Development Game

Термин “scrum”, применительно к разработке проектов, был впервые упомянут Хиротака Такеучи и Икуджиро Нонака в статье, опубликованной в 1986 году в Harvard Business Review.

Один из параграфов статьи имел заголовок: “Moving the Scrum Downfield”, и дальше проводилась прямая аналогия с игрой в регби. Термином “scrum” в регби обозначается один из элементов игры, когда игроки двух команд после нарушения правил или приостановки игры собираются вместе, сцепляются друг с другом и с командой-соперником и ждут вброса мяча «девяткой» — игроком команды под номером девять (scrum half). Это первоначальное состояние, после которого та или иная команда овладевает мячом, и начинается игра.

Вот как это описывает статья :

Наиболее типичные ошибки при оценке работ в проектах 1С

Для кого эта статья? Если вы руководитель проектов (РП) с опытом «от трех проектов», то можете не читать: скорее всего, ничего нового вы не узнаете. А если вы хотите стать РП в проектах 1С или вы профессионал (разработчик, аналитик, консультант), к которому часто обращаются за оценкой, то вам будет полезно узнать о типичных ошибках при оценке.
Если вам необходимо реализовать задачу, которую не имеет смысла делать по классической проектной технологии, но заказчик требует фиксированной оценки, и задача на 2-5 человеко-месяцев, — то вам будет полезно понять методы оценки работ.
Если читатель часто пользуется услугами удаленных разработчиков/аналитиков, то вам, возможно, станет понятно, почему «человек все сделал, мы ему заплатили, сколько сказал, а он от нас ушел и больше работать не хочет».
Типичные ошибки распределю по классам.

Ключевые понятия в Scrum

В методологии Scrum используются следующие ключевые понятия:

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

• практики — способы и техники, применяемые создателями продукта при работе над ним;

• артефакты (документы) — детализированные описания продуктов и графики достижения целей, составленные командой;

• итерации — временные отрезки, составляющие рабочий процесс;

• спринт — период от 1 до 4 недель. За эти сроки создается фрагмент продукта, ценного для пользователя. Перед запуском проектной командой планируются этапы создания релиза и формулируются требования к нему.

Роли в Scrum-методологии представлены:

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

• скрам-мастером (Scrum Master) — координатором, организующим всю деятельность разработчиков. Scrum Master  проводит совещания, ликвидирует конфликты и затруднения в рабочих процессах, контролирует выполнение всех практик, сохранность и использование Scrum-инвентаря;

• командой разработки (Development Team) — рабочей группой из 5-9 человек — программистами, тестировщиками, аналитиками, архитекторами и другими специалистами. Команда разработки проводит оценку функциональности продукта, отслеживает все процессы вместе со скрам-мастером, предоставляет готовые результаты заказчику.

Также в разработке продукта опосредованно участвуют Stakeholders (акционеры) — инициаторы работ, которым скрам-проект принесет прибыль, и Users — пользователи продукта, на которых он рассчитан.

Составные элементы скрама

В сухом остатке для использования этого метода требуются три стороны:

• Владелец продукта, который располагает информацией об объеме работы и очереди задач (бэклоге), а также может ответить на все вопросы
• Скрам-мастер, который проводит совещания-летучки и ищет самые эффективные способы выполнить работу
• Участники команды, обычно многопрофильные специалисты, от которых требуется сделать многое за небольшое время

Для скрам-процесса необходимы:

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

Отличия традиционного подхода от «гибких» методов

Итак, в чём же отличия традиционных подходов в образовании от современных гибких методов? Для удобства и наглядности мы собрали их в одну таблицу:

	Традиционный подход в обучении	Agile-подходы в образовании
Период обучения	от трёх месяцев до полугода	короткие спринты от одной до двух недель
Формат обучения	соответствие строгому учебному плану	обучение построено как игра
Форма организации	общие лекции и семинары	практические группы от 6 до 8 человек
Форма восприятия информации	пассивное восприятие	активная самостоятельная работа в группах
Оценка результатов	внешняя оценка	внутренняя оценка
Роль преподавателя	полностью контролирует весь учебный процесс	направляет и корректирует

Как теряют бизнес. Реальные истории от бизнес-консультанта. Промо

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

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

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

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

Scrum доска/Agile Board

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

Пример доски из жизни:

Определение «Готовности»

Когда элемент Журнала Продукта или же Инкремент назван “готовым”, все должны понимать, что означает “Готово”. Хотя это определение разные Скрам Команды интерпретируют по-разному, чтобы гарантировать прозрачность, члены Команды должны иметь общее совместное понимание, что означает, когда работа сделана. Именно такое единое определение понятия “Готовности” используется Скрам Командой для оценки окончания работ над Инкрементом Продукта.
Одно и то же определение помогает Команде Разработчиков в понимании того, сколько требований выбрать из Журнала Продукта во время Планирования Спринта. Целью каждого Спринта является разработка Инкремента потенциально готовой к выпуску функциональности, отвечающей текущему определению “Готовности” Скрам Команды.
По окончанию каждого Спринта Команда Разработчиков представляет Инкремент функциональности продукта. Такой Инкремент является пригодным к эксплуатации, и поэтому Владелец продукта может решить сразу же его выпустить. Каждый последующий Инкремент должен дополнять все предыдущие Инкременты, а также быть тщательно протестирован для обеспечения стабильной работы всех Инкрементов продукта.
По мере увеличения профессионализма Скрам Команды, определение понятия “Готовности” может расширяться более строгими критериями для достижения лучшего качества продукта.

Заключение

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

5
1
Голос

Рейтинг статьи

Книга о том, как перейти на Scrum

Долгое время Scrum был уделом небольших компаний, или шустрых IT-компаний, но постепенно, в Scrum стало вливаться «позднее большинство», и примерять на себя этот подход стали большие, неповоротливе компании, которым нужен был гарантированный результат.

В 2009 году Майк Кон опубликовал книгу “Succeeding with Agile: Software Development using Scrum”.

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

Майк Кон приводит множество данных, доказывающих эффективность применения Scrum при разработке продуктов. Например, вот сравнение Time To Market в Agile-проектах по сравнению со средним в индустрии:

Так же много внимания было уделено выбору пилотного проекта для Scrum. Это было крайне актуально, так как наступило время больших Enterprise-проектов, которые делаются по Scrum, и вопрос адаптации «мастодонтов» к новым реалиям стоял как никогда остро.

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

Очень много внимания в книге уделено работе с бэклогом. По-моему, понятие “Айсберг бэклога” (Backlog Iceberg) впервые упомянуто именно в этой книге.

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

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

Кто входит в состав development team

Команда разработки – это не только непосредственно разработчики. В эту самую многочисленную часть scrum-команды входят тестировщики и DevOps, и UA/UX-дизайнеры, и другие специалисты, которые обеспечивают создание инкремента продукта. Все зависит от того, как организована работа над конкретным проектом.

Команда разработки является ключевой рабочей единицей. Глава Amazon Джефф Безос сформулировал «правило двух пицц» для размера scrum-команды – от 4 до 10 человек, то есть то количество людей, которых можно накормить двумя пиццами. Размер и состав scrum-команды на протяжении спринта не меняется.

Оценка внутри беклога

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

Допустим, в сервисе есть user story типа «Регистрация пользователя». Возьмём её за образец и дадим ей ценность в 1 бал или один story point. Каждый участник команды напишет собственную оценку к остальным историям пользователя в списке, учитывая задачу, взятую за образец.

Выше мы видим, что «Фотогалерея с довольными клиентами» оценивается 0,5 story point, т. е. она меньше образца в 2 раза. Все эти оценки члены команды проставляют анонимно, например, на стикерах, написав и перевернув.

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

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

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

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

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

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

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

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

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

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

Попробуйте такой шаблон для ретроспективы.

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

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

Команда как функциональная единица

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

Характеристика	Метод исследования	Метрика
Команда	Наблюдение за принципами организации групп и наличие сущности «команда».	Отсутствует понятие команды — 0 баллов. Команда образована по функциональному признаку — 1 балл. Самоорганизация команды по предметному признаку — 3 балла. Команда образована по предметному признаку (направление) — 5 баллов.
Скрам-мастер	Наблюдение за наличием функций: — развитие продуктовой команды;— поддержка среды с культурными ценностями;— поддержка среды в рамках фреймворка SCRUM;— мотивация продуктовой команды;— применение модели «менеджер — слуга»;— организация производства;— решение внутренних и внешних конфликтов.	Роль отсутствует, функции роли отсутствуют — 0 баллов. Роль отсутствует, функции роли присутствуют — 1 балл. Роль присутствует, функции роли отсутствуют — 3 балла. Роль присутствует, функции роли присутствуют — 5 баллов.
Владелец продукта	Наблюдение за наличием функций: — разработка дорожной карты продукта;— управление продуктовым бэклогом;— планирование и развитие продукта;— проведение демонстрации продукта;— проведение ежедневных стендапов;— разработка бизнес-гипотез.	Роль отсутствует, функции роли отсутствуют — 0 баллов. Роль отсутствует, функции роли присутствуют — 1 балл. Роль присутствует, функции роли отсутствуют — 3 балла. Роль присутствует, функции роли присутствуют — 5 баллов.
Разработчик	Наблюдение за восприятием роли разработчика в контексте всех необходимых функций для выполнения задач в команде.	Роль включает в себя только компетенции программирования — 0 баллов. Роль включает в себя все необходимые компетенции для поставки версии продукта — 5 баллов.

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

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

17–20 баллов — высокий результат, характеризующий наличие самодостаточной организационной единицы производства инкремента продукта, признанной на уровне организации. При данном результате, рекомендуется сделать акцент на мероприятиях направленные на управление продуктом, непрерывное обеспечение качества и CI/CD, как вектор роста команды.

Что такое Agile и Scrum

Прежде, чем говорить о применении Agile-методологии и scrum-технологий в образовании, давайте разберёмся, что они обозначают.

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

Agile — метод и образ мышления

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

Agile-мышление опирается на четыре важные ценности:

1. На первом месте люди и взаимодействия между ними, а не процессы.
2. Акцент на продукте, а не на регламентах и документах.
3. Тесное взаимодействие с заказчиком, а не бесконечные согласования по факту.
4. Постоянные эксперименты и изменения в процессе, а не строгое следование плану.

Подробнее о 4 ценностях и 12 принципах методологии для IT-разработки можно почитать непосредственно в Agile-манифесте.

Вдохновлялись создатели Agile-методологии научным методом, который разработал ещё Галилео Галилей. Что роднит IT-разработчиков и итальянского учёного? В основе двух подходов — постоянное повторение эксперимента и уточнение результатов.

Фреймворк Scrum

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

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

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

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

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

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

Процесс работы scrum-команды

Процесс работы scrum-команды проходит в несколько обязательных этапов.

Планирование бэклога спринта

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

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

Scrum-митинг, или совещание на ходу

Каждый день вся команда проводит короткую встречу, не более15 минут. Scrum-мастер и владелец продукта тоже участвуют. Суть встречи — получить от каждого члена команды ответ на три вопроса:

1. Что я сделал с момента прошлой встречи?
2. Чем я займусь сегодня?
3. Какие есть препятствия?

Задача scrum-мастера — понять, если что-то идет не так, и помочь команде справиться с трудностями.

Scrum-доска

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

Как выглядит scrum-доска

Когда что-то идет не так

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

Обзор результата

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

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

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

OOPSLA 95

В октябре 1995 года на конференции OOPSLA (“Object-Oriented Programming, Systems, Languages & Applications”) в Остине, штат Техас, Кен Швабер и Джефф Сазерленд впервые представили Scrum в своем докладе дали первое описание Scrum-процесса.

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

Обратите внимание: речь про “существующие системы” или работающие производственные прототипы. Ни слова ни про продукты, ни про работу в большой зоне неопределенности

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

А вот как выглядел Scrum-процесс на картинке:

Весьма непривычно для современного читателя. Где Ретроспектива? Что за Wrap и Adjust? Процедуры Planning & System Architecture вынесены за пределы рабочего процесса.

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

Внедрение программного продукта. Особенности работы бизнес-консультанта. Часть II Промо

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

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