В этом посте размещен перевод статьи Рона Джеффриса о технических навыках, необходимых для команд, практикующих agile-разработку.
В ответ на недавний твитшторм пара человек попросили меня перечислить все необходимые технические навыки, которые я в нем имел в виду. Не думаю, что смогу это сделать, но все же попытаюсь назвать хотя бы некоторые из них в этой статье.
Вот, кстати, несколько полезных статей на эту тему:
Какие подходы Agile необходимы
В статье «Навязываение Agile», упомянутой выше, я достаточно подробно описал то, что, по моему мнению, необходимо для организации гибкой разработки программного обеспечения. С другой стороны, для успешной agile разработки нам необходимо выполнять по крайней мере эти несколько простых, но совсем нетривиальных условий от начала и до конца создания продукта:
- В первую неделю работы над продуктом, создайте рабочий протестированный действующий Инкремент продукта. В нем будет совсем мало фич, но будет нечто, отражающее суть продукта.
- Каждую последующую неделю создавайте Инкремент продукта, добавляя какие-либо сценарии работы, выбранные вами для очередной сборки. Эти сценарии должны иметь ценность для клиентов и выбираться в процессе бизнес-ориентированного планирования в команде. (В этом процессе могут участвовать Владелец Продукта, реальные пользователи, смежные команды и так далее. Оно должно всегда быть ориентировано на возможности пользователей, а не на архитектуру, дизайн или что-либо в этом роде.)
- Инкремент продукта всегда должен быть полностью протестирован. Под этим я подразумеваю, что он должен быть протестирован достаточно, чтобы можно было с почти полной уверенностью определить, сколько в нем ошибок. И нужно постараться, чтобы это количество было близко к нулю. Если оно становится выше нуля, мы исправляем соответствующую ошибку, а также исправляем ту часть нашего процесса, из-за которой ошибка смогла пройти в продукт.
- Код Инкремента продукта всегда чистый. Имена понятны и согласованы. В коде мало дублирования или копипастных фрагментов. Он состоит из модулей (объектов, функций и т. д.), которые целостны сами по себе, но слабо связаны между собой. Если код становится менее чистым (а это с ним происходит всегда), мы возвращаем его в нужное состояние.
- Дизайн и архитектура Инкремента всегда хороши настолько, чтобы мы знали, как их реализовать. Если они начинают расползаться, от того, что мы считаем необходимым, возвращаем их в нужное состояние.
Условия, что я перечислил выше, могут показаться пугающими: надеюсь, что так и есть. Но дело в том, что их действительно требуется выполнять для того, чтобы работал даже самый простой Agile процесс ― Scrum. Вы мне не верите? Прочитайте короткое и увлекательное Руководство по Скраму и подумайте о том, что в действительности означает доставка Инкремента продукта.
Это означает, что каждую неделю (или две недели, если вы слабаки) вы доставляете реальную, протестированную, рабочую и наращиваемую версию продукта, которую можно выпустить в работу с действительно хорошим качеством. А поскольку нужно это делать каждую неделю (или две), она должна быть хороша как изнутри, так и снаружи.
Требуемые навыки
Итак, вышеперечисленные условия просты: по сути, в первую неделю мы должны создать близкую к совершенству мини-версию продукта и поддерживать ее высокое качество, добавляя при этом все больше и больше возможностей каждую неделю.
Звучит просто, но трудновыполнимо. Для этого необходимо множество навыков, причем большую часть нужных нам сведений не преподают в школах, и мы не можем почерпнуть их из книги Изучение Python за 180 дней. Их просто нет в подобных книгах.
Что же необходимо сделать, чтобы выполнить вышеперечисленные условия? Давайте подумаем.
- Разбиение историй: Чтобы в течение недели получить рабочую версию, то есть за Спринт, необходимо уметь отделять маленькие кусочки функциональности продукта ― настолько маленькие, чтобы их можно было выполнить за Спринт.
- Тестирование всего нового: Поскольку количество ошибок должно постоянно быть равно или близко к нулю, каждый новый кусочек Инкемента продукта должен быть полностью протестирован, а не только разработан, в течение той же недели.
- Тестирование всего старого: А поскольку мы будем улучшать дизайн, удалять дубликаты и добавлять необходимые возможности, необходимо также каждую неделю тестировать не только новые, но и все предыдущие функции.
- Развитие кода, дизайна и архитектуры: В начале Спринта у нас в голове еще может не быть окончательного дизайна и архитектуры. И, скорее всего, их еще и не должно быть. Но у нас всегда должен быть хороший код, дизайн и архитектура, что означает, что текущее качество кода, дизайна и архитектуры должно постоянно улучшаться с ростом возможностей продукта.
Эти несколько пунктов влекут за собой целый набор необходимых навыков. Программисты не рождаются со знанием того, как все это делается. Большинство знакомых мне людей, занятых технической стороной Agile, учились делать это годами, все лучше и лучше. Эти пункты просты, но они трудновыполнимы.
Технические практики
Существует множество практик и инструментов, помогающих выполнять эти простые, но трудновыполнимые вещи. Наилучшие из известных мне практик основаны на следующих основных принципах:
- Разработка через тестирование: Разработка через тестирование (TDD) ― это практика разработки, согласно которой мы пишем небольшой тест для следующего маленького кусочка функциональности, который собираемся добавить; убеждаемся, что этот тест пока не работает; создаем этот маленький кусочек функциональности; убеждаемся, что этот тест и все прочие тесты работают; а затем сразу же улучшаем качество кода и убеждаемся, что все тесты по-прежнему работают. Поскольку мы делаем это каждые несколько минут, все тесты должны быть автоматизированными и выполняться очень быстро.
- Рефакторинг: Улучшение кода, дизайна и архитектуры, о котором я упоминал выше, называется Рефакторингом. Это понятие означает улучшение дизайна кода: не массовое переписывание или замена больших участков кода, а небольшие инкрементальные изменения, которые постепенно возвращают дизайн к тому состоянию, в котором он должен быть. Если каждое изменение поведения продукта, которое мы добавляем, мало́, то, как правило, и изменения дизайна малы, а значит, задача рефакторинга в этом случае довольно проста. Иногда, однако, она бывает более сложной.
- Разработка через приемочное тестирование: На мой взгляд, разработка через приемочное тестирование (ATDD) ― это практика, главным образом нацеленная на общение между стейкхолдерами от бизнеса и разработки. Оно добавляет дополнительную уверенность в качестве продукта, но я считаю, что аспект общения более важен. ATDD ― это в некотором смысле внешний слой тестов, помимо TDD. Мы разрабатываем функции, ориентированные на клиентов, и используем «приемочные тесты» («клиентские тесты» или «продуктовые тесты») для того, чтобы описать то, что именно собираемся сделать, а затем показать самим себе и стейкхолдерам, что система действительно делает то, что планировалось изначально. Поскольку продукт (как и его дизайн) растет, мы хотим каждый раз проверять все его функции, а значит, эти тесты, как и тесты в TDD, должны быть автоматизированы.
- Глубокое знание архитектуры и дизайна: Это не практика и не инструмент, но я добавил это условие, потому что оно очень важно.1 Выше я упоминал Рефакторинг как способ достичь (в большинстве случаев) постоянного усовершенствования дизайна и архитектуры при инкрементальной разработке продукта. Чтобы применять этот способ, необходимо уметь отличать хорошую архитектуру и дизайн от не очень хороших. Мы должны иметь в запасе богатый набор приемов изменения архитектуры и дизайна, начиная от самых простых опций до более сложных, которые могут понадобиться по мере роста системы. Знаний о качестве архитектуры, кода и дизайна не бывает слишком много. Но, конечно, применять их следует разумно и постепенно, шаг за шагом.
- Непрерывная интеграция: В большинстве случаев мы приходим к выводу, что для еженедельного получения работающего протестированного продукта необходимо постоянно иметь работающий протестированный продукт, собирая его каждый день или даже каждые несколько часов. Для поддержки непрерывной интеграции существует целый арсенал различных инструментов и практик.
И это еще не все…
Выше я привел основные технические навыки, которые необходимо развивать. В интернете можно найти различные статьи и книги на эту тему. Кроме того, существуют курсы в режиме «онлайн» или «офлайн», которые обучают этому, такие же как и курсы scrum.
Тем не менее, нам необходимо учиться всю жизнь. И поскольку хороший процесс разработки программного обеспечения по Agile требует постоянного наличия рабочего продукта, приведенные мной навыки абсолютно необходимы.
- Спасибо Джеймсу Шору за напоминание об этом недостающем списке навыков. Вы знаете больше необходимых навыков? Напишите мне о них. Безусловно, нам необходимо знать много различных вещей, но я написал о самых главных, на мой взгляд. О навыках, важных по мнению Джеймса и Дианы Ларсен, можно прочитать в их статье о их подходе Agile Fluency.
