Agile, Scrum, модные слова для написания программного обеспечения, которое обеспечивает результат
Независимо от того, с какой стороны вы на это посмотрите, в целом разработчики программного обеспечения для бизнеса имеют плохую репутацию. Системы почти неизбежно поставляются с опозданием или даже не поставляются вообще. Среднестатистический пользователь в средней компании будет тратить буквально часы каждую неделю, жалуясь на компьютерные системы, с которыми ему приходится мириться. «Почему это сделано?», «Что, черт возьми, это значит?» это пара вещей, которые я слышу каждый день.
Я потратил годы на написание бизнес-систем, и по большей части пользователи положительно отзывались о том, что они получали и использовали. Системы написаны в соответствии с первоначальной спецификацией, протестированы до смерти, а затем адаптированы по мере необходимости и по согласованной цене, если это необходимо. Постоянная поддержка клиента и стабильный доход компании-разработчика программного обеспечения стали выигрышной комбинацией. Первоначальная спецификация, основанная на детальном анализе требований, всегда будет функциональным обзором и не будет содержать каких-либо особенностей кода. Кажется, я когда-то использовал псевдокод (когда писал игры). «Это то, для чего нам это нужно» обычно было для меня достаточно хорошо. Помимо этого, было несколько макетов пользовательского интерфейса, большой объем работ по проектированию базы данных, и понеслось. Фаза тестирования и «настройки» жизненного цикла разработки была очень важна. Системы в целом доставлялись вовремя и работали.
В наши дни (я никогда не думал, что скажу такое) все, что связано с системами, связано с планированием, еще большим планированием, а затем с возможностью повторного использования. Что мне кажется таким чуждым, так это то, что большая часть этого планирования направлена не на удовлетворение функциональных требований, а, скорее, на детализацию того, как и почему мы собираемся писать то, что пишем, когда пишем это. Надеюсь, это имеет смысл? Зачем писать в 10 строк что-то, что вы могли бы сделать за 1000, если вам «возможно» понадобится повторно использовать это через 2 года? На личном уровне я никогда не писал ничего такого, чего не смог бы переписать лучше два года спустя. Я всегда учусь и совершенствуюсь, и когда я оглядываюсь назад на код, даже 12-месячной давности, я часто съеживаюсь. Глядя на объявления о вакансиях, легко потеряться в требуемых методологиях и навыках. Возможно ли по-человечески, чтобы один человек знал так много, о чем я часто спрашиваю себя? Другой вопрос: производят ли они когда-нибудь продукт? При всем этом планировании и беспокойстве по поводу повторного использования кода что-нибудь удается сделать? Я знаю компанию, которая нанимала академических разработчиков, которые были настолько заняты дизайном, что компания обанкротилась еще до того, как какой-либо продукт был даже близок к готовности, серьезно! Сколько задержек мы можем ожидать от людей, ведь этап тестирования никогда не был проблемой! Почему компания, платящая нам за продукт, должна платить за код, который будет использоваться снова и снова в последующих проектах, а не за них?
Не поймите меня неправильно, я не говорю, что планирование — это плохо, это важная часть разработки систем, но не единственная. Возможно, я придерживаюсь старой закалки, но мне нравится писать систему и заставить ее работать. Хорошо, я знаю, что системы постоянно становятся больше и сложнее. Большие команды разработчиков — это норма. Просто я считаю, что сколько бы вы ни планировали, визуализировали и мозговой штурм, всегда что-то будет упущено. Мы стремимся к невозможному, совершенным системам, но в худшем случае мы фактически не создаем никакой системы. Не верите мне? Посмотрите на Майкрософт. Представьте себе, сколько человеко-часов уходит на планирование любого из их приложений? Как часто обнаруживаются новые ошибки или уязвимости? Почему это не продумали на стадии проектирования? Команде разработчиков даже в голову не пришло, что «уязвимость X» вообще может возникнуть. Проще говоря, с чем-то большим, чем простейшая система, практически невозможно предусмотреть все возможные варианты развития событий, независимо от того, насколько вы логичны. Почему их не обнаруживают при тестировании? Является ли решение здесь старой школьной разработкой: меньше времени на планирование (обсуждение), больше времени на написание и тестирование? Меньше времени беспокоиться о повторном использовании кода, больше времени на предоставление клиенту и заказчику работающего продукта? Будет ли Microsoft лучше или хуже, если они будут тратить меньше времени на планирование и больше времени на тестирование? В защиту Microsoft они очень хорошо умеют устанавливать исправления, и я полагаю, что их можно рассматривать как использование нас в качестве тестировщиков. Может быть, если бы они потратили больше времени на правильное тестирование, нам не пришлось бы их тестировать?
Худший пример чрезмерного планирования, с которым я еще не сталкивался, — это финансовая система, которой я пользуюсь ежедневно. Внедрение этой системы обошлось в миллионы долларов, годы планирования и неизвестно сколько консультантов. Он написан одним из крупнейших игроков в индустрии программного обеспечения и адаптирован специализированной консалтинговой компанией по программному обеспечению. Конечным результатом этого является система, которая практически непригодна для использования и не слишком далека от того, чтобы быть замененной продуктом, снятым с полки. На самом низком уровне все настолько плохо, что даже неверный щелчок мышью приведет к зависанию приложения. Я не могу поверить, что эта система когда-либо тестировалась перед передачей. Он и так был доставлен очень поздно, причина заключалась в более продолжительном, чем ожидалось, «цикле планирования». То, что он делает, не так уж сложно, просто очевидно, что оно было запланировано до такой степени, что реализация была в спешке. Все это планирование даже не привело к созданию системы, которая отвечала бы основным функциональным требованиям своих пользователей, но хех, я уверен, что когда-нибудь они будут повторно использовать этот код.
В любом случае, я только что начал получать диплом, который поможет мне понять, почему так важно использовать несколько разных стратегий планирования. Зачем писать за 1 день то, что я мог бы потратить месяц на то, чтобы сделать «правильно»? Я знаю, что прочитаю это через пару лет и задаюсь вопросом, о чем я думал; либо так, либо я скажу себе: «Ух ты, именно тогда я действительно заканчивал то, что писал». А если серьезно, я уверен, что к концу я пойму, в чем ошибаюсь, а пока я просто продолжу писать приложения в своем стиле RAD (я рад, что у него есть имя!), которое хоть и не всем по вкусу, но мне вполне подходит.
nb Кто бы мог подумать, что у моего подхода к разработке есть название: он называется Agile-методологией! Вот отличная статья, которая объясняет гибкие методологии в некоторых подробностях.