Аннотация
- Докладчик
- Александр Лесневский
Иногда все идет как по писаному, иногда сталкиваешься с трудностями и препятствиями, объяснение которым находится не сразу, и способы преодоления которых не лежат на поверхности.
Об отрицательном опыте говорят не часто....
В докладе будет поведано об истории внедрения 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а) и самыми жадными алгоритмами удовлетворения заказчика не могут ничего поправить, решено было эту хромую лошадь пристрелить.
Внимание! Данная статья выбрана для репликации во внешнюю базу знаний компании. Пожалуйста, не допускайте в этой статье публикацию конфиденциальной информации, ведения обсуждений в теле статьи, и более ответственно относитесь к качеству самой статьи — проверяйте орфографию, пишите по-русски, избегайте непроверенной вами информации.
