Есть такой момент. Увы, средствами разметки habr-а так же, как и в оригинале, разметить текст не удается. Варианты с изменением текста на «сверху-снизу» и вставку картинки счел некорректными.
Брукс, кстати, отмечает эффект снижения эффективности команды в целом для проекта от её быстрого роста. Добавляя людей в проект, вы только его замедлите. Однако, разумный и управляемый рост вполне допустим и оправдан. Это абсолютно не противоречит тому, что пишет Эстер.
Так и есть. Однако, надо понимать, что группа профессионалов-индивидуалов — не есть команда. Это раз. Развитие команды происходит быстрее, чем индивидуалов по-отдельности. Это два. Проверено собственной практикой.
На мой взгляд, кроме этого, есть и ещё один момент, который в этой статье не упомянут: наличие в группе работников, уже имеющих опыт. Лично я не слышал об успешной практике создания подобных команд из абсолютных новичков.
То, что описывает Том, это не Scrum, т.к. бэклог с историями на реализацию, не хранится в репозитории кода, и не совсем BDD, т.к. менее детально — не определяет поведение методов в каждом случае, и понятно и команде разработчиков — кто, что и как собирается реализовывать, и пользователю — после окончания реализации кода Readme файл остается. Естественно, надо и к этой практике подходить с умом.
А вообще, agile методики, на то и agile методики, что не определяют обязательных правил, которыми надо руководствоваться: если вам это удобно и приносит пользу, используйте, если нет — не используйте. :)
Согласен, «пообщаться с командой» — это самый эффективный вариант. Правда он не всегда работает, как например, в случае, если члены команды находятся в разных часовых поясах.
Вообще-то идея в том, чтобы писать Readme до того, как начинать кодировать. Это значит, что ещё нет ни кода, ни, соответственно, комментариев.
На мой взгляд, эта идея вполне соответствует принципу agile «Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.»
Лично я предпочитаю набросать что-то письменно. Причём, это что-то для себя — что-то среднее между описанием того, что получится и технической документацией. Если развить до уровня команды, получается распространение индивидуальных идей и, как их сумма, общее видение того, что получится.
Неожиданно: в только что запущенном сервисе от Data LiberationGoogle Takeout (выгрузка своих данных из сервисов Google), если зайти под аккаунтом Google Apps уже показывается Google Profile. К сожалению только показывается.
А вообще, agile методики, на то и agile методики, что не определяют обязательных правил, которыми надо руководствоваться: если вам это удобно и приносит пользу, используйте, если нет — не используйте. :)
На мой взгляд, эта идея вполне соответствует принципу agile «Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.»
Blade Runner
Nirvana
А еще можно было подключить внешний привод и установить openSUSE с Live дистрибутива.
Хм… а ничего так.