Чаще всего Agile встречается в крупных компаниях и не распространен среди фрилансеров, но стоит ли фрилансеру использовать «водопад»? Нет. Фрилансеру также стоит использовать гибкие методологии проектирования и разработки, которые помогают использовать итерационную разработку.

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

Что дает Agile?

1. Быстрая демонстрация результата клиенту;
2. Предъявления требований возможно в любое время;
3. Итеративный подход.

Т.е. мой клиент увидеть начальный результат через 1 спринт, может предоставить мне требование в середине и в конце разработки проекта и вновь выдвинутые требования никак не усложнят и не изменят процесс разработки. Т.е. клиент может «щупать» продукт каждые 2 недели выдвигая свои рекомендации к последующему продакшену. Т.е. большинство пожеланий не повлияют на сроки и трудоемкость разработки ПО.

Это то, что просит клиент от профессионального фрилансера. Как это выглядит в жизни.

Получив предоплату за проект (без предоплаты советую не никогда не работать) беремся за работу, естественно выполняя процесс разработки согласно Agile. Разрабатываем «морду» любой страницы, вешаем ее на схему MVC, делаем ссылки кликабельные. Напоминаем клиенту, что раз в неделю происходит обновление dev версии его сайта и что после каждого просмотра можно отправлять дополнительные требования или корректировки. Получив список всех за и против, мы дописали в ожидании от второго спринта (ранее составленное нами) и ушли на выходные. Далее продолжаем в том же духе.

Совпало ли то, что мы сделали? Мы получили быстрый результат, получили новые требования/замечания, прошли первый цикл итерации. Да, мы молодцы и следуем Agile.

И еще: нельзя бросать заказчика одного. Работа с заказчиком идет на протяжении всей разработки проекта.

Когда заказчик говорит «я приду смотреть на готовый результат», я отвечаю: «вот, пожалуйста, смотрите начальную версию готового результата и вносите рекомендации». Потому что наивысшим приоритетом есть удовлетворение потребностей заказчика, следовательно, нужен feedback и следовательно нужны новые пожелания, новые требования, новые рекомендации и нужны они не по окончанию разработки, а сегодня и сейчас. Кто-то скажет ТЗ опишет все задачи и главное сделать все по ТЗ. На практике все иначе. Частично ТЗ все опишет, а частично все ли правильно понято и все ли правильно сделано и все ли, что хотел заказать клиент, он описал в ТЗ. Или, может, «ту штучку» которую, клиент только что увидел, будет не доставать новенькому ПО. Удовлетворенный клиент – постоянный клиент.

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

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

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

Продолжая рассказ об Agile, стоит обратить внимание на качественный контроль. Такой подход обеспечивает Скрам.
Скрам (Scrum) — это набор принципов, на которых строится процесс разработки, позволяющий в жёстко фиксированные и небольшие по времени итерации, называемые спринтами (sprints), предоставлять конечному пользователю работающее ПО с новыми возможностями, для которых определён наибольший приоритет. Возможности ПО к реализации в очередном спринте определяются в начале спринта на этапе планирования и не могут изменяться на всём его протяжении. При этом строго фиксированная небольшая длительность спринта придаёт процессу разработки предсказуемость и гибкость.

Спринт в Agile — это период времени, за который происходит обновление результата, т.е. то время которое мы усердно работаем ни о чем не думаем. Это неделя, но можно и от 2 до 4 недель.

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

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

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

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

Что происходит в жизни: ежедневно производится оценка цикла выполнения задач и выстраиваются планы на следующий мини цикл (спринт длиною в сутки). Т.е. каждое утро смотрим, что получилось вчера и что предстоит сделать сегодня, насколько мы приблизились к завершению, насколько наш продукт соответствует требованиям. После этого продолжаем работу. Таким образом, происходит ежедневный самоконтроль, что есть хорошо, потому что самоконтроль выполненных задач приводит к самоконтролю всего процесса разработки. Всегда есть возможность отчитаться перед заказчиком, для заказчика всегда же есть возможность внести корректировки требований и внести новые требования к конечному продукту.

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