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