Agile или Agile Development — мы слышим эти слова чаще в наши дни. Но мы действительно знаем, что это такое? Как это может помочь нам стать более эффективными, одновременно занимаясь разработкой программного обеспечения? Как мы можем использовать его для общения с деловыми людьми и сделать это общение простым и конструктивным для обеих сторон?
Что такое Agile Development?
Там было много очень талантливых и опытных парней, разрабатывающих серьезное программное обеспечение. Эти разработчики наблюдали за другими компаниями и командами разработчиков и за тем, как их процессы облегчали их работу. Они составили свои наблюдения, чтобы создать Agile Manifesto. И они сказали:
Мы раскрываем лучшие способы разработки программного обеспечения, делая это и помогая другим делать это. Благодаря этой работе мы пришли к оценке:
- Индивидуумы и взаимодействия над процессами и инструментами
- Рабочее программное обеспечение над всеобъемлющей документацией
- Сотрудничество с заказчиком в процессе переговоров
- Реагировать на изменения после плана
То есть, хотя в элементах справа есть ценность, мы слева оцениваем элементы больше.
В этой статье я представлю двенадцать теорий и методов Agile Development. Это только первый шаг в новый мир процесса разработки программного обеспечения.
1 — удовлетворенность клиентов
Нашим главным приоритетом является удовлетворение потребностей клиентов путем ранней и непрерывной поставки ценного, но не полнофункционального программного обеспечения. Это означает, что мы разрабатываем программное обеспечение и добавляем хотя бы одну функцию на каждую итерацию.
Давайте представим, что мы хотим создать блог-движок; мы могли бы сделать это, используя следующий процесс:
- Создать страницу отображения блога; доставить заказчику
- Создать функцию управления пользователями и членства; доставить его нашему клиенту
- Добавить возможность комментирования и управления; доставить заказчику
- Так далее и тому подобное…
Это простой подход, но клиент видит реальный прогресс своего программного обеспечения и дает вам немедленную обратную связь по каждой новой функции. Он может быть идеальным или требовать настройки, но вы можете быстро реагировать на изменения: беспроигрышная ситуация.
2 — адаптироваться к меняющимся требованиям
Даже на поздних стадиях цикла разработки гибкие процессы позволяют приветствовать изменения, направленные на конкурентное преимущество клиента.
Заказчик хочет, чтобы проект был завершен быстро и как можно ближе к дизайну, который он задумал. Это легко достигается простым прослушиванием их входных данных и готовностью к изменениям. Если мы способны быстро реагировать на меняющиеся требования, мы, вероятно, лучший выбор, который когда-либо делал наш клиент. Agile — это общение и изменения. Мы делаем вещи так, как нас просят, чтобы процесс разработки программного обеспечения завершался быстрее. Это достигается за счет того, что мы разрабатываем небольшие части программного обеспечения, и изменение требований на нас не влияет.
3 — Доставить часто
Мы должны доставлять обновления от пары недель до пары месяцев; чем короче время, тем лучше.
клиенты чувствуют себя более уверенно в нас и нашем продукте по мере его обновления
Исходя из моего опыта, клиенты чувствуют себя более уверенно в нас и нашем продукте, когда он обновляется, что жизненно важно для наших отношений с ними. Еще одним преимуществом является обратная связь с нашим клиентом; что позволяет нам реагировать путем изменения классов, функций, модулей или даже архитектуры. Мы не проснемся после нескольких дней или месяцев работы, только чтобы увидеть, что все идет в мусорное ведро. Давайте рассмотрим гипотетическую ситуацию:
Вас попросили создать модуль, который будет отображать простой текст в менеджере контента. Внезапно требования меняются, и вам нужно добавить форму, которая должна отправить электронное письмо на настроенный адрес. Кроме того, форма должна быть настраиваемой, чтобы пользователь мог добавлять новые поля и определять валидаторы. Таким образом, вы в основном должны забыть о первоначальном требовании простого текста. Как скоро вы хотели бы узнать об этом изменении?
Если вы работаете над проектом со своим клиентом и часто выполняете его, вы будете быстрее узнавать об этих изменениях, и такие изменения станут легче для вас обоих.
4 — часто работаем вместе
Это может оказаться самым сложным принципом, к которому нужно привыкнуть, если вы разрабатываете программное обеспечение в старом стиле водопада. Вы, как разработчик, обычно не говорите на том же языке, что и ваш клиент, но вы можете найти способы поддерживать конструктивное общение с ними. Один из лучших способов, на мой взгляд, это описать все с помощью простой истории, которая рассказывает нам, разработчику, для кого эта функция, в чем ее ответственность и зачем она вообще нужна. Конечно, это становится проще, чем больше мы работаем с нашим клиентом. Еще один полезный подход — разработка на основе поведения (BDD), но это тема другой статьи.
5 — Создание проектов с мотивированными людьми
Дайте людям, с которыми вы работаете, среду и поддержку, в которой они нуждаются, и, прежде всего, доверьте им выполнение своей работы.
Важно обеспечить привлекательную атмосферу и все инструменты, необходимые для создания хорошего программного обеспечения. Компании теряют своих лучших работников в основном потому, что они не заботятся о них. Вера в то, что разработчики могут писать, тестировать и развертывать программное обеспечение на каком-либо сервере с помощью FTP-клиента и редактировать рабочие файлы, где-то потерялась. Если вы не осудили эти привычки старой школы, вам лучше сделать это сейчас.
Удержание сотрудников — это только одно преимущество; Вы также можете разрабатывать лучшее и большее программное обеспечение в более быстром темпе. Подумайте об этом: написание многократно используемого кода, автоматических тестов и автоматического развертывания на любом сервере (помимо прочего) может положительно повлиять на время разработки. Обычно мы думаем, что замедляем проект, потому что нам нужно научиться использовать полезные инструменты, такие как Jenkins, GIT, SVN, Gerrit, Behat и т. Д. Честно говоря, мы делаем это, но затем мы можем повторно использовать эти инструменты и концепции в будущих проектах.
6 — Общайтесь лицом к лицу
Это самый эффективный и эффективный метод передачи информации нашим клиентам и команде разработчиков.
Кто не был потрясен и / или рассержен, увидев 6 255 384 электронных писем в вашем почтовом ящике, потому что ваша компания требует, чтобы все разговоры были «на бумаге»? Я лично видел это несколько раз в своей жизни, и я не рекомендую работать в компании с такими привычками. Общение лицом к лицу делает общение легче и плавнее, и позволяет нам предоставлять больше информации. Мы можем использовать вербальные и невербальные способы общения, чтобы показать нашим товарищам по команде, что мы думаем. Это очевидно быстрее, чем переписываться друг с другом.
Но, прежде всего, нам нужно доверять друг другу; доверие легко получить в среде, которая поощряет общение лицом к лицу.
7 — Измерение прогресса с рабочим программным обеспечением
Это одно из моих любимых правил; это позволяет нам свободно работать в соответствии с нашими собственными процессами. Разработчики программного обеспечения отличаются от других сотрудников; поэтому, естественно, они должны рассматриваться как таковые. Из своего личного опыта я научился не судить никого из команды разработчиков, пока работа выполнена. Разработчики не хотят создавать плохое программное обеспечение, и они с меньшей вероятностью сделают это, если мы позволим им работать в соответствии с их собственными предпочтениями. В конце концов, клиент доволен, если заказанная им работа выполнена правильно; им все равно, как это было сделано.
8 — Поддерживать постоянный темп
Гибкие процессы способствуют устойчивому развитию, позволяя поддерживать постоянный темп на неопределенный срок.
Наиболее известные преимущества Agile (такие как принятие изменяющихся требований, быстрая реакция на обратную связь и т. Д.) Широко ценятся, но, на мой взгляд, лучшим преимуществом является способность точно определять количество времени, в течение которого проект или функция будут потребляют. После нескольких поставок команда разработчиков создаст самый ценный бизнес-номер: емкость. Вместимость — это объем работы, которую команда может выполнить за одну итерацию. Количество мощностей остается стабильным после нескольких итераций, и мы можем избежать нелепых сроков и временных оценок, которые «вытаскиваются из головы» при представлении предложения нашей компании клиенту.
Многие люди говорят, что это невозможно, и планирование оказывается более точным. Я не согласен; расписание предполагает, что не будет ошибок или неизбежных задержек.
Это идеальный план для идеальной команды, которой не существует.
9 — Обратите внимание на промышленный прогресс
Постоянное внимание к нашей отрасли повышает маневренность.
Мы должны развиваться и прогрессировать. Мы должны продолжать учиться каждый день, потому что индустрия движется такими быстрыми темпами. По мере улучшения как аппаратного, так и программного обеспечения мы должны идти в ногу со временем; в противном случае мы потеряемся в «море нового», и будет трудно вернуться на правильный путь.
Рефакторинг является решением большинства проблем. Постоянно проводя рефакторинг (при необходимости), мы можем легко применять новые методы и улучшать архитектуру нашего программного обеспечения.
10 — Простота необходима
Билл Гейтс однажды сказал:
Если у меня есть какая-то сложная работа, я дам ее самому ленивому человеку, потому что он найдет самый простой способ сделать это.
Простота — золотое правило. Это не означает, что вам нужно быть ленивым, но это означает, что разработчики в большинстве случаев усложняют свою работу. Если вы выполняете только ту работу, которую хочет клиент, без каких-либо дополнительных функций и улучшений, ваша рабочая нагрузка уменьшится, и вы достигнете своих целей. В конечном счете, это все, что заботит клиента.
11 — Самоорганизация
Лучшие архитектурные решения, требования и проекты возникают из самоорганизующихся команд.
Мы только люди; мы не можем все предсказать.
Вы когда-нибудь были в ситуации, когда разрабатывали большое и трудоемкое приложение, и, проведя бесчисленные часы перед экраном, написав тысячи строк кода и прочитав статьи, учебные пособия и книги, вы сели, глядя на какое-то плохое (но рабочий) код думал: «Теперь я знаю, как написать это лучше»? Я думаю, что у всех нас были такие моменты.
Здесь вступает одиннадцатое правило. У нас есть команда разработчиков, которые могут следовать принципам Test Driven Development (TDD), где рефакторинг является частью процесса. Каким-то волшебным образом наше программное обеспечение полезно, красиво, хорошо написано, протестировано и создано быстро. Мы только люди; мы не можем все предсказать.
Все это исходит из идеи самоорганизующейся команды, в которой у каждого участника есть роль — не заданная или не принуждаемая — но возникшая через некоторое время совместной работы. В этом прелесть командной работы.
12 — Отразить и настроить
Через регулярные промежутки времени ваша команда разработчиков должна размышлять о том, как стать более эффективной, и соответственно корректировать свое поведение.
Это может потребовать нескольких циклов разработки, но команда будет работать в полной гармонии. Даже добавление новых людей в эту команду не будет вредным. Agile команда разработчиков — это все, что нужно для выполнения работы. Если они работают в дружественной среде, они найдут «мелодию работы», и вы увидите, насколько быстрой может быть разработка программного обеспечения.
Несколько методологий гибкой разработки
Существует несколько методологий, основанных на гибких принципах и основанных на них. Я не буду описывать их все, потому что каждая методология может быть рассмотрена в своей статье. Я, однако, обрисую некоторые из наиболее известных подходов Agile. Следует помнить, что нет единой методологии, которая бы управляла ими всеми. Выберите тот, который лучше всего соответствует вашим потребностям, и даже «настройте» его в соответствии с вашими конкретными требованиями.
SCRUM
SCRUM, созданный Кеном Швабером и Джеффом Сазерлендом, представляет собой бизнес-ориентированную среду для управления процессами разработки программного обеспечения. Есть много разных типов SCRUM; просто помните, что главная цель — работать эффективно и продуктивно, а не придерживаться правил.
Экстремальное программирование (XP)
XP, созданный Kent Back, представляет собой список рекомендаций, которым должны следовать разработчики при создании программного обеспечения. Это часто называют «расширением SCRUM». Эта методология правил, ориентированных на развитие, родилась благодаря тому, что SCRUM был довольно ориентирован на бизнес.
Бережливая разработка программного обеспечения
Двумя основными принципами Lean являются: DALAP (принять решение как можно позже) и DAFAP (выполнить как можно быстрее). Я лично рекомендую прочитать больше об этой методологии, поскольку она может быть очень полезной.
В семье Agile больше методологий; Я просто сослался на самые популярные варианты. Если вы решите использовать Agile в процессе разработки, вам необходимо знать, каковы эти методологии, чтобы выбрать подходящую для вас.
Последние мысли
Agile методы действительно работают?
Действительно ли Agile-методы работают, и действительно ли методологии настолько волшебны, как все говорят? Не всегда.
Проблема, с которой я столкнулся в компаниях, где Agile-методы не давали результатов (или даже ухудшали ситуацию), была неправильно выбранной методологией и отсутствием убежденности среди ее пользователей (членов бизнеса, команды разработчиков и т. Д.). Вот почему, по мнению этого автора, вы должны быть уверены, что все участники процесса понимают правила и знают, «что это такое».
Спасибо за прочтение!