История создания “Манифеста Agile-разработки ПО”

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

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

Договорились о многих аспектах разработки ПО, и поэтому решили оформить этот общий базис в виде боевого клича для всей отрасли. Хотели показать, что отстаивают и чему сопротивляются. Создают хорошие продукты для клиентов в среде, где не просто говорят о “людях, как самом ценном ресурсе”, но своим поведением показывают, что люди критически важны. Первый проект по XP стартовал в 1996, а оформился подход в 1999.

Agile-подход и принципы Agile

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

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

Успешный переход к Agile невозможен без глубокого понимания сути подхода. Разобраться с этим помогает Agile-манифест и сформулированные на его основе принципы, которые лежат в основе эффективной https://deveducation.com/ работы современного HR. Agile-манифест действительно часто служит отправной точкой для тех, кто хочет распространить идеи agile за пределы разработки ПО, и основой для развития бизнес-гибкости.

Методы и средства реализации

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

Легковесные — то бишь те, где все участники процесса работают с первичными требованиями от пользователей, заказчика или стейкхолдеров. Эти требования могут быть заявкой, хотелкой, пользовательской https://deveducation.com/ историей или выражены еще в какой–то форме удобной людям. Легковесные подходы как альтернатива тяжеловесным — где очень и очень много документации и жестких регламентов.

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

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

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

После долгих разговоров и обсуждений, участники смогли выработать формулировку четырех ценностей, которые отражают чаяния каждого из них. 17 человек из списка приглашенных, все-таки приехали в Сноуберд, и приняли участие во встрече. Именно им мы обязаны появлением Agile-манифеста в том виде, в котором мы его знаем. Неизвестно, каким был бы результат встречи, если бы эти люди приняли в ней участие. Но мне думается, что Том ДеМарко, Гради Буч и Питер Коад могли сильно повлиять на ход встречи, и добавить в нее много интересного, и Agile-манифест мог бы выглядеть совсем иначе.

Иерархия компетенции в Agile

Два списки объединили, да и вообще, постарались собрать всех активных, кому может быть интересно. Рабочим названием встречи было «Lightweight Methods Summit». Звучит классно, но нуждается в более подробном объяснении. Детально эти принципы изложены в книге Гривз и Лэинг “Growing Agile”. Кроме того, следует упрощать процессы, минимизируя количества лишних операций.

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

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

Тяжеловесы и легковесы

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

Agile-манифест: ценности, принципы и алгоритм применения методологии

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

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

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

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

Персональные инструменты

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

Автор: Денис Белый