Agile – манифест разработки программного обеспечения. Agile/Scrum/Kanban: разбираемся вместе |

Основополагающие принципы agile-манифеста

Мы следуем таким принципам:

1. Наивысшим приоритетом является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения.
2. Изменение требований приветствуется, даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества.
3. Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.
4. На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.
5. Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.
6. Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.
7. Работающий продукт — основной показатель прогресса.
8. Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс разработки.
9. Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.
10. Простота — искусство минимизации лишней работы — крайне необходима.
11. Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.
12. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.

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

Так, а что же там за манифест

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

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

Перевод — ответственная работа. Потеря контекста при переводе иностранной литературы — это серьезная проблема, которая формирует неверное представление о сути у читателя.

Простой пример: «Agile-манифест разработки программного обеспечения». Что вы запомните из этой фразы? Наверное, «Agile-манифест», а вспомните ли вы, что это про разработку программных продуктов? Надеюсь. А вот призёр — первое место, золотая медаль на конкурсе по потере контекста в процессе перевода.

В оригинале книга называется «Scrum — the art of doing twice the work in half the time», что практический любой бесплатный электронный переводчик переведёт как «Scrum — искусство делать вдвое больше работы в два раза быстрее». Ни слова о проекте. Scrum вообще не про проекты. Увы и ах.

Люди и взаимодействие важнее процессов и инструментов. Работающий продукт важнее исчерпывающей документации. Сотрудничество с заказчиком важнее согласования условий контракта. Готовность к изменениям важнее следования первоначальному плану. То есть, не отрицая того, что справа, мы всё-таки ценим то, что слева.

— из Agile-манифеста

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

Кстати, позвольте придерусь к первой ценности в русскоязычном манифесте. В оригинале на месте слова «важнее» стоит слово “over», которое дословно переводится как «над». То есть дословный перевод — «Люди и взаимодействие над процессами и инструментами».

Да, на русском языке фраза достаточно странная, но в данном случае перевод мог бы быть: «Люди и характер их взаимодействия определяют необходимые процессы и инструменты».

Что дальше?

В процессе разработки команда руководствовалась достаточно распространенной схемой продвижения.

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

• ¾ – планирование спринта не более 2 часов;
• ¾ – спринт с периодичностью 1 неделя;
• ¾ – ежедневный Scrum-митинг не более 15 минут;
• ¾ – ретроспектива спринта не более 1 часа.

Наибольшей
детализацией подверглась задача №2, которая была разбита на более мелкие задачи
с предварительной их оценкой по времени выполнения: анализ того, как это
происходит сейчас; запрос статистики наиболее распространенных вопросов-ответов
на тему запросов у колл-центра; проведение анализа вопросов в колл-центре; запрос
поведенческой статистики по сайту компании; разработка матрицы для анализа
статистики сайта компании и т.д.

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

Ретроспектива спринта по реализации 2-й задачи бэклога представлена в таблице 2.

Например, на первой ретроспективе
было обсуждено, что будет сделано и как будет выполнена работа, а также цель спринта. С
учетом общего доступного за один спринт времени работы команды (4 человек * 8
часов * 5 дней = 160 часов) и по приоритетности задач для первого
спринта, был выбран ряд задач из бэклога.

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

Agile — простая и симпатичная философия

Если вы думаете, что авторы Agile Manifesto написали сборник советов о работе над проектом, вы немного ошибаетесь. Манифест включает в себя 4 ценности, 12 принципов и 0 практик.

Начнем с ценностей, потому что именно они соль Agile:

• Люди и взаимодействие важнее процессов и инструментов.

• Работающий продукт важнее исчерпывающей документации.

• Сотрудничество с заказчиком важнее согласования условий контракта.

• Готовность к изменениям важнее следования первоначальному плану.

В этом виде Agile похож на религию прекраснодушных ИТ-эльфов. Авторы как будто не знают, что разработка ПО — это бессонные ночи авралов, скандалы между проектировщиками и кодерами, переносы релизов, нервы и прочие прелести реальной жизни.

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

