Как мы внедряли Scrum и какие выводы сделали — опыт компании AniArt

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

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

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

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

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

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

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

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

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

Мы хотим рассказать о нашем пути адаптации классического Scrum-фреймворка в работе над системой управления для «Академии современного образования А+». Это современный образовательный центр в Киеве, в который входят школа, детский сад, и специализированные курсы. Всего в Академии занимается более тысячи детей на почти 150 различных курсах.

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

Как заказчику и исполнителю начать работать по Scrum

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

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

Какие мы сделали выводы после этого этапа:

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

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

• Со стороны заказчика: «Это то, что мы просили, но это не то, что нам надо».
• Со стороны исполнителя: «Мы четко делали то, что вы просили. А теперь ваши потребности звучат для нас совсем иначе. Мы согласны все переделать, но за ваш счет. И вообще изменений так много, что доработка займет еще полгода».

Шаг №1: Бизнес-анализ и адаптация методологии

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

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

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

Часть нашего product backlog

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

Пример user story

Какие мы сделали выводы после этого этапа:

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

Шаг №2: Планирование спринта. Как мы адаптировали sprint planning

Изначально нам нужно было получить 2 вещи: сформулированную цель спринта и утвержденный sprint backlog. Цель спринта — то, ради чего спринт нужен. Самое главное, чтобы цель была обозначена в терминах бизнеса, а не технических. То есть языком, понятным даже людям вне команды. 

Sprint backlog — это выборка историй из общего product backlog. Он представляет собой список историй, которые команда определила как наиболее важные на данном этапе и обязалась выполнить в течение спринта.

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

Планирование спринта (sprint planning) — это очень важная Scrum-активность. Все осознают ответственность за правильную оценку, потому что:

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

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

• User story #1: преподаватель заходит в систему и проставляет оценки по любому предмету из расписания класса за день. Система с одной простой, но уже работающей функцией. Уже на sprint demo преподаватель сказал, чем пользоваться удобно, а чем — нет, чтобы в следующих спринтах команда могла запланировать корректировки и дать обновленный инструмент. Какую реальную ценность дает: оцифрованная успеваемость реального класса, актуальные оценки, перспектива для автоматической подготовки месячной, семестровой, квартальной отчетности.
• User story #2: еженедельный отчет родителям об успеваемости на почту. Какую ценность добавляет: информирование родителей о текущей успеваемости; комментарии преподавателя к домашнему заданию; минимальную, но реальную аналитику.

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

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

Еще яркий пример итеративного Scrum-подхода — конструктор расписания

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

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

Вот как конструктор расписания выглядел изначально — «брутальный редактор»:

Каким стал в итоге: 

Какие мы сделали выводы после этого этапа:

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

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

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

Шкала оценки или Scrum-poker

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

Заметьте, последовательность значений на карточках — нелинейная. Вот, например, между 13 и 21 ничего нет. Почему так? Во-первых, это нужно, чтобы избежать появления ложного чувства точности для больших оценок. Если история оценивается примерно в 17 story points, то нет смысла обсуждать, должна ли она быть 15, или 18, или 21. Все, что нам нужно знать, — историю сложно оценить. Поэтому мы назначаем ей оценку в 21. Ориентировочно.

Во-вторых, людям свойственно преувеличивать свои возможности, а шкала не позволяет сильно ошибаться с оценкой времени и ресурсов. Например, команда сошлась на мнении, что на одну из задач достаточно 6 story points. Но если нет уверенности, что хватит и 5, то лучше выбрать 8.

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

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

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

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

В рамках проекта мы разрабатывали «Живую ленту». Это инструмент, который уведомляет учеников, учителей и родителей  о разных событиях: получение оценки, замена урока, инцидент и так далее. 

Перед стартом мы обсуждали с разработчиками, во сколько оцениваем объем работ — каждый предполагал, сколько story points потребуется. Выяснилось, что у нас большие расхождения во взглядах, и обратили внимание на крайние мнения: почему кто-то оценил задачу в 50 story points, а его коллега всего в 5. Так мы обнаружили невыявленные требования и вскрыли глобальные задачи, связанные с персонализацией. 

Какие выводы мы сделали по методике оценки:

• Это нормально, чтобы оценку технической истории выдали также QA и UX-дизайнер.
• На первых спринтах команда сопротивляется эмпирическим story points, потому что привычнее и «проще» оценивать трудозатраты в часах и днях. Мы обкатывали эту систему оценки, иногда сильно ошибались, но потом очень точно определяли объем задач.

Шаг №3: Спринт запущен. Как мы адаптировали sprint execution и ежедневный Scrum

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

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

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

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

