10 проверенных советов по Agile-разработке

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

Чтобы команда разработчиков была на одной волне на протяжении всего цикла разработки, нужно следовать модели, которая может наилучшим образом облегчить процесс. За прошедшие годы было довольно много таких названий, как Waterfall, Spiral, V-model и т. д., которые иллюстрируют, как разрабатывается программное обеспечение, от концепции до получения готового продукта, а затем его поддержки.

Источник изображения: Agile Manifesto Poster Адама Вайсбарта.

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

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

Отличное оборудование для ваших разработчиков и тестировщиков

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

Но чего действительно хотят программисты, так это нескольких мониторов, чтобы иметь как можно больше экранного пространства для написания кода. Хорошие клавиатуры также являются большим преимуществом, поскольку ввод кода — это их хлеб с маслом, а механические клавиатуры долговечны и удобны для печати (по крайней мере, с тактильными переключателями).

Нацеленность на результат

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

Благодаря этой нисходящей модели управления ожидается, что команда разработчиков даст конкретные и измеримые результаты. Они должны иметь возможность показать свою работу не только в коде, но и иметь что-то, что действительно работает так, как задумано. Затем это ставится под контроль с помощью Test Driven Development (TDD), процесса, который играет большую роль в Agile Development.

Сначала внедрите непрерывную доставку

В общем, продолжайте в том же духе. Это гарантирует, что разработка ведется в постоянном темпе, а разработчики получают обратную связь рано и часто. Постоянное общение и обратная связь — вот что такое Agile Development, что позволяет команде адаптироваться к внезапным изменениям и неожиданным обстоятельствам, когда это необходимо. Вот тут-то и появляются «сборки».

Сборка — это, по сути, полезная версия разрабатываемого программного обеспечения. Благодаря концепции непрерывной доставки (CD) необходимо частое развертывание последовательных сборок, каждая из которых выпускается после внесения улучшений и исправлений, основанных на отзывах о предыдущей сборке.

Получить спонсорство для высшего руководства

В то время как Agile Development использует подход «сверху вниз», может потребоваться довольно много времени, чтобы дождаться разрешения от высшего руководства, прежде чем внедрять или изменять что-либо.

Когда все сделано неправильно, это может привести к потере большого количества времени на ожидание разрешения. Хорошим решением является наличие представителя, который может быстрее передать эту проблему от разработчика властям, желательно, кто-то, кто умеет предлагать идеи и может понять, о чем просят.

Переход к более коротким циклам разработки и тестирования

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

Поскольку Agile Development направлена ​​на то, чтобы все происходило как можно быстрее, включая приток отзывов, важно иметь более короткие циклы разработки, чтобы получить «минимально жизнеспособный продукт». Это дает пользователям что-то, во что они могут вонзить свои зубы и иметь возможность давать соответствующие отзывы, которые затем могут быть рассмотрены в следующей сборке.

Достижение автоматизации с первого дня

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

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

Эффективное соотношение команды

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

Планируйте открытые проблемы

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

Запросить отзыв

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

Оценка вашего процесса

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