Comments 30
Не хотел бы преуменьшать ваших заслуг в области пересказа содержания книги, но недавно уже была рецензия на эту же книгу — megamozg.ru/post/21106
P.S. кстати, прочитал и не могу рекомендовать. Уж лучше «scrum и xp заметки с передовой» — воды и лирики меньше, конкретики и пользы больше.
P.S. кстати, прочитал и не могу рекомендовать. Уж лучше «scrum и xp заметки с передовой» — воды и лирики меньше, конкретики и пользы больше.
Вы дали ссылку на рецензию, т.е. на субъективное мнение читателя о книге.
В нашем посте мы опубликовали все ключевые идеи данной книги. Объективно. Без какой-либо привязки нашего мнения о ней.
По-поводу воды в книге совершенно с Вами согласен. Очень много отвлеченных примеров и рассказов из жизни. Во время чтения книги я все задавал себе вопрос: «Когда же автор все-таки начнет писать про scrum ?» )
В этом и недостаток нон-фикшн книг.
В нашем посте мы опубликовали все ключевые идеи данной книги. Объективно. Без какой-либо привязки нашего мнения о ней.
По-поводу воды в книге совершенно с Вами согласен. Очень много отвлеченных примеров и рассказов из жизни. Во время чтения книги я все задавал себе вопрос: «Когда же автор все-таки начнет писать про scrum ?» )
В этом и недостаток нон-фикшн книг.
Посоветуйте пожалуйста историй из РЕАЛЬНОЙ жизни в РОССИИ с факапами, людьми и историями.
Чтобы без смузи и фотографий из фотобанков.
Чтобы без смузи и фотографий из фотобанков.
Книга ок.
Но лучше продумать недостатки scrum-подхода к управлению проектами.
Но лучше продумать недостатки scrum-подхода к управлению проектами.
А в чем Вы видите недостатки данного подхода?
Мы в команде их пока не заметили. И было бы интересно узнать Ваше мнение.
Мы в команде их пока не заметили. И было бы интересно узнать Ваше мнение.
C ходу: Низкая эффективность при наличии четко определенных требований. Легко «поломать», если участники (хотя бы один) не разделяют важности периодических мероприятий или 100% выполнения спринта. Заказчики очень долго привыкают к такому подходу — первая итерация всегда крайне болезненна. Заказчик, если требования меняются динамичнее, будет против фиксации состава sprint backlog. «Мы не используем наркоз, так как у нас Scrum-хирургия. Мы будем постоянно получать от вас обратную связь, особенно в первую итерацию».
Если рассматривать Скрам как механизм, то он очень требователен к предварительной настройке и к условиям эксплуатации. Почти так же, как древние автомобили по-сравнению с современными.
Поверьте сперва, что я фанат аджайла, и очень его люблю и ценю.
Также поверьте в то, что я готов высосать глаза через нос любому недомерку, который начнет говорить, что «если у вас скрам не работает, значит, вы неправильно его применяете». Пожалуйста, не говорите так никому и никогда, уважайте труд уборщицы.
К делу: у нас большая компания, делаем веб-магазины на основе нескольких платформ (это уже не первая компания подобного типа, в которой я работаю). Можем сравнить это со станцией тех-обслуживания, где собирают новые машины из деталек. Вроде бы все по-шаблону, но в каждом проекте или «что-то новое», или «что-то уникальное», бо веб-магазин сам по себе не имеет смысла, его надо интегрировать в уже работающую инфраструктуру клиента, отсюда постоянная нужда в программистах, тестировщиках да дизайнерах…
Скрам на проектах в кмопании применяется в разных пропорциях и видах. Где-то он был насильно внедрен «так хочет клиент», где-то до него доросли, где-то просто «решили попробовать».
Итак, какие обнаружились сложности и недостатки у скрама в глобальном плане:
Для начала необходимо выбрать «Владельца продукта» — человека, обладающего видением того, что вы собираетесь создать или достигнуть.
Это кто? Владелец продукта — глава совета директоров компании Adidas подходит на эту роль? Мы для адидаса магазины делали, например. Кто их владелец?
В учениях про аджайл в контексте product owner указывают на человека, к которому все члены команды имеют прямой доступ. И хорошо, мол, если он сидит прямо рядом с командой.
А ему там нужно сидеть, бо он нужен всем и в качестве источника принятия решений, и как замена всему тому, что мы называем «исчерпывающая документация» — требования, тесты, вот это вот всё.
Мы получаем на вход рассказы о том, как и что должно работать, затем сами решаем, как это будет реализовано (я тестировщик, поэтому в этот момент у меня генерируется плевательный яд, бо без ТЗ результат действительно ХЗ, тесты не на чем обосновывать), и постоянно нуждаемся в советах и корректировке относительно того, что и как МОЖЕТ и ДОЛЖНО быть реализовано.
Рассмотрите классическое "Я могу скормить банкомату мою карту и проверить количество денег на счету" — а как именно это делать? Приплясывать перед видеокамерой? Читать Упанишады в микрофон? Нажимать на клавиши на дисплее, или на клавиши на клавиатуре (ВНЕЗАПНО, клавиши в банкоматах и по краям дисплея, но и на передней панели, и они друг друга не дублируют). Можно всё. Что мы выберем? Кто это выберет? Кто возьмет на себя ответственность о принятии последнего решения? Вся команда, бо все должны быть самостоятельны в принятии решений? Нужен если не аналитик, то менеджер, который…
Внезапно, скрам-команде нужен менеджер…
И аналитик, чтобы требования продумывал. И еще аналитик, который будет продуманные требования записывать.
Затем нужно собрать «Команду», в которую войдут люди, непосредственно выполняющие работу. Они должны обладать навыками и знаниями, которые помогут воплотить идею владельца продукта в жизнь.
А еще они должны быть кроссфункциональны. Заболеет программист — не беда, я возьмусь за клавиатуру. Не надо? Но… мы же… кроссфункц…
Ладно, что кроссфункциональны… Члены команды должны быть самостоятельны в принятии решений. Но в нашей культуре? В нашем менталитете «стоять за всех, своих не сдавать, начальникам не жаловаться»???
На западе действительно бывает сложно собрать единую команду из одиночек. Это доблесть для менеджера. Когда с детства каждый сам за себя, выживает сильнейший/хитрейший (пресловутое предложение «сообщайте нам о всех непорядках, которые заметите у ваших коллег, а им об этом сообщать не надо»), тогда действительно сложно собрать команду. Про это пишут книги, там это действительно сложная задача.
У нас менталитет с детства иной, у нас «команда против менеджера», ее собирать незачем, ей нужно уметь управлять. Нужно учиться ее не бояться, например. Нужно понимать, что решения командира все рассматривают как паттерны поведения, которые можно/нужно предусмотреть, использовать для своих нужд, да и просто взломать, если понадобится.
Неоднократно наблюдал, как западные (у нас других нет) заказчики не понимали, почему «команда не работает», «почему они все знают зарплаты друг друга», «почему они всегда замалчивают проблемы» — не уверен, что это нужно объяснять всем западным заказчикам, но понимать всё это им было бы полезно. Мы же учимся взаимодействовать с ними в разрезе культурных разниц.
Нужно выбрать «Скрам-мастера» — того, кто будет следить за ходом реализации проекта, обеспечивать проведение коротких собраний и помогать команде устранять препятствия на пути достижения цели.
Ну да, нам нужен политрук. Или парторг. С сертификатом парторга.
Ибо у нас групповой менталитет-с. Вот в западном менталитете без скрам-мастера действительно сложно.
Приступая к работе, нужно создать максимально полный список всех требований, предъявляемых к продукту или цели. Пункты этого списка должны быть расставлены по приоритету. Список носит название «Бэклог продукта». Он может развиваться и изменяться на протяжении всего срока реализации проекта.
Чота ржу, извините.
Бэклог — это те же «требования». Кто их продумывает и заранее записывает? Вы умеете работать с требованиями? Вам знаком эффект «чем больше и детальнее продумываешь требования, тем сильнее их количество стремится к бесконечности», а ведь это только требования, мы еще про их тестирование не подумали — знакомо?
Вам еще не нужен выделенный аналитик?
Участники команды должны оценить по своей системе оценок каждый пункт на предмет сложности и затрат, которые потребуются для его выполнения.
Это да, это надо делать. Но личностно, а не коллективно (менталитет).
После показа результатов работы за спринт участники проводят ретроспективное собрание, на котором обсуждают, что команда делала хорошо, что можно сделать лучше, что можно улучшить прямо сейчас.
Ретроспектива — прекраснейший инструмент. Нужнейший. Она не только скраму присуща. В некоторых журналистских коллективах ретроспектива каждого номера не только рулит, но и по-настоящему полезна всем. В армии после боя полезно всем выжившим собраться и вслух порассуждать о том, почему они выжили. Что полезного сделали? Что делать и в будущем?
У нас ретроспективы поначалу проводятся очень активно и воодушевленно, но чем дальше, тем их меньше.
Пример (из неоднократно наблюдаемого):
Знакомо?
Ибо менталитет-с. Не та почва, на которой скрам произрастал.
Планы рассыпаются в прах. Альтернатива — это Scrum
Эй, когда мы в спринт берем какие-то задачи — это тоже планирование! И эти планы тоже в прах обертаются.
Напоминаю, что я фанат аджайла, и очень его люблю и ценю.
Также напоминаю про высасывание глаз через нос.
Поверьте сперва, что я фанат аджайла, и очень его люблю и ценю.
Также поверьте в то, что я готов высосать глаза через нос любому недомерку, который начнет говорить, что «если у вас скрам не работает, значит, вы неправильно его применяете». Пожалуйста, не говорите так никому и никогда, уважайте труд уборщицы.
К делу: у нас большая компания, делаем веб-магазины на основе нескольких платформ (это уже не первая компания подобного типа, в которой я работаю). Можем сравнить это со станцией тех-обслуживания, где собирают новые машины из деталек. Вроде бы все по-шаблону, но в каждом проекте или «что-то новое», или «что-то уникальное», бо веб-магазин сам по себе не имеет смысла, его надо интегрировать в уже работающую инфраструктуру клиента, отсюда постоянная нужда в программистах, тестировщиках да дизайнерах…
Скрам на проектах в кмопании применяется в разных пропорциях и видах. Где-то он был насильно внедрен «так хочет клиент», где-то до него доросли, где-то просто «решили попробовать».
Итак, какие обнаружились сложности и недостатки у скрама в глобальном плане:
Для начала необходимо выбрать «Владельца продукта» — человека, обладающего видением того, что вы собираетесь создать или достигнуть.
Это кто? Владелец продукта — глава совета директоров компании Adidas подходит на эту роль? Мы для адидаса магазины делали, например. Кто их владелец?
В учениях про аджайл в контексте product owner указывают на человека, к которому все члены команды имеют прямой доступ. И хорошо, мол, если он сидит прямо рядом с командой.
А ему там нужно сидеть, бо он нужен всем и в качестве источника принятия решений, и как замена всему тому, что мы называем «исчерпывающая документация» — требования, тесты, вот это вот всё.
Мы получаем на вход рассказы о том, как и что должно работать, затем сами решаем, как это будет реализовано (я тестировщик, поэтому в этот момент у меня генерируется плевательный яд, бо без ТЗ результат действительно ХЗ, тесты не на чем обосновывать), и постоянно нуждаемся в советах и корректировке относительно того, что и как МОЖЕТ и ДОЛЖНО быть реализовано.
Рассмотрите классическое "Я могу скормить банкомату мою карту и проверить количество денег на счету" — а как именно это делать? Приплясывать перед видеокамерой? Читать Упанишады в микрофон? Нажимать на клавиши на дисплее, или на клавиши на клавиатуре (ВНЕЗАПНО, клавиши в банкоматах и по краям дисплея, но и на передней панели, и они друг друга не дублируют). Можно всё. Что мы выберем? Кто это выберет? Кто возьмет на себя ответственность о принятии последнего решения? Вся команда, бо все должны быть самостоятельны в принятии решений? Нужен если не аналитик, то менеджер, который…
Внезапно, скрам-команде нужен менеджер…
И аналитик, чтобы требования продумывал. И еще аналитик, который будет продуманные требования записывать.
Затем нужно собрать «Команду», в которую войдут люди, непосредственно выполняющие работу. Они должны обладать навыками и знаниями, которые помогут воплотить идею владельца продукта в жизнь.
А еще они должны быть кроссфункциональны. Заболеет программист — не беда, я возьмусь за клавиатуру. Не надо? Но… мы же… кроссфункц…
Ладно, что кроссфункциональны… Члены команды должны быть самостоятельны в принятии решений. Но в нашей культуре? В нашем менталитете «стоять за всех, своих не сдавать, начальникам не жаловаться»???
На западе действительно бывает сложно собрать единую команду из одиночек. Это доблесть для менеджера. Когда с детства каждый сам за себя, выживает сильнейший/хитрейший (пресловутое предложение «сообщайте нам о всех непорядках, которые заметите у ваших коллег, а им об этом сообщать не надо»), тогда действительно сложно собрать команду. Про это пишут книги, там это действительно сложная задача.
У нас менталитет с детства иной, у нас «команда против менеджера», ее собирать незачем, ей нужно уметь управлять. Нужно учиться ее не бояться, например. Нужно понимать, что решения командира все рассматривают как паттерны поведения, которые можно/нужно предусмотреть, использовать для своих нужд, да и просто взломать, если понадобится.
Неоднократно наблюдал, как западные (у нас других нет) заказчики не понимали, почему «команда не работает», «почему они все знают зарплаты друг друга», «почему они всегда замалчивают проблемы» — не уверен, что это нужно объяснять всем западным заказчикам, но понимать всё это им было бы полезно. Мы же учимся взаимодействовать с ними в разрезе культурных разниц.
Нужно выбрать «Скрам-мастера» — того, кто будет следить за ходом реализации проекта, обеспечивать проведение коротких собраний и помогать команде устранять препятствия на пути достижения цели.
Ну да, нам нужен политрук. Или парторг. С сертификатом парторга.
Ибо у нас групповой менталитет-с. Вот в западном менталитете без скрам-мастера действительно сложно.
Приступая к работе, нужно создать максимально полный список всех требований, предъявляемых к продукту или цели. Пункты этого списка должны быть расставлены по приоритету. Список носит название «Бэклог продукта». Он может развиваться и изменяться на протяжении всего срока реализации проекта.
Чота ржу, извините.
Бэклог — это те же «требования». Кто их продумывает и заранее записывает? Вы умеете работать с требованиями? Вам знаком эффект «чем больше и детальнее продумываешь требования, тем сильнее их количество стремится к бесконечности», а ведь это только требования, мы еще про их тестирование не подумали — знакомо?
Вам еще не нужен выделенный аналитик?
Участники команды должны оценить по своей системе оценок каждый пункт на предмет сложности и затрат, которые потребуются для его выполнения.
Это да, это надо делать. Но личностно, а не коллективно (менталитет).
После показа результатов работы за спринт участники проводят ретроспективное собрание, на котором обсуждают, что команда делала хорошо, что можно сделать лучше, что можно улучшить прямо сейчас.
Ретроспектива — прекраснейший инструмент. Нужнейший. Она не только скраму присуща. В некоторых журналистских коллективах ретроспектива каждого номера не только рулит, но и по-настоящему полезна всем. В армии после боя полезно всем выжившим собраться и вслух порассуждать о том, почему они выжили. Что полезного сделали? Что делать и в будущем?
У нас ретроспективы поначалу проводятся очень активно и воодушевленно, но чем дальше, тем их меньше.
Пример (из неоднократно наблюдаемого):
— Значит, во вторних рухнула база, и мы не успели… А почему? А это у нас Дениска ковырялся, и потёр конфиги. Иди,сукаДениска, сюда. Иди и всем пообещай, что больше ты так делать не будешь…
— (утирая слезы) Товарищи! Да я! Я обязуюсь! Отныне и впредь! Всегда!
— Иди, товарищ. Мы верим в то, что ты искренне раскаялся перед коллективом...
Знакомо?
Ибо менталитет-с. Не та почва, на которой скрам произрастал.
Планы рассыпаются в прах. Альтернатива — это Scrum
Эй, когда мы в спринт берем какие-то задачи — это тоже планирование! И эти планы тоже в прах обертаются.
Напоминаю, что я фанат аджайла, и очень его люблю и ценю.
Также напоминаю про высасывание глаз через нос.
Пожалуйста, напишите отдельную статью. Очень интересное.
С удовольствием прочитал Ваш комментарий и личные впечатления о Scrum.
Спасибо большое!
Спасибо большое!
Немного типичных заблуждений о скраме:
1) Кроссфункциональность — это на уровне всей команды, а не каждого человека. Тестировщик не должен программировать вместо заболевшего программиста.
2) Скрам мастер должен быть выделенным человеком. Лучше всего «девочка» с гуманитарным образованием. Она отвечает за скрам-процессы и климат в коллективе. При это не принимает решений по сути. Идея в том, что не нужно делать из хорошего программиста плохого менеджера или скрам-мастера, а лучше его оставить программистом и взять отдельного человека в отдельную иерархию.
3) Владелец продукта готовит беклог и отвечает на миллиард вопросов ежедневно. Часто у него бывает своя команда. Там аналитики, дизайнеры и прочие маркетологи. Вопрос в том, что скрам не делался для заказной разработки проектов, а делался для длительной разработки продуктов. При заказной разработке владельца продукта и его команду нужно придумывать как отдельную структуру внутри фирмы-подрядчика.
4) Размер беклога не проблема. Проблема его отсортировать в порядке важности/очередности. Это даже хорошо, что заказчик видит, что еще есть что улучшать. Может, дозакажет сейчас или потом.
5) В самом скраме как именно оценивать не говорится. Предполагается, что как-то в чем-то каждый лично оценивает. Причем скрытно от других членов команды. Потом люди, давшие мин и макс оценки обсуждают почему у них такое расхождение. Это просто разная скорость или учтены разные вещи?
6) Разбор проблем на ретроспективе должен идти не поверхностно (покайся Дениска), а на несколько уровней вглубь (как сделать так, чтобы проблема в принципе не могла повториться; например, автодеплой на сервера).
7) Если планы рассыпаются в прах, то либо сработало слишком много рисков и на них заложили меньше времени, либо изначальные оценки были неверными (не разбиты задачи или оценки выполнения задач для senior, а делали junior). Обе проблемы скрам не решает. Скрам решает проблему с тем, чтобы делали именно то, что нужно заказчику, а не что-то другое.
В общем, обычно пытаются запустить скрам без скрам-мастера (выделенного человека без права принятия решений) и владельца продукта (выделенного человека, который постоянно принимает решения по требованиям к продукту), поэтому получается что-то странное.
1) Кроссфункциональность — это на уровне всей команды, а не каждого человека. Тестировщик не должен программировать вместо заболевшего программиста.
2) Скрам мастер должен быть выделенным человеком. Лучше всего «девочка» с гуманитарным образованием. Она отвечает за скрам-процессы и климат в коллективе. При это не принимает решений по сути. Идея в том, что не нужно делать из хорошего программиста плохого менеджера или скрам-мастера, а лучше его оставить программистом и взять отдельного человека в отдельную иерархию.
3) Владелец продукта готовит беклог и отвечает на миллиард вопросов ежедневно. Часто у него бывает своя команда. Там аналитики, дизайнеры и прочие маркетологи. Вопрос в том, что скрам не делался для заказной разработки проектов, а делался для длительной разработки продуктов. При заказной разработке владельца продукта и его команду нужно придумывать как отдельную структуру внутри фирмы-подрядчика.
4) Размер беклога не проблема. Проблема его отсортировать в порядке важности/очередности. Это даже хорошо, что заказчик видит, что еще есть что улучшать. Может, дозакажет сейчас или потом.
5) В самом скраме как именно оценивать не говорится. Предполагается, что как-то в чем-то каждый лично оценивает. Причем скрытно от других членов команды. Потом люди, давшие мин и макс оценки обсуждают почему у них такое расхождение. Это просто разная скорость или учтены разные вещи?
6) Разбор проблем на ретроспективе должен идти не поверхностно (покайся Дениска), а на несколько уровней вглубь (как сделать так, чтобы проблема в принципе не могла повториться; например, автодеплой на сервера).
7) Если планы рассыпаются в прах, то либо сработало слишком много рисков и на них заложили меньше времени, либо изначальные оценки были неверными (не разбиты задачи или оценки выполнения задач для senior, а делали junior). Обе проблемы скрам не решает. Скрам решает проблему с тем, чтобы делали именно то, что нужно заказчику, а не что-то другое.
В общем, обычно пытаются запустить скрам без скрам-мастера (выделенного человека без права принятия решений) и владельца продукта (выделенного человека, который постоянно принимает решения по требованиям к продукту), поэтому получается что-то странное.
Если бы все было так просто.
«Scrum. Революционный метод управления проектами»
Скорее всего, это подходит к проектам малого уровня.
Я пилотирую промышленные проекты серьезного уровня (10+М€), к ним скрам/ажиль итд просто неприменимы. Нужно четкое планирование, диаграммы Ганта, комитеты пилотажа, итд итп. Внешних каналов больше сотни (клиент, его прожект менеджеры, поставщики, субподрядчики, внутренние отделы продаж, закупок, логистики и так далее). Как этим можно управлять скрам командой в 7 человек? Никак.
«Scrum. Революционный метод управления проектами разработки программного обеспечения малых и средних масштабов» — может так стоило автору назвать книгу?
Скорее всего, это подходит к проектам малого уровня.
Я пилотирую промышленные проекты серьезного уровня (10+М€), к ним скрам/ажиль итд просто неприменимы. Нужно четкое планирование, диаграммы Ганта, комитеты пилотажа, итд итп. Внешних каналов больше сотни (клиент, его прожект менеджеры, поставщики, субподрядчики, внутренние отделы продаж, закупок, логистики и так далее). Как этим можно управлять скрам командой в 7 человек? Никак.
«Scrum. Революционный метод управления проектами разработки программного обеспечения малых и средних масштабов» — может так стоило автору назвать книгу?
В книге без особых подробностей автор рассказывает, что якобы применял скрам в том числе для многомиллиардных проектов на несколько лет длинной (в том числе для ФБР).
Если же обратиться к другой, более практичной литературе, вроде упомянутого мною «scrum и xp заметки с передовой», то для больших проектов рекомендуется использовать скрам скрамов (т.е. когда команды объединяются в нечто вроде нейросети).
На самом деле, я тоже несколько скептически смотрю на всё это дело…
Не знаю, тут надо смотреть реальные кейсы в подробностях, окунаться в такое производство. А то может у них там не скрам, а звездец и хаос просто.
Если же обратиться к другой, более практичной литературе, вроде упомянутого мною «scrum и xp заметки с передовой», то для больших проектов рекомендуется использовать скрам скрамов (т.е. когда команды объединяются в нечто вроде нейросети).
На самом деле, я тоже несколько скептически смотрю на всё это дело…
Не знаю, тут надо смотреть реальные кейсы в подробностях, окунаться в такое производство. А то может у них там не скрам, а звездец и хаос просто.
Скрам срамов… ради чего? Ради скрама, разве что…
Проецируя на мой опыт в промышленности (производство высокоточных станков для ВПК), я не могу представить применение скрама. Есть определенные требования контракта по ведению проекта, в том числе и майлстоуны, на которые завязаны транши оплаты. Не могу себе представить, как это можно делать с вайтбоардом со стикерами без диаграмм Гантта. А если бы и мог, то как убедить клиента из ВПК, что этот метод будет лучше, чем проверенный годами. Это не только подвергнет риску контракт, но и уронит лицо компании на и так уже нишевом рынке.
Поэтому я и думаю, что громкое название книги применимо только к производству ПО/веб проектам малого уровня.
Проецируя на мой опыт в промышленности (производство высокоточных станков для ВПК), я не могу представить применение скрама. Есть определенные требования контракта по ведению проекта, в том числе и майлстоуны, на которые завязаны транши оплаты. Не могу себе представить, как это можно делать с вайтбоардом со стикерами без диаграмм Гантта. А если бы и мог, то как убедить клиента из ВПК, что этот метод будет лучше, чем проверенный годами. Это не только подвергнет риску контракт, но и уронит лицо компании на и так уже нишевом рынке.
Поэтому я и думаю, что громкое название книги применимо только к производству ПО/веб проектам малого уровня.
Я думаю, вы согласитесь, что есть много вещей, которые мы не можем себе даже представить (и тем более не можем представить себе их применение) пока не окунёмся в реальный пример.
Я вот тоже пока учился в ВУЗе не мог до конца понять КПУ, дозиметрию, курс элементарных частиц, кванты и т.п.
Не сказать чтобы понимание всех этих вещей пришло ко мне после полутора лет на реальном предприятии. Но понимание некоторых других (так же первоначально загадочных и абсолютно казалось бы глупых) появилось.
Опыт удивительная штука и творит чудеса.
Сейчас я работаю с крупным заказчиком в невероятно странных условиях. Для меня тоже принципиальны сроки, майлстоуны и т.п.
Но я вот для себя решил раздвинуть горизонт изученного. Прочитал на данный момент 5 разных книг о гибких методологиях (в основном Scrum), прошёл пару курсов на Coursera, пообщался с людьми… И не то чтобы я смог перевести свой процесс на рельсы скрама — это действительно невозможно (пока по крайней мере так кажется), но ряд разумных мыслей я уловил. И несколько процессов, которые мы перевели на аналоги таковых из гиких методологий (Беклог, короткие итерации и т.п.) видны.
В общем, я против того чтобы подобно автору преподносить скрам, как серебряную пулю и кремлёвскую таблетку. Но присмотреться к нему и взять для себя небольшой набор полезных практик считаю правильным. Это никак не противоречит стандартам PMBOCK.
Я вот тоже пока учился в ВУЗе не мог до конца понять КПУ, дозиметрию, курс элементарных частиц, кванты и т.п.
Не сказать чтобы понимание всех этих вещей пришло ко мне после полутора лет на реальном предприятии. Но понимание некоторых других (так же первоначально загадочных и абсолютно казалось бы глупых) появилось.
Опыт удивительная штука и творит чудеса.
Сейчас я работаю с крупным заказчиком в невероятно странных условиях. Для меня тоже принципиальны сроки, майлстоуны и т.п.
Но я вот для себя решил раздвинуть горизонт изученного. Прочитал на данный момент 5 разных книг о гибких методологиях (в основном Scrum), прошёл пару курсов на Coursera, пообщался с людьми… И не то чтобы я смог перевести свой процесс на рельсы скрама — это действительно невозможно (пока по крайней мере так кажется), но ряд разумных мыслей я уловил. И несколько процессов, которые мы перевели на аналоги таковых из гиких методологий (Беклог, короткие итерации и т.п.) видны.
В общем, я против того чтобы подобно автору преподносить скрам, как серебряную пулю и кремлёвскую таблетку. Но присмотреться к нему и взять для себя небольшой набор полезных практик считаю правильным. Это никак не противоречит стандартам PMBOCK.
Думаю, что Scrum можно применять везде. Все зависит от желания и возможностей.
Сам автор в книге приводит примеры реализации методики в школах, политике, сельском хозяйстве, строительстве.
Т.е. таких сферах, в которых представить работу по scrum, в принципе, очень сложно.
Сам автор в книге приводит примеры реализации методики в школах, политике, сельском хозяйстве, строительстве.
Т.е. таких сферах, в которых представить работу по scrum, в принципе, очень сложно.
Можно, как и водопад, v-модель и т.д., только зачем? Каждая методика разрабатывалась для решения конкретных проблем управления проектами, если такие проблемы в проекте есть, методика помогает, если нет, то работает принцип «Лучше как-то управлять, чем не управлять».
> Думаю, что Scrum можно применять везде.
Когда у тебя в руках молоток, все задачи кажутся гвоздями. (с) Маслоу
Когда у тебя в руках молоток, все задачи кажутся гвоздями. (с) Маслоу
Если требования гарантированно не меняются и достаточно детальны для выполнения работ, то «гибкие методики» не нужны. Если заказчику не нужно проверять гипотезу, то SCRUM не поможет, а будет мешать. Обычно берут лучшее, например, строгое проектное управление по созданию новой модели самолета, при котором на ранних этапах «создание проекта самого большого самолета» :) (с фиксированными сроками и бюджетом) кроссфункциональные команды работают по скраму. Как только майлстоун достигнут скрам «выключают» и продолжают идти «по ганту».
А ведь есть очень крупные и длительные проекты в которых все требования могут существенно меняться ежемесячно, и это никак нельзя предусмотреть. Там и живут скрамы скрамов.
А ведь есть очень крупные и длительные проекты в которых все требования могут существенно меняться ежемесячно, и это никак нельзя предусмотреть. Там и живут скрамы скрамов.
Я тоже хотел отметить пример автора про ФБР.
У госструктуры был некий глобальный заказной проект на несколько миллиардов долларов.
Компания, взявшая проект, при анализе проекта использовала как раз те самые диаграммы Ганта, графики, отчеты и т.п.
Было распланировано все до мелочей: сроки, нагрузка, ресурсы.
Но по ходу реализации проекта начали возникать незапланированные заминки.
По итогам таких заминок проект задерживал срок сдачи на несколько лет.
И только внедрение скрам в команду разработчиков проекта помогло завершить проект с минимальными затратами.
Но я скорее соглашусь с Вами. Нет панацеи и единственно эффективной методики.
Все зависит от конкретного случая. Команды. Мотивации.
У госструктуры был некий глобальный заказной проект на несколько миллиардов долларов.
Компания, взявшая проект, при анализе проекта использовала как раз те самые диаграммы Ганта, графики, отчеты и т.п.
Было распланировано все до мелочей: сроки, нагрузка, ресурсы.
Но по ходу реализации проекта начали возникать незапланированные заминки.
По итогам таких заминок проект задерживал срок сдачи на несколько лет.
И только внедрение скрам в команду разработчиков проекта помогло завершить проект с минимальными затратами.
Но я скорее соглашусь с Вами. Нет панацеи и единственно эффективной методики.
Все зависит от конкретного случая. Команды. Мотивации.
Честно говоря пример с ФБР больше тянет на байку. Там очень много слишком сказочного автор описывает.
Даже при том, что я верю в эффективность scrum в отдельных проектах, в данном случае смахивает на враньё.
По крайней мере статья на ВИКИ больше похожа на рекламу — en.wikipedia.org/wiki/Sentinel_(FBI)
Даже при том, что я верю в эффективность scrum в отдельных проектах, в данном случае смахивает на враньё.
По крайней мере статья на ВИКИ больше похожа на рекламу — en.wikipedia.org/wiki/Sentinel_(FBI)
Скрам для продуктов, а не проектов. Если непонятно что на самом деле нужно сделать (требования постоянно меняются, приоритеты задач постоянно меняются, так что непонятно что будет делаться через 2 недели, при этом фиксируются обязательства на итерацию) — скрам идеален. Он тяжело масштабируется, но масштабируется (например, что-то в районе 60 скрам-команд у аэрбэнби, 600 разработчиков за год съедают больше 10М чего угодно).
Когда изначально закладывается Скрам культура в процессе создания стартапа, то и масштабирование возможно.
Меня побудило написать свой первый комментарий именно то, что методология Скрам представлялась как панацея для всех проектов.
По поводу «продуктов, а не проектов». Создание продукта — это и есть проект. Создание сервиса — это тоже проект. Продажа и производство линии станков — это тоже проект. Только они очень разные, начиная с контекста, заканчивая требованиями заказчиков. Для сложных проектов, в которых поэтапная оплата завязана на майлстоуны, гибкость скрама просто неприменима. Невозможно планировать ни финансовые, ни производственные потоки, ориентируясь на доску с бэклогом.
Да, в процессе продвижения проекта всегда случаются задержки. Для этого нужно внедрять с самого начала риск менеджмент, закладывая маржу (производственных ресурсов, оборотных средств итд).
Я видел проекты, в которых изначально при подписании контракта закладывался график оплаты пени (штрафов) за просрочку поставки оборудования. То есть контракт подписывался, и уже было ясно, что производственные мощности не справляются. В результате, новый СЕО отдал на субподряд 95% производства, оставив на внутреннем производстве только узкоспецифичное know-how.
Как бы с этим справился Скрам, я не вижу.
Меня побудило написать свой первый комментарий именно то, что методология Скрам представлялась как панацея для всех проектов.
По поводу «продуктов, а не проектов». Создание продукта — это и есть проект. Создание сервиса — это тоже проект. Продажа и производство линии станков — это тоже проект. Только они очень разные, начиная с контекста, заканчивая требованиями заказчиков. Для сложных проектов, в которых поэтапная оплата завязана на майлстоуны, гибкость скрама просто неприменима. Невозможно планировать ни финансовые, ни производственные потоки, ориентируясь на доску с бэклогом.
Да, в процессе продвижения проекта всегда случаются задержки. Для этого нужно внедрять с самого начала риск менеджмент, закладывая маржу (производственных ресурсов, оборотных средств итд).
Я видел проекты, в которых изначально при подписании контракта закладывался график оплаты пени (штрафов) за просрочку поставки оборудования. То есть контракт подписывался, и уже было ясно, что производственные мощности не справляются. В результате, новый СЕО отдал на субподряд 95% производства, оставив на внутреннем производстве только узкоспецифичное know-how.
Как бы с этим справился Скрам, я не вижу.
Продукт — не проект. Раньше выделяли 2 типа активностей: процессы (постоянная деятельность, например бухгалтерия или работа точки МакДональдса) и проекты (уникальная деятельность, например, открытие точки МакДональдса). Сейчас появилось мнение, что развитие продукта — это ни то, ни другое (постоянная деятельность стратегически, уникальная деятельность тактически). Ближе к проектам, но не то. В продукте важна перспектива и определение направления развития, а не сдача изначального ТЗ в срок/бюджет/качество. Скрам — организационный фреймворк, который показывает как ПМа в продукте можно разделить на Product Owner и Scrum Master, кто за что отвечает при взаимодействии со stakeholders и командой, как вполне эффективно организовать процессы.
Поставка оборудования — это не продукт, тут Скрам не помошник. Более того, Скрам про разработку ПО, а не общую организацию деятельности. А вот если бы выводили новую линейку оборудования на рынок, то можно было бы как-то попытаться приспособить Скрам к этому, но, опять же, скорее к прошивке для оборудования, чем к самому оборудованию (из-за сложности изменения физического производства).
Поставка оборудования — это не продукт, тут Скрам не помошник. Более того, Скрам про разработку ПО, а не общую организацию деятельности. А вот если бы выводили новую линейку оборудования на рынок, то можно было бы как-то попытаться приспособить Скрам к этому, но, опять же, скорее к прошивке для оборудования, чем к самому оборудованию (из-за сложности изменения физического производства).
Уже давно придумано понятие программы (и кстати портфеля проектов) для тех случаев, когда управление выходит за рамке сроков, бюджета и стоимости. Скрам — это способ организации производства, как и любые другие методы организации процессов разработки. Проект и управление проектом — это способ организовать скрам или что бы то ни было на нужное время для нужного результата.
Я бы сказал скорее для продуктов среднего уровня в таком случае.
Лично я занимаюсь hardware разработкой. Не понимаю как организовать её под данной технологии в моих небольших проектах. Когда одни человек сразу и схемотехник и трассировщик, зачастую один программист по встраиваемым системам, один конструктор. А узкие специалисты — вообще нанимаются со стороны для решения конкретных задач. Кроме этого задержки и нюансы с поставкой компонентов, изготовления плат, косяки с их монтажом…
В проекте может участвовать команда и из пяти человек и больше, но SCRUM похоже не для нас. Зачастую каждый уникальный специалист, определённую работу может сделать только он и не кто другой и оценить время её выполнения остальным бывает сложно. Плюс к тому часть работы очень сильно зависит от внешних факторов. Так что для моего случая старая добрая диаграмма Ганта похоже незаменима.
Лично я занимаюсь hardware разработкой. Не понимаю как организовать её под данной технологии в моих небольших проектах. Когда одни человек сразу и схемотехник и трассировщик, зачастую один программист по встраиваемым системам, один конструктор. А узкие специалисты — вообще нанимаются со стороны для решения конкретных задач. Кроме этого задержки и нюансы с поставкой компонентов, изготовления плат, косяки с их монтажом…
В проекте может участвовать команда и из пяти человек и больше, но SCRUM похоже не для нас. Зачастую каждый уникальный специалист, определённую работу может сделать только он и не кто другой и оценить время её выполнения остальным бывает сложно. Плюс к тому часть работы очень сильно зависит от внешних факторов. Так что для моего случая старая добрая диаграмма Ганта похоже незаменима.
Команда должна постоянно стремиться к тому, чтобы превзойти в новом спринте количество наработанных баллов за предыдущий спринт, то есть ее цель — постоянно превосходить свои собственные результаты — «наращивать динамику производительности».
В результате наступает момент, когда практически все члены команды работают с 8 утра до 9 вечера. А дальше два варианта — или пахать без перерывов на сон, или бросить к чертям такую работу. В данный момент наша команда как раз находится в этой точке.
Sign up to leave a comment.
«Scrum. Революционный метод управления проектами». Книга за 15 минут