Меня недавно спросили, можно ли использовать Scrum вне сферы разработки ПО.
Скажем в отделе маркетинга.
Буду рад узнать мнение и опыт людей, которые это пробовали.
Вот мои мысли:
Scrum можно использовать для ведения любых проектов, не только по разработки
ПО. Так как он не включает в себя никаких (!) инженерных практик.
Есть ряд проектных характеристик, когда его использование оправдано (которые
часто присутствуют в проектах разработки ПО), это:
- наличие двух заинтересованных сторон( заказчика и команды)
- возможность и интерес к долгосрочному планированию проекта (планирование
релизов, прогнозирование объема работ vs времени)
- возможность выделить небольшие периоды одной длины, когда команда работает
над спланированными задачи, имеющими общую цель, и минимально отвлекается на
незапланированные работы (итеративно-инкрементальная разработка)
Таким образов Scrum нельзя применить на проекте, где поток задач полностью
непредсказуем (к примеру тех поддержка). Либо же, если нет интереса к
долгосрочному планированию, то выгоды от Scrum будут не так очевидны.
Имея же перечисленные хакартеристики в каком-либо проекте, вы можете
применить Scrum как подход согласования интересов сторон, ведения и
прогнозирования проекта. В плановой работе маркетинг отдела, я уверен, Scrum
можно внедрить со всеми вытекающими выгодами.
Честно говоря, буквально сегодня вспоминал в разговоре мой опыт "руководства" проектом по ремонту своей квартиры.
В какой-то момент, я был вынужден взять руководство в свои руки и самостоятельно раздавать задания "ремонтникам" дабы завершить ремонт хоть как-то. Поэтому в итоге у меня было: 1. Очень Заинтересованный Заказчик (т.е. я сам) и команда (ремонтники) 2. Product Backlog (т.е. достаточно долгосрочный список работ примерно на месяц) 3. Итерации длинной в неделю.
В итоге за 2-3 итерации я добился нужных мне результатов и после этого объявил ремонт "законченным". Правда это было после того как они больше 2х месяцев работали в каком-то "спонтанном" режиме и их прораб (проджект менеджер?) показал свою полную несостоятельность :-(
Я пишу все это к тому, что я полностью согласен с идеей того, что SCRUM подходит не только для IT - это вопрос наличия "здравого смысла" и желания получить что-то конкретное и законченное.
Ну и приведенные тобой характеристики достаточно точно отображают минимальные необходимые требовния для внедрения. Правда я бы добавил еще один не маловажный пункт: - наличие команды, желающей и способной понять основные принципы и следовать им.
Хотя, может в других сферах проще? Типа можно начать внедрять "сверху", силой воли руководителя, а там глядишь все втянутся и подхватят ритм :-) Нужно у кого-то спросить.
АУ, HRы, маркетологи и все остальные non-IT профессии - есть желание попробовать жить и работать по другому? Думаю сможем научить при необходимости :-)
On 08/01/2008, Alexey <alexeykrivit...@gmail.com> wrote:
> Меня недавно спросили, можно ли использовать Scrum вне сферы разработки > ПО. Скажем в отделе маркетинга.
> Буду рад узнать мнение и опыт людей, которые это пробовали.
> Вот мои мысли:
> Scrum можно использовать для ведения любых проектов, не только по > разработки ПО. Так как он не включает в себя никаких (!) инженерных практик.
> Есть ряд проектных характеристик, когда его использование оправдано > (которые часто присутствуют в проектах разработки ПО), это:
> - наличие двух заинтересованных сторон( заказчика и команды)
> - возможность и интерес к долгосрочному планированию проекта (планирование > релизов, прогнозирование объема работ vs времени)
> - возможность выделить небольшие периоды одной длины, когда команда > работает над спланированными задачи, имеющими общую цель, и минимально > отвлекается на незапланированные работы (итеративно-инкрементальная > разработка)
> Таким образов Scrum нельзя применить на проекте, где поток задач полностью > непредсказуем (к примеру тех поддержка). Либо же, если нет интереса к > долгосрочному планированию, то выгоды от Scrum будут не так очевидны.
> Имея же перечисленные хакартеристики в каком-либо проекте, вы можете > применить Scrum как подход согласования интересов сторон, ведения и > прогнозирования проекта. В плановой работе маркетинг отдела, я уверен, Scrum > можно внедрить со всеми вытекающими выгодами.
- производство на потоке не нуждается в агайле - как часто меняется рецептура кефира или требования к ёлочным игрушкам?. - производство на заказ (мебель) тоже агайлом быть особо не может - дотачивание напильником по месту не в счёт и по-большому счёту агайлом считаться не может. - вообще любое производство чего-то материального очень сложно агайлится... кроме случаев, когда что-то собирается из кубиков lego :)
С другой стороны HR, маркетинг, реклама, PR - короче взаимодействия с людями - непредсказуемы с точки зрения "done" или "velocity" - пойдите в свой отдел HR и скажите "мне надо 4 явиста". Очень навряд ли вам скажут, что будут находить по 1му явисту в неделю и за 4 недели управятся - скажут, что месяца 2-3 и будут, но когда точно неясно. Другими словами, чтобы спринты были осмысленными в этих сферах, они должны быть длиной в 2-4 месяца.
С другой стороны есть много сфер деятельности пересекающиеся с разработкой ПО, которые в теории хорошо SCRUMятся - дизайн (разный), производство роликов (фильмов, фонограмм), написание сценариев
Короче подвожу мысль к завершению: *для применения SCRUM'а (и прочих агайл-методик) подходят любые интеллектуальные производства "нематериальных" сущностей.* именно производство сущностей (т.е. не реклама, не маркетинг, не ПР) и именно нематериальных (чтобы можно было менять, иначе зачем агайл?).
кстати про "прочие агайл-методики" - "парное программирование" уже давным давно применяется в написании сценариев для сериалов...
> - производство на потоке не нуждается в агайле - как часто меняется > рецептура кефира или требования к ёлочным игрушкам?.
> Автомобили - производство на потоке ?
Продукционная система Тойота (согласен заранее, что лин, а не аджайл) - но основополагающие принципы те же.
> - производство на заказ (мебель) тоже агайлом быть особо не может - > дотачивание напильником по месту не в счёт и по-большому счёту агайлом > считаться не может. > - вообще любое производство чего-то материального очень сложно > агайлится... кроме случаев, когда что-то собирается из кубиков lego :)
> Можно узнать, что понимается под агайлингом ? > С другой стороны HR, маркетинг, реклама, PR - короче взаимодействия с > людями - непредсказуемы с точки зрения "done" или "velocity" - пойдите в > свой отдел HR и скажите "мне надо 4 явиста". Очень навряд ли вам скажут, что > будут находить по 1му явисту в неделю и за 4 недели управятся - скажут, что > месяца 2-3 и будут, но когда точно неясно. Другими словами, чтобы спринты > были осмысленными в этих сферах, они должны быть длиной в 2-4 месяца.
В маркетинге планируються маркетинговые компании. И там средства планирования и тракинга (типа беклога) является достаточно адекватными для определенного размера команд, для которых делается планирование.
Поэтому мне кажеться, что имеет смысл говорить об определенных задачах
> С другой стороны есть много сфер деятельности пересекающиеся с разработкой > ПО, которые в теории хорошо SCRUMятся - дизайн (разный), производство > роликов (фильмов, фонограмм), написание сценариев
> Короче подвожу мысль к завершению: *для применения SCRUM'а (и прочих > агайл-методик) подходят любые интеллектуальные производства "нематериальных" > сущностей.* > именно производство сущностей (т.е. не реклама, не маркетинг, не ПР) и > именно нематериальных (чтобы можно было менять, иначе зачем агайл?).
А не лучше ли провести различие по линии конструирование/ массовое производство?
Итеративная/инкрементальная разработка с тестированием результатов - разумная стратегия для разработки/тестирования новой продукции, зависящая, скорее от того, насколько быстро можно получить обратную связь, и насколько дорого стоит получение обратной связи / и ее отсутсвие.
Может быть, вопрос стоит сформулировать следующим образом : При каких условиях вы бы никогда не примяняли аджайл методы ?
Какие базовые предпосылки для применения аджайл методов ?
При каких условиях эмпирический контроль является более оправданным, чем использование определенного (defined) процесса? При каких условиях четко определенные процессы являються предпочтительными, чем использование эмпирического контроля?
> > моё мнение такое, что можно, но мало где нужно:
> > - производство на потоке не нуждается в агайле - как часто > > меняется рецептура кефира или требования к ёлочным игрушкам?.
> > Автомобили - производство на потоке ? > Продукционная система Тойота (согласен заранее, что лин, а не аджайл) - но > основополагающие принципы те же.
> > - производство на заказ (мебель) тоже агайлом быть особо не может > > - дотачивание напильником по месту не в счёт и по-большому счёту агайлом > > считаться не может. > > - вообще любое производство чего-то материального очень сложно > > агайлится... кроме случаев, когда что-то собирается из кубиков lego :)
> > Можно узнать, что понимается под агайлингом ?
> > С другой стороны HR, маркетинг, реклама, PR - короче взаимодействия с > > людями - непредсказуемы с точки зрения "done" или "velocity" - пойдите в > > свой отдел HR и скажите "мне надо 4 явиста". Очень навряд ли вам скажут, что > > будут находить по 1му явисту в неделю и за 4 недели управятся - скажут, что > > месяца 2-3 и будут, но когда точно неясно. Другими словами, чтобы спринты > > были осмысленными в этих сферах, они должны быть длиной в 2-4 месяца.
> В маркетинге планируються маркетинговые компании. > И там средства планирования и тракинга (типа беклога) является достаточно > адекватными для определенного размера команд, для которых делается > планирование.
> Поэтому мне кажеться, что имеет смысл говорить об определенных задачах
> > С другой стороны есть много сфер деятельности пересекающиеся с > > разработкой ПО, которые в теории хорошо SCRUMятся - дизайн (разный), > > производство роликов (фильмов, фонограмм), написание сценариев
> > Короче подвожу мысль к завершению: *для применения SCRUM'а (и прочих > > агайл-методик) подходят любые интеллектуальные производства "нематериальных" > > сущностей.* > > именно производство сущностей (т.е . не реклама, не маркетинг, не ПР) и > > именно нематериальных (чтобы можно было менять, иначе зачем агайл?).
> А не лучше ли провести различие по линии конструирование/ массовое > производство?
> Итеративная/инкрементальная разработка с тестированием результатов - > разумная стратегия для разработки/тестирования новой продукции, зависящая, > скорее от того, насколько быстро можно получить обратную связь, и насколько > дорого стоит получение обратной связи / и ее отсутсвие.
> Может быть, вопрос стоит сформулировать следующим образом : > При каких условиях вы бы никогда не примяняли аджайл методы ?
> Какие базовые предпосылки для применения аджайл методов ?
> > кстати про "прочие агайл-методики" - "парное программирование&q
