Гибкая методология разработки

— Привет, Амиго!

— Привет, Билаабо!

— Сегодня я расскажу тебе о том, как обычно разрабатываются программы.

В 20 веке, когда современное ИТ только зарождалось, всем казалось, что программирование чем-то похоже на строительство или производство.

Обычно дело обстояло примерно так:

Заказчик рассказывал, какая программа ему нужна, что и как она должна делать.

Бизнес-аналитики выслушивали его и, на основе его историй, составляли полный список требований к программе.

Затем менеджеры проекта разбивали эти требования на задачи (таски), а также определяли, какой программист будет делать какую таску и в каком порядке.

Затем программисты приступали к работе. Иногда это могло занять несколько лет(!).

Когда работа была сделана, программу отдавали тестировщикам.

Тестировщики проходились по каждому пункту требований к программе и проверяли, что он реализован и программа работает как надо.

Если что-то было не так, тестировщики писали баги и отправляли их программистам.

Затем программисты фиксили (исправляли) эти баги и опять отправляли исправленную программу тестировщикам. И так по кругу.

Когда основные баги были исправлены, программа отдавалась заказчику.

— Что, так прям все и происходило?

— Ну, тут конечно многое упрощено, но дело почти так и было.

— И что, проект реально мог писаться полтора-два года?

— Иногда, когда разработка проекта была очень длительной, ее разбивали на отдельные релизы. Каждые 3-6 месяцев разработчики обязаны были сделать определенную часть функционала программы, протестировать ее, исправить все баги и показать заказчику.

Чтобы он мог внести свои замечания и, что более важно, продолжал платить деньги за разработку программы.

— Продолжал платить?

— Тогда разработка очень часто растягивалась в 2-3 раза. А т.к. оплата труда программистов часто была почасовая, то и стоимость программы вырастала в 2-3 раза. А вот польза от нее при этом падала. Ведь то, что нужно сегодня и за $100,000, совсем не обязательно будет нужно через 3 года, да еще за втрое большую цену.

— Т.е. заказчики часто отказывались платить?

— Ага. Потом они придумали добавлять в договоры штрафные санкции, но это ситуацию не улучшило. Разработка программ затягивалась и затягивалась, и никто не мог с этим ничего поделать, даже если хотел.

— А почему так?

— Ну, во-первых, на этапе планирования слишком многое не известно. Чаще всего, проблемы, с которыми сталкивались программисты, в самом начале не мог предсказать никто.

— Но ведь опытные программисты должны были бы сами все предвидеть, разве нет?

— Видишь ли, программирование – это уникальная профессия.

Обычный специалист очень часто выполняет одну и ту же работу. Часовщик делает часы, повар – готовит, учитель – учит, врач – лечит, и т.д.

Фактически каждый из них ежедневно занимается тем же, что и вчера. И поэтому начинает делать свою работу все лучше и лучше.

В программировании другой подход. Как только у программиста каждый день возникает одна и та же задача, он пишет для нее функцию/модуль/программу и больше к ней не возвращается.

Каждую свою задачу программист обычно решает один раз в жизни.

Чем-то похоже на ученого или на инженера-конструктора, который что-то изобретает.

— Ага. А какая роль в проекте самая важная?

— Ну, что тебе сказать. Легко сказать, какая самая важная, сложно сказать – какая самая не важная.

Основная задача тестировщиков (Quality Assurance, QA) – следить за состоянием работы программы и вовремя рапортовать о найденных ошибках. Чем больше и раньше тестировщик найдет ошибок, тем больше их будет исправлено. Хороший тестировщик влияет на качество продукта больше, чем хороший программист.

— А почему программист не может сам тестировать свою программу. Ведь он лучше знает, что в ней работает, а что – нет?

— Хороший программист просто не может быть хорошим тестировщиком. Программист хорошо знает, как устроена программа, поэтому пользуется ей всегда специфическим образом. В отличие от пользователя, который пользуется программой, как бог на душу положит.

Кроме того, тестировщик не тестирует то, что еще не работает. Тестировщик тестирует ту функциональность, те части программы, которые по мнению программиста уже работает и работают чуть ли не идеально.

И вот когда тестировщик находит там горы ошибок, а программист их исправляет, продукт действительно становится ближе к идеалу.

Основная задача программиста (Software Developer Engineer, Developer, SDE) – реализовывать новую функциональность. Или, если быть проще – выполнять назначенные на него задачи. Назначили задачи с новыми фичами – делает их. Назначили баги – фиксит баги.

— Что-то у тебя одни англицизмы в разговоре. Каждое второе слово.

— Это не столько англицизмы, сколько профессиональный сленг. Привыкай.

Но иногда бывают задачи и посложнее, например, придумать архитектуру программы или ее части. Чем лучше будет предложенная архитектура, тем легче будет делать дальнейшую работу.

Проблема в том, что архитектуру надо выбрать в самом начале, а удачную ты выбрал архитектуру или нет, становится понятно не раньше середины разработки.

Более того, если архитектура была удачной и программа получилась отличной, то, скорее всего, на ее базе заказчик захочет выпустить новую версию программы.

Это я к чему.

Какую бы версию архитектуры программы ты ни выбрал, всегда найдется куча изменений, дополнений, новых фич, которые этой архитектурой не учитываются.

Вот тебе хороший пример.

Заказал клиент построить дом на 5 этажей, ты придумал архитектуру, и дом построили.

Затем заказчик говорит, а давайте достроим еще один этаж, а затем еще один и т.д.

А ведь стены первых этажей на такую нагрузку не рассчитаны, фундамент тоже, вот и приходится все переделывать.

А если заказчик после дома в 5 этажей захочет дом сразу в 50?

— Тогда легче снести то, что было и построить все заново…

— Но насчет архитектуры, у меня для тебя есть один совет.

Архитектура приложения в первую очередь должна быть гибкой и подразумевать, что при решении переделать половину программы не придется полностью переделывать вторую половину. Такую архитектуру обычно называют гибкой и модульной.

Основная задача менеджера – это принимать решения. Менеджер – это человек, который видит всю картину и принимает решения исходя из этого.

Допустим, в процессе разработки выяснилось, что некоторая задача не получится в таком виде, в каком ее хотят видеть. И тут менеджер может:

а) попробовать договориться с заказчиком, чтобы эту задачу поменяли;

б) выделить больше времени на эту задачу;

в) привлечь более опытных программистов с других проектов.

Тут еще много вариантов.

Дело в том, что в каждом из них придется чем-то жертвовать, а задача менеджера – свести суммарный ущерб от таких жертв до минимума.

Или, например, ведущего программиста перекупают конкуренты, предложив в два раза больше денег.

Менеджер может:

а) ничего не делать. Программист уходит, проект, вероятно, затянется и попадет на штрафные санкции.

б) поднять ему зарплату в два раза. Тогда остальные люди в команде тоже захотят себе повышения ЗП. Если всем им дать денег, расходы на проект вырастут, и он может стать убыточным.

в) свой вариант.

— Ясно.

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

Хороший менеджер и команда средних программистов почти всегда сделают проект быстрее, чем плохой менеджер и команда отличных программистов.

— Ясно.

— Вот как выглядят эти профессии глазами друг друга:

— Ха-ха, смешно.

— Ладно, давай сделаем небольшой перерыв, а потом – продолжим.