Kanban

С тем как сломать и построить заново всё понятно — искать квалифицированного Scrum-мастера (или своего воспитывать), выявлять инициативных желающих, формировать команды и вперёд на ежедневные тренировки.

Но можно не ломать, а менять последовательно. В интернете часто упоминается фраза «Kanban-доска», увы, к реальному «Канбану» она имеет крайне отдаленное отношение.

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

Kanban — про правильные процессы. Правильные — с точки зрения достижения целей вашей организации. Рельсы, на которых ваша организации будет уверенно двигаться вперёд. Так что не спешите бежать сломя голову в Scrum, как минимум познакомьтесь с плавными методами трансформации.

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

Scrum

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

Впервые термин прозвучал в 1986 году. Японские исследователи Икуджиро Нонака и Хиротака Такеучи в статье The new New product development game сформулировали принципы, позволяющие быстрее создавать новый продукт. Среди условий такой разработки назвали самоорганизующуюся команду специалистов, их полную свободу в творчестве и работе — без ограничений со стороны топ-менеджмента. Этот подход авторы описали так:

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

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

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

Методика, предложенная Нонака и Такеучи, нашла применение в IT-сфере, разработке инженерных решений в машиностроении, электронике. В 90-х Scrum оформился как проработанная и цельная методология, оброс конкретными приемами, помогающими с нуля наладить работу команды.

Xp — программируем экстремально!

Речь не о Windows XP. Под этой аббревиатурой скрывается еще одна методология из класса Agile: eXtreme Programming — экстремальное программирование. Ее придумал разработчик Кент Бек, развивали Уорд Каннингем, Мартин Фаулер и другие. Это набор простых принципов и практик, которые помогают наладить эффективную работу.

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

Вспомним, как работает классический разработчик. Он тщательно продумывает, планирует, а затем пишет фрагмент программы — работающий блок или функцию. Тестирует ее, отлавливает баги, устраняет их, снова проверяет и исправляет… Потом передает завершенный код на проверку тестировщикам или коллегам-программистам. Когда накапливаются изменения, их сводят воедино и создают работающую версию программы.

В экстремальном программировании все эти принципы доведены до предела. Нет времени объяснять — нужно делать! Планируют на короткий срок. Итерации разработки максимально сжатые. Чем быстрее выйдет рабочая версия — тем лучше. Реализуется самое простое из решений, а код пишется и тестируется параллельно.

В чём же суть agile

Один из авторов манифеста (Дейв Томас) после его создания не посещал конференции, мероприятия, не интересовался тренингами по Agile. В рамках своего знаменитого выступления «Agile мёртв» он описал, что и как надо делать.

Что делать

1. Понять что сейчас происходит вокруг.
2. Сделать маленький шаг в сторону достижения поставленной цели.
3. Скорректировать текущее понимание ситуации по результатам полученной информации.
4. Повторить вышеописанные действия.

Как делать

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

Что для этого нужно

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

И эти правила не персональные, они должны работать на уровнях:

• человек;
• команда;
• организация.

Так что берите их на вооружение и начинайте меняться уже сегодня.

Возможности

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

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

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

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

Ввиду того, что в туристической
компании на момент разработки продукта отсутствовал опыт работы по Scrum, и,
соответственно, отсутствовали специалисты, обладающие необходимыми знаниями, компания
приняла решение к привлечению в качестве Scrum-мастера сотрудника
компании – разработчика программного продукта.

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

• ¾ – быть самоорганизующейся,
• ¾ – быть кросс-функциональными, обладать всеми необходимыми навыками,
• ¾ – нести коллективную ответственность за создание Инкремента.

Рекомендуемый размер
команды, согласно Agile, – 7 (плюс-минус 2)
человек. С
учетом требований к команде были выбраны следующие сотрудники компании:

