Я — PM в сервисе рассылок UniSender. 6 лет назад я пришёл программистом, а теперь отвечаю за взаимодействие между командами продукта. Раньше наша разработка состояла из одной распределённой команды и у нас было 2 беды. Но не дураки и дороги, а задержки по спринтам и скучные стендапы на полчаса.
Расскажу, как мы их решили.
Как я уже говорил, у нас было 2 беды:
- Спринт мог задержаться по вине одной задачи. QA и Dev работали над одним спринтом, скоуп задач фиксировался в начале работы, и вся команда героически бросалась его реализовывать. Иногда прилетали срочные баги, которые шли в «master» хотфиксами. Задачи в спринте могли быть достаточно объёмными. Когда одни задачи уже были готовы к релизу, другие всё ещё были в разработке. В результате команда могла задержать спринт из-за одной задачи.
- Стендапы занимали много времени и имели сомнительную полезность. Команда росла, стендапы проводились по скайпу, и в начале ничего не предвещало беды. Мы начали подозревать неладное, когда стендапы начали растягиваться на 20-30 минут. Присутствующие не всегда понимали, чем занимаются другие участники команды.
Некоторое время мы жили с этими проблемами, потом пробовали бороться.
- Сокращали стендапы через введение регламента на человека.
- Уменьшали количество присутствующих — на стендапы ходил только тимлид.
- Пробовали недельные спринты.
- Уменьшали количество задач в спринте.
Ожидаемого результата эти попытки не давали. Пришло понимание, что без радикальных изменений не обойтись.
Тут надо пару слов сказать о продукте.
Мы — SaaS-решение, доступное 24/7. Кроме видимой пользователям части — GUI — у нас есть еще большой пласт системной логики, который работает независимо от времени суток или политической ситуации в стране. То есть, разработка и обновление сервиса идет непрерывно, без остановки.
Переход на Kanban
Первая масштабная революция случилась, когда мы поняли: «Scrum нам не подходит».
Решили переходить на Kanban. Мы, конечно, не Toyota и внедрять полную реализацию не стали. Поэтому «наш канбан» будет отличаться от «вашего канбана».
Спринты и работа команд
В двух словах о нашей версии:
- Единицей работы мы считали спринт (завершённый кусок функционала).
- Команду под задачу собирали в зависимости от загрузки и необходимых скилов. В одной команде обычно было до 3 разработчиков и 1 QA. Постоянных команд не было.
- Количество одновременных спринтов стало больше одного.
- Физической доски и других атрибутов Kanban не было, задачи вели через дополнение к Jira.
При этом команда должна была делать спринт от начала и до конца. Это касалось и этапа тестирования: ошибки исправляли те же люди, которые работали над спринтом.
Результат.
- При задержке больших задач не страдали остальные, разработка которых завершилась.
- Уменьшилось количество проблем при деплоях — в одном спринте стало меньше разношёрстных задач.
Стендапы
Стендапы преобразились — на них ходило по одному представителю от каждой команды, которая работала над отдельным спринтом.
Результат.
- Стендапы стали похожи на стендапы и мы снова начали укладываться в эталонные 10-15 минут.
Таким образом мы смогли решить критичные проблемы.
Но… из-за острова начал выплывать весь айсберг!
После перехода на Kanban у нас появилась выделенная frontend-команда, а в backend и продуктовой команде стало больше сотрудников. Взаимодействие между отделами усложнилось — над одним проектом могли работать несколько команд.
Одни проблемы мы решили, но на передний план вышли новые:
- На стендапах участвовали не все — часто приходилось пересказывать информацию команде.
- У одного QA могло быть 2-3 параллельных спринта с разными командами. Приходилось переключаться: вспоминать особенности спринта и постоянно редеплоить код на тестовых окружениях.
- QA были не до конца вовлечены в процесс работы над спринтами. Часто задача доходила до них в конце спринта и требования изучались уже после завершения разработки.
- Команды собирались под проект и их состав часто менялся. Команда из двух разработчиков могла работать над 3 спринтами одновременно: 2 спринта на тесте плюс 1 текущий спринт.
- Было сложно оценить время разработки. Не понятно, сколько времени съест предыдущий незаконченный спринт.
Некоторое время мы жили по новым правилам и боролись с новыми вызовами. Попробовали разные подходы и набили много шишек.
В итоге, мы снова начали подозревать, что что-то идет не так. Новой революции быть.
Разделение на команды, новые стендапы, введение Fireteam
Мы проанализировали процессы от зарождения идеи до деплоя готовой реализации в прод. Посмотрели, как работают agile-методологии в других компаниях. Поняли, что наши подходы к процессу разработки были не такими уж и плохими.
Не нужно ломать работающую систему, нужно исправлять моменты, которые причиняют боль.Вот, что мы изменили в процессе разработки.
Спринты
Мы всё ещё оперировали понятием «спринта». Спринт — это «околодвухнедельный» скоуп работ для команды.
В чём плюс. Код не «протухает» и попадает на прод без существенных задержек. Если команда собирается делать спринт за 2 недели — нужно постараться, чтобы затянуть его до месяца.
Что можно улучшить. Часто «промахиваемся» с оценкой и спринты немного затягиваются. Время на работу над некоторыми спринтами изначально тяжело оценить (например, большой рефакторинг). Эту проблему нам предстоит решить.
Разделение на команды
Мы разбили одну большую команду на несколько команд поменьше. В каждую из них входят 2-3 разработчика и один выделенный QA. Сейчас команды стабильны и не меняются от проекта к проекту. Иногда люди переходят между командами для оптимизации составов или добавления требуемой экспертизы в команду. BA участвует в работе команды, но одновременно может вести 2-3 проекта.
Хотя отдыхаем всё равно одной командой)
При этом вся команда работает над одним проектом от начала и до его завершения. Один проект может состоять из нескольких спринтов.
В чём плюс.
- Команды находятся в одном помещении. До этого все сидели по отделам.
- Команда включена в работу над проектом от начала и до конца, что снижает bus-factor.
- Участники команды присутствуют на всех ивентах: ретро, стендапы, пленинги. Все сотрудники в курсе текущих задач.
- Команда больше не работает над чужими спринтами. Теперь всё своё-родное.
Что можно улучшить. Хотелось бы полноценно ввести BA в команды. Это проблематично, потому что ВА обычно приступает к работе раньше остальной команды.
Работа команды
У команды в работе может быть не больше двух спринтов: «тот, который всё ещё на тесте» и «новый, который будем пилить». Как правило, после окончания разработки, все по мере освобождения начинают работу по новому спринту.
В чём плюс. Работа команды стала более предсказуемой, все знакомы с кодом и могут саппортить спринт во время тестирования. Участники стали реже переключаться между задачами, а сам процесс переключения теперь происходит быстрее.
Что можно улучшить. В идеале — у команды должен быть только один спринт в работе. Но пока идеальный мир — не наш мир.
Fireteam
Каждая команда на одну неделю становится избранной. Эта команда реагирует на все внешние раздражители: обращения других отделов, аномальное поведение сервиса, хотфиксы. Мы называем эту команду «Fireteam».
В чём плюс. Fireteam-неделя не засчитывается команде во времени спринта. В перерывах между тушением пожаров сотрудники могут сосредоточиться на своих задачах:
- Провести рефакторинг.
- Доделать задачу по спринту.
- Написать документацию.
- Провести knowledge transfer с другими командами.
Недостаток. В fireteam-неделю жизнь команды очень насыщена событиями. Этих людей любят и знают в лицо все отделы, особенно техподдержка. Приходится постоянно переключаться между разными задачами: дебажить, вычитывать логи, пилить срочные задачи и тушить все пожары. Делать всё это нужно одновременно.
Стендапы
Мы ввели 2 типа стендапов:
- Командные. В них участвует команда, которая работает над проектом.
- Общие. Проходят раз в неделю, в них участвуют лиды от каждой команды.
В чём плюс.
- Команда информирована о состоянии дел по спринту.
- Сотрудники в курсе, чем занимаются другие команды.
- Стендапы не превращаются в «скучные мероприятия по чтению с бумажки каких-то наборов цифр». Все присутствующие понимают, о чём идет речь. Стало проще обнаружить проблемные места в работе.
- Стендапы занимают 5-10 минут.
Недостаток. Информацию до команды по прежнему доносит тимлид.
Итог
Таким образом, постепенно изменяя процесс мы решили большинство актуальных проблем:
- Мы собрали стабильные команды из 2-3 разработчиков и QA. У каждой команды в работе теперь не больше 2 спринтов, участники не работают над чужими проектами.
- Появилась команда, которая обрабатывает сообщения из других отделов, реагирует на аномальное поведение сервиса и хотфиксы. Другие команды на эти задачи не отвлекаются.
- Теперь в компании 2 типа стендапов: командные и общие. Все сотрудники информированы о состоянии дел по спринту, а стендап занимает эталонные 5-10 минут.
Что ж, работаем дальше.
Комментарии (42)
dedyshka
30.03.2019 16:56ИМХО, у вас проблема не со спринтами, а с работой с бэклогом.
Канбан это не процесс (спринты), а результат (реализация фичи), поэтому в канбане нет, как таковой, оценки срока реализации (для команды хорошо, для бизнеса и ПМ — новые реалии).
Почему для оценки спринта (если уж они у вас есть) не используете покер?altersun Автор
30.03.2019 23:13-1У нас чаще всего «спринт» === «большая фича». А как его называть «задача» либо «спринт» либо «итерация», как по мне — дело десятое.
Беклоги мы тоже поделили. У каждого модуля системы свой беклог. Т.к. задач очень много — так намного удобней формировать задачи для спринта.
Пленинг покер используем, но носит он больше информативный характер. Для синхронизации команды в понимании задачи.
T13Nemo
30.03.2019 23:52Sprint != Большая задача. Это один из худших антипаттернов.
Sprint это timebox. Когда время вышло, спринт закончен. То же самое и со всеми остальными церемониями.
Из статьи создаётся ощущение, как верно сказали выше, что у команды нет четкого понимания того как работает scrum и зачем. А самое важное — нет scrum master — человека который отвечает головой за оптимизацию процесса и рост velocity (не инфляцию velocity, а именно рост).
Мне кажется что у вас очень серьезные проблемы с декомпозицией на Story, а учитывая "рекомендательный характер" оценки, команда еще не очень хорошо понимает как эта самая оценка работает. Возможно, в силу размера техдолга, неправильной разбивки задач, отсутствия необходимых скиллов в команде.
Что же касается Kanban, то это очень строгая методология. Я не видел ни одной успешной канбан-команды, у которой были бы проблемы со scrum. Т.е. всего того что описали вы.
Все это, в целом, очень знакомо, и связано, в частности, с недостатком знаний и информации по теме.
К счастью, это легко исправить.
Я очень рекомендую почитать вот этих ребят:
https://www.scrum.org/resources/scrum-guide
Jeff Sutherland — один из создателей Scurm. Scrum.org — это его компания.
Удачи вам в становлении ваших процессов.mgear
31.03.2019 02:04в целом согласен с вашими замечаниями по скраму и особенно с посылом к скрамгайду.
но вот по канбану… это не методология, это метод управления работой. формально нет ролей, нет митингов — есть принципы. тоесть в целом канбан менее предписуем по сравнению со скрамом. Девид Андерсон выделяет 7 уровней зрелости канбан системы, но, в целом, даже просто визуализация работы в виде стикеров на стене, то это тоже будет канбан. www.kanbanmaturitymodel.comT13Nemo
31.03.2019 04:17Согласен, что формально это будет Kanban-ish, но даже стабильный lead time без эффективно выстроенных процессов, инфраструктуры и умения правильно декомпозировать задачи — фактически недостежим, а значит и планирование будет неэффективным.
Вы верно сказали выше, любое внедрение должно начинаться со строгого следования правилам. А все остальное это kai-zen.
Спасибо что обратили на это внимание. Это — суть agile. Фрэймворк это вторично.
vortupin
30.03.2019 18:12Некоторое время мы жили с этими проблемами, потом пробовали бороться.
Сокращали стендапы через введение регламента на человека.
Уменьшали количество присутствующих — на стендапы ходил только тимлид.
Пробовали недельные спринты.
Уменьшали количество задач в спринте.
А почему вы не попробовали разбивать задачи на более простые? И что значит: «на стендапы ходил только тимлид»? Это совсем не по Scrum-овски. Т.е. понимание, зачем вообще нужны ежедневные стендапы, отсутствовало.
Похоже, что все беды от того, что Scrum master либо отсутствовал, либо неверно понимал и выполнял свои обязанности.
orcy
30.03.2019 19:08Увидел негативные комментарии и захотел сказать что мне понравилась статья. Я сам встречался с сетапом когда скрам не очень работает, так что на мой взгляд не стоит догматично за него держаться.
NordicEnergy
30.03.2019 19:57+11Мде, статья «эталонного» ПМа… Куча модных вставок типа «редеплой», «пленинги», если вам уж так сильно нравятся англоязычные термины, то пишите на английском, а то кровь из глаз идет от таких статей.
Куча телодвижений из-за экономии 10(!) минут, серьезно? Сотрудники любой компании на кофе, перекуры и чтение телеграмчика тратят в разы больше времени, а вы оптимизируете длительность стендапа.
Как показываете практика, если его вообще отменить и заставить ПМа читать jira/youtrack (или что вы там используете), то можно добиться такого же результата за те же 10 минут и при этом не тратить время всех сотрудников.
Все это басни про agile/scrum на хабре больше напоминают борьбу с ветряными мельницами, т.к. в любой компании есть более значимые проблемы, но ПМы занимаются именно пинанием половых органов.
Не, ну реально, вы в итоге пришли к разбивке на фиксированные команды по меньше. Шикарно! В 2008-м работали так же, все успевалось, правда тогда никто не знал, что это какая-то модная методология, ведь в Совке тоже так же работали. Вот так новости.altersun Автор
30.03.2019 23:27Очень нравятся термины :) И термины кстати ровно из повседневной жизни, Вы же наверняка их тоже используете?
Дело не в 10 минутах, если бы захотели экономить — вообще отменили бы стендапы. Это больше вопрос синхронизации команды и озвучивания проблем. Иногда проблемы вскрываются там, где их вроде-бы не было (Пр: по разному поняли задачу; ждут кого-то, но не сказали об этом, либо сказали, но их не услышали).NordicEnergy
31.03.2019 00:36Вы же наверняка их тоже используете
Стараюсь избегать слова-паразиты, по крайней мере там где есть возможность сказать/написать тоже самое с использованием русского языка. Люди, которые не обладают грамотной речью хотя бы на родном языке — обезьяны обычные.
Это больше вопрос синхронизации команды и озвучивания проблем
Все это прекрасно и без стендапов всяких реализуется. Достаточно привить работникам привычку писать в конце рабочего дня что они сделали, что НЕ сделали и причину. 5 предложений в slack/jira/yt/etc отнимают 1 минуту времени, не отнимают нервы и не заставляют тащить свою задницу куда-то дальше своего рабочего места, что весьма комфортно.
по разному поняли задачу
Задачу ставит тимлид, если он не может разделить задачу между сотрудниками так чтобы все поняли, то гнать его ссаными тапками в мидлы. Не, ну серьезно, как можно по разному понять задачу?
Единственный момент когда нужны совещания — этап проработки ТЗ. Все! Вся остальная работа ведется по этому ТЗ. Если у вас вылезают «неожиданности», то учитесь писать и прорабатывать ТЗ, а не морочить голову какой-то оптимизацией с помощью инструментов, которые еще и никто не понимает в компании (судя по описанному в статье).istego9
31.03.2019 07:35Говорить про ТЗ в agile-процессах как-то странно. Нормальный скрам не предполагает ТЗ, так как ТЗ это классический waterfall со своими всем известными проблемами.
NordicEnergy
31.03.2019 08:25+3Так речь шла о бесполезности аджайла, если его не умеют применять и не понимают. В таком случае классический вариант сильно продуктивнее. Ну и как бы не было странно, но большие проекты и в том числе интерпрайз пишутся по ТЗ, даже если анонсируется якобы аджайл.
Когда заказчик приносит мешок денег — он хочет четко понимать, что он получит на выходе, а как вы это реализуете вопрос десятый и заказчика не касается. ТЗ нужно банально для составления договора или у вас бизнес работает так:
— Добрый день, меня зовут Ахмет и вот вам 200к$, хочу приложение отвечающее моим требованиям;
— Драсьте, круто, мы берем твои деньги, Ахмет;
— Давайте пропишем что я получу в конце, мне нужен убийца фейсбука и чтобы миллиард клиентов держал единовременно;
— Вы знаете, мы работает по agile/спринты/скрамы/митинги и такая методология не предполагает ТЗ, мы ваши требования выслушали, но ТЗ составлять не будем;
— А если вы сделаете говно?
— Ну аджайл это же гибкая разработка и эксперименты, мы не можем вгонять себя в формальные рамки;
— Ок, пойду в другое место.
Так что ли? Вы можете договор или список требований не называть «тех. заданием», но в реальности оно им не перестанет быть. И вот собрания нужны просто чтобы помочь заказчику сформировать эти требования/ТЗ, выбросить лишние, добавить что-то важное. На всех остальных этапах сборища людей — это скучная трата времени, куда разработчики идут как на каторгу, а не за «продуктивным обсуждением».VolCh
31.03.2019 16:38На вопрос "а если вы сделаете говно?" апологеты аджайл отвечают что-то вроде "мы вместе составляем ТЗ на 2 недели и мы по нему работаем, через 2 недели вместе смотрим результат и составляем ТЗ на следующие 2 недели".
NordicEnergy
31.03.2019 17:51Идеальная схема для выкачивания денег из заказчика)) А самое забавное, что никакой ответственности, т.к. нет гарантии, что результат будет достигнут и нет ТЗ по которому будет вестись приемка продукта. Одно радует — в родное hardware данная мода еще не сильно пробралась.
VolCh
31.03.2019 21:33В теории это идеальная схема для получения заказчиком в и тоге, того что ему в итоге нужно, а не того, что он думал, что нужно три года назад.
Приёмка ведётся каждые две недели по ТЗ на эти две недели. Если скорость продвижения заказчика не устраивает, то он меняет подрядчика. Опять же рисков меньше чем выдать ТЗ на три года с этапами по полгода.hhba
31.03.2019 23:04Без всяких "в теории". Достаточно попытаться поднять хотя бы один сколько-нибудь новаторский в рамках конкретной компании проект, и сразу станет понятно, что "работа по утвержденному ТЗ" === "работа в стол". Пока такого опыта нет — можно с апломбом делать утверждения любого масштаба.
VolCh
31.03.2019 23:22Сильно зависит от процессов компании, её масштабности и отношения проекта к этим масштабам. Где-то хорошо зайдёт, где-то только ненужный оверхед внесёт.
grinCo
01.04.2019 06:50Чисто ради информации, как сказать редеплой по русски?
VolCh
01.04.2019 10:21«переразвёртывание», «повторное развёртывание»
grinCo
01.04.2019 10:29Спасибо.
Не слышал ни разу.
ИМХО долго и неудобно, причем режет слух гораздо больше, чем редеплой. ИТ термины пришли с английского языка и не всегда стоит им искать замену.
Я подозреваю, что русский язык заимствовал большУю часть слов из других языков: тюркских, финнского, французского, немецкого. Вы же не говорите лошадиное молоко, а кратко и употребляете более подходящее кумыс.
Заимствования делают язык богаче.NordicEnergy
01.04.2019 12:31Вы же не говорите лошадиное молоко, а кратко и употребляете более подходящее кумыс
Ага, не говорим, учитывая, что кумыс это не лошадиное молоко. Кумыс лишь изготавливается из него :))grinCo
01.04.2019 18:56Хорошо, вы не говорите кисломолочный напиток из кобыльего молока.
Может пример не очень удачный, но суть в том, что любой язык непрерывно развивается и заимствует слова. И в случае с ИТ терминологией для русского языка это не несет негативных последствий.
alatushkin
30.03.2019 20:36+1В статье не хватает чисел «было»/«стало», а без этого нельзя наверняка понять стало ли лучше.
Пока получается, что у вас были «какие-то процессы», вы «что-то сделали», и у вас стали «какие-то другие процессы». Это здоровое, но…
orion76
30.03.2019 20:51Блин, тоже хочется «поворчать», но влом-)
Наверное хабр пора делить на хабр-next и хабр-старпёр -))
reinvent
30.03.2019 20:54+2Сотрудники как относятся ко всем этим экспериментам? Вы их спрашивали, как по их мнению наладить эффективную работу?
NordicEnergy
30.03.2019 23:26+4Рабам не надо думать об эффективности, рабам надо налегать на весла. Думать и философствовать о эффективности должен штат специально обученных людей: ПМы, скрам-мастера, аджайл коучи, бизнес-аналитики.
Просто если сесть и обсудить методы повышения эффективности с разработчиками, то велика вероятность реально поднять ее и решить большинство проблем бизнеса. Что тогда делать десяткам тысяч мастеров-коучей-менеджеров? В дворники что ли идти? Вы знаете как тяжело после пинания болта и получения оклада 100к+ пойти и реально что-то делать в рабочее время? Вот! Пожалейте бедняг, не надо спрашивать сотрудников.hhba
31.03.2019 23:08Я разработчик, не разбираюсь в менеджменте, но тем не менее считаю, что вы написали чушь. Как мне перестать так считать, и начать столь же надменно говорить о работе других людей, в которой я ничего не понимаю?
NordicEnergy
01.04.2019 12:35Для прикола можно дорасти до тимлида и познать всю бесполезность этих супер-методик, даже если имеются в штате скрам-мастер и прочие «опытные специалисты». Если считаете, что я не прав, то покажите мне в СНГ компанию, которая работает по всяким канбанам и достигла уровня Toyota или хотя бы приблизилась к нему.
altersun Автор
30.03.2019 23:31Сотрудники относятся с пониманием :) Часто инициативы для изменений приходят с ретро либо с one-2-one. Не все, что хочется можно внедрить и не все приживается, но сотрудников точно слушают и слышат.
VMichael
30.03.2019 23:29В результате команда могла задержать спринт из-за одной задачи.
И к каким негативным последствиям это приводило?altersun Автор
30.03.2019 23:42Спринт из 20-30 задач задерживался и ждал решения одной задачи. В результате — один человек фиксит проблему, остальные «придумывают» себе работу.
Т.к. продукт работает 24/7, а code-freeze делаем только в случае выкатки критического функционала — чем дольше спринт ждет — тем больше риск конфликтов и необходимости повторной прогонки регрессии(а то и не одной).
+ бизнес нервничает, куа нервничают, все нервничают, а нервные клетки не восстанавливаются :)VMichael
31.03.2019 10:561. Если без доделанной задачи нельзя запустить остальные 20-30 задач, значит задачи жестко связаны и тут или косяк планирования и выбора приоритетности выполнения задач и я не знаю, как вы в вашей «новой» методике это обойдете.
2. Если остальные 20-30 задач можно выкладывать, но они ждут еще одну только потому, что ее «включили в спринт» это вообще глупость. Как и то, что вне рамок вашего «спринта» у остальных сотрудников заканчивается работа.
Просто вопрос здравого смысла и некоторого планирования.
Мы работали без спринтов и прочих штук, просто поток задач. Часть из них связанные. Сделал задачу, бери следующую. К моменту релиза, релизятся все готовые задачи (понятно, если есть связанные, ожидается завершение всей цепочки для включения в релиз).
Все. Никаких формальных спринтов с принципом «все задачи или ничего».
Понятно, что бывают большие проекты, где нужно выкатить набор задач, которые должны идти все вместе. Тут снова вопрос здравого смысла, что бы распараллелить работы по программистам. Но опять же, пока последнюю задачу заканчивают, что мешает дать другую работу программистам? Если только у вас работа циклическая, по синусоиде. Когда работа приваливает пачками и вы должны ее сделать быстро, поддерживая для этого численность персонала, а в перерыве между пачками работы курите бамбук. Как вариант. Других причин искусственно тормозить работы коллектива до «пока последний доделает свою работу» ради неких «спринтов» в голову не приходит.
VolCh
31.03.2019 11:52Что-то мне кажется в самом начале было как то неправильно. Спринт в скрам не предлагает релиза в конце спринта, может быть релтз раз в год, а может каждая закрытая задача релтз. И спринт не может быть задержан. Прошёл срок и подводим итог успешный спринт или нет. Ждать никого не надо, надо начинать новый спринт, в который не выполненные задачи из неуспешного переносятся, если не появились более приоритетные.
mgear
уберите пожалуйста тег, из agile у вас здесь только терминология. и, может, управление процессами разработки это не ваше?..
VIkrom
Забавно, когда начинают рассказывать, что кто-то делает agile неправильно. Забывая о сути самого слова.
mgear
забавно говорить о agile, забывая как минимум прочесть scrumguide и хоть что-то о канбан-методе. безусловно agile об экспериментах, но вся статья сквозит непониманием базовых принципов
VolCh
Зачем читать scrumguide если намерения внедрять скрам нет? Был консультант, который пособирал информацию и сказал, что скрам не взлетит.
altersun Автор
Может Вы можете подсказать, какой agile является правильным? :)
mgear
тот, в котором организация, ее структура и процессы в целом осознано оптимизируются на доставке бизнес ценности отталкиваясь от принципов и ценностей agile. концепцию shu ha ri слыхали? сначала делаем, как канонически предписано, потом адаптируем под себя, потом уже создаем свои правила.
зачастую нельзя поправить ситуацию использовав «кусочек» agile, проблемы оказываются системными. вы же в Москве, идите в scrumtrek.ru, определенно помогут поставить «правильный» agile