Agile принципы




Principles behind the Agile Manifesto

We follow these principles:

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

Welcome changing requirements, even late in
development. Agile processes harness change for
the customer’s competitive advantage.

Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.

Business people and developers must work
together daily throughout the project.

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.

Continuous attention to technical excellence
and good design enhances agility.

Simplicity—the art of maximizing the amount
of work not done—is essential.

The best architectures, requirements, and designs
emerge from self-organizing teams.

At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.

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

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

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

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

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

На протяжении всего проекта разработчики и представители бизнеса должны
ежедневно работать вместе.

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

Непосредственное общение является наиболее практичным и эффективным
способом обмена информацией как с самой командой, так и внутри команды.

Работающий продукт — основной показатель прогресса.

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

Постоянное внимание к техническому совершенству и качеству
проектирования повышает гибкость проекта.

Простота — искусство минимизации лишней работы — крайне необходима.

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

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

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

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

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

Читайте также :

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

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

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

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

Как же выглядит Agile для школы и какие изменения он принесёт — читайте далее в сокращённом переводе Надежды Артемьевой и Татьяны Глухаревой из​ «Утренней школы».

Agile-школы: как технологии помогают спасти образование

Американская система образования зашла в тупик

Даже незначительный рост успеваемости, который был достигнут за годы с момента старта программы No Child Left Behind («Ни одного отстающего ребенка», далее по тексту: NCLB), замедлился. Энтузиазм учителей низок как никогда. Федеральному правительству и правительствам штатов не хватает денег на образовательные программы. А тех из нас, кто работает в школах (если у нас ещё есть работа), просят потуже затянуть пояса.

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

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

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

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

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

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

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

Манифест на любое время года

Некоторые идеологи реформы образования призывают к полной «реорганизации кода» (refactoring) современной школы. Приступая к своей миссии по реорганизации системы образования, я начал с Манифеста Agile.

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

Читайте также :

Манифест Agile-школы

Мы постоянно открываем для себя более совершенные методы обучения детей, занимаясь обучением непосредственно и помогая в этом другим. Благодаря проделанной работе мы смогли осознать, что:

  • Люди и взаимодействие важнее процессов и инструментов;
  • Осмысленное научение важнее формальных тестов;
  • Сотрудничество между участниками процесса важнее постоянных согласований/переговоров;
  • Готовность к изменениям важнее следования первоначальному плану.

То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева. Это не просто игра слов, это мощный инструмент эффективного управления школой.

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

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

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

Как Agile учит нас реформировать наши школы

В четырех пунктах Манифест также объясняет, почему нам так тяжело даётся школьная реформа:

1. Большинство школ зациклены на процессах и инструментах; потребности индивида отходят на второй план.

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

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

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

Если бы школы были фабриками, учителя шестеренками, а дети деталями, то это имело бы смысл.

Читайте также :

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

2. Большая часть работников системы образования зациклена на методиках обучения, дидактических материалах и результатах тестов (это то, что они хотят «построить»); ценность того, что дети в результате усваивают (потребности «клиента») редко обсуждается, почти никогда не оценивается и не используется в качестве критерия положительных изменений.

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

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

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

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

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

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

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

4. Школьная культура подразумевает всеобъемлющее планирование и сопротивление изменениям.

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

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

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

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

Если вы уже давно чешете в затылке, пытаясь понять, почему нам так трудно даётся реформа образования, теперь у вас есть ответ: пытаясь понять, как должна работать современная школа, мы не следуем принципам Agile.

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

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

Двенадцать принципов Agile-школы

Мы придерживаемся следующих принципов:

Читайте также :

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

Здесь мы снова видим готовый рецепт удачной школьной реформы. Никто не спорит с тем, что школа должна обеспечивать «осмысленное обучение». Споры ведутся о том, чем именно это осмысленное обучение является.

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

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

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

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

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

© Copyright 2008 by Teaching That Makes Sense, Inc. Used by permission. For information contact Steve Peha at stevpeha@ttms.org.

Оригинал статьи опубликован на английском в журнале InfoQ.

В оформлении статьи использована фотография инсталляции «Suspense» by Sophia Chang.

Методология Agile

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

Содержание статьи

Три объёма значения Agile

В первом, более узком значении, этот термин стал с начала 2000-х использоваться в сфере разработки программного обеспечения, когда в американском штате Юта, на горном курорте, собрались отраслевые специалисты, чтобы обсудить методики и практики создания программных продуктов, востребованных конечным потребителем. Результатом той встречи стал Манифест (Agile Manifesto) разработки программных продуктов, с 12-ю принципами, которые, в первую очередь, касались узкой сферы деятельности авторов, но потенциально могли быть распространены и на некоторые другие бизнес-проекты.