• ¾ – представитель отдела продаж;
• ¾ – представитель колл-центра;
• ¾ – системный администратор компании;
• ¾ – представитель отдела маркетинга и рекламы.

Таким образом, размер
команды составил 5 человек.

Гибкость во всем

С английского agile переводится как «подвижный, быстрый, проворный». Но в русской IT-лексике за этой группой методологий закрепилось определение «гибкие». Agile-подход динамично организует программирование, постоянно адаптируя проект к новым обстоятельствам и требованиям.

Не углубляясь в детали, вспомним, как устроена разработка по методологии Waterfall:

1. Выдвигаются требования к ПО, разрабатывается техническое задание (ТЗ).
2. Поставленные задачи воплощаются в коде.
3. Выполняется тестирование.
4. Готовое ПО внедряется в работу.

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

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

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

Чтобы понять, как это работает, представим коллектив разработчиков, создающих аудиоплеер. Уже написан костяк программного кода: интерфейс и базовый функционал. Программа умеет воспроизводить файлы формата MP3, WAV и OGG. Но пользователи предлагают добавить проигрывание CD-дисков и подключить горячие клавиши, чтобы быстро управлять плеером.

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

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

На этом итерация завершается — и начинается новый виток разработки.

Если забыть о философии, ничего не выйдет

Есть еще одна проблема, в которой авторы Agile не виноваты: методология стала слишком популярной и даже попсовой. Люди говорят, что работают по Agile, даже не понимая её сути. Они разбиваются на небольшие команды, нарезают проект на небольшие задачи, планируют спринты, регулярно релизят, но убогих проектов не становится меньше.

Помните, в начале статьи я говорил про принципы? Несмотря на их наивность, принципы — самое ценное в Agile. Сначала нужно осознать их и только потом браться за инструменты и практики.

• Люди и взаимодействие важнее процессов и инструментов.

• Работающий продукт важнее исчерпывающей документации.

• Сотрудничество с заказчиком важнее согласования условий контракта.

• Готовность к изменениям важнее следования первоначальному плану.

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

Agile — мировоззрение, а не набор советов. Примите Agile, и только потом беритесь за практику.

Мнение автора и редакции может не совпадать. Хотите написать колонку для «Нетологии»? Читайте наши условия публикации.

Командный дух

В команде, работающей по принципам Scrum, нет внутренней иерархии: ни руководителей, ни подчиненных, ни указаний-приказов. Есть два особых члена группы: product owner — владелец продукта, и scrum master — скрам-мастер.

Product owner лучше всех знает, каким должен быть продукт. Зачастую это заказчик, его представитель или сотрудник, ответственный за взаимодействие с клиентом. Он должен ясно понимать, что именно требуется конечному пользователю программы. Все пожелания и предложения по функциональности и внешнему виду продукта (в Scrum они называются stories — истории) он заносит в специальный список — Product Backlog. Бэклог формируется до старта разработки и по ходу постоянно пополняется. Здесь же указывают приоритеты доработок.

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

На самом деле не все любят agile

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

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

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

Agile подталкивает к мысли: то, что функция работает, намного важнее того, как она реализована. На дистанции такой подход приводит к проблемам. Единственная страховка — сверхдисциплинированная и организованная команда.

Набор для практики

Вопросы

1. Поясните понятие “гибкая методология разработки программного обеспечения”.
2. Какие компетенции необходимы для команды разработчиков, использующих гибкие методологии.
3. Как управляют рисками в гибких методологиях разработки ПО?
4. Какие задачи выполняются на итерациях в методологии гибкой разработки?
5. Назовите ключевые ценности методологий гибкой разработки ПО.
6. Назовите основные принципы гибкой разработки ПО.
7. Какие существуют методологии, которые соответствуют принципам гибкой разработки ПО?
8. Поясните, как в гибком подходе относятся к документированию и выпуску работоспособного кода.
9. Поясните, как должно быть организовано взаимодействие с заказчиком в гибком подходе к разработке ПО.
10. Поясните, как относятся к изменениям в гибком подходе к разработке ПО.

