Agile
Материал из AgileWiki
Коллекция определений собранных со всего мира.
Содержание |
Определения
Wikipedia: Ги́бкая методоло́гия разрабо́тки (англ. Agile software development) — это концептуальный каркас, в рамках которого выполняется разработка программного обеспечения.
Ссылка: http://ru.wikipedia.org/wiki/Agile
Денис Миллер: Agile - это культура разработки программного обеспечения. Как любая культура имеет четко определенные ценности и принципы. В отличии от методологий не определяет практики, оставляя каждому определить тот набор практик, которые целесообразно применять в данном контексте. Или коротко Agile - это методология с нулём практик.
Agile = 4 ценности + 12 принципов + 0 практик
Краткое определение. Agile - это то, про что пишут в Agile-журналах, -блогах и -сайтах
Видео: Что такое Agile; Agile + Scrum + XP + ... (кто есть кто)
Что такое Agile
Agile это семейство методологий. К этому семейству также относятся SCRUM, Extreme Programming, Crystal, Lean, Dynamic System Development Method (DSDM) и некоторые другие. Все эти методологии объединяются манифестом гибкой разработки.
Общие черты всех гибких методологий
Ориентированность на изменение практически неизбежно приводит к следующим следствиям.
- Итеративность. Разработка ведется короткими итерациями (до месяца длиной). Короткие итерации позволяют улучшить обратную связь с клиентом. Заказчик может гибко влиять на разработку, формируя scope на на следующую итерацию по результатам текущей итерации.
- Инкрементность. В Agile система эволюционирует: в каждой итерации реализуется то, что представляет наибольший интерес для заказчика с точки зрения увеличения ROI. Заказчик расставляет приоритеты для каждой функциональности (feature) и в конце каждой итерации реализуется инкремент системы, который потенциально может быть предоставлен заказчику.
- Самоуправляемая команда. Практика показывает, что в постоянно изменяющемся окружении лучше всего работает самоуправляемая и самоорганизующаяся команда. Agile предоставляет набор практик, которые позволяют превратить команду в самоуправляемую.
- Адаптивный процесс. В Agile не существует заранее определенного процесса, который бы описывал методы работы в проекте и диктовал команде как добиваться поставленных целей. Вместо этого команда должна сама определить тот процесс, который позволяет ей добиваться высоких результатов.
История Agile
История возникновения гибких методологий
Одной из самых ранних работ, повлекших за собой появление современных методов итеративной разработки, является опубликованная в 1985 году статья «Спиральная модель разработки программного обеспечения» Барри Боэма, автора базовой методики оценки трудоемкости процесса разработки ПО.
В начале 90-х годов Джефф Сазерленд и Кен Швабер изобрели и начали использовать в компании Easel Corp. методологию, которую они назвали Scrum. Метод был основан на подходе, который применялся в таких несофтверных компаниях, как Honda, Canon и Fujitsu. Для Scrum характерны 30-дневные итерации, называемые спринтами, а также то, что повышенное внимание должно уделяться практикам по самоорганизации команд. Первая работа по Scrum была опубликована в 1999 году.
В середине 90-х годов компания Rational начала разработку методологии Rational Unified Process (унифицированный процесс Rational), в основу которой были положены итеративность и инкрементность разработки. Процесс основан на применении прецедентов использования (Use Cases) и включает набор некоторых «лучших практик» софтверной разработки на все случаи жизни.
В 1994-м группа людей, использовавших Rapid Application Development, собралась, чтобы обсудить описание стандартного итеративного процесса. Через некоторое время это описание трансформировалось в методологию DSDM (Dynamic Systems Development Method), которая в наши дни особенно популярна на ее родине, в Великобритании.
В 1996 году к проекту Chrysler C3, который к тому времени уже был практически провален, присоединился Кент Бек. Он вместе с Роном Джеффрисом использовал все известные ему на тот момент практики и пришел к выводу, что их совместное применение намного превышает эффект, получаемый от каждой по отдельности. Методология, названная Extreme Programming (XP; экстремальное программирование), быстро получила широкую известность благодаря упору на простоту, коммуникацию и раннее тестирование, а также из-за провокационного названия.
В 1997 году Питер Коад и Джефф Де Люка подключились к безнадежному проекту по построению большой логистической системы и успешно справились с ним за счет применения практики итеративной разработки. Они описали свой подход к разработке в методологии Feature Driven Development (FDD).
В феврале 2001 года 17 разработчиков методологий, авторов DSDM, XP, Scrum, FDD и др., собрались для того, чтобы попытаться обнаружить что-нибудь общее в своих подходах. Результатом стал Манифест гибкой разработки (Agile Manifesto; http://agilemanifesto.org). Тогда же появился термин Agile (то есть гибкий, шустрый), объединяющий все методологии под одной крышей.
Проблемы при внедрении Agile
Привычка к роли
Члены проектной команды поначалу неохотно соглашаются выполнять работы, не свойственные привычным для них проектным ролям, даже если они понимают, что это принесет несомненную пользу проекту. Например, аналитики не любят тестировать систему, хотя кому как не им знать, как она должна работать. Проблемы такого рода легко заметны в проекте, и, как правило, решаются на рестроспективах самой командой
Привычка к документам
Поначалу разработчики ожидают от заказчика документа требований по проекту, где будут разъяснены все вопросы. Это не самый эффективный способ передачи информации и разработчики должны научиться работать напрямую с заказчиком. Через какое то время работы в проекте, пообщавшись напрямую с заказчиком, разработчики смогут ориентироваться в бизнесе и решение части очевидных вопросов смогут брать на себя. Даже если они допустят ошибку, она будет замечена заказчиком в конце итерации и затем исправлена.
Новая команда
Настоящим вызовом для менеджера проекта является новая команда, где рабочие отношения между людьми еще не сформировались. Люди не знают друг друга, стесняются обращаться за помощью и боятся открыто критиковать друг друга за неправильные проектные решения. Менеджер проекта должен помочь команде как можно скорее установить неформальные отношения друг с другом. Очень полезными оказываются различные мероприятия по тимбилдингу, такие как совместные походы в рестораны или спортивные мероприятия.
Проблемы с общением
К сожалению, далеко не все люди являются экстравертами и способны на открытое общение. Далеко не всегда они способны эффективно общаться друг с другом. На начальном этапе проекта менеджер проекта должен проводить все митинги с между членами проектной команды, добиваясь продуктивности и эффективности.
Давление по срокам
Заказчик оказывает давление по срокам. Ему необходимо получить желаемую функциональность как можно скорее. Задача команды состоит в том, чтобы по возможности выполнить его, не принося в жертву качество продукта. В противном случае скорость разработки в долгосрочной перспективе упадет, так как стоимость изменений из-за низкого качества станет высокой. Кроме того, плохое качество отрицательно влияет и на мотивацию внутри проектной команды. Задача менеджера проекта - постоянно напоминать команде и заказчику необходимости поддерживать высокое качество.
Креативность
Не все задачи в проекте одинаково интересны. Разработчикам часто интересно принимать проектные решения, которые идут в ущерб проекту, но интересны с технической точки зрения. Тут важно помнить о принципах KISS (keep it simple) и YAGNI (you ain't gonna need it). Проектные решения должны быть простыми. Не стоит делать то, что не является абсолютно необходимым на обозримом промежутке времени. Как же научить команду принимать простые решения? Автору показалось полезным дать команде ошибиться один раз и затем разобрать пример на ретроспективе с тем чтобы разработчики сделали вывод на будущее.
Практически в любом проекте время от времени возникают исследовательские задачи (новые технологии, новые технические области знаний). Именно здесь место для всяких проб и экспериментов.
Оценка времени
При оценке времени на выполнение задачи разработчики часто забывают, что помимо написания кода в задачу как минимум входит дизайн и тестирование. По этой причине в начале проекта программисты часто переоценивают свою производительность. На рестроспективах эти ошибки отмечаются и делаются выводы на будущее. В длительной перспективе команда учится делать правильные оценки и со временем (через 3-4 итерации) точность растет наряду с самой производительностью.
Проблема с менеджментом
Менеджмент ожидает наличия определенной функциональности к определенному сроку. Но agile не может гарантировать стопроцентного выполнения планов. Можно лишь ожидать, что высокоприоритетные требования будут реализованы в первую очередь. Полезно согласовывать с менеджментом планы на уровне релизов. Высокоуровневость плана релиза позволяет менеджеру продукта в достаточно широких пределах варьировать объем разработки даже на уровне отдельных функций системы. Например, в задачу разработки подсистемы поиска можно включать учет морфологии, а можно и сэкономить на нем.
Проблемы с некомандным поведением
При внедрении Agile иногда можно наблюдать следующую ситуацию. Во время митинга вдруг кто-то один вскакивает со своего места и начинает предлагать какие-то идеи. Возражения он сходу отметает и начинает вести митинг. Через некоторое время он заявляет, что решение принято и пора перейти ко второму вопросу. Разумеется, команда никакого решения не принимала. Фактически, этот человек принял решение за команду, играя против нее.
Тут возможны разные варианты. Конечно, может быть этот человек просто увлекся и через некоторое время придет в себя. Но есть и люди, которые просто в силу своих человеческих качеств неспособны играть в команде. Agile полагается на способность людей договариваться друг с другом и умение решать проблемы в личном общении. Если этих качеств у человека нет, то можно с сожалением констатировать, что Agile ему не подходит и с таким человеком лучше расстаться.
Оригинал: Внедрение Agile. Асхат Уразбаев
