Мы обычно узнаем о новых методах разработки программного обеспечения, оплачивая консультантов и читая отчеты Gartner. Благодаря им, мы смогли узнать, что для нас должны быть важны:
На недавней конференции я вдоволь наслушалась разговоров трёх менеджеров о самоорганизующихся командах.
«Вы не можете просто так взять и дать волю людям, и предоставить команде всё решать самой. Они же всё испортят! Да, и к тому же, все эти Scrum-мастера, тренеры и самоорганизующиеся команды похоже могут оставить меня без работы», — говорил один из них с обречённостью в голосе.
«Ограничения по времени классная штука», — говорил другой. «Засуньте их всех в комнату, поддайте жару и они начнут творить», — утверждал он.
«О, так это означает, что я могу перетасовывать людей между проектами и они сами просто объединятся в команду и самоорганизуются. Я могу иметь подвижные Scrum команды по первому требованию!» — восклицал третий.
Последнее время я слышу множество разговоров о разработке, основанной на тестировании (TDD), о разработке, основанной на функционировании (BDD), об экстремальном программировании (XP), о SCRUM-е, о собраниях стоя и ещё Бог знает о каком количестве методик для создания ПО, но все эти методики не имеют смысла, если ПО, которое мы создаём не соответствует требованиям пользователей. Давайте я попробую это объяснить по-другому. Идеальная реализация неправильно составленной спецификации бесполезна. Так же, как и полезность прекрасно написанной библиотеки стремится к нулю, если у неё нет документации. Что-то определённо не так, если ваше приложение не решает поставленную проблему или, если никто не знает как им воспользоваться.
Здорово. И как же нам решить эту проблему? Проще, чем вы думаете, и достаточно важно, чтобы выделить ответ в отдельный параграф.