Упражнения

1. Проведите анализ возможностей методологии AgileUnifiedProcess.
2. Проведите анализ возможностей методологии AgileDataMethod.
3. Проведите анализ возможностей методологии Featuredrivendevelopment.

Никакого волшебства

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

Agile-методологии предъявляют высокие требования к профессионализму, квалификации и настрою специалистов. Важна сплоченность коллектива, взаимное уважение и обмен опытом. Экстремальные практики не научат плохого программиста гениально кодить, Scrum не поможет конфликтному специалисту влиться в коллектив.

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

Преимущества agile

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

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

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

Принцип № 12: «команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы».

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

Хотя принцип гласит, что команда должна стать эффективнее, эти «ретроспективы» помогают программистам стать эффективнее (читай: в большей безопасности) в команде. Это естественно для людей, но приводит к общей деградации команды. Общеизвестно, что лучшая команда — та, которая способна быстро и неумолимо отторгать плохие элементы.

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

Вячеслав Цырульник писал в своём блоге на Medium колонку о том, что такое манифест Agile, зачем он нужен компаниям и как лучше трансформировать бизнес. Очень правильные замечания по теме.

Принципы и значение гибкой разработки

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

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

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

Для создания высокопроизводительных команд в гибких методологиях кроме эффективной команды и хороших коммуникаций необходим совершенный программный инструментарий.

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

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

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

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

Постулаты гибкой разработки поддерживаются 12 принципами [11]. В конкретных методологиях гибкой разработки определены процессы и правила, которые в большей или меньшей степени соответствуют этим принципам. Гибкие методологии создания программных продуктов основываются на следующих принципах[12]:

1. Высшим приоритетом считать удовлетворение пожеланий заказчика посредством поставки полезного программного обеспечения в сжатые сроки с последующим непрерывным обновлением. Гибкие методики подразумевают быструю поставку начальной версии и частые обновления. Целью команды является поставка работоспособной версии с течение нескольких недель с момента начала проекта. В дальнейшем программные системы с постепенно расширяющейся функциональностью должны поставляться каждые несколько недель. Заказчик может начать промышленную эксплуатацию системы, если посчитает, она достаточно функциональна. Также заказчик может просто ознакомиться с текущей версией программного обеспечения, предоставить свой отзыв с замечаниями.
2. Не игнорировать изменение требований, пусть даже на поздних этапах разработки. Гибкие процессы позволяют учитывать изменения для обеспечения конкурентных преимуществ заказчика. Команды, использующие гибкие методики, стремятся сделать структуру программы качественной, с минимальным влиянием изменений на систему в целом.
3. Поставлять новые работающие версии ПО часто, с интервалом от одной недели до двух месяцев, отдавая предпочтение меньшим срокам. При этом ставится цель поставить программу, удовлетворяющую потребностям пользователя, с минимумом сопроводительной документации.
4. Заказчики и разработчики должны работать совместно на протяжении всего проекта. Считается, что для успешного проекта заказчики, разработчики и все заинтересованные лица должны общаться часто и по многу для целенаправленного совершенствования программного продукта.
5. Проекты должны воплощать в жизнь целеустремленные люди. Создавайте команде проекта нормальные условия работы, обеспечьте необходимую поддержку и верьте, что члены команды доведут дело до конца.
6. Самый эффективный и продуктивный метод передачи информации команде разработчиков и обмена мнениями внутри неё – разговор лицом к лицу. В гибких проектах основной способ коммуникации – простое человеческое общение. Письменные документы создаются и обновляются постепенно по мере разработки ПО и только в случае необходимости.
7. Работающая программа – основной показатель прогресса в проекте. О приближении гибкого проекта к завершению судят по тому, насколько имеющаяся в данный момент программа отвечает требованиям заказчика.
8. Гибкие процессы способствуют долгосрочной разработке. Заказчики, разработчики и пользователи должны быть в состоянии поддерживать неизменный темп сколь угодно долго.
9. Непрестанное внимание к техническому совершенству и качественному проектированию повышает отдачу от гибких технологий. Члены гибкой команды стремятся создавать качественный код, регулярно проводя рефакторинг.
10. Простота – искусство достигать большего, делая меньше. Члены команды решают текущие задачи максимально просто и качественно. Если в будущем возникнет какая-либо проблема, то в качественный код имеется возможность внести изменения без больших затрат.
11. Самые лучшие архитектуры, требования и проекты выдают самоорганизующиеся команды. В гибких командах задачи поручаются не отдельным членам, а команде в целом. Команда сама решает, как лучше всего реализовать требования заказчика. Члены команды совместно работают над всеми аспектами проекта. Каждому участнику разрешено вносить свой вклад в общее дело. Нет такого члена команды, который единолично отвечал бы за архитектуру, требования или тесты.
12. Команда должна регулярно задумываться над тем, как стать ещё более эффективной, а затем соответственно корректировать и подстраивать свое поведение. Гибкая команда постоянно корректирует свою организацию, правила, соглашения и взаимоотношения.