Во втором, более широком, значении термина принципы Agile применяются к ведению почти любого бизнеса и в качестве составляющих используются, например, в концепции «бережливого стартапа» (Lean Startup). В этом значении под Agile-моделью (Agile Model) понимают следование гибкой методологии развития проекта, проходящей по характерной схеме в несколько шагов.

  1. Работа над проектом ведётся итерациями – короткими циклами (спринтами). (В случае с разработкой программного обеспечения продолжительность этих циклов составляет от 1 недели до 1 месяца).
  2. По завершении каждого цикла выходит продукт, который уже можно применять в бизнесе. Для программного обеспечения таким продуктом может стать приложение или только его часть, однако даже «сырой» софт уже можно и нужно пробовать в деле.
  3. Продукт проверяется заказчиком или пользователями, которые поддерживают с разработчиками постоянную обратную связь. Клиентоориентированный подход применяется в течение всего проекта (всех итераций).
  4. Любые замечания быстро включаются в доработку, а изменения, позволившие сразу по ходу подправить разработку продукта, – приветствуются, поскольку это позволяет не накапливать глобальные ошибки системы.

В третьем, ещё более широком значении, Agile – это часть модели управления, применяемого на заводах «Toyota» и теперь – одна из базовых составляющих менеджмента почти любого успешного производства. Основы Agile в этом контексте схожи с основами понимания технологии в других контекстах.

Быструю обратную связь в настройке конечного формата производства на заводах «Toyota» обеспечивал любой рабочий, который мог стать инициатором остановки конвейера и автором корректировок по донастройке производственного цикла. В масштабах всего производства Agile-трансформация может повлечь за собой переналадку производственной деятельности в целом, если продукт становится результатом живого отклика на текущие потребности клиента. Так, если фабрика выпускала пластиковые тазы, а обратная связь с клиентом демонстрирует потребность в вёдрах, то быстрая адаптация с параллельной корректировкой нюансов (формы ручки, величины, цвета) будет как раз в стиле Agile management (если соблюдены и остальные принципы).

Принципы Agile-управления

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

  1. Решающее значение для настройки продукта имеет потребитель и степень его вовлеченности в создание результата.
  2. Для принятия решения команды должны быть высокоэффективными и сплочёнными.
  3. Поэтапная и цикличная работа становится основой процесса. Проект делится на мелкие части, которые завершаются к определённому сроку до завершения проекта в целом.
  4. Фокус оценки результативности направлен на частые представления промежуточных состояний проекта.
  5. В работе коллектив опирается на закон Парето, по которому 20% усилий дают 80% эффективности, что позволяет не доводить каждый отдельный цикл до совершенства перед представлением результата потребителю. Продукт совершенствуется естественным образом с каждой новой итерацией.
  6. Предполагается обязательное завершение одного этапа перед переходом к следующему.

«Гибкий» подход стал базовым для целого ряда методологических практик, которые отличаются между собой, но включают идеи Agile: Scrum, Kanban, Lean, Crystal и др. Методология Scrum, например, практически всегда рассматриваются в связке с Agile как единая система управления проектами по разработке программного обеспечения.

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

  • Product backlog предполагает формирование списка требований, созданного по единому шаблону (User Story) и отсортированного по приоритетам. Если требований нет, проект завершается.
  • Sprint backlog – это требования ближайшего спринта (этапа), разделённые на задачи без возможности добавлять новые требования в течение спринта. Обязательство на ближайший этап, взятые командой с типом управления Agile, записываются на доске (т. н. Kanban).
  • Sprint Goal – общая цель спринта – ориентир при принятии альтернативных решений.
  • Sprint Burndown Chart – «диаграмма сгорания». Она показывает насколько продвинулась команда в течение этапа.

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

Характерные ошибки внедрения Agile и недостатки подхода

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