Какие выводы мы считаем важными для этапа sprint running:

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

Шаг №4: Как мы проводили демонстрацию результатов. Наша адаптация sprint demo

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

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

Мы всегда приветствовали, чтобы после каждой продемонстрированной истории заказчики сами попробовали что-то сделать в системе. Тогда конечный пользователь проверяет каждый пункт критерия приемки. Он говорит, что устраивает, а что нет, какие аспекты можно улучшить. И так — по каждой user story, которая была запланирована на этот спринт.

Какие выводы мы сделали по методике проведения демонстрации результатов:

• Обязательный состав для демо: заказчик, эксперт по Scrum (Scrum master), представители заказчика и конечные пользователи, которые будут работать с инструментом, команда.
• Перед каждой демонстрацией нужно зачитывать соответствующую пользовательскую историю, чтобы ввести всех в контекст.
• Полезно проводить демонстрацию на продуктовой системе с реальными данными и реальными пользователями, которые уже работают в системе. Такой подход возможен когда система находится в стадии альфа-тестирования.
• Важно не тратить много времени на подготовку демо, мы никогда не создавали эффектную презентацию. Мы концентрировались только на демонстрации реально работающего кода и получении обратной связи.
• Не нужно показывать кучу исправлений мелких багов и элементарных фич. Можно упомянуть о них, но демонстрировать их не стоит, потому что это забирает много времени и снижает внимание к более важным историям.

Шаг №5: Как мы проводили ретроспективы

Для нас ретроспектива — это важное мероприятие сразу же после sprint demo. Ретроспективы полезны, особенно когда что-то идет не так. Без ретроспектив может оказаться, что команда наступает на одни и те же грабли снова и снова.

Самые частые грабли — это когда реальная производительность команды сильно отличается от прогнозируемой. Реальная производительность рассчитывается на основании начальной оценки каждой истории. И когда в середине спринта мы понимаем, что история, оцененная в 5 story points, делается столько же, сколько обычно занимает задача на 13 story points — и из-за нее мы не можем начать выполнять другие задачи — ретроспектива неизбежна.

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

Пример наших улучшений по результатам одной из ретроспектив:

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

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

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

12% — много, но это того стоит, так как в классическом «водопаде» цена использования методологии — это отдельная роль проджект-менеджера. В среднем по нашему сегменту рынка на менеджмент затрачивается около 15% от стоимости разработки.

Какие выводы мы сделали по методике проведения ретроспектив:

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

Шаг №6: Как мы адаптировали product backlog refinement, или Grooming

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

Чтобы все работало правильно, существует специальная Scrum-активность: product backlog refinement. Для ее проведения необходимо попросить заказчика дать горизонт планирования: очертить, какие истории могут быть кандидатами на ближайший спринт. Если среди них окажутся истории, требующие углубленного изучения или специальных компетенций, которых нет у команды, назначается собрание — grooming/pre-planning.

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

Какие выводы мы сделали:

• Это важное мероприятие, которое позволяет прояснить, чего мы не знаем, каких компетенций нам не хватает. Благодаря этому мы однажды решили привлечь стороннего разработчика-консультанта в специфических вопросах, опыта решения которых у нас на тот момент еще не было.
• Эти обсуждения у нас проходили очень эффективно, мы рассматривали множество альтернатив и вариантов, что позволяло держать проблему в голове, и к sprint planning сложнейшая история уже была «разложена по полкам».
• Сложные, казалось бы, неразрешимые проблемы находят понятные решения. Иногда достаточно просто купить библиотеку, чем вести разработку сложного участка самостоятельно.

Фэйлы

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

Фэйл 1: Лишняя работа над ненужной функциональностью

На втором спринте заказчик поддался мнению одного из завучей, который считал что «журнал куратора» — крайне важная функция. Мы взяли эту историю в спринт, потратили на нее усилия.

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

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

Фэйл 2: Равнение на продвинутых пользователей

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

Вывод: подтверждать историю на обычных пользователях.

Фэйл 3: Работа по привычным схемам

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

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

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

Итоги

1. Про гибкость

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

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

2. Про максимально эффективное использование ресурса

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

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

3. Про взаимодействие 

Scrum — когда обе стороны застрахованы от рисков. 

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

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

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

Материалы и литература, которые помогли нам:

• Software Estimation: Demystifying the Black Art (Developer Best Practices)
• Manifesto for Agile Software Development
• Principles behind the Agile Manifesto
• Agile Retrospectives: Making Good Teams Great

Автор: Андрей Лещинский, проджект-менеджер компании AniArt