Вышеприведенным принципам, в определенной степени, соответствуют ряд методологий разработки программного обеспечения:

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

С каждым спринтом продукт становится полезнее

Перед первым спринтом команда и заказчик проводят совещание. Заказчик — условная роль, им может быть и член команды. Он определяет задачи, которые команда решит за спринт.

Здесь появляется первая сложность. Согласно философии Agile, после каждого спринта продукт должен быть:

• работоспособным;

• полезным для пользователя;

• более совершенным, чем до спринта.

Agile-подход к разработке продукта.

Результатом первых недель работы должен стать продукт, готовый к выходу на рынок. Такой продукт называют минимально работоспособным (Minimum Viable Product, MVP).

Запуск MVP — важная точка проекта. Удачный MVP либо сразу привлекает пользователей, либо сразу проваливается и показывает нежизнеспособность идеи.

Допустим, мы делаем интернет-магазин. Магазину нужны карточки товаров, поиск, корзина, профили пользователей, бонусная система, рассылки и все такое. Если делать это по каскадной методологии, до запуска пройдут месяцы. Мы идем по Agile, поэтому ищем MVP.

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

Возвращаемся к спринту. Во время него команда работает по модели, близкой к каскадной. Каждую новую функцию проектируют и программируют, а затем тестируют и документируют. Когда спринт завершен, команда имеет работоспособную, полезную и более совершенную версию продукта.

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

Пары «план — спринт» идут одна за другой, пока живет проект.

Старые методы разработки слишком громоздки

До появления Agile IT-компании использовали каскадную модель разработки (она еще известна как водопадная, потому что по-английски называется Waterfall). Чтобы стало чуть яснее, что́ с ней не так, скажу, что методологию сформулировали в 1970-м. Её суть в том, что работа над проектом состоит из жесткой последовательности этапов:

Анализ требований

Проектирование

Реализация

Тестирование

Интеграция

Поддержка

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

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

При каскадной разработке между анализом требований к продукту и интеграцией (выводом на рынок) проходят месяцы и годы. К этому времени рынок меняется, продукт порой устаревает еще до релиза.

Риск потерять уйму денег — хороший повод поразмыслить. В 2001 году практикующие айтишники собрались на горнолыжном курорте в Юте. Официальный сайт преподносит событие так: «…seventeen people met to talk, ski, relax, and try to find common ground — and of course, to eat». Итогом стала Библия Agile — Agile Manifesto.

Экстремально — не значит плохо

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

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

Экстремальное программирование не предписывает, как действовать в конкретной ситуации. Если решение задачи для всех очевидно и написать код не составит труда — нет реальной необходимости в парном программировании. Если на часах 18:00, а вам осталось дописать двадцать строк кода — можно не откладывать на завтра. Методология не заменяет здравый смысл!