Аннотация
- Докладчик
- Александр Лесневский
Иногда все идет как по писаному, иногда сталкиваешься с трудностями и препятствиями, объяснение которым находится не сразу, и способы преодоления которых не лежат на поверхности.
Об отрицательном опыте говорят не часто....
В докладе будет поведано об истории внедрения Scrum в компании Промедичи, ошибках, и уроках, которые можно извлечь из этой истории.
Видео
Для этого доклада нужен подкаст (аудиозапись)?
Презентация
Примечания и отзывы
Ссылки имеющие отношение к этому кейсу:
Доклад Александра Лесневского и Никиты Филлипова про то как перевод проекта на ажайл-рельсы помог понять инвестору, что продукт будет убыточным. Оказывается и такое бывает) После того, как agile-подход сделает процесс боле прозрачным ВНЕЗАПНО можно узнать, что он особо то и не нужен.
©
Очень скучный дядька. Когда увидел очередной слайд презентации, захотелось выколоть свои глаза. Александр может быть и хороший спец, и интересным опытом хотел поделиться, и даже человек он может быть хороший, но после доклада Дмитрия Лайера я решил не рисковать и пошел кушать бутерброды с чаем.
Очень странный доклад. Был большой инвестиционный проект, бизнес-план под который предусматривал опеределенную разработку, окупающуюся за десяток внедрений. Четыре года он шел с не очень понятным результатом — с одной стороны, была пара пилотных внедрений, с другой — до фиксации продукта было непонятно сколько, и темпы движения невнятные. Пытались исправить ситуацию через внедрение scrum и отчасти это удалось — внедрили и вроде получили реальный прогноз — еще четыре года. А дальше инвестор, узнав прогноз, предпочел зарыть проект. Но инвестор сохранил деньги, и это бизнес-позитив внедрения scrum. Хотя лично мне получение реалистичного прогноза на 4 года по результатам менее чем полугода работы представляется сомнительным, за этот срок скорость новых команд не могла выйти на плато. Да, я мог напутать, и везде говорилось о 2 годах, а не о 4.
Рассказывали все достаточно интересно, с привязкой к типам Адизес — была харизматичная хозяйка (тестеры), поджигатель, фонтанирующий идеями и отказывающийся и провокатор с подколками. Были трудности, но в результате добились стабильной работы. Но харизматичную хозяйку ушли, потому как сопротивлялась. Делили команды, чтобы внутри конфликтов не было. И, все-таки оценив реальные сроки разработки по результатам итераций инвесторы компанию закрыли…
Кривая — разработчики нечто сдали тестировщикам. а тестировщики — не признавали этого и не принимали продукт.
На старте было 2+7+3 в конце — 1+5+1 с той же производительностью. Я: вполне понятно по Белбину.
Смотреть приятно, ибо тут самое приятное, что может быть — чужие эпические провалы. И дело не только в этом, ведь должен быть кто-то, кто кроме Success Stories, проведет и посмертное вскрытие («Больной перед смертью потел? — Это хорошо»). А то действительно, возникают мифы об Agile, как мифы о дельфинах, толкающих утопающих к берегу (очевидно те бедолаги, которых они толкали в другую сторону — ничего не расскажут).
Тут конечно, SCRUM не виноват.
Возможно тут даже не виноват Александр Лесневский, хотя его я помню по докладу
SEC(R) 2007: Отчет Стаса Фомина#Разработка Web 2.0 ресурса: позиционирование, методика управления проектом, технологические решения, об очередном видеохостинге (который почему-то правда еще не закрыт и вяло тухнет несколько лет), и возможно умирающие проекты — это его карма.
Скорее всего, там все было плохо задолго до него.
Я помню и доклад с говорящим названием «Хроники окопной войны» на РИТ-2010 (см. также отчет Виталия), был от пред-предыдущего замдиректора этой компании, и тоже про эту проклятую компанию, основная проблема которой — они так и не смогли раздобыть третьего заказчика.
Говорят, что 10 способов про… деньги инвестора в интернет-проекте, это тоже про них.
И когда выяснилось, что даже собственно Agile со SCRUMом (от лучших скрамоводов SCRUMTrekа) и самыми жадными алгоритмами удовлетворения заказчика не могут ничего поправить, решено было эту хромую лошадь пристрелить.
Внимание! Эта статья была создана путем автоматического реплицирования из внутренней базы знаний компании Заказные Информ Системы. Любые правки этой статьи могут быть перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».