Информация об изменениях

Сообщение Re[9]: Scrum не подходит для программной разработки от 06.03.2021 15:52

Изменено 06.03.2021 19:23 Министр Промышленности

Re[9]: Scrum не подходит для программной разработки
САД>на предпочтения разработчиков, как правило, всем насрать. работать будут так, как им скажут.

это грубо неправильно, поскольку разработка у них скорее всего ключевая деятельность
с точки зрения разработчика — нужно оценить потери в комфорте карме и нервах и жоходах
рассмотреть возможность уволиться


МП>>скрам практики добавляют и навязывают несколько лишних совещаний, которые все являются по меньшей мере переключением контекста


САД>знаешь что забавно? в своей скрам комманде, я сократил количество стендапов и прочих миттингов к минимуму.

САД>но потому девелоперы попросили их добавить назад. и я прекрасно понимаю зачем и меня это радует. а ты?

на моих последних 2х работах разработчики стонали от скрама, но веса не хватало его отменить
в Luxoft разок получился курьёзный случай:
менеджер проекта задержался на стендап, а все разработчики уже собрались на конфу и базарили
речь сначала зпшла про химию, а потом как-то я захватил повествование и изложил кратко технологию производства напрягающего бетона
менеджер так и не пришёл а время стендапа закончилось, так что я плавно завершил речь и сказал что похоже пора расходиться
для проекта не поменялось ровным счётом ничего, был даже плюс, посколько некоторые поржали с такого поворота событий

на другой работе до того был якобы скрам, но от него остались только стендапы ближе к концу рабочего дня — там было норм
по сути это был просто способ социализации команды


МП>>что расслабленный девелопмент это разумеется технологически лучше, чем "ужаленный в жопу" менеджмент

МП>>но хуже, чем с умеренным напряжением здоровая проектная работа с целью и ништяками за успех
МП>>(на практике правда всего перечисленного сразу сам нигде не видел — ништяки всегда куда-то пропадали)

САД>девелопмент должен быть комфотрным. для всех. и для девов, и для манагеров. поощрения, они, безусловно есть, но это не значит, что человек должен овертаймить постоянно.

САД>комфорт и размеренность, дают стабильные результат на протяжении всего года.
САД>нет вот этого вот всего студенческого, когда мы пол года расслабляемся, а потом в последний месяц херачим с овертаймами. нет. это не то, что нужно проекту.
САД>но если у вас только такой подход... что ж... боритесь

нет, овертаймы это не по технологии
фундаментальная подоснова под этим следующая, упрощенно:
у разработчика моральные силы восстанавливаются довольно медленно
(моральные силы разработчика — это на самом деле главный показатель покруг которого и должен плясать процесс)
восстанавливаются не на 8 часов в день, а на 5-6
это усреднённый показатель, на деле эти силы тратятся на создание контекста, и меньше тратятся на его удержание и развитие, если нет отвлечений
соответственно, даже 8-часовой рабочий день в идеале выработает все силы раньше чем он закончится на 2-3 часа
а овертаймы тем более
Re[9]: Scrum не подходит для программной разработки
САД>на предпочтения разработчиков, как правило, всем насрать. работать будут так, как им скажут.

это грубо неправильно, поскольку разработка у них скорее всего ключевая деятельность
с точки зрения разработчика — нужно оценить потери в комфорте карме и нервах и жоходах
рассмотреть возможность уволиться


МП>>скрам практики добавляют и навязывают несколько лишних совещаний, которые все являются по меньшей мере переключением контекста


САД>знаешь что забавно? в своей скрам комманде, я сократил количество стендапов и прочих миттингов к минимуму.

САД>но потому девелоперы попросили их добавить назад. и я прекрасно понимаю зачем и меня это радует. а ты?

на моих последних 2х работах разработчики стонали от скрама, но веса не хватало его отменить
в Luxoft разок получился курьёзный случай:
менеджер проекта задержался на стендап, а все разработчики уже собрались на конфу и базарили
речь сначала зашла про химию, а потом как-то я захватил повествование и изложил кратко технологию производства напрягающего бетона
менеджер так и не пришёл а время стендапа закончилось, так что я плавно завершил речь и сказал что похоже пора расходиться
для проекта не поменялось ровным счётом ничего, был даже плюс, посколько некоторые поржали с такого поворота событий

на другой работе до того был якобы скрам, но от него остались только стендапы ближе к концу рабочего дня — там было норм
по сути это был просто способ социализации команды


МП>>что расслабленный девелопмент это разумеется технологически лучше, чем "ужаленный в жопу" менеджмент

МП>>но хуже, чем с умеренным напряжением здоровая проектная работа с целью и ништяками за успех
МП>>(на практике правда всего перечисленного сразу сам нигде не видел — ништяки всегда куда-то пропадали)

САД>девелопмент должен быть комфотрным. для всех. и для девов, и для манагеров. поощрения, они, безусловно есть, но это не значит, что человек должен овертаймить постоянно.

САД>комфорт и размеренность, дают стабильные результат на протяжении всего года.
САД>нет вот этого вот всего студенческого, когда мы пол года расслабляемся, а потом в последний месяц херачим с овертаймами. нет. это не то, что нужно проекту.
САД>но если у вас только такой подход... что ж... боритесь

нет, овертаймы это не по технологии
фундаментальная подоснова под этим следующая, упрощенно:
у разработчика моральные силы восстанавливаются довольно медленно
(моральные силы разработчика — это на самом деле главный показатель покруг которого и должен плясать процесс)
восстанавливаются не на 8 часов в день, а на 5-6
это усреднённый показатель, на деле эти силы тратятся на создание контекста, и меньше тратятся на его удержание и развитие, если нет отвлечений
соответственно, даже 8-часовой рабочий день в идеале выработает все силы раньше чем он закончится на 2-3 часа
а овертаймы тем более