Сообщение Re[13]: Scrum не подходит для программной разработки от 08.03.2021 11:12
Изменено 08.03.2021 11:17 Министр Промышленности из Minecraft'а
Re[13]: Scrum не подходит для программной разработки
МП>>вот именно — ни о чём, она не нужна
L>Ну, для удаленного саппорта говен мамонта и правда не нужна.
для саппорта она как раз не сможет навредить так сильно
L>Для командной разработки софта — жизненно необходима.
нет
если надо скоординировать работу, то два разработчика списываются или созваниваются друг с другом,
а не слушают по расписанию всю байду которую вещает весь отдел
в редких случаях — там будет более двух разработчиков — решат по потребности
МП>>также интересно в какой части дня она проводится
МП>>если утром в начале дня и за пропуск карают — это фактор того, что разработчики будут сидеть на работе сонные
МП>>если в середине или конце дня — это прерывание и сбивка контекста
L>Короче, очередные стенания на тему "где бы не работать, лишь бы не работать".
чо за бред
выделенное — основополагающий принцип технологии разработки
это не про отлынивание от работы, а про то, как работу реально сделать
L>Я знаю, что подавляющее большинство здесь присутствующих предпочитают работать в режиме "оставьте меня в покое". Я бы и сам так работал, есличо.
вот так и работай
L>Только вот время одиночек, выдающих на-гора полезный продукт, закончилось лет 20 назад. Сегодня разработка софта — это очень сложный инженерный процесс, который нельзя отдавать на откуп индивидуальным разработчикам. Результат такого подхода — это вотерфольное состояние продукта, который "почти готов" в течение года до релиза, но в QA в первый раз запускается и не падает сразу только в ночь перед дедлайном.
восторженные мантры пошли
L>Ну, для удаленного саппорта говен мамонта и правда не нужна.
для саппорта она как раз не сможет навредить так сильно
L>Для командной разработки софта — жизненно необходима.
нет
если надо скоординировать работу, то два разработчика списываются или созваниваются друг с другом,
а не слушают по расписанию всю байду которую вещает весь отдел
в редких случаях — там будет более двух разработчиков — решат по потребности
МП>>также интересно в какой части дня она проводится
МП>>если утром в начале дня и за пропуск карают — это фактор того, что разработчики будут сидеть на работе сонные
МП>>если в середине или конце дня — это прерывание и сбивка контекста
L>Короче, очередные стенания на тему "где бы не работать, лишь бы не работать".
чо за бред
выделенное — основополагающий принцип технологии разработки
это не про отлынивание от работы, а про то, как работу реально сделать
L>Я знаю, что подавляющее большинство здесь присутствующих предпочитают работать в режиме "оставьте меня в покое". Я бы и сам так работал, есличо.
вот так и работай
L>Только вот время одиночек, выдающих на-гора полезный продукт, закончилось лет 20 назад. Сегодня разработка софта — это очень сложный инженерный процесс, который нельзя отдавать на откуп индивидуальным разработчикам. Результат такого подхода — это вотерфольное состояние продукта, который "почти готов" в течение года до релиза, но в QA в первый раз запускается и не падает сразу только в ночь перед дедлайном.
восторженные мантры пошли
Re[13]: Scrum не подходит для программной разработки
МП>>вот именно — ни о чём, она не нужна
L>Ну, для удаленного саппорта говен мамонта и правда не нужна.
для саппорта она как раз не сможет навредить так сильно
L>Для командной разработки софта — жизненно необходима.
нет
если надо скоординировать работу, то два разработчика списываются или созваниваются друг с другом,
а не слушают по расписанию всю байду которую вещает весь отдел
в редких случаях — там будет более двух разработчиков — решат по потребности
МП>>также интересно в какой части дня она проводится
МП>>если утром в начале дня и за пропуск карают — это фактор того, что разработчики будут сидеть на работе сонные
МП>>если в середине или конце дня — это прерывание и сбивка контекста
L>Короче, очередные стенания на тему "где бы не работать, лишь бы не работать".
чо за бред
выделенное — основополагающий принцип технологии разработки
это не про отлынивание от работы, а про то, как работу реально сделать
L>Я знаю, что подавляющее большинство здесь присутствующих предпочитают работать в режиме "оставьте меня в покое". Я бы и сам так работал, есличо.
вот так и работай
L>Только вот время одиночек, выдающих на-гора полезный продукт, закончилось лет 20 назад. Сегодня разработка софта — это очень сложный инженерный процесс, который нельзя отдавать на откуп индивидуальным разработчикам. Результат такого подхода — это вотерфольное состояние продукта, который "почти готов" в течение года до релиза, но в QA в первый раз запускается и не падает сразу только в ночь перед дедлайном.
восторженные мантры пошли
L>Ну, для удаленного саппорта говен мамонта и правда не нужна.
для саппорта она как раз не сможет навредить так сильно
L>Для командной разработки софта — жизненно необходима.
нет
если надо скоординировать работу, то два разработчика списываются или созваниваются друг с другом,
а не слушают по расписанию всю байду которую вещает весь отдел
в редких случаях — там будет более двух разработчиков — решат по потребности
МП>>также интересно в какой части дня она проводится
МП>>если утром в начале дня и за пропуск карают — это фактор того, что разработчики будут сидеть на работе сонные
МП>>если в середине или конце дня — это прерывание и сбивка контекста
L>Короче, очередные стенания на тему "где бы не работать, лишь бы не работать".
чо за бред
выделенное — основополагающий принцип технологии разработки
это не про отлынивание от работы, а про то, как работу реально сделать
L>Я знаю, что подавляющее большинство здесь присутствующих предпочитают работать в режиме "оставьте меня в покое". Я бы и сам так работал, есличо.
вот так и работай
L>Только вот время одиночек, выдающих на-гора полезный продукт, закончилось лет 20 назад. Сегодня разработка софта — это очень сложный инженерный процесс, который нельзя отдавать на откуп индивидуальным разработчикам. Результат такого подхода — это вотерфольное состояние продукта, который "почти готов" в течение года до релиза, но в QA в первый раз запускается и не падает сразу только в ночь перед дедлайном.
восторженные мантры пошли