Комментарии 124
Если участник часто опаздывает, то нужно избавляться от такого участника, а не от инструмента.
Если участники скатываются в мелочи, забыв про суть и ограничения, то нужно избавляться от руководителя/организатора, а не инструмента.
А не противоречит ли такой подход Agile Manifesto? -)
В скраме идет упор на человечность в целом, что все мы люди
Стоит поговорить с командой, когда им удобнее, а не заставлять всех приходить в 9 утра
Стоит поговорить с командой, когда им удобнее, а не заставлять всех приходить в 9 утра
Это однозначно — нужно согласовывать предварительно удобное время, а не эгоистично обозначать время. Я указал лишь то, что дисциплина при такой работе очень важна.
Кстати, помогает в согласовании времени массовое использование календарей, которые (почти все) имеют функционал отображения занятости подключаемых сотрудников.
PS Тупо минусят, вообще не вдумываясь в организацию групповых обсуждений. Что с Хабром то…
Кстати, помогает в согласовании времени массовое использование календарей, которые (почти все) имеют функционал отображения занятости подключаемых сотрудников.
PS Тупо минусят, вообще не вдумываясь в организацию групповых обсуждений. Что с Хабром то…
У меня это сработало иначе.
Поговорить не помогло -)
Я стал начинать ровно в 10:00 и заканчивать ровно в 10:10 и все привыкли не опаздывать. Тем более все хотели меньше времени тратить на планерки!
Поговорить не помогло -)
Я стал начинать ровно в 10:00 и заканчивать ровно в 10:10 и все привыкли не опаздывать. Тем более все хотели меньше времени тратить на планерки!
«Канбан спасет мир»
«перерывы между спринтами»
Расскажите подробнее про этот пункт, не понял откуда Вы его взяли. На опыте может дошли к этому, но в скрам гайде такого не видел
Сам Сазерланд говорил, что нужно добиться ритмичности, чтобы вся команда могла работать на одном темпе бесконечно. А если команда «устает» от спринта — проблема с планированием, или ещё с чем-нибудь
Расскажите подробнее про этот пункт, не понял откуда Вы его взяли. На опыте может дошли к этому, но в скрам гайде такого не видел
Сам Сазерланд говорил, что нужно добиться ритмичности, чтобы вся команда могла работать на одном темпе бесконечно. А если команда «устает» от спринта — проблема с планированием, или ещё с чем-нибудь
Скорее всего я это прочел в книге «Scrum и XP: заметки с передовой» Хенрик Книберг. Кстати крутая практическая книга даже в чем-то лучше Сазерлэнда, очень рекомендую!
Практика это подтверждает! Должны быть перерывы между спринтами, иначе выгорают люди.
Практика это подтверждает! Должны быть перерывы между спринтами, иначе выгорают люди.
Если быть точным, то Сазерленд пишет, что следующий спринт должен начинаться немедленно по завершении предыдущего. Причём в формате "демонстрация, сразу после — ретроспектива, и сразу после — новый спринт".
К сожалению мне нигде не доводилось работать в таком режиме, так что пока хожу только с желанием попробовать:)
Это, конечно, не мое дело и вообще может быть трудная тема… Но кто такая Маша?
--
А как оно натягивается на сценарий «огромный скоуп — фиксированная дата»? Понятно, что кейс ужасный для любой методологии, но в дикой природе постоянно встречается. Типичный пример- партнерское соглашение с уже подписанной датой и обязательствами сторон. Ну, то есть, инкрементально деливерить можно сколько угодно, но пока все не сделано value=0.
Сазерлэнд именно такие примеры в своей книге и описывает.
От себя добавлю, что если не показывать динамику, то проект могут и закрыть. А если спринтом выкатить первую грубую версию, то дальше заказчик немного прозревает и с ним уже можно на что-то адекватное договориться.
От себя добавлю, что если не показывать динамику, то проект могут и закрыть. А если спринтом выкатить первую грубую версию, то дальше заказчик немного прозревает и с ним уже можно на что-то адекватное договориться.
Ну тут, скорее, даже не с точки зрения убеждения заказчика (предположим, что у нас полное доверие), а скорее как бы радостно не продолбить даты увлекаясь планированиями пары спринтов вперед
Планировать пару спринтов вперед — это не по скраму -)
Согласен — это фигура речи скорее. А если по сути?
Я постоянно участвую в таких проектах.
1. Там обычно не прописано четко, что нужно сделать, чтобы проект считать завершенным, хорошо, если нет противоречий.
2. Первым спринтом закрываем базовый функционал и отдаем заказчику тестить рабочую систему.
3. Заказчик тестит, радуется, ведь что-то сдвинулось с мертвой точки, грустит, что все не идеально, пишет лист доработок для идеала.
4. Его лист естественно никак не матчится с «огромный скоуп — фиксированная дата».
5. Идем на встречу по гибкой методолгии и договариваемся: что добавляем в огромный скоуп, что убираем из огромного скоупа, что делаем с датой.
6. Вторым спринтом закрываем открывшиеся понимание и предлагаем уже тестить на живых пользователях.
7. Вот тут у многих заказчиков проблема, никак не могут одобрить релиз. Оттягивают его, пытаются все сделать идеально. Но как бы идеально не было — все равно живые пользователи прикалываются к чему-нибудь совершенно непредсказуемому. Поэтому чем раньше первый релиз — тем лучше.
1. Там обычно не прописано четко, что нужно сделать, чтобы проект считать завершенным, хорошо, если нет противоречий.
2. Первым спринтом закрываем базовый функционал и отдаем заказчику тестить рабочую систему.
3. Заказчик тестит, радуется, ведь что-то сдвинулось с мертвой точки, грустит, что все не идеально, пишет лист доработок для идеала.
4. Его лист естественно никак не матчится с «огромный скоуп — фиксированная дата».
5. Идем на встречу по гибкой методолгии и договариваемся: что добавляем в огромный скоуп, что убираем из огромного скоупа, что делаем с датой.
6. Вторым спринтом закрываем открывшиеся понимание и предлагаем уже тестить на живых пользователях.
7. Вот тут у многих заказчиков проблема, никак не могут одобрить релиз. Оттягивают его, пытаются все сделать идеально. Но как бы идеально не было — все равно живые пользователи прикалываются к чему-нибудь совершенно непредсказуемому. Поэтому чем раньше первый релиз — тем лучше.
Потому что не правильно его готовите.
Да, больно, но это сладкая боль — за ней следует протрезвение.
Затягивают встречи — не надо убеждать ничего. Пускай затягивают. Завалят итерацию — вспомнят всех, кто опаздывал и убедят не опаздывать.
Команда не просто берет задачи, а берет обязательство их сдать в конце.
Если уводят задачи — значит, делаете неправильно оценку. На оценке тот, кто более компетентный покажет меньший балл, чем тот, кто менее компетентный и сможет убедить окружающих в том, что его оценка правильная. Если они одинаково компетентны, но одному хочется больше, то договоритесь, что следующую задачу возьмет тот, кто получил более вкусную сегодня.
Скрам-мастер не несет ответственность за команду. Он ей помогает убирать препятствия, которая сама команда не может. Ну, помимо, проведения митингов и всего остального.
Про стратегию. Владелец видения — не мастер, а оунер. В чем проблема зашедулить даже двух-трех часовой митинг с разъяснением видения — не понимаю.
Да, больно, но это сладкая боль — за ней следует протрезвение.
Затягивают встречи — не надо убеждать ничего. Пускай затягивают. Завалят итерацию — вспомнят всех, кто опаздывал и убедят не опаздывать.
Команда не просто берет задачи, а берет обязательство их сдать в конце.
Если уводят задачи — значит, делаете неправильно оценку. На оценке тот, кто более компетентный покажет меньший балл, чем тот, кто менее компетентный и сможет убедить окружающих в том, что его оценка правильная. Если они одинаково компетентны, но одному хочется больше, то договоритесь, что следующую задачу возьмет тот, кто получил более вкусную сегодня.
Скрам-мастер не несет ответственность за команду. Он ей помогает убирать препятствия, которая сама команда не может. Ну, помимо, проведения митингов и всего остального.
Про стратегию. Владелец видения — не мастер, а оунер. В чем проблема зашедулить даже двух-трех часовой митинг с разъяснением видения — не понимаю.
Ну это совсем жесткий провал первых двух спринтов.
Я все-таки за то, чтобы был позитив.
Я все-таки за то, чтобы был позитив.
Почему первых двух? Одного.
Талеб написал целую книгу про «шкуру на кону».
Вам шашечки, или ехать?
Талеб написал целую книгу про «шкуру на кону».
Вам шашечки, или ехать?
Я прочел предыдущие три книги. Метод Талеба — это сплошной невроз. Фу так жить.
Вы наверное заказываете все-таки такси, а не джихад-мопед, когда ехать хотите? -)
Комфорт важен. Удовольствие от жизни и работы важно.
Вы наверное заказываете все-таки такси, а не джихад-мопед, когда ехать хотите? -)
Комфорт важен. Удовольствие от жизни и работы важно.
Невроз — это застарелые неразрешенные противоречия. На самом деле, как раз таки стресс — и есть комфорт. Только именно стресс, а не невроз. Вы, увы, не можете выбрать и «достигать крутых результатов» и при этом, «не напрягаться».
Когда вы видите богатых челах на майбахах — они в свободное от позирования время напрягаются как кони ломовые. А на майбахах и приватных бизнес-джетах «на сдачу» катаются от основных обязанностей. Вы, конечно, можете пять минут почувствовать комфорт. Но это будет последний комфорт в вашей жизни.
Когда вы видите богатых челах на майбахах — они в свободное от позирования время напрягаются как кони ломовые. А на майбахах и приватных бизнес-джетах «на сдачу» катаются от основных обязанностей. Вы, конечно, можете пять минут почувствовать комфорт. Но это будет последний комфорт в вашей жизни.
Рассуждения Талеба о пользе стресса я хорошо помню. Еще посттравматический рост он боготворит. Может вам ногу сломаем ради живительного стресса?
Допустим, мы ломаем вам ногу и туда вставляем титановую пластину. Нога стала лучше чем была до стресса! Это же настоящая «антихрупкость» по Талебу!
В общем подход Талеба — это развитие у себя психических заболеваний.
Я в этом плане не с Талебом, а с Зелигманом и Чиксентмихайи!
Допустим, мы ломаем вам ногу и туда вставляем титановую пластину. Нога стала лучше чем была до стресса! Это же настоящая «антихрупкость» по Талебу!
В общем подход Талеба — это развитие у себя психических заболеваний.
Я в этом плане не с Талебом, а с Зелигманом и Чиксентмихайи!
Вы путаете. Физическая боль она безусловная. Любому человеку ногу сломай — будет больно.
А вот психологическую боль вы себе сами организуете, особым образом сжимая внутренние органы и лицевую мускулатуру.
Вообще-то есть люди, которые с любой жизненной ситуацией справляются без психологической боли.
И, да, если им сломать ногу — им тоже будет больно. Но это не вызовет психологических проблем. Они быстро адаптируются к новой ситуации и будут действовать так, как будто бы с ногой все в порядке в тех ситуациях, которые не будут требовать на нее опереться.
Талеб просто немножечко груб, и, видимо, еще и перевод посредственный, поэтому вам кажется что он что-то ужасное пишет. Но, на самом деле, он прав.
А вот психологическую боль вы себе сами организуете, особым образом сжимая внутренние органы и лицевую мускулатуру.
Вообще-то есть люди, которые с любой жизненной ситуацией справляются без психологической боли.
И, да, если им сломать ногу — им тоже будет больно. Но это не вызовет психологических проблем. Они быстро адаптируются к новой ситуации и будут действовать так, как будто бы с ногой все в порядке в тех ситуациях, которые не будут требовать на нее опереться.
Талеб просто немножечко груб, и, видимо, еще и перевод посредственный, поэтому вам кажется что он что-то ужасное пишет. Но, на самом деле, он прав.
Кстати есть еще Малком Глэдуэл, который в одной из своих книг кажется в «Переломном моменте» рассказывает о том, как живет Талеб.
Это невроз конечно -)
А психологические боли также универсальны как физические, просто порог разный. И также опасны, как физические!
Это невроз конечно -)
А психологические боли также универсальны как физические, просто порог разный. И также опасны, как физические!
рассказывает о том, как живет Талеб.
Я не читал. Перескажите своими словами.
И также опасны, как физические!
Безусловно. Только разница в том, что вы их сами себе делаете. Если нога, как правило, ломается по воле обстоятельств, то психологические вы себе сами организуете.
И стресс не обязательно означает психологические боли. Просто бодрость духа.
В общем Талеб покупает путов на всю катлету и сидит и ждет пока они выстрелят. А они не выстреливают и он мучается под давлением инвесторов -)
Доказано Зелигманом в опытах на животных, что психологические травмы это не сам себя.
Доказано Зелигманом в опытах на животных, что психологические травмы это не сам себя.
В общем Талеб покупает путов на всю катлету и сидит и ждет пока они выстрелят. А они не выстреливают и он мучается под давлением инвесторов -)
Я так понимаю, что вы настолько все упростили, что потерялась суть. Все мучаются. Просто он еще и бабки заколачивает.
Доказано Зелигманом в опытах на животных, что психологические травмы это не сам себя.
Я погуглил «Зелигман опыты на животных», ничего не нашел. Поясните что имеете в виду.
1. Бабки он разве что на консультациях и книгах заколачивает а на путах он сливает, понятное дело. И еще нервы себе портит.
2. В книге Learned Optimism Seligman рассказывает как вызвал депрессию у собак если упрощенно. Если подробно, то выученную беспомощность.
2. В книге Learned Optimism Seligman рассказывает как вызвал депрессию у собак если упрощенно. Если подробно, то выученную беспомощность.
1. Ну, может, если он перестанет сливать, то и книги будет не о чем писать и перестанет бабки заколачивать на них и на консультациях.
2. А. Ну, это не то. Там же током бьет, и клетка закрыта. То есть, у бедняжки выбора нет — приходится в себе депрессию развивать. Людей никто током не бьет.
Но, таки, если вы действительно будете себе делать психологическую боль регулярно в одних и тех же обстоятельствах, у вас тоже разовьется «выученная беспомощность».
2. А. Ну, это не то. Там же током бьет, и клетка закрыта. То есть, у бедняжки выбора нет — приходится в себе депрессию развивать. Людей никто током не бьет.
Но, таки, если вы действительно будете себе делать психологическую боль регулярно в одних и тех же обстоятельствах, у вас тоже разовьется «выученная беспомощность».
судя по названию, садо-мазо?
НЛО прилетело и опубликовало эту надпись здесь
1. По духу скрама это должно разбираться на ретроспективах YChebotaev что думаете?
2. Из мой практики я либо модерирую, либо закрываю глаза
2. Из мой практики я либо модерирую, либо закрываю глаза
Как это должно решаться в рамках самоорганизации команды?
Вы сами и ответили. Как команда сама с собой организуется — так и будет.
Смотрите. Тут вообще принципиально другая модель работы: обычные проекты как делаются. Берутся «рабы» и кидаются на амбразуры. А «рабы» и рады быть рабами — ответственности зато никакой. В скраме по-другому. За работу берутся свободные ответственные, добросовестные люди. Это как масоны против древнеегипетских рабов. И те и те камни складывали, но масоны до сих пор существуют.
Один и тот же человек может быть утром рабом, а вечером свободным, ответственным и добросовестным, а потом наоборот.
Не могу понять как вы решили селекцию организовать?
Не могу понять как вы решили селекцию организовать?
Не, нифига. Настоящее рабство давно закончилось. Да даже если человек и раб юридически, у него все равно даже в этом статусе довольно много свободы.
Человек сам себе селекцию организует. Приглашаешь в проект: «смотри, такая штука классная, будет вот то-то и то-то. Присоединяйся». Он смотрит и соглашается. Или не соглашается. Все.
Не могу понять как вы решили селекцию организовать?
Человек сам себе селекцию организует. Приглашаешь в проект: «смотри, такая штука классная, будет вот то-то и то-то. Присоединяйся». Он смотрит и соглашается. Или не соглашается. Все.
Ну нет, это так не работает.
Сегодня согласился, а завтра бабушка умерла и все.
Сегодня согласился, а завтра бабушка умерла и все.
Сегодня согласился, а завтра бабушка умерла и все.
Ну так работа, не взирая на обстоятельства — это и есть рабство. В скраме, если у тебя умерла бабушка и ты перехотел работать — тебя попросят дотянуть до конца итерации, возможно, даже перераспределят оставшиеся обязательства на других членов команды. И после этого — все, гуляй, Вася.
А раб так не может.
В скраме по-другому
Ага. В скраме
На самом деле, у скрам-мастера главный инструмент — не скрамбук, а фасилитация.
А фасилитация, в свою очередь, это единственный необходимый элемент групповой самоорганизации. Без нее не будет и группы.
Да, безусловно, скрам, в своей основе, тиранический. Но это наименее тиранический способ делать дела из всех остальных. Отказавшись от фасилитации, вы, фактически, откажетесь и от планов выпустить продукт и заработать сотни нефти.
Можете попробовать, и если у вас получится — напишите книгу и расскажете — как. До вас ни у кого не получалось.
Скрам облегчает боли, связанные с разработкой продукта, а не усиливает. Без него ваш единственный выход — больше тирании.
Вы, конечно, можете решить, что «раз нет иного пути, кроме тирании, какая разница, насколько ее больше? Чуть-чуть туда, чуть-чуть сюда — еще никому не навредило». Ну, удачи с привлечением других участников в такой проект. Больше тирании означает меньше свободны для них самих, для их жен, детей, родных и друзей. Вы противостоите им всем.
А фасилитация, в свою очередь, это единственный необходимый элемент групповой самоорганизации. Без нее не будет и группы.
Да, безусловно, скрам, в своей основе, тиранический. Но это наименее тиранический способ делать дела из всех остальных. Отказавшись от фасилитации, вы, фактически, откажетесь и от планов выпустить продукт и заработать сотни нефти.
Можете попробовать, и если у вас получится — напишите книгу и расскажете — как. До вас ни у кого не получалось.
Скрам облегчает боли, связанные с разработкой продукта, а не усиливает. Без него ваш единственный выход — больше тирании.
Вы, конечно, можете решить, что «раз нет иного пути, кроме тирании, какая разница, насколько ее больше? Чуть-чуть туда, чуть-чуть сюда — еще никому не навредило». Ну, удачи с привлечением других участников в такой проект. Больше тирании означает меньше свободны для них самих, для их жен, детей, родных и друзей. Вы противостоите им всем.
Так «свободные самоорганизованные люди, без менеджеров» или «тирания скрам мастера и скрамбука», который в случае чего тебя фасилитирует?
Скрам-мастер, кстати, тоже будет тестировать продукт и полы мыть, если что? Он ведь тоже самоорганизованный и «за результат»?
Скрам-мастер, кстати, тоже будет тестировать продукт и полы мыть, если что? Он ведь тоже самоорганизованный и «за результат»?
Так «свободные самоорганизованные люди, без менеджеров» или «тирания скрам мастера и скрамбука», который в случае чего тебя фасилитирует?
Здесь нет противоречия. Свободные, самоорганизованные люди без менеджеров обменивают часть своей свободы на мастера и скрамбук, чтобы сделать продукт.
Если еще более углубиться, то фасилитатор — это такой штатный психотерапевт.
Вы же к психотерапевту ходите и глазом не ведете. А тут то же самое, только еще и продукт получается.
Просто мастер не будет (да и не сможет) ничего делать с вашими страхами, неврозами, болями соматическими и т.п. Предполагается, что еще до вступления в команду у вас ничего этого нет.
Скрам-мастер, кстати, тоже будет тестировать продукт и полы мыть, если что?
Если потребуется и если захочет. Скрам не запрещает совмещать роли мастера и члена команды, лишь бы ему самому не потребовалась фасилитация.
Больше тирании — это далеко не единственный выход!
Например, «обучающее лидерство» — «Делай как я!»
«Вдохновляющее лидерство» — «Я верю, что нужно делать так, поверь и ты!»
Эти два примера гораздо эффективнее авторитарного лидерства. Были исследования.
Например, «обучающее лидерство» — «Делай как я!»
«Вдохновляющее лидерство» — «Я верю, что нужно делать так, поверь и ты!»
Эти два примера гораздо эффективнее авторитарного лидерства. Были исследования.
Ну, для того, чтобы было «делай как я!» нужно, чтобы лидер был компетентнее всей остальной команды в том, что он делает. Так иногда бывает, конечно, но вообще-то предполагается, что оунер не компетентен в разработке. Соответственно, не может и учить команду. Наоборот, команда учит оунера как с ней взаимодействовать.
То есть, такую модель можно представить даже в рамках скрама (синьор учит жуниоров), но оунер команду ничему не может научить.
Или, наоборот. В каком-то смысле, оунер передает свою компетенцию команде. Но это не как код писать, а свою компетенцию по отношению к пониманию проблем клиента. Тогда вообще да. И даже не противоречит скраму.
Покажите другую методологию, которая была бы столь же близка к «обучающему лидерству».
То есть, такую модель можно представить даже в рамках скрама (синьор учит жуниоров), но оунер команду ничему не может научить.
Или, наоборот. В каком-то смысле, оунер передает свою компетенцию команде. Но это не как код писать, а свою компетенцию по отношению к пониманию проблем клиента. Тогда вообще да. И даже не противоречит скраму.
Покажите другую методологию, которая была бы столь же близка к «обучающему лидерству».
В скраме не авторитарное лидерство же, а духовное. Как у шамана — если что-то где-то идёт не так, то шаман поможет с чем угодно, от лишая у оленей до норм общения с чужаками и до выбора места для стойбища. При этом если всё идёт нормально — то лишай полечит знахарь, с чужаками всё разрулит вождь, а место подберут охотники; шаману при этом ничего и не доложат. Он нужен именно тогда и только тогда, когда профильные спецы почему-то не справились и неясно что делать.
Правда, доказанного практического смысла советы шамана обычно не имеют вовсе. Но это мелочи, если вы работаете фасилитатором за большие деньги, правда? :-)
Правда, доказанного практического смысла советы шамана обычно не имеют вовсе. Но это мелочи, если вы работаете фасилитатором за большие деньги, правда? :-)
Бааалин, и отчего я не работаю фассилитатором за большие деньги? Я бы смог -)
Фассилитировали фассилитировали и невыфасселитровали -)
Фассилитировали фассилитировали и невыфасселитровали -)
НЛО прилетело и опубликовало эту надпись здесь
Нет, только лишь скрам и прочее «нужно просто договориться».
Я работал в компании, которая делала форму трекинга для какой-то почтовой службы (типа DHL, но я не уверен, что именно для них).
Одно поле ввода — трек-номер, и одна страница еще, где отображается маршрут посылки.
Казалось бы, фигня вопрос.
Проект делали по фиксед-прайсу.
В итоге, мало того, что проект вышел сильно убыточный, так еще пришлось и людей с бенчей привлекать и еще центры компетенции. И всех, кто рядом проходил.
В итоге, одно поле ввода делали что-то около года всей конторой немаленькой.
Вот вам и Software Engineering.
Одно поле ввода — трек-номер, и одна страница еще, где отображается маршрут посылки.
Казалось бы, фигня вопрос.
Проект делали по фиксед-прайсу.
В итоге, мало того, что проект вышел сильно убыточный, так еще пришлось и людей с бенчей привлекать и еще центры компетенции. И всех, кто рядом проходил.
В итоге, одно поле ввода делали что-то около года всей конторой немаленькой.
Вот вам и Software Engineering.
Одно поле ввода — трек-номер, и одна страница еще, где отображается маршрут посылки.
В итоге, одно поле ввода делали что-то около года
Вы вот сейчас проявляете худшие признаки «людей, далёких от разработки».
Я прям как сейчас помню, как мне один деятель бизнеса (в хорошем смысле слова) где-то три года назад тоже мимоходом говорил про то, как плохие программисты ему очень долго и за большие деньги не могли сделать «одно поле». Когда я спросил, какое — «Ну, чтоб человек ввёл туда любое название товара, и вышел бы прямо на точки продажи».
Занавес.
Вы вот сейчас проявляете худшие признаки «людей, далёких от разработки».
Только почему я-то? Ребята не по скраму работали. Работали бы по скраму, было бы все ок.
Угу. В итоге, если «самоорганизованная самомотивированная команда профессионалов» выдает хороший результат — то это благодаря фасилитатору и скраму. Если не выдает — то или команда неправильная или скрам у них неправильный. Я ничего не упустил?
В целом, да. Но команда может выдавать результаты и без скрама.
Скрам нужен простым смертным, которые без него вообще ничего не выпустят.
Смотрите. Есть команды-звезды, которые могут в любых условиях делать качество. А есть обычные ребята, которым гуглы с фейсбуками офферами не машут. Вот для таких ребят скрам и придумали.
Людей, которые «органически» способны делать классные штуки очень мало. Ну прям очень. Остальные ребята что-то делают в основном из под палки. Скрам — это замена для палки. Можете без скрама работать. Но тогда вопрос, на что вы его поменяете. Если на звездную команду, то вообще никаких вопросов, респект и уважуха. А вот если на палку, то к вам вопросы есть, нафига вам это надо.
Скрам нужен простым смертным, которые без него вообще ничего не выпустят.
Смотрите. Есть команды-звезды, которые могут в любых условиях делать качество. А есть обычные ребята, которым гуглы с фейсбуками офферами не машут. Вот для таких ребят скрам и придумали.
Людей, которые «органически» способны делать классные штуки очень мало. Ну прям очень. Остальные ребята что-то делают в основном из под палки. Скрам — это замена для палки. Можете без скрама работать. Но тогда вопрос, на что вы его поменяете. Если на звездную команду, то вообще никаких вопросов, респект и уважуха. А вот если на палку, то к вам вопросы есть, нафига вам это надо.
Если эффект от скрама тот же, что и у палки, то палка явно выигрывает. Она проще, понятна, к ней в комплект не нужно нанимать скрам-мастера, достаточно обезьяны.
И ее невозможно «неправильно внедрить» (Гусары, молчать).
И ее невозможно «неправильно внедрить» (Гусары, молчать).
Ну, с палкой есть еще две проблемы.
Во-первых, все меньше и меньше компаний с палками. То есть, они тупо разоряются. Делать проекты из под палки долго, дорого и плохо. И у них тупо не хватает денег чтобы платить зарплаты.
Вторая беда, что все меньше и меньше руководителей хотят махать палкой. Это же грех на душу брать. Вся ответственность на тебе. А руководители тоже люди, они хотят много ништяков и поменьше ответственности.
Так что даже если вы сейчас трудоустроены в «палочную» компанию, через пару лет, когда он разорится, вам может просто тупо будет некуда идти. Ну или ваша компания перейдет на скрам. И очень хорошо, если сможет.
Во-первых, все меньше и меньше компаний с палками. То есть, они тупо разоряются. Делать проекты из под палки долго, дорого и плохо. И у них тупо не хватает денег чтобы платить зарплаты.
Вторая беда, что все меньше и меньше руководителей хотят махать палкой. Это же грех на душу брать. Вся ответственность на тебе. А руководители тоже люди, они хотят много ништяков и поменьше ответственности.
Так что даже если вы сейчас трудоустроены в «палочную» компанию, через пару лет, когда он разорится, вам может просто тупо будет некуда идти. Ну или ваша компания перейдет на скрам. И очень хорошо, если сможет.
В скраме очень много подводных камней, без которых магия скрама не работает. Пример стендапы, казалось бы те же пятиминутки, но на самом деле это совсем не то.
Но, стендап это как раз то место где работает самоорганизованая команда. Которая должна за строго за 15 минут, поделить задачи на день для достижения спринта. А 15 минут потому что, за день 5-9 человек не могут сделать больше чем за 15 минут обсудят. Если есть практика, то знаете если команду оставить на полчаса, то они за это время придумают средненькую архитектуру, а если на 3 часа то придумают такую что 5 лет потом реализовывать будут. Потому 15 минут и не секунды больше.
Во вторых команда самоорганизованая, это значить Т-шейп специалисты, способные быть и QA и девелоперами одновременно и фронта и бэк-а, короче универсальные солдаты. (помним про 15 минут, они не зря, и мы не стремимся к «идеальной», нам нужна «рабочая» архитектура, потому «без излишеств» и «тех долга»)
В третих личная ответсвенность перед заказчиком, а точнее тем кто платит бабло. Для этого ПО и СМ приводят этих ребят на встречи к команде, где те видят своего клиента и поинмают его потребности(за что он будет платить бабло). А это поверьте мотивирует гораздо сильнее всяких печенек и плейстейшена в комнате отдыха.
Вот так, каждое утро обсуждаем, обязательно без начальников, менеджеров, и желающих «нарезать и раздать задачки», локально только командой(даже без ПО) — чего еще надо чтоб закрыть потребность клиента(цель спринта), и чем я могу помочь достичь целей.
И в такой команде нет — «я чё тестировать должен», «я бэкенд, фронт писать не умею», «я не буду этого делать»… Все мотивированы и пытаются решить эжедневно мини задачки, чтоб достичь цель спиринта.
И тогда поверьте и будет у Вас сваггер вместо тех писателя, и будут автотесты вместо мануальшика, и автоматический CI и еще кучу фишек, потому что не Вы, со своим узким взглядом, будете нарезать им задачки, а они будут решать задачки )
Но, стендап это как раз то место где работает самоорганизованая команда. Которая должна за строго за 15 минут, поделить задачи на день для достижения спринта. А 15 минут потому что, за день 5-9 человек не могут сделать больше чем за 15 минут обсудят. Если есть практика, то знаете если команду оставить на полчаса, то они за это время придумают средненькую архитектуру, а если на 3 часа то придумают такую что 5 лет потом реализовывать будут. Потому 15 минут и не секунды больше.
Во вторых команда самоорганизованая, это значить Т-шейп специалисты, способные быть и QA и девелоперами одновременно и фронта и бэк-а, короче универсальные солдаты. (помним про 15 минут, они не зря, и мы не стремимся к «идеальной», нам нужна «рабочая» архитектура, потому «без излишеств» и «тех долга»)
В третих личная ответсвенность перед заказчиком, а точнее тем кто платит бабло. Для этого ПО и СМ приводят этих ребят на встречи к команде, где те видят своего клиента и поинмают его потребности(за что он будет платить бабло). А это поверьте мотивирует гораздо сильнее всяких печенек и плейстейшена в комнате отдыха.
Вот так, каждое утро обсуждаем, обязательно без начальников, менеджеров, и желающих «нарезать и раздать задачки», локально только командой(даже без ПО) — чего еще надо чтоб закрыть потребность клиента(цель спринта), и чем я могу помочь достичь целей.
И в такой команде нет — «я чё тестировать должен», «я бэкенд, фронт писать не умею», «я не буду этого делать»… Все мотивированы и пытаются решить эжедневно мини задачки, чтоб достичь цель спиринта.
И тогда поверьте и будет у Вас сваггер вместо тех писателя, и будут автотесты вместо мануальшика, и автоматический CI и еще кучу фишек, потому что не Вы, со своим узким взглядом, будете нарезать им задачки, а они будут решать задачки )
Во вторых команда самоорганизованая, это значить Т-шейп специалисты, способные быть и QA и девелоперами одновременно и фронта и бэк-а, короче универсальные солдаты. (помним про 15 минут, они не зря, и мы не стремимся к «идеальной», нам нужна «рабочая» архитектура, потому «без излишеств» и «тех долга»)
У вас этот абзац почти полностью состоит из взаимоисключающих параграфов. И никогда в жизни не видел (и даже не слышал убедительного теоретического обоснования), как это должно работать на практике в долгосрочной перспективе.
1) T-shape — это люди, хорошо делающие одно, и плохо и медленно, но делающие всё другое. Ключевые слова — плохо и медленно. Это значит техдолг и переделывание, если речь, например, о написании кода, и плохое тестирование, если человек был вынужден заняться QA, а «медленно» — значит провал спринтов. Техдолг и провалы не будут лавинообразно нарастать только в том случае, если подавляющую часть времени все участники работают именно по своей специализации, а всё остальное — редкие исключительные случаи. В рамках классического скрама это быстро упрётся во внешние ограничения, скажем в найм: нужен еще специалист А, а специалист Б не нужен, его надо убрать из команды, но во-первых у нас ТК и законодательство, во-вторых спецов А на рынке нет, и так далее и так далее. И это я только про идеальный случай, когда скрам-команда реально может управлять своим составом в широких пределах, а часто и это невозможно.
Более того, повышение доли работы не по специальности приведет к тому, что некоторые работники прокачают разные области скиллов, станут незаменимыми «многостаночниками» и устремят bus factor к единице в лице самих себя.
Я не говорю, что это проблемы только скрама, нет, это проблемы любой коллективной работы вообще, но я не вижу никаких механизмов в скраме, которые бы позволяли ему как-то более эффективно решать проблему распределения ресурсов, и в силу этого не вижу никакого смысла в выставлении каких-то определенных требований к членам команды.
2) «Рабочая» архитектура «без излишеств» и «техдолга» в условиях изменяющихся требований и рамок скрама — это «архитектура1.0» сегодня, «архитектура2.0» на следующем спринте с новыми требованиями, «архитектура3.0» через спринт, и так далее, пока очередное переписывание архитектуры не поставит весь проект колом. В реальности же — это, естественно, излишества (если в команде опытные люди, заранее «подстилающие соломку» там, где она, скорее всего, будет нужна в будущем), или же полное собрание костылей и подпорок в 100500 томах (то есть, техдолг).
Я встречал мнение, что «кроссфункциональными» (T-shaped и т.д.) в первую очередь должна быть «команда», а не каждый специалист в частности. Т.е. как раз bus factor > 1 (в идеале — хотя бы 1,5). Волшебство вида «универсальные солдаты которые хорошо делают что угодно», увы, вряд ли достижимо — слишком много нужно знать. Но команда должна быть способна закрывать успешно спринт без привлечения других команд/сторонних специалистов, если это необходимо и «почти успешно» закрывать его, в случае форс-мажора (какой-то специалист уволился/заболел).
А уж рассказы о «ну и что ты фронтендер — иди фигачь серверный код, мы же свободные самоорганизованные люди и по скраму работаем», это вообще какие-то влажные мечты «продавцов скрама».
А уж рассказы о «ну и что ты фронтендер — иди фигачь серверный код, мы же свободные самоорганизованные люди и по скраму работаем», это вообще какие-то влажные мечты «продавцов скрама».
Да, я тоже такое встречал, и такая точка зрения для меня выглядит в разы более вменяемой, чем «надо полы мыть — ну пойди и помой».
Такие люди существуют, хоть и редкие. Другое дело, что они, как правило, работают за очень большие деньги и на кризисных точках, а потом подолгу отдыхают от всего этого. Обычный «универсальный солдат» за обычные деньги — это именно T-shape, умеет хорошо одно и плохо — многое другое. В частности, подавляющее большинство фуллстекеров именно такие: могут хорошо либо во фронт, либо в бек, но в оставшееся — плохо.
Волшебство вида «универсальные солдаты которые хорошо делают что угодно», увы, вряд ли достижимо — слишком много нужно знать.
Такие люди существуют, хоть и редкие. Другое дело, что они, как правило, работают за очень большие деньги и на кризисных точках, а потом подолгу отдыхают от всего этого. Обычный «универсальный солдат» за обычные деньги — это именно T-shape, умеет хорошо одно и плохо — многое другое. В частности, подавляющее большинство фуллстекеров именно такие: могут хорошо либо во фронт, либо в бек, но в оставшееся — плохо.
Отличный коммент, со всем согласен.
Добавлю только как это происходит в реальности.
Выпал кто-то очень важный из команды: заболел, умер, выгорел, что угодно.
Команда начинает думать как без него обойтись. И совсем не обязательно это лежит в плоскости «фронтендера на серверный код». Например можно предложить заказчику какой-то вкусный функционал на фронтенде и он откажется от части серверного кода — уже облегчение. Часть серверного функционала бывает можно забрать во фронтенд если это не вызовет тормозов. Можно переосмыслить архитектурные решения какие-то, что высвободит руки и головы…
Добавлю только как это происходит в реальности.
Выпал кто-то очень важный из команды: заболел, умер, выгорел, что угодно.
Команда начинает думать как без него обойтись. И совсем не обязательно это лежит в плоскости «фронтендера на серверный код». Например можно предложить заказчику какой-то вкусный функционал на фронтенде и он откажется от части серверного кода — уже облегчение. Часть серверного функционала бывает можно забрать во фронтенд если это не вызовет тормозов. Можно переосмыслить архитектурные решения какие-то, что высвободит руки и головы…
НЛО прилетело и опубликовало эту надпись здесь
Без тимлида нет способа решения конфликтов.
нужен внешний фасилитатор
И это скрам-мастер. Ему не нужно быть экспертом, потому что спорщики — сами эксперты. Они вполне могут друг с другом договориться.
Очень сложно составить такую цель, чтобы все максимальные 9 человек команды работали для её достижения.
Наоборот. Пока у членов команды нет скрытой повестки дня, они все будут ориентированы на эту цель и работать в соответствии с ней.
Как готовить релиз?
А как вы до этого готовили? Так же и тут.
Как разбирать конфликты в качестве кода?
Не жертвовать качеством.
Как найти еще пару лишних десятков часов в сутках у PO?
Зачем? У всех самый обычный 8-ми часовой рабочий день, как и везде.
Если оунер взял на себя обязательств больше, чем укладывается в его день, то ему это или очень надо, или ему придется отказаться от чего-то.
Как насчет потестировать код за другим разработчиком, когда QA зашивается?
Не вижу проблем. Ну возьми да протестируй. Руки отсохнут?
Может еще и полы помыть?
Тоже не вижу проблемы. Дома ведь моете и нормально. Ничего не смущает.
Многие члены команды демотивированы подобным и их производительность сильно снижается.
Если они берут обязательства выше своих скиллов, то понятно почему — приходится учиться.
В остальных случаях не понятно, почему.
навязав свой способ достижения цели
Никто никого не навязывает. Синьор вполне может пользоваться своими способами достижения цели. Наоборот, в скраме это даже лучше регулируется, чем обычно: синьор, благодаря своим навыкам достигает цель более эффективно и у него остается время на то, чтобы научить джуниоров писать код.
То есть, смотрите. В обычной ситуации задачи просто идут сплошным потоком, а в скраме в пределах итерации объем не меняется. То есть, синьор будет иногда запаздывать относительно изначальной оценки, а иногда сдавать задачу раньше срока. И ошибки планирования не влияют за пределами итерации, то есть, даже если одну итерацию все задачи сданы с опозданием, на следующую итерацию это не повлияет. Это-то время и можно употребить на подтягивание джуниоров. В обычной ситуации даже если он сделает задачу раньше, ему просто поставят новую.
Приходится выполнять не только свою роль, не только роль других членов команды, но и роль менеджмента (Self-Organizing Teams).
Смотря что вы называете «ролью менеджера». У менеджера обычно две сферы ответственности: пинать свою команду и пинать менеджеров других команд. Другие команды в скраме пинает мастер. А себя… ну вы же сами себя пинаете каждый день. Чтобы с утра встать и позавтракать вам не нужен менеджер. И чтобы встать со стула и спросить у коллеги важный для вас вопрос вам тоже менеджер не нужен. Та часть менеджмента, которая заключается в пинании своей команды — это по-сути, воспитатель в детском саду. Вам это не нужно самим.
Что делать с техническим долгом (возьмем для примера бекенд), который есть в проекте, но PO его не видит?
Вы видите. И честно говорите: «вот это задача не сделана, ее нужно в следующей итерации доработать».
Это же вам же нужно, а не оунеру. Смотрите. Если эта итерация последняя и вы наверняка знаете что больше не будет — можно отрываться по-полной. Но если предвидятся следующие — вы же сами с этим самым долгом столкнетесь. Вы столкнетесь с ним одним из двух способов: или это повлияет на оценку какой-то задачи на планировании итерации (вы знаете, что там ТД и знаете, что нужно будет переписать), и это лучший случай. Или вы столкнетесь с ним в момент релиза — тогда у вас будет два пути: или организовать аврал и весь долг быстро-быстро выплатить. Или выпустить «как есть», тогда с ТД столкнутся ваши клиенты. И этот путь для вас самый плохой: во-первых, будут недовольны клиенты, во-вторых, будет недоволен оунер, ну и в-третьих, будете недовольны вы, потому что все будут знать что «комадна А (ваша) релизит говно». И это несмываемый позор. Так что в ваших же интересах ТД не допускать и разбираться по мере появления сразу же.
У вас есть ответы на все эти вопросы?
Блин. Надо было это в самом начале написать. Я ответил только на те, которые мне интересны, не думал, что надо на все. Ну, надеюсь, кто-то еще подключится и ответит на все остальные.
НЛО прилетело и опубликовало эту надпись здесь
Нет, если проблема не организационная, а касающаяся технических навыков.
Например?
Не так же, у отдельной команды в скраме нет возможности выполнить доставку кода, DoD не может быть достигнут только силами этой команды.
Если вы взяли задачу, DoD которой не можете удовлетворить — об этом надо было сказать на планировании и не брать задачу.
Если вы вообще все задачи не можете поставить — о чем тогда разговор?
Фраза из серии «делайте хорошо, не делайте плохо» без объяснения, что такое «хорошо», а что такое «плохо». У специалистов в разных командах разные навыки и разные представления о качестве. И эти команды между собой не взаимодействуют, скрам скрамов не про них.
Популярное решение — отдельная архитектурная команда, занимающаяся качеством. но работающая, внимание, не по скраму.
У разных команд разные представления о качестве. В рамках скрама подход такой, что им жертвовать нельзя. Качество на самом высоком уровне — это технический долг. Технический долг — это объем работ, оставшийся до достижения цели спринта. То есть, в начале итерации у команды нет ничего, один технический долг. В конце — этого технического долга должно быть 0 в идеале. Но иногда так не происходит — остаются задачи, которые не доделаны. Что с ними делать — решается после. Скрам говорит лишь о том, что нельзя помечать задачу как выполненную, если по-факту она не выполнена.
Вот это означает «хорошо» и «плохо» в рамках скрама.
А полы помыть? А сортир? Человека берут выполнять определенные должностные обязанности, продиктованные его профессией.
Нет. В скраме нет подразделений на «профессии». Более того, человек сам берется делать продукт, который ему нравится. И который он, как ему кажется, он сможет лучше всего сделать благодаря своим навыкам.
Конечно же могут заставить
Вообще, смешная, конечно, проблема. Обычно вопрос с полами решается как-то сам собой: в бизнес-центре, офис в котором снимает команда обычно есть какой-то клининг, который все прибирает, это вопрос нескольких тысяч плюсом к аренде, свету и интернету.
Но если команда сильно бюджетная и не может себе позволить клининг — кто за нее будет мыть полы? Пушкин? Вы же сами эту команду выбрали и вписались в этот продукт.
Или вы предлагаете изначально набирать фуллстек-разработчиков без явной специализации, которые умеют всего понемногу?
Не имеет смысл браться за проект, который команда не может сделать. Если для проекта достаточно одних фуллстэков — не вижу проблем. Но если в команде никто мыть полы не умеет и не хочет учиться, то или придется смириться с грязными полами, или разбегаться.
Полы мыть тоже учиться?
Все умеют мыть полы с детства. Кроме детдомовцев. И у вас действительно есть проблема с полами, только если все в команде — детдомовцы. Это само по себе довольно причудливо и маловероятно, но даже если вся команда — детдомовцы — есть еще видеоуроки на ютубе, которые учат мыть полы. Блин. Это вообще смешно такой вопрос на серьезных щщах обсуждать.
НЛО прилетело и опубликовало эту надпись здесь
Например выбор архитектурного решения A и B. Когда сеньор топит за A и два мидла за B. И у обоих сторон есть доводы.
Ну, это не конфликт, а нормальная рабочая обстановка. До тех пор, пока, конечно никто по голове другому не стучит.
Это решается просто: выложили «на стол» все факты, все доводы, предпосылки, рассмотрели, и собрали из них вариант, который всем нравится. Это просто обычная работа.
Конфликт — это когда кто-то все равно остался не доволен. Это значит, что он просто не все «на стол» выложил и что-то осталось в рукаве.
А если у всех задач DoD удовлетворяется только в применением третьей стороны (например соседней команды, которая доставляет код в продакшен)?
Это значит, что команда недоукомплектована и не может браться за проект.
Нужно или доукомплектовать команду нужными компетенциями, или принять тот факт, что продукт, над которым работает команда — внутренний. И клиент у нее тоже внутренний — другая команда. И требования выставляет та самая команда, для которой делается продукт. Это неизбежно повлияет на DoD, но не в смысле качества, а в том смысле, что продукт просто не тот, который вы ожидали.
Так и что с ним делать, если одна команда считает качество допустимым, а вторая считает это огромным добавленным куском технического долга, который многократно затратит время, не уделенное ему изначально, причем сразу же в следующих спринтах?
Надо разбираться в конкретном случае что происходит.
А почему это проблема нанятого работника?
Потому что вы не «нанятый работник», а живой человек.
У меня впечатление возникло, что вы на аутсорсе работаете. Что значит «вписались»?
То и значит. Вам же не господь бог этот проект назначил, вы его сами выбрали. Могли выбрать другой. Могли вообще не выбирать. Даже если в вашем городе проектов мало и вам ни один не нравится, всегда есть другие города. Другие страны. И вы всегда можете начать свой проект. Если вам даже свой проект не будет нравится, ну тогда не знаю вообще. Начните другой.
некоторые люди не хотят делать что-то не потому что они это не умеют, а потому что не должны (по трудовому договору) и не желают это делать (по личным убеждениям) одновременно
Ну тогда живите с грязными полами. Не вижу проблемы, на самом деле.
Это решается просто
Меня беспредельно восхищает, как вы всю человеческую историю общественных отношений, дипломатию, и многое другое уместили в «это решается просто».
Тут не хватает только окончания — «а мужики-то и не знали!».
Если бы речь шла про взаимодействие разных групп людей — то да. Тут нужна дипломатия. А здесь группа одна — одна команда. Одна команда всегда сама с собой договорится, если у ее членов нет скрытых интересов.
Ну сколько дней может занять выбор архитектурного решения? При условии, конечно, что вы не пытаетесь выбрать лучшее архитектурное решение на все времена и все скоупы. Ну, день, ну два, ну неделю, ну месяц. Месяц — это уже очень крупный проект. Я не знаю, что можно делать два месяца, когда речь идет о выборе архитектуры.
Ну сколько дней может занять выбор архитектурного решения? При условии, конечно, что вы не пытаетесь выбрать лучшее архитектурное решение на все времена и все скоупы. Ну, день, ну два, ну неделю, ну месяц. Месяц — это уже очень крупный проект. Я не знаю, что можно делать два месяца, когда речь идет о выборе архитектуры.
Между взаимодействием групп людей и людей нет принципиальной разницы. И скрытые интересы у участников есть всегда — просто потому, что вы никогда нигде не рассказываете о всей гамме ваших интересов, перед тем как сделать какое-то действие, более того, это невозможно в силу рекурсивности.
Разница только в том, что интересы групп более сложны, чем интересы отдельных людей (зато аппроксимируются), но это количественная разница, а не качественная.
Или не договорится. Или договорится, но будут недовольные, которые завтра уйдут и развалят команду. Много вариантов, в общем, которые вы почему-то не рассматриваете.
PS: Вообще всякий раз, когда я смотрю на попытки обосновать, почему надо скрам и как это хорошо — я не могу отделаться от ощущения, что в основе этого скрывается обычный культизм. Безусловно здравые вещи (ранние релизы и тому подобное) не являются прерогативой скрама, и отлично применимы и в других условиях, а более спорные вещи (про людей, их универсальность, «просто договориться», и многое другое) — предлагаются как аксиомы, которые просто почему-то должны работать. И которые будут работать — по модели самосбывающегося пророчества, если все люди в команде считают, что они могут «просто договориться» и будет норм — они и вправду так будут делать, и будет норм.
В итоге это всё очень похоже на, например, хиппи-коммуны — не то, чтоб анархия, но близко, всё держится на евангелистах и самосбывающихся пророчествах, и в целом работает, пока в эту систему вливаются только те, кто в эту систему безоговорочно верят. Но в историческом разрезе — не устойчиво, не масштабируется, и особыми плюсами относительно родственных способов общественного взаимодействия не обладает.
Разница только в том, что интересы групп более сложны, чем интересы отдельных людей (зато аппроксимируются), но это количественная разница, а не качественная.
Одна команда всегда сама с собой договорится
Или не договорится. Или договорится, но будут недовольные, которые завтра уйдут и развалят команду. Много вариантов, в общем, которые вы почему-то не рассматриваете.
PS: Вообще всякий раз, когда я смотрю на попытки обосновать, почему надо скрам и как это хорошо — я не могу отделаться от ощущения, что в основе этого скрывается обычный культизм. Безусловно здравые вещи (ранние релизы и тому подобное) не являются прерогативой скрама, и отлично применимы и в других условиях, а более спорные вещи (про людей, их универсальность, «просто договориться», и многое другое) — предлагаются как аксиомы, которые просто почему-то должны работать. И которые будут работать — по модели самосбывающегося пророчества, если все люди в команде считают, что они могут «просто договориться» и будет норм — они и вправду так будут делать, и будет норм.
В итоге это всё очень похоже на, например, хиппи-коммуны — не то, чтоб анархия, но близко, всё держится на евангелистах и самосбывающихся пророчествах, и в целом работает, пока в эту систему вливаются только те, кто в эту систему безоговорочно верят. Но в историческом разрезе — не устойчиво, не масштабируется, и особыми плюсами относительно родственных способов общественного взаимодействия не обладает.
скрытые интересы у участников есть всегда
Очень далеко не всегда. Обычный человек не так уж и много всего делает. У него интересы: иметь жену, воспитать детей, побегать в тренажерке, обслужить автомобиль. Ну хобби — повышивать крестиком. Ну к родителям съездить, ну с друзьями в баре посидеть, ну телевизор посмотреть. Не бином Ньютона.
Разница только в том, что интересы групп более сложны, чем интересы отдельных людей (зато аппроксимируются), но это количественная разница, а не качественная.
Еще, разница в том, что группы людей производят значительно большую угрозу для других групп. Дело в том, что один человек зависит от мнения окружающих. А вот два человека — уже нет. Даже два человека, если организуют устойчивую пару могут сделать очень много, вы даже не представляете. Только потому что у окружающих резко сокращаются варианты на них воздействовать.
Или не договорится. Или договорится, но будут недовольные, которые завтра уйдут и развалят команду. Много вариантов, в общем, которые вы почему-то не рассматриваете.
Конкретная ситуация может быть сложной. Но, в конечном итоге, все сводится к очень ограниченному кругу классов ситуаций: решаемая проблема или нерешаемая. Решаемую проблему можно решить, просто приложив немного труда и смекалки. Нерешаемую решить невозможно в том виде, в котором она есть. Но можно поделить такую проблему на две части: решаемую и жертву. Если никто не готов принести жертву, проблема остается не решенной и становится токсичной.
Очень далеко не всегда.
Абсолютно всегда. И просто потому, что все ваши интересы — скрытые, пока вы их не выложите. А вы их не выкладываете все (как я уже говорил, это просто невозможно), и не выкладываете каждое их изменение.
Обычный человек не так уж и много всего делает.
Вы подменили интересы реальных участников вашей команды абстрактными «средними людьми» (которых не существует), и посчитали, что интересы реальных участников будут в основном укладываться в эти «средние» рамки. Статистически вы будете правы больше, чем не правы (рамки не зря «средние», ага) — но это вам никак не поможет, когда вы таки окажетесь не правы.
Еще, разница в том, что группы людей производят значительно большую угрозу для других групп.
Это исключительно количественная разница, и никак не особенность. Один тренированный морской пехотинец в разрезе физических воздействий создаст вам в разы большую угрозу, чем вы ему. Хоть это всё и 1 на 1. А один хороший и мотивированный трепатель языком сможет одолеть плохо организованную и мотивированную группу.
Даже два человека, если организуют устойчивую пару могут сделать очень много, вы даже не представляете. Только потому что у окружающих резко сокращаются варианты на них воздействовать.
Вы только что изобрели специализацию: это именно благодаря ей организованные группы делают намного больше, чем N одиночек по отдельности. А не потому, что защищены от каких-то окружающих (вернее говоря, защита от окружающих в группах может тоже быть специализирована).
Решаемую проблему можно решить, просто приложив немного труда и смекалки.
Термоядерный реактор можно построить, просто приложив немного труда и смекалки. (с)
Проблемы — они на то и проблемы, что они не обязательно решаются просто. Сложные проблемы решаются сложно. Классификация проблем на «решаемые» и «нерешаемые» не обязательно будет хорошо применяться к проекту, в конце концов «нерешаемость» проблем в общем виде нельзя доказать для любых проблем, и де-факто «нерешаемость» означает «мы не знаем, как это решать», а не «это нельзя решить». Вы что-то признали нерешаемым, но на самом деле это вполне может быть решаемым после некоторого простого применения труда и смекалки (с) на исследование проблемы. Так что ваша классификация не выглядит какой-то особо хорошей и широко применимой.
Абсолютно всегда. И просто потому, что все ваши интересы — скрытые, пока вы их не выложите. А вы их не выкладываете все (как я уже говорил, это просто невозможно), и не выкладываете каждое их изменение.
Вы правы теоретически, но на практике этой проблемы не возникает. То есть, годам к 20 все уже давно в курсе всех своих интересов, их там не много совсем.
Статистически вы будете правы больше, чем не правы (рамки не зря «средние», ага) — но это вам никак не поможет, когда вы таки окажетесь не правы.
Мне не надо быть абсолютно правым. Достаточно, что все необычные интересы не требуют особого обхождения по сравнению с обычными.
Ну что, что в вас такого необычного, что потребует персональных правил? Смотрели сериал Декстер? Там чел в свободное от работы время людей убивал, расчленял и топил в речке. И ему для этого не потребовалось ничего экстраординарного.
Это исключительно количественная разница, и никак не особенность.
Разница, конечно, качественная.
Тренированный морпех в очереди за продуктами в пятерочку значит сильно больше, чем тот же самый морпех на поле боя.
А один хороший и мотивированный трепатель языком сможет одолеть плохо организованную и мотивированную группу.
Хорошо организованную и мотивированную — только в кино. В жизни так не бывает.
Да даже в кино, каждый раз, когда протагонист бьется с толпой, из этой толпы противники к нему подходят по одному за раз.
Вы только что изобрели специализацию: это именно благодаря ей организованные группы делают намного больше, чем N одиночек по отдельности. А не потому, что защищены от каких-то окружающих (вернее говоря, защита от окружающих в группах может тоже быть специализирована).
Не. Это разные вещи.
Даже если в группе один человек работает, а другой «нифига не делает», такая группа даст большие результаты, чем просто один человек, который работает. Потому что второй не нифига не делает, а регулирует психику того, кто работает, чтобы тот был в порядке продолжал работу.
означает «мы не знаем, как это решать», а не «это нельзя решить».
Это одно и то же, когда мы говорим про групповую работу. Если группа не может решить проблему, значит, проблема не решаема.
Так что ваша классификация не выглядит какой-то особо хорошей и широко применимой.
Предложите свою.
Вы правы теоретически, но на практике этой проблемы не возникает. То есть, годам к 20 все уже давно в курсе всех своих интересов, их там не много совсем.
Я-то сам конечно, скорее всего, буду в курсе (хотя не всегда). Это не означает, что об этом будет в курсе вся команда — например о том, что через пару месяцев я выплачиваю свою ипотеку, и после этого проекту придам вращенье известно на чём, потому что я тут был только из-за денег, а так мне хочется совсем другого в жизни.
Это не «Декстер», зато вот в реальности на каждом шагу. Вася спорит с Петей относительно технического решения потому, что считает, что это для проекта лучше, или потому, что Вася скоро подастся на вольные заработки, а пока хочет попробовать новую крутую штучку за счёт проекта? Или может это Петя подастся? При этом любой из них может быть твёрдо уверен, в том числе и для самого себя, что он на самом деле горой стоит за проект. Психика — штука интересная.
Даже если в группе один человек работает, а другой «нифига не делает», такая группа даст большие результаты, чем просто один человек, который работает. Потому что второй не нифига не делает, а регулирует психику того, кто работает, чтобы тот был в порядке продолжал работу.
Два человека дают больше результата, чем один. Оба-на, вот это открытие!
Остаётся только выяснить, кто даёт больше результата: два человека, делающих дело, или один человек, делающий дело, и один «фасилитатор». Я даже знаю, за какой вариант вы будете внутренне голосовать, вот только реальность может оказаться не такой.
Предложите свою.
Я уже. Есть проблемы простые — те, относительно которых команда может согласиться о том, как их надо решать. Есть проблемы сложные — те, о которых команда не соглашается, соответственно. Простые проблемы в рамках скрама всегда решаются, сложные проблемы — не обязательно. Это не означает, что их нужно считать «нерешаемыми», это всего лишь означает, что скрам плохо подходит для решения определенных сложных проблем.
Я-то сам конечно, скорее всего, буду в курсе (хотя не всегда). Это не означает, что об этом будет в курсе вся команда — например о том, что через пару месяцев я выплачиваю свою ипотеку, и после этого проекту придам вращенье известно на чём, потому что я тут был только из-за денег, а так мне хочется совсем другого в жизни.
Если вас прямо спросили «в чем дело?», а вы не рассказали про ипотеку и про вращение, то вы лжец и с вами дел иметь нельзя.
Это не «Декстер», зато вот в реальности на каждом шагу. Вася спорит с Петей относительно технического решения потому, что считает, что это для проекта лучше, или потому, что Вася скоро подастся на вольные заработки, а пока хочет попробовать новую крутую штучку за счёт проекта? Или может это Петя подастся? При этом любой из них может быть твёрдо уверен, в том числе и для самого себя, что он на самом деле горой стоит за проект. Психика — штука интересная.
Вы слишком глубоко копаете. Еще пару предложений и докопаетесь до солипсизма.
На самом деле, проблема не такая серьезная. Достаточно спросить Васю «ты почему хочешь именно это решение, несмотря на то, что вот есть причины, почему вот то решение — лучше». Тот отвечает: «я просто хочу попробовать новую технологию». У Пети спрашивают: «а ты хочешь попробовать эту технологию?». Петя говорит: «хочу». Все, технологии — зеленый свет. Хочет там Вася подастся на вольные заработки или не хочет — к делу не относится. Ответственность — групповая. Если группа приняла ответственность, значит, что бы не сделал Вася, Петя будет защищен: ему помогут, снизят нагрузку, разрешат «выпилить это говно» или «выделят время на рефач».
Два человека дают больше результата, чем один. Оба-на, вот это открытие!
Остаётся только выяснить, кто даёт больше результата: два человека, делающих дело, или один человек, делающий дело, и один «фасилитатор». Я даже знаю, за какой вариант вы будете внутренне голосовать, вот только реальность может оказаться не такой.
Когда речь заходит про группы, логика «кто дает больше результатов» не работает. Вы просто не можете это посчитать. Потому что вот сидят Вася с Петей, работают. Вы смотрите, а Петя сачкует: хабру листает или с пикабу угарает целыми днями. Увольняете Петю. И тут Вася начинает хандрить — заваливает итерации, плохо все делает, производительность падает. Вы ничего не понимаете.
Мы не знаем в точности что происходит в этот момент на самом деле. Но психика заточена на функционирование среди людей. И эти люди психику регулируют.
Я уже. Есть проблемы простые — те, относительно которых команда может согласиться о том, как их надо решать. Есть проблемы сложные — те, о которых команда не соглашается, соответственно. Простые проблемы в рамках скрама всегда решаются, сложные проблемы — не обязательно. Это не означает, что их нужно считать «нерешаемыми», это всего лишь означает, что скрам плохо подходит для решения определенных сложных проблем.
Ну, по-сути, ровно то же самое, что и у меня, только другими словами. Просто я немного глубже ухожу в причины, а вы на поверхности плаваете.
Конечно, у скрама есть границы применимости. Никто в этом и не сомневался никогда.
Если вас прямо спросили «в чем дело?», а вы не рассказали про ипотеку и про вращение, то вы лжец и с вами дел иметь нельзя.
Подождите, а кто и когда меня прямо спросит и почему? Я пришел на проект за идею, пилил его за идею, потом взял ипотеку, а в идее разочаровался — хоба, и я уже пилю проект чисто за деньги, но внешне вообще ничего не изменилось. А потом у меня мотивация «за деньги» заканчивается, и я прям на этом месте машу ручкой строго по трудовому кодексу, и проблемы индейцев меня более не волнуют.
На самом деле, проблема не такая серьезная.
Если вы не сталкивались с аналогично выглядящими серьезными проблемами — ну ой. Я — встречался, один раз мне коллега фактически так и сказал прямым текстом: я в ближнем будущем сваливаю, а пока хочу штуку попробовать, штука в среднесрочной перспективе проблем не даст, поэтому если тебе интересно, то ты тоже можешь за неё топить, или хотя бы не высказываться против. А на дальнюю перспективу она плохая, но — «или ишак, или падишах».
Достаточно спросить Васю «ты почему хочешь именно это решение, несмотря на то, что вот есть причины, почему вот то решение — лучше». Тот отвечает: «я просто хочу попробовать новую технологию». У Пети спрашивают: «а ты хочешь попробовать эту технологию?». Петя говорит: «хочу».
В реальности обычно всё сводится к «у варианта А есть такие-то плюсы, у варианта Б такие-то, они не квантифицируются, и поэтому стороны могут до посинения спорить о том, чьи плюсы важнее для проекта». Авторитарно это разруливается очень быстро и примитивно, при этом если принимающий решения пользуется уважением и выслушал обе стороны, то к решению, как правило, все отнесутся нормально, каким бы оно не было (принимающий решения мог отойти за угол и бросить монетку). Мне не известно, как это разрулить неавторитарно без серьезной комплексной дипломатии, если Вася не особенно сильно авторитетен для Пети, и наоборот. Быстро решить что-то можно, но одна из сторон останется недовольной, и при достаточном количестве недовольства — будет конфликт.
Подождите, а кто и когда меня прямо спросит и почему? Я пришел на проект за идею, пилил его за идею, потом взял ипотеку, а в идее разочаровался — хоба, и я уже пилю проект чисто за деньги, но внешне вообще ничего не изменилось. А потом у меня мотивация «за деньги» заканчивается, и я прям на этом месте машу ручкой строго по трудовому кодексу, и проблемы индейцев меня более не волнуют.
Ну ок.
Если ваша ситуация не становится причиной противоречий с другими членами команды — проблем нет. Просто как вы определяете «мотивацию»? Что это такое? Если действительно ничего не поменялось, значит, не поменялась и мотивация. Как правило, что-то все-таки меняется и это заметно и об этом спрашивают.
Если вы не сталкивались с аналогично выглядящими серьезными проблемами — ну ой.
Какие проблемы вы называете серьезными? Любое противоречие — супер-серьезная проблема, его нельзя оставлять неразрешенным.
В реальности обычно всё сводится к «у варианта А есть такие-то плюсы, у варианта Б такие-то, они не квантифицируются, и поэтому стороны могут до посинения спорить о том, чьи плюсы важнее для проекта». Авторитарно это разруливается очень быстро и примитивно, при этом если принимающий решения пользуется уважением и выслушал обе стороны, то к решению, как правило, все отнесутся нормально, каким бы оно не было (принимающий решения мог отойти за угол и бросить монетку). Мне не известно, как это разрулить неавторитарно без серьезной комплексной дипломатии, если Вася не особенно сильно авторитетен для Пети, и наоборот. Быстро решить что-то можно, но одна из сторон останется недовольной, и при достаточном количестве недовольства — будет конфликт.
Авторитет — это ведь не святой дух. У любого человека, числе прочего, есть внутренний авторитет, который все и так знает и понимает.
Очень редко бывает так, чтобы одни плюсы были исключали другие плюсы. Но когда так случается, все понимают, чьи плюсы плюсовее.
Проблема только в том, что в этот момент в человеке «активен» не его авторитет, а какая-то другая фигня. Вот переключить фигню на «авторитет» — и задача других людей.
Термоядерный реактор можно построить, просто приложив немного труда и смекалки. (с)
Смотрите. Если термоядерный реактор — нерешаемая проблема, то вы не сможете его построить. Сможете построить что-то другое, но жертвой станет отказ от мечты о термоядерном реакторе. Вам придется греть чай не на термоядерной энергии, а на от ГЭС.
Но если он — решаемая проблема, то вы построите термоядерный реактор через какое-то время.
У вас рекурсивное определение — «если вы не сможете сделать Х, то это значит, что вы не сможете сделать Х, а если вы смогли сделать Х, значит вы можете сделать Х». Чёрт возьми, как всё просто!
Вы программист? Знаете, такая структура данных есть — фильтр Блума. Тут очень похожая логика.
То есть, любая проблема может оказаться решаемой или нет. Но если вы попробовали решить проблему и у вас получилось, значит проблема решаемая. Но если вы попробовали и у вас не получилось, это ничего не говорит о проблеме, только о том, что у вас не получилось.
Мы не можем знать наверняка что какая-то проблема не решаемая, пока не существует строгого формального доказательства ее нерешаемости. Такие доказательства существуют для очень небольшого количества проблем. Большинство нерешаемых проблем мы опознаем только по косвенным признакам: например, в команде из 9 человек никто не знает, как ее решать, не видел, чтобы кто-то решал и в гугле не нашлось решений.
То есть, любая проблема может оказаться решаемой или нет. Но если вы попробовали решить проблему и у вас получилось, значит проблема решаемая. Но если вы попробовали и у вас не получилось, это ничего не говорит о проблеме, только о том, что у вас не получилось.
Мы не можем знать наверняка что какая-то проблема не решаемая, пока не существует строгого формального доказательства ее нерешаемости. Такие доказательства существуют для очень небольшого количества проблем. Большинство нерешаемых проблем мы опознаем только по косвенным признакам: например, в команде из 9 человек никто не знает, как ее решать, не видел, чтобы кто-то решал и в гугле не нашлось решений.
НЛО прилетело и опубликовало эту надпись здесь
После обсуждения один сеньор продолжает топить за вариант A и два мидла за вариант B. Как будете решать?
Значит, плохо обсудили. Смотрите. Если решение сеньора действительно хорошее, значит, он сможет это доказать. А вот если решение сеньора плохое и два других члена команды его не покупают, значит, этот сеньор игнорирует реальность. Вопрос в том, что ему дает игнорирование реальности?
Вероятно, проблема уже не техническая, а психологическая. Тогда привлекается мастер-фасилитатор, который берет мидла и синьоров и те «выкладывают на стол» уже не технические, а психологические карты.
Почему недоукомплектована?
Вы не можете делать продукт без релизов. Релизы — естественная часть процесса разработки. Если вы не можете делать релизы, значит, вы не можете делать и продукт.
Даже веб-приложения все равно подвержены релизам. Никто давно уже не правит файлы руками по FTP. Вы, в принципе, можете так делать и тогда у вас не будет проблем с релизами. Но будут другие проблемы.
То есть реальный PO будет только у одной основной команды, а для остальных команд в роли PO с видением проекты будут выступать разные люди из первой команды?
Да. Но нет подразделения на «реальных» и «виртуальных» оунеров. Они все реальные или все виртуальные, в зависимости от того, что вы вкладываете в это понятие.
Но если какая-то из второстепенных команд сделает задачи некачественно, то как их PO (член первой команды) сможет это проверить и понять?
На демонстрации.
Не совсем понятно, что вы имеете в виду под «не качественно». Если задача не работает просто — ну, это быстро вскроется. Если работает, но не так как надо, надо смотреть «как надо». Если она работает как в DoD-е, то это просто «расширилось видение продукта», «появилась новая информация», «мы чему-то научились за этот спринт». Если не как в DoD-е, значит, задача не сделана и ее вообще не должны были до демо допустить, а отчитаться просто, что «что-то пошло не так», и разобраться что именно пошло не так на ретро.
Кто и как должен разбираться?
Команда. Ну, в данном конкретном случае, я имел в виду, что просто мне не понятно и я не могу на этот вопрос ответить в той формулировке, в которой он задан.
Что-то путаете. Для работодателя я в первую очередь нанятый на определенные обязанности, соотвтесвующие моей позиции, работник. Не друг и не партнёр.
Живой человек — это уже дополнение, которое должно работать исключительно в обе стороны.
Не в скраме. С скраме команда образуется вокруг продукта. Если вам (как члену команды) нравится продукт, который вы собрались делать — как вы можете быть наемным работником?
А если продукт вам не нравится, зачем вы его тогда делаете? Делайте другой продукт, который нравится.
Пожалуйста не занимайтесь подменой понятий, «проект» и «работодатель» — разные вещи. У текущего работодателя, например, более тысячи проектов. И да, я себе на конкретной работе проект не выбирал, мне его назначили.
Смотрите. Когда вы работаете над продуктом, у вас появляется право на долю от реализации этого продукта (как считать эту долю — отдельный вопрос). Вы просто каждый месяц продаете этот опцион капиталисту и называете вырученное зарплатой, а капиталиста — работодателем. Вас так делать никто не заставляет. Есть другие проекты и другие условия. Вы на это согласились и «работодатель» согласился. Вы можете с ним поговорить и попросить его не выкупать весь ваш опцион, а лишь часть. Ему это может быть не интересно и он от вашего предложения откажется. Но и вас никто не заставляет.
И по трудовому договору я, как работник, не могу на это повлиять. Даже уйти сразу не могу, надо отрабатывать определенный срок.
Вы обязаны предупредить в течении двухнедельного срока. И, на самом деле, это вам же нужнее такое требование. Потому что если кто-то узнает, что вы свалили без предупреждения, ваша же репутация будет испорчена.
Достаточно подойти к «работодателю» и договориться. Ему вас так-то тоже нет особого резона кормить две недели. Один раз мне предлагали без «отработки» и отказался, а другой раз я сам попросил «одним днем» и мне пошли на встречу.
Проваленный проект — не проблема? Вы именно эту аналогию взяли.
Вне скрама подобные условия к провалу проекта не приведут.
Не проблема, если вы с самого начала взялись за него, чтобы провалить. Правда, все, конечно, будут знать что вы так делаете и к вам будут очень много вопросов. Но это не проблема.
А если реально были такие проблемы, которые являются внешним фактором относительно ответственности самого разработчика?
Допустим, конечно же бывает форс-мажор. Но если разрабу задать вопрос «а что мы могли сделать чтоб не допустить этого?», найдутся сразу как минимум 3-4 варианта. Так вот ответственность, это когда не надо задавать вопросов, команда сама понимает, и делает то что необходимо для недопущения, или исправления проблемы, абсолютно не важно что стало причиной. Как моряки, будут до последнего спасать свой корабль, ибо пойдут на дно с кораблём.
В ватерфольной, все работы санкционированы, потому варианта — «а мы тут еще дописали», не допустимо(но в жизни бывает конечно).
В ватерфольной структуре, при возникновении трабл, будут искать тех кто должен был, но не санкционировал каких то работ(не предусмотрел, не описал, не затестил). Вот и вся разница, разработчик или волен делать как он считает нужным, или будет вечно «кодером», а за него будут думать другие.
Качество кода должно быть достаточным. Если оно не достаточно, то не хватает поддержки и добавленного функционала.
Ага )))) Только лет 20 назад тому может быть такое прокатывало, когда не было фреймворков, писали код с нуля и платили за строчки кода. Когда нормально было делать софт за 3-4 года. На сегодняшний момент, технологии развиваются так быстро, что за год твой код уже морально устареет. Если знания в IT живут не более 3-х лет, студенты что сейчас на 1 курсе, при выпуске уже будут иметь неактуальные знания. Потому, актуально ли закладывать на 5 лет вперед возможности добавленого функционала, строить сложную архитектуру, если с 90% вероятностью ты перепишешь/отрефакторишь своё приложение в следующем году. А точнее так, может это и не твоё желание будет, но АПИ фреймворков поменяется, новые секьюрти гепы итд… и всё равно всё переписывать.
Потому нет смысла делать сейчас сложных монолитов, микро сервисы которые как «печеньки» потом меняй и переписывай хоть по 20 штук на день.
Это крайний случай конечно же, достаточность должна быть, но если клиент платит — то по моему он должен определять уровень достаточности.
Из опыта скажу что первые 3-4 релиза, всегда лучше делать «на костылях» и побыстрее(по научному это называют MVP если что), потому что как только у клиента появиться возможность «поклацать», тут же польётся поток хотелок, который реализуя поменяет архитектуру еще 20 раз. Так вот лучше в начале протыкать чем потом на свою «идеальную» архитектуру накручивать костыли.
НЛО прилетело и опубликовало эту надпись здесь
В армии есть такая фраза «инициатива <совершает насильственные действия в отношении> инициатора». Очень подходит.
В том и беда, что нас так «насильственно» выучили еще со школы, что мы боимся проявить инициативу. А это очень плохо, и компании такие «молчаливые» стоят очень дорого.
И SCRUM мастер обычно с этим первым делом бореться, учит людей говорить своё мнение, пусть даже надуманные.
И ой как это сложно, 5 здоровых дядек учить в 35+ говорить как детей о проблемах(правду), потому что ранее выявление проблем стоит компании в 100 раз дешевле чем, исправление их уже в продакшене. Тут чисто финансы, так обычно компании «дешевле» ))))
Окей, во фронтенде и мобильной разработке так. В моих двух сферах все спокойно и стабильно, даже за пять лет особо ничего не поменялось.
У меня тоже местами есть легаси на java 6 + GF 3, и если бы там были хоть какие то деньги, то поверьте мы переписали бы их на современные фреймворки, но там нет денег, нет апдейтов. Приложения живут в полудохлом саппорте, падает-поднимаем, иногда что то дописываем мелкое, и их использование у нас это скорее «плохая привычка», чем полноценная эксплуатация. Когда то недочитали про SOA архитектуру, наваяли монолиты никому не нужные, но зато на 2012 год это выглядело прямо круть как современно )))) на 2020 это унылое говно, осознали свои ошибки(но еще не все). И поверьте этим не горжусь, что у меня апп по 3 года не получают апдейта (((
на днях узнал что даже реализация smpp(протокол с 80-х прошлого столетия) в java, и тот имеет кучу апдейтов, что то допиливают, меняют апи… команда развивает это как продукт, и это восхитительно!
Тут простая истина, продукт для SCRUM команды должен решать какую то клиентскую проблему, и пользователь за неё платит ресурсами в общем, хорошо когда деньгами в частности. Так вот, в тех сферах где за продукт клиент платит, обычно есть конкуренция, а она уже тянет за собой постоянные изменения в продукте.
Только если Вы не живете в бизнесе который имеет абсолютную монополию, типа гос. органов. но опять же там нет изменений не потому что это не целесообразно, а потому что просто жмотят на развитие, а в итоге оно дороже получается.
Помнится мне что когда Шварцнейгер, вроде писал, что обнаружил что весь софт мерии работает на древнейшей СУБД FOXPRO. Как бы справляется, но саппорт разработчиками из далёких 80-х обходится мерии каких то колосальных денег, а добится от их ИТ отдела каких то доработок невозможно, все перегружены. Потому и выгнал в шею всех, переписали софт на современные рельсы, так тоже бывает ))))
Надо относится к софту как ресурсу, либо зарабатывает, либо проедает. И избавляться от того что проедает.
Окей, во фронтенде и мобильной разработке так.
Да нет, даже и там не так. Это типичная ошибка а-ля «будет популярным другой фреймворк, а значит наш код на фреймворке, который популярен сейчас — станет легаси». Когда есть нормальная архитектура — нужный и интересный код (т.е. бизнес-логика) вообще ни на каком фреймворке, и от изменения моды не страдает.
За год устаревает то, что пишется кое-как, но чуть получше прототипирования (потому что там обычно всё устаревает сразу же).
>>У вас есть ответы на все эти вопросы?
Все ответы между строк в SCRUM Guide.
Одно добавлю, в СКРАМ ответсвенность прямая и её больше, чем в привычном проджект менеджменте. Потому что вся иерархия в ватерфлоу, служит для «зашиты» нещасного разраба от какой либо ответсвенности. Чтоб потом, в случае любой траблы, можно было сказать
— это аналитик криворукий написал
— а чё ты ко мне, мне задачу тим лид бросил, к нему ходи
— в проде не работает, чё ко мне, есть QA его иди спрашивай как он тестил
итд…
А апогеем будет такое — habr.com/ru/post/429946
по 3 месяца на один фикс мелкой проблемы ) Главное чтоб разраб не чуствовал никакой ответсвенности ))))
в СКРАМ ты(разраб) за всё, перед клиентом, которого видишь на встречах регулярно ответственен. При чем местами и материально )))) (бабла не получишь если инкремент хреновый) И тогда вопрос про твой «тех. долг», «идеальную архитектуру», чистый код итд… отпадёт сам собой))) Код должен приносить бабло а не красивый в гите пылится )
Все ответы между строк в SCRUM Guide.
Одно добавлю, в СКРАМ ответсвенность прямая и её больше, чем в привычном проджект менеджменте. Потому что вся иерархия в ватерфлоу, служит для «зашиты» нещасного разраба от какой либо ответсвенности. Чтоб потом, в случае любой траблы, можно было сказать
— это аналитик криворукий написал
— а чё ты ко мне, мне задачу тим лид бросил, к нему ходи
— в проде не работает, чё ко мне, есть QA его иди спрашивай как он тестил
итд…
А апогеем будет такое — habr.com/ru/post/429946
по 3 месяца на один фикс мелкой проблемы ) Главное чтоб разраб не чуствовал никакой ответсвенности ))))
в СКРАМ ты(разраб) за всё, перед клиентом, которого видишь на встречах регулярно ответственен. При чем местами и материально )))) (бабла не получишь если инкремент хреновый) И тогда вопрос про твой «тех. долг», «идеальную архитектуру», чистый код итд… отпадёт сам собой))) Код должен приносить бабло а не красивый в гите пылится )
Буквально треть статьи прочитал, и вижу что Вы наступили на все возможные грабли Скрама!!! Чем и отбили желание им заниматся. Отвечая на Ваш вопрос — почему все поголовно не внедряют СКРАМ — да потому что мы еще не умеем думать по СКРАМУ, работать по нему. Читали СКРАМ ГАЙД? Первая страница, СКРАМ — легкий к освоению, но сложный для мастеров, подумайте о этом ))))
Кстати тут 90% коментаторов, из тех же «мы наступим на свои грабли скрама»
Что не правильно:
1) Команда у Вас не самоорганизованая.
Если есть опоздания, значить есть «протест». Вангую что Вы команду в принудительном порядке собрали, ну а как же иначе в ватерфольных структурах )))) А должны били они сами организовались вокруг продукта.
В любом случае стендапы всегда начинаются и заканчиваются вовремя. «Рассказать о деталях» — это значить команда вместо стендапа, делает пятиминутку где пытается показать какой я молодец перед начальством/менеджерами/авторитетами. Вот это всё надо искоренить, стендап для команды и только команда(без ПО и СМ) там работает. И если какой то хрен в команде саботирует стендапы, то команда либо это принимает(тогда СМ-у пофиг, команде так удобно), или его «увольняет»( о чем на ретро скажет СМ-у и этому хрену в лицо)
2) А есть ли у Вас продукт? Продукт первичней чем команда, вокруг продукта нанимают команду. И менеджмент ДОЛЖЕН видеть результат продукта а не команды.
Вангую продукта нет, потому и не всем понятна миссия, цели спринта, в том числе и менеджменту, а там и боязнь выпускать в конце спринта инкремент в продакшен итд…
3) Клиент? Ха, в большинстве нормальных СКРАМ команд, клиент на ПБР-ах, и Планингах. А есть ли у Вас, на этих встречах реальный клиент, тот кто бабло платит.
Вангую что нет, но есть очередной менеджер карьерист, который строит свой микро стартап ресурсами компании, чтоб получить очередное повышение.
Потому что «ватерфольные» менеджеры, в бюрократических компаниях, никогда не упустят шанс получить «карманную» команду. И он для команды и ПО и Клиент, и папочка в одном лице. А бывает еще что этот «папочка», слёзно на стендапах — да я ж ради вас жопу начальству целовал, да я же выбивал вас…
Только, в таком «черном скраме» часто инкремент не тот, то вроде ссыт в прод пускать, то выпуслили а оно нахрен не нужно.
А первопричина что все требования — фантазии таких менеджеров, не имеющие ничего общего с реальностью и клиентами, и бабла ТАМ НЕТ! Потому и ссымся, сливаемся, фейлимся))))
О этом в книжках увы не написано, это всё между строк в скрам гайде есть ))))
P.S. Практикующий СМ, с большим мозолём на лбу от граблей на которые наступал ))))
Кстати тут 90% коментаторов, из тех же «мы наступим на свои грабли скрама»
Что не правильно:
1) Команда у Вас не самоорганизованая.
Если есть опоздания, значить есть «протест». Вангую что Вы команду в принудительном порядке собрали, ну а как же иначе в ватерфольных структурах )))) А должны били они сами организовались вокруг продукта.
В любом случае стендапы всегда начинаются и заканчиваются вовремя. «Рассказать о деталях» — это значить команда вместо стендапа, делает пятиминутку где пытается показать какой я молодец перед начальством/менеджерами/авторитетами. Вот это всё надо искоренить, стендап для команды и только команда(без ПО и СМ) там работает. И если какой то хрен в команде саботирует стендапы, то команда либо это принимает(тогда СМ-у пофиг, команде так удобно), или его «увольняет»( о чем на ретро скажет СМ-у и этому хрену в лицо)
2) А есть ли у Вас продукт? Продукт первичней чем команда, вокруг продукта нанимают команду. И менеджмент ДОЛЖЕН видеть результат продукта а не команды.
Вангую продукта нет, потому и не всем понятна миссия, цели спринта, в том числе и менеджменту, а там и боязнь выпускать в конце спринта инкремент в продакшен итд…
3) Клиент? Ха, в большинстве нормальных СКРАМ команд, клиент на ПБР-ах, и Планингах. А есть ли у Вас, на этих встречах реальный клиент, тот кто бабло платит.
Вангую что нет, но есть очередной менеджер карьерист, который строит свой микро стартап ресурсами компании, чтоб получить очередное повышение.
Потому что «ватерфольные» менеджеры, в бюрократических компаниях, никогда не упустят шанс получить «карманную» команду. И он для команды и ПО и Клиент, и папочка в одном лице. А бывает еще что этот «папочка», слёзно на стендапах — да я ж ради вас жопу начальству целовал, да я же выбивал вас…
Только, в таком «черном скраме» часто инкремент не тот, то вроде ссыт в прод пускать, то выпуслили а оно нахрен не нужно.
А первопричина что все требования — фантазии таких менеджеров, не имеющие ничего общего с реальностью и клиентами, и бабла ТАМ НЕТ! Потому и ссымся, сливаемся, фейлимся))))
О этом в книжках увы не написано, это всё между строк в скрам гайде есть ))))
P.S. Практикующий СМ, с большим мозолём на лбу от граблей на которые наступал ))))
Хм, а нет ли у вас ощущения, что вы сделали много смелых выводов не разобравшись в нашем кейсе? -)
Допускаете ли вы, что в статьях и книгах обычно рисуется собирательный образ? -)
Допускаете ли вы, что в статьях и книгах обычно рисуется собирательный образ? -)
Понимаю, но просто не вы первый и жаль что не последний, пишите про эти «грабли». Есть даже «черная книга скрама» — «pmjournal.ru/articles/keysy/chernaya-kniga-skram» о том же…
Образ вроде собирательный но ни разу не уникальный))). Потому смело предположил…
Хотите, с удовольтвием поделюсь своим опытом )
Я больше о том, как у меня было в компании, люди прочитали эту книгу и сразу сделали выводы — мол скрам не возможен в принципе, давайте перестанем заниматся херней(дословно).
А все потому что наделали кучу типичных ошибок, от принудиловки в команды, до полного отсутсвия продукта.
И с подобным Вашему кейсу, «опаздуном» тоже боролись, ждали, переносили стендапы, уговаривали, увольняли, принимали в команду итд… а надо было просто команду строить из тех кому продукт интересен, мотивация в основе скрама. Но мы ж были умные, и не читали гайды))))
Образ вроде собирательный но ни разу не уникальный))). Потому смело предположил…
Хотите, с удовольтвием поделюсь своим опытом )
Я больше о том, как у меня было в компании, люди прочитали эту книгу и сразу сделали выводы — мол скрам не возможен в принципе, давайте перестанем заниматся херней(дословно).
А все потому что наделали кучу типичных ошибок, от принудиловки в команды, до полного отсутсвия продукта.
И с подобным Вашему кейсу, «опаздуном» тоже боролись, ждали, переносили стендапы, уговаривали, увольняли, принимали в команду итд… а надо было просто команду строить из тех кому продукт интересен, мотивация в основе скрама. Но мы ж были умные, и не читали гайды))))
Ок, если другие тоже пишут про боли скрама, мне это не запрещено я надеюсь?
Я где-то делал упор на уникальность?
Я где-то писал, что скрам невозможен?
Сазерлэнд не пишет про Скрам вокруг продукта. Наоборот он пишет про Скрам в школе, например.
Если ошибки типичные, мне запрещено о них писать?
Как мы уже начали догадываться кейс ни один их ни два и ни три. И лично я не боролся, не ждал, не переносил, не уговаривал, не увольнял и т.д. Все решилось без этого. И без продукта. Именно продукт ни в Agile Manifesto, ни у Сазерлэнда ни у Бека не требуется.
При этом я фанат Customer Development, книги Блэка, Риса, Альварес, Фицпатрика и даже Симса и даже Зерацки я с удовольствием прочел. Гибкая методология действительно совместима с Customer Development и это тема для отдельной статьи или может быть книги. Этот текст я решил не перегружать продукатми.
Вы гайды не читаете. ОООК. А я читаю и много!
Я где-то делал упор на уникальность?
Я где-то писал, что скрам невозможен?
Сазерлэнд не пишет про Скрам вокруг продукта. Наоборот он пишет про Скрам в школе, например.
Если ошибки типичные, мне запрещено о них писать?
Как мы уже начали догадываться кейс ни один их ни два и ни три. И лично я не боролся, не ждал, не переносил, не уговаривал, не увольнял и т.д. Все решилось без этого. И без продукта. Именно продукт ни в Agile Manifesto, ни у Сазерлэнда ни у Бека не требуется.
При этом я фанат Customer Development, книги Блэка, Риса, Альварес, Фицпатрика и даже Симса и даже Зерацки я с удовольствием прочел. Гибкая методология действительно совместима с Customer Development и это тема для отдельной статьи или может быть книги. Этот текст я решил не перегружать продукатми.
Вы гайды не читаете. ОООК. А я читаю и много!
Ок, если другие тоже пишут про боли скрама, мне это не запрещено я надеюсь?
Поправил: «Если другие тоже пишут о моих болях, когда я пытался начать работать по скраму, мне это не запрещено я надеюсь?»
Не запрещено. Пишите. Просто не называйте это болями скрама.
Но если они не уникальны, как мы установили выше!
Могут ли они быть все-таки болями присущими скраму, а не мне? -)
Могут ли они быть все-таки болями присущими скраму, а не мне? -)
Сазерлэнд не пишет про Скрам вокруг продукта. Наоборот он пишет про Скрам в школе, например.
В последней редакции Scrum Guide, первая строчка:
Scrum is a framework for developing, delivering, and sustaining complex products.
Скрам это фреймворк для разработки, поставки, и поддержки комплексных продуктов.
А продукты кстати бывают и в школах, и в политике и даже в автомобилестроении.
И извините, но только так… без продукта натягивать скрам на проджект менеджмент, или деманд менеджмент, первая «универсальная» ошибка.
Ща модно продукты вот он и лепит их везде теперь. НО! Скрам шире продуктов. Почитайте что он в определении пишет.
Definition of Scrum
Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.
habr.com/ru/post/494966
Скрам в 90-ых формировался, а каздев в 00-х.
Заявление, что без продукта нет скрама — это смело. Очень смело! Давайте Джефу напишем и спросим -)
Definition of Scrum
Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.
habr.com/ru/post/494966
Скрам в 90-ых формировался, а каздев в 00-х.
Заявление, что без продукта нет скрама — это смело. Очень смело! Давайте Джефу напишем и спросим -)
А Вы знакомы с Киневин фреймворком(https://uk.wikipedia.org/wiki/Cynefin), там есть категоризация задачь по доменам. Так вот скрам это как раз «COMPLEX adaptive problems» потому так и написано в гайде )))) своего рода отсылка к Киневин фрейморк ). Весь гайд если что это отсылки к другим успешным практикам, так сказать эволюция управленчиского опыта )
А давайте напишем ) Только сначала прочитаем про то что до нас уже написали www.scrum.org/search/forum?keys=Product&f%5B0%5D=type%3Aforum&advanced-form=1
Да и не смущает Вас что SCRUM команда где то 3-5 лет, должна учится T-шейпится, понимать клиента, научится говорить о проблемах итд… Вы серьёзно думаете что на проекте в полгода команда сможет раскрыть весь свой потенциал, подружится с клиентом, принять на себя обязательства за продукт? А если это произойдёт, ну бывает то потом Вы их с этого продукта не сможете «оторвать», да они скорее все уволятся, и уйдут в свой «стартап» под крыло клиента чем потеряют «любимый продукт». Это обратная сторона медальки СКРАМ-а, проекты демотивируют, продукты влюбляют в себя.
Давайте Джефу напишем и спросим -)
А давайте напишем ) Только сначала прочитаем про то что до нас уже написали www.scrum.org/search/forum?keys=Product&f%5B0%5D=type%3Aforum&advanced-form=1
Да и не смущает Вас что SCRUM команда где то 3-5 лет, должна учится T-шейпится, понимать клиента, научится говорить о проблемах итд… Вы серьёзно думаете что на проекте в полгода команда сможет раскрыть весь свой потенциал, подружится с клиентом, принять на себя обязательства за продукт? А если это произойдёт, ну бывает то потом Вы их с этого продукта не сможете «оторвать», да они скорее все уволятся, и уйдут в свой «стартап» под крыло клиента чем потеряют «любимый продукт». Это обратная сторона медальки СКРАМ-а, проекты демотивируют, продукты влюбляют в себя.
А если это произойдёт, ну бывает то потом Вы их с этого продукта не сможете «оторвать», да они скорее все уволятся, и уйдут в свой «стартап» под крыло клиента чем потеряют «любимый продукт».
Ну так это камень в огород аутсорса, а не скрама.
Я вообще думаю, что аутсорс должен умереть. Он как временная отдушина в переходный период от ватерфолла к скраму.
Это даже не камень а булыжник, от самого Джефа и Кена ))))
Но есть один момент о котором обычно молчат все консультанты по трансформациям в СКРАМ.
«Один продукт = одна команда»
И если у тебя обычно 20 человек в тех дирекции тянули 20 недо продуктов. То теперь они смогут(если их конечно «операционка» отпустит) тянуть максимум 4, а то и 2. Таким образом, или компании надо сильно раздувать штат, что наврядли, либо отказыватся от этой костыльной внутренней разработки. И переходить на использование нормальных вендорных решений.
Вот с этим вообще многие не согласны ) Потому что «внутренний IT» для не софтвейной компании, это всегда был способ «за дёшево» получить продукт «своими силами».
Но есть один момент о котором обычно молчат все консультанты по трансформациям в СКРАМ.
«Один продукт = одна команда»
И если у тебя обычно 20 человек в тех дирекции тянули 20 недо продуктов. То теперь они смогут(если их конечно «операционка» отпустит) тянуть максимум 4, а то и 2. Таким образом, или компании надо сильно раздувать штат, что наврядли, либо отказыватся от этой костыльной внутренней разработки. И переходить на использование нормальных вендорных решений.
Вот с этим вообще многие не согласны ) Потому что «внутренний IT» для не софтвейной компании, это всегда был способ «за дёшево» получить продукт «своими силами».
Не согласен. Скрам не заставляет вас любыми силами доделывать продукт. Если после нескольких итераций и фидбека с рынка стало понятно, что финансов не хватит, или не полетит — можно прекратить и никто в накладе не останется.
Я представляю это себе как такой «мягкий абордаж». Вы как бизнес плывете-плывете, и тут к вам на борт поднимается скрам-команда, которая воплощает ваш продукт. Да, в конечном итоге, продукт становится не целиком ваш, потому что команда, по правде сказать, делает для него больше. Но альтернатива — вообще никакого продукта и разорение.
Так что все так, как и должно быть.
Я представляю это себе как такой «мягкий абордаж». Вы как бизнес плывете-плывете, и тут к вам на борт поднимается скрам-команда, которая воплощает ваш продукт. Да, в конечном итоге, продукт становится не целиком ваш, потому что команда, по правде сказать, делает для него больше. Но альтернатива — вообще никакого продукта и разорение.
Так что все так, как и должно быть.
1. И что же нам дает поиск по ключевому слову продукт? Где тут написано, что скрам весь вокруг продукта и без продукта невозможен?
2. И еще поясните если продукт провальный то как быть? Все продукты на свете успешны? Или может быть 80% продуктов успешны? Или хотя бы больше половины? Ну хотя бы треть продуктов прибыльна а?
2. И еще поясните если продукт провальный то как быть? Все продукты на свете успешны? Или может быть 80% продуктов успешны? Или хотя бы больше половины? Ну хотя бы треть продуктов прибыльна а?
Хмм да нет, сложилось ощущение что они осваивали скрам методологию используя скрам методологию. XD
Звучит очень инфоцыганно
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.
SCRUM: поэма о любви и боли