Это все хорошо звучит в теории, но так себе реализуемо на практике. Единственный способ реализовать это — сделать механизм выключения фич, что требует дополнительных затрат.
Просто пример. Вот есть у вас система плагинов. Понадобилось ее полностью переписать (например, хотите SOA внедрить для нее) Ну как ни крути нельзя ее разбить на маленькие стори сначала. Пока не готов фреймворк, вы не сможете переписывать отдельные плагины. Можно поставлять старые плагины вместе с новыми. Но зачем? А можно просто делать их в отдельном бранче и выпустить, когда все будет готово.
У нас был XP сначала, но в принципе процесс планирования там и в Scrum практически одинаковые. Итерации у нас были года 3. Отказались по разным причинам. Во-первых, частенько не успевали сделать все, что запланированно. Как мы ни старались улучшить эстимейты, все равно бывали ошибки и в полтора и в два раза. Во-вторых, хотелось иметь возможность выпускать релизы в любое удобное время, без итераций это делать гораздо проще. В-третьих, легче совмещать длинные и сложные фичи с небольшими улучшениями. Можно часто выпускать небольшие улучшения, параллельно работая над серьезными фичами.
Я думаю, что Scrum хорош для начала проекта и разработки с нуля. Но для матерых продуктов лучше Kanban.
Не думаю, что твое утверждение каким-то образом противоречит статье, но безусловно является не полным.
Вот соберешь ты команду креативных, мотивированных студентов, которые не умеют программировать.
И че? За год сделаешь новый фейсбук?
Кстати, на эту тему. Частенько говорят, что команда должна быть self-organized. Особенно на это делают упор в Scrum. Я уверен, самоорганизация невозможно без хорошего лидера. Команда середнячков, конечно, тоже самоорганизуется, но она скорее будет делать упор на выживание, чем на достижения высоких целей. Так что нужен лидер и хотя бы пару сильных духом и скилом людей.
Хороший поинт. Но надо попасть в команду, где люди любят учить других людей. А еще лучше если там практикуется (хотя бы частично) парное программирование.
Видимо, надо пояснить.
Минимум общения — значит минимум оверхеда.
Конечно общение должно быть. Но надо очень аккуратно выбирать митинги и оценивать их целесообразность.
И конечно, если есть сомнения в решении проблемы, надо их обсудить с кем-то.
И конечно, если есть новые идеи, их тоже надо обсудить.
Но. Не надо прибегать к товарищу, вырывать его из состояния потока, и рассказывать новую гениальную идею.
Не надо также прибегать и сразу задавать вопрос, ответ на который знает гугл.
И еще много чего не надо делать.
Общение общению рознь.
Просто пример. Вот есть у вас система плагинов. Понадобилось ее полностью переписать (например, хотите SOA внедрить для нее) Ну как ни крути нельзя ее разбить на маленькие стори сначала. Пока не готов фреймворк, вы не сможете переписывать отдельные плагины. Можно поставлять старые плагины вместе с новыми. Но зачем? А можно просто делать их в отдельном бранче и выпустить, когда все будет готово.
Я думаю, что Scrum хорош для начала проекта и разработки с нуля. Но для матерых продуктов лучше Kanban.
Вот соберешь ты команду креативных, мотивированных студентов, которые не умеют программировать.
И че? За год сделаешь новый фейсбук?
Минимум общения — значит минимум оверхеда.
Конечно общение должно быть. Но надо очень аккуратно выбирать митинги и оценивать их целесообразность.
И конечно, если есть сомнения в решении проблемы, надо их обсудить с кем-то.
И конечно, если есть новые идеи, их тоже надо обсудить.
Но. Не надо прибегать к товарищу, вырывать его из состояния потока, и рассказывать новую гениальную идею.
Не надо также прибегать и сразу задавать вопрос, ответ на который знает гугл.
И еще много чего не надо делать.
Общение общению рознь.