К распространённым ошибкам внедрения относятся следующие:

  1. Ограничение командной свободы со стороны руководства. Руководитель проекта не всегда готов отпустить команду, дав ей самостоятельно решать, что делать. Для эффективной работы необходимо реальное расширение возможностей и прав каждого участника процесса. Руководство не должно ставить мелкие задачи исполнителям и проверять выполнение каждого действия. Но иногда право решения передаётся исполнителю частично и в ограниченном виде, что снижает эффективность общего процесса.
  2. Отсутствие доверия внутри команды и старые привычки. При внедрении подхода Agile в уже сложившихся коллективах с классической иерархией команде сложно бывает отказаться от патерналистских установок. Даже сознательно соглашаясь с новыми правилами игры, работники реализовываются в рамках ранее сформированных навыков взаимодействия. Чтобы изменить навыки, такие коллективы проходят специальные тренинги работы в команде. Но и это не застраховывает от мелких конфликтов. Нововведения редко проходят абсолютно гладко. Считается, что, в среднем, до 30% персонала так и не переходят на новый формат работы, что влечёт либо проволочки, либо серию увольнений.
  3. Нарушения в обратной связи. Иногда обратную связь от клиентов могут просто игнорировать, мотивируя это тем, что клиент хуже знает, что ему на самом деле надо. Тут важно отдавать себе отчёт в том, что именно заказчик – заинтересованная сторона.
  4. Недостаточное тестирование. Иногда тестирование прекращают после запуска первой рабочей версии продукта. Так же минуют стадию обсуждения в конце итерации.
  5. Отсутствие у топ-менеджеров чёткого понимания целей внедрения новой системы с гибким подходом и отсутствие методологий. Как правило, цели с цифрами заменяются лозунгами или слоганами (например, «Быть всегда впереди конкурентов»), а вместо методологий описываются идеи, а не операции.
  6. Внедрение подхода на одном участке. Для эффективности обычно советуют переформатировать деятельность всех сфер компании, начиная с бухгалтерии и отдела продаж и заканчивая производством и маркетингом.
  7. «Остывание». Процесс перехода на новую систему работы может занять несколько месяцев. Иногда нужно произвести переоборудование (установить новые станки или ПО и обучить сотрудников), иногда – полностью изменить тип мышления в рамках рабочего процесса. Поскольку со временем люди устают от перемен, процесс перехода на новую модель начинает надоедать на полпути. Теряется мотивация, а с ней уменьшается и вероятность успешного внедрения.
  8. Разочарование после первых итераций. Иногда после первых этапов исполнители просто недовольны результатом, но нередко это недовольство выливается в неконтролируемое стремление довести продукт до почти идеального состояния. А правильное совершенствование продукта происходит именно в процессе многократной шлифовки с разделением на соответствующее потребностям число итераций. Частично это решается грамотным планированием, при котором пропускная способность одной итерации одной командой оценивается адекватно (без пере- и недооценки).

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

Agile принципы

Автор : А. Беляев

Дата публикации: 9 декабря 2013 г.

Agile (англ. “живой”, “подвижный”) — семейство гибких методологий разработки ПО, появившееся в начале 2001 года как новая ступень программирования после Code-and-Fix (сначала пишем, потом проверяем и исправляем) и инженерного (анализируем – проектируем – реализуем – тестируем).

По своим принципам гибкие методологии — это нечто среднее между двумя предшествующими подходами. Они отчасти вариативны, как и code-and-fix, но отнюдь не пишутся без какой-либо основы; отчасти они строго структурированы, как и инженерные модели. И при всём этом, называясь новым, это семейство методологий основывается на давно известных идеях.

Манифест гибкой разработки

Манифест гибкой разработки — это четыре пункта, содержащих альтернативу:

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

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

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

Принципы гибкой разработки основаны на ценностях, указанных в Манифесте в качестве ориентира при разработке ПО:

1. Удовлетворение клиента за счёт ранней и бесперебойной поставки ценного программного обеспечения.

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

3. Частая поставка рабочего программного обеспечения (каждый месяц или неделю или ещё чаще).

4. Тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта.

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

6. Рекомендуемый метод передачи информации — личный разговор (лицом к лицу).

7. Работающее программное обеспечение — лучший измеритель прогресса.

8. Спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределённый срок.

9. Постоянное внимание улучшению технического мастерства и удобному дизайну.

10. Простота — искусство не делать лишней работы.

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

12. Постоянная адаптация к изменяющимся обстоятельствам.

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

Длина итерации в различных Agile-разработках различается (от 1 до 6 недель), но главное правило — чем короче, тем лучше. При этом итерационный жизненный цикл основан на управлении с обратной связью. Его важнейший этап — анализ результатов, получение обратной связи и улучшение рабочего процесса.

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

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

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

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

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

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

В завершении хотелось бы отметить, что принципы плотного сотрудничества с клиентами, взаимной помощи для достижения наилучших результатов знакомы нам не понаслышке. Мы уделяем особое внимание работе с заказчиком, потому что для компании «Pharus» главная цель – принести максимальную пользу, не пренебрегая качеством.

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

Отзывы наших клиентов

ФГУП «Гостехстрой» выражает огромную благодарность и признательность команде профессионалов компании Pharus за проделанную работу по разработке и дизайну нового сайта. Несмотря на огромное количество подобных сайтов, команде Pharus удалось создать сайт, который выигрышно отличается современным дизайном, удобством в навигации и эффективностью продвижения нашей компании.