Есть старая шутка: «Если и существует такая вещь, как хороший парик, то я никогда его не видел». Секрет Полишинеля в Голливуде: ведущие актеры, такие как Тед Дэнсон и Берт Рейнольдс, носят парики. Но не ковры из енота — очень дорогие, искусно сделанные, которые никто не может отличить от натурального волоса.

Agile разделяет это качество: когда это хорошо, вы этого не замечаете. На самом деле первоначальный манифест Agile утверждает это в своих принципах: «Предпочитайте людей процессу». Но слишком часто организации изменяют процесс Agile, чтобы избежать изменения сложной внутренней динамики. Это приводит к тому, что Кент Бек, подписавший манифест Agile, называет «Scrum But», например: «Мы практикуем Scrum, *но*…» (Scrum — обсуждается позже — настолько тесно связан с Agile, что их часто используют взаимозаменяемо).

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

Доставьте наиболее важные функции как можно скорее.

Просто, верно? Конечно, просто не легко! Люди часто чрезмерно усложняют Agile, потому что, как хороший парик, они никогда не видели, чтобы он был сделан правильно.

Для меня наиболее исчерпывающим способом показать вам, как правильно применять простой Agile, было бы пригласить вас присоединиться к проекту в самом начале и «следовать» по мере прохождения этапов. Поскольку это невозможно в статье, вместо этого мне придется описать процесс. В духе Agile сделаю максимально просто, но так как просто не бывает легко, то и короткого не будет. Давайте разобьем его на три части:
1. Основной принцип
2. Ежедневная практика
3. Основные моменты: оценка разработки программного обеспечения

Основной принцип

В часовом деле все, кроме часовой и минутной стрелок, например, хронометра или указателя даты, называется усложнением. Это усложняет реализацию механизма. Но это не делает часы с индикацией только часа и минуты простыми! Эта операция достаточно сложная, без каких-либо дополнительных осложнений.

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

Agile стремится предоставлять функции как можно скорее, сводя процесс к абсолютному минимуму. Но есть минимумы, ниже которых лежит провал. Одним из таких минимальных компонентов является тестирование.

Какова самая важная особенность вашего проекта? Есть поговорка, которую используют некоторые спортсмены: «Второе место — это просто «первый проигравший». Грубовато, но Agile требует безжалостной расстановки приоритетов. Если ваша самая важная функция не работает, имеет ли смысл что-то еще в вашем проекте?

Вы можете подумать об «особом соусе», который делает ваше приложение убийственным. Но это бесполезно, если ваши пользователи не могут получить к нему доступ. Таким образом, такие функции, как «войти», а до этого «создать учетную запись», на самом деле более важны.

Самая важная особенность всех программных проектов — это что-то вроде «это должно работать». Если веб-сайт, приложение или библиотека не компилируются и не выполняются, никакие другие функции не имеют значения.

Agile-проекты требуют автоматизированного тестирования, и точка. Если вы не тестируете, вы не Agile. По мере того, как мы добавляем все больше и больше функций, функции, предоставленные ранее — по определению более важные, чем более поздние — должны оставаться функциональными. Если менее важная/более поздняя функция ломает более важную/более раннюю, мы нарушили наши приоритеты.

Ручное тестирование поначалу может работать, но по мере роста проекта оно становится неэффективным. Кроме того, десятилетия передового опыта показали, что код, написанный так, чтобы его можно было легко тестировать, имеет огромные преимущества: значительно меньше ошибок, большая поддержка дополнительных функций и многое другое. Написание тестируемого кода начинается очень сложно, но со временем становится легче. Не делать этого с самого начала — не вариант, если только вы не хотите «ад разработки» в конце проекта, когда изменение какой-либо части кода вызывает проблемы где-то еще.

Начните с так называемого «дымового теста». Название происходит от электронного оборудования: если вы подаете питание на схему, а паяные соединения начинают дымиться, что-то ужасно неправильное. Дымовой тест просто утверждает, что страница загружается, или объект существует, или какие-то другие базовые критерии. Он также утверждает, что тестовая установка работает! По мере того, как проект развивается для поддержки более сложных функций, смоук-тест по-прежнему имеет преимущество: когда многие тесты функций терпят неудачу одновременно, состояние смоук-теста помогает быстро определить, влияет ли проблема на всю систему.

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

Еще одно место, где кажется заманчивым сократить процесс, на самом деле ненавязчиво связывает команды разработчиков и бизнес-команды: передача от проектирования к разработке. Новички в Agile-процессе часто предполагают, что вместо того, чтобы заставлять бизнес-заинтересованных лиц писать критерии приемлемости, разработчики должны работать с макетами изображений, которые исходят от команды дизайнеров. Кажется, что это простой способ сэкономить время, но он сопряжен с большим риском.

«Картинка стоит тысячи слов» — это правда; но ценность большинства из этих тысяч слов в том, как должен выглядеть дизайн. Когда вы даете разработчику картинку и просите его придумать, как должно вести себя программное обеспечение, вы просите его принять бизнес-решение. Разработчики должны уметь программировать — просить их работать так далеко за пределами их области неэффективно.

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

«Преждевременная оптимизация» — это жаргон программного обеспечения, означающий «решение проблемы, которой у вас еще нет». Разработчики, как известно, думают обо всех требованиях, которые могут когда-либо предъявляться к программному обеспечению. Иногда они сосредотачиваются на производительности, рассчитывая время загрузки на основе воображаемого прогнозируемого количества будущих пользователей; иногда речь идет о функциях, делающих каждый элемент приложения бесконечно настраиваемым «на всякий случай».

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

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