Отличная статья мне кажется. Более менее адекватно рассмотрены плюсы и минусы платформ без упора в какой то хейт (сам играю на линуксе с карточкой от хуанга возвращаться на винду не буду)
"Заверили в готовности выслушать и дали пространство для обратной связи" это не self-managing. Self-managing это про способность самостоятельно решать внутри команды. Ну правда, из-за чего мы спорим?
Смотрите, я не пытаюсь сказать, что то, вы делали плохо или неправильно. В статье описаны вполне разумные вещи, и кросс функциональность, и DoD и пр. Просто в описаниях скрам обычно пишется (например в гайде на скрам орг), что речь идёт о том что команда должна быть "self-managing, meaning they internally decides who does what, when, and how". А то что описываете вы на это описание не очень похоже
Ну собственно ваша следующая фраза про судьбу сотрудника, она по моему явно показывает что о селф менеджменте речи не идет
Хм у меня скорее вопрос а зачем тим лиду досконально знать суть работы всех членов команды вне зависимости от роли? Звучит как что то напоминающее микроменеджмент. Ну и мне скорее сложнее представить как может нормально работать структура где у команд жесткое функциональное разделение.
Собственно кросс функциональные команды, которые самостоятельно способны "довозить" изменения до релиза это основа scrum, то что команды в скрам должны быть кросс функциональные это прямо написано в скрам гайдах. Другой вопрос, что такой подход не всем может подходить или не всем нравится. Но если судить по вашему комментарию, у вас сама идея кросс функциональных команд вызывает вопросы. Что странно в статье про скрам )
Но если по сути, то статья выглядит немного странно. С одной стороны подаётся как пример успешного внедрения скрам. С другой такое ощущение что все изменения инициализировать и проводились сверху, менеджером и тех льдом и консультантами. Не до конца ясно какую роль в этом играли сами команды, кроме выдачи фидбека. И тут есть два момента на мой взгляд, можно ли такое в принципе считать scrum или agile. А второе, не один раз видел в подобных ситуациях картину, когда сверху командам прилетает какое то требование по изменению процессов, которое члены команды не понимают зачем нужно, и в итоге люди продолжают работать по старому посылая наверх фидбек, что все теперь хорошо, или проводя формально какие то ритуалы просто потому что "так надо" не видя в них реально никакой ценности.
мне всегда казалось, что разница между "я просто пишу код" и способностью самостоятельно принимать решения, думать о том какое вэлью приносит работа, а не "я просто пилю фичу" и вот это все. это как раз что отличает мидла от синьора.
за исключением узкой прослойки специалистов с прямо очень уж хорошими техническими скилами.
у меня вопрос уже к первому абзацу. "если убрать все серам атрибуты то менеджерам будет нечего делать"
Я прошу прощения, но в скраме разве есть такая роль "менеджер"? Я не то что бы большой фанат скрам (имхо это такой костыль, для тех кто никогда не работал по agile). Но по моему каждый раз когда в критике скрам появляется слово "менеджер" это такой Ред флаг, говорящий что сейчас будет не критика скрам, а критика чего то, на что пытаются натянуть снятую со скрам "кожу" в виде терминологии, ритуалов и тп. Но что ни к скрам ни к аджайл отношения не имеет
ну бывает ещё вариант, что аджайл просто не подходит.
ну или вон как в примере, "команды делают костыли чтобы успеть к концу спринта", ну так может спринты реально слишком короткие, причем тут аджайл.. нигде же гвоздями не прибито что спринт должен быть 2 недели.
даже не знаю. вообще не матчится с моим опытом. у меня такие разработчики уходили обычно либо потому что им платили недостаточно их уровню экспертизы, или потому что им просто становилось скучно.
а такого что менеджер выживал хорошего специалиста потому что боялся за свой авторитет, это какой то невероятный уровень токсичности должен быть в команде
мне кажется у дяди боба в совершенной архитектуре максимально просто описано, там в духе что процедурное - про то что должна быть одна точка входа, одна точка выхода, запрет на использование переходов типа goto и тп, функциональное - про то что нужно использовать чистые функции, иммутабельность и тп, а обьектно ориентированное - про то что держать данные и методы которые эти данные используют рядом и данные должны быть видимы только тому коду которому они нужны а не торчать куда попало. как то так. И не важно как это все формально называется, какие используются ключевые слова какой синтаксис. И все это можно в определенной степени комбинировать.
Странное чувство. Мне не нравится как сформулировано. Но по сути я вроде со всем согласен
Отличная статья мне кажется. Более менее адекватно рассмотрены плюсы и минусы платформ без упора в какой то хейт (сам играю на линуксе с карточкой от хуанга возвращаться на винду не буду)
Что то я надеялся после заголовка на какую то более информативную статью
"Заверили в готовности выслушать и дали пространство для обратной связи" это не self-managing. Self-managing это про способность самостоятельно решать внутри команды. Ну правда, из-за чего мы спорим?
Я про иллюстрацию )
Смотрите, я не пытаюсь сказать, что то, вы делали плохо или неправильно. В статье описаны вполне разумные вещи, и кросс функциональность, и DoD и пр. Просто в описаниях скрам обычно пишется (например в гайде на скрам орг), что речь идёт о том что команда должна быть "self-managing, meaning they internally decides who does what, when, and how". А то что описываете вы на это описание не очень похоже
Ну собственно ваша следующая фраза про судьбу сотрудника, она по моему явно показывает что о селф менеджменте речи не идет
Хм у меня скорее вопрос а зачем тим лиду досконально знать суть работы всех членов команды вне зависимости от роли? Звучит как что то напоминающее микроменеджмент. Ну и мне скорее сложнее представить как может нормально работать структура где у команд жесткое функциональное разделение.
Собственно кросс функциональные команды, которые самостоятельно способны "довозить" изменения до релиза это основа scrum, то что команды в скрам должны быть кросс функциональные это прямо написано в скрам гайдах. Другой вопрос, что такой подход не всем может подходить или не всем нравится. Но если судить по вашему комментарию, у вас сама идея кросс функциональных команд вызывает вопросы. Что странно в статье про скрам )
Но если по сути, то статья выглядит немного странно. С одной стороны подаётся как пример успешного внедрения скрам. С другой такое ощущение что все изменения инициализировать и проводились сверху, менеджером и тех льдом и консультантами. Не до конца ясно какую роль в этом играли сами команды, кроме выдачи фидбека. И тут есть два момента на мой взгляд, можно ли такое в принципе считать scrum или agile. А второе, не один раз видел в подобных ситуациях картину, когда сверху командам прилетает какое то требование по изменению процессов, которое члены команды не понимают зачем нужно, и в итоге люди продолжают работать по старому посылая наверх фидбек, что все теперь хорошо, или проводя формально какие то ритуалы просто потому что "так надо" не видя в них реально никакой ценности.
Как слесарь, по первой специальности, хочу сказать, что в вашем новом процессе у вас шестерни в зацепление не входят
мне всегда казалось, что разница между "я просто пишу код" и способностью самостоятельно принимать решения, думать о том какое вэлью приносит работа, а не "я просто пилю фичу" и вот это все. это как раз что отличает мидла от синьора.
за исключением узкой прослойки специалистов с прямо очень уж хорошими техническими скилами.
у меня вопрос уже к первому абзацу. "если убрать все серам атрибуты то менеджерам будет нечего делать"
Я прошу прощения, но в скраме разве есть такая роль "менеджер"? Я не то что бы большой фанат скрам (имхо это такой костыль, для тех кто никогда не работал по agile). Но по моему каждый раз когда в критике скрам появляется слово "менеджер" это такой Ред флаг, говорящий что сейчас будет не критика скрам, а критика чего то, на что пытаются натянуть снятую со скрам "кожу" в виде терминологии, ритуалов и тп. Но что ни к скрам ни к аджайл отношения не имеет
ну бывает ещё вариант, что аджайл просто не подходит.
ну или вон как в примере, "команды делают костыли чтобы успеть к концу спринта", ну так может спринты реально слишком короткие, причем тут аджайл.. нигде же гвоздями не прибито что спринт должен быть 2 недели.
даже не знаю. вообще не матчится с моим опытом. у меня такие разработчики уходили обычно либо потому что им платили недостаточно их уровню экспертизы, или потому что им просто становилось скучно.
а такого что менеджер выживал хорошего специалиста потому что боялся за свой авторитет, это какой то невероятный уровень токсичности должен быть в команде
мне кажется у дяди боба в совершенной архитектуре максимально просто описано, там в духе что процедурное - про то что должна быть одна точка входа, одна точка выхода, запрет на использование переходов типа goto и тп, функциональное - про то что нужно использовать чистые функции, иммутабельность и тп, а обьектно ориентированное - про то что держать данные и методы которые эти данные используют рядом и данные должны быть видимы только тому коду которому они нужны а не торчать куда попало. как то так. И не важно как это все формально называется, какие используются ключевые слова какой синтаксис. И все это можно в определенной степени комбинировать.
использую чат гпт для быстрой справки. гораздо быстрее выходит чем лезть в доки/гугл/стаковерфлоу
хорошая статья, нужна такая же про моментс