На недавней конференции я вдоволь наслушалась разговоров трёх менеджеров о самоорганизующихся командах.

«Вы не можете просто так взять и дать волю людям, и предоставить команде всё решать самой. Они же всё испортят! Да, и к тому же, все эти Scrum-мастера, тренеры и самоорганизующиеся команды похоже могут оставить меня без работы», — говорил один из них с обречённостью в голосе.

«Ограничения по времени классная штука», — говорил другой. «Засуньте их всех в комнату, поддайте жару и они начнут творить», — утверждал он.

«О, так это означает, что я могу перетасовывать людей между проектами и они сами просто объединятся в команду и самоорганизуются. Я могу иметь подвижные Scrum команды по первому требованию!» — восклицал третий.

Время развеять некоторые заблуждения.

При попытке отредактировать этот старый пост слетело всё форматирование. Может быть я его когда-нибудь исправлю.

Я потратил несколько месяцев на борьбу с глюками Git-svn и обдумывание разных вариантов, прежде чем пришёл к этому методу организации рабочего процесса с сайтом — простому, гибкому и удобному в работе.

Основные преимущества:

• Делая push из удалённой копии мы автоматически обновляем live-копию сайта
• Правки файлов на сервере не будут разрушать историю коммитов
• Простота, не нужны особые правила выполнения коммитов
• Можно применить к уже запущенному сайту, без повторного деплоя или перемещения файлов

Последнее время я слышу множество разговоров о разработке, основанной на тестировании (TDD), о разработке, основанной на функционировании (BDD), об экстремальном программировании (XP), о SCRUM-е, о собраниях стоя и ещё Бог знает о каком количестве методик для создания ПО, но все эти методики не имеют смысла, если ПО, которое мы создаём не соответствует требованиям пользователей. Давайте я попробую это объяснить по-другому. Идеальная реализация неправильно составленной спецификации бесполезна. Так же, как и полезность прекрасно написанной библиотеки стремится к нулю, если у неё нет документации. Что-то определённо не так, если ваше приложение не решает поставленную проблему или, если никто не знает как им воспользоваться.

Здорово. И как же нам решить эту проблему? Проще, чем вы думаете, и достаточно важно, чтобы выделить ответ в отдельный параграф.

Первым делом создайте Readme файл.