А вы читали принципы Agile-манифеста?
Поднимите руки, сколько из нас здесь работают в Agile-команде? (Все руки поднимаются)
Поднимите руки, кто читал Agile Manifesto (некоторые руки поднимаются)
Поднимите руки, кто считает, что руководство и директора их компании прочитали Манифест Agile (Руки не поднимаются)
Agile-манифест нельзя долго читать — это буквально страница с несколькими маркерами на ней. Вы читали его? Вы это поняли? Вы действительно придерживаетесь принципов в своем повседневном поведении?
Я думаю, что процессы и принципы, описанные в Agile-манифесте, — это фантастический подход к разработке программного обеспечения. Я также думаю (к сожалению), что Agile потерпел неудачу. Не потому, что это плохая идея — как раз наоборот. Я думаю, что это не удалось, потому что, говоря откровенно, никто не удосужился прочитать и понять содержание Agile-манифеста.
Правильно выполненная Agile может (но не улучшит) улучшить перспективы проекта, в зависимости от проекта, клиента, команды и многих других «вещей». Хороший Agile — это толчок в правильном направлении, а не панацея, гарантирующая успех вашего проекта. Неправильный Agile может (но не может) погрузить ваш проект в бездну бесхозяйственности, раздутых бюджетов, срыва сроков и раздражения членов команды!
В Agile-манифесте перечислены двенадцать принципов. В течение следующих нескольких недель я собираюсь просмотреть их все, по очереди, и попытаться подумать о том, что требуется от команды, отдельного лица или организации, чтобы действительно жить в соответствии с принципами. .
В этом посте я начну с первого, а именно:
Нашим наивысшим приоритетом является удовлетворение потребностей клиентов за счет своевременной и непрерывной поставки ценного программного обеспечения.
Как и в случае со всеми принципами Agile, интуитивно это хорошая идея. «Держите своих клиентов довольными» всегда был основополагающим советом во всех компаниях. Точно так же нетрудно понять выгоду от своевременной доставки любых продуктов и услуг!
К сожалению, применение этого простого и разумного совета к программному проекту гораздо сложнее и сложнее, чем может показаться на первый взгляд. В этом посте я расскажу о сложности, лежащей в основе этого, и предложу, как подходить к жизни по этому принципу.
Одной из неотложных проблем является то, что часто заказчик может не знать, чего именно он хочет в начале проекта — понимание заказчиком собственных требований будет улучшаться по мере продвижения проекта. Также часто клиенты могут не знать об ограничениях и возможностях доступных технологий.
Наконец, реализация программного проекта может занять годы, и от начала до конца рынок может коренным образом измениться. То, что удовлетворяет клиента в начале проекта, может не удовлетворить его в (довольно важную) дату поставки.
В приведенном выше также есть предположение, что компания-разработчик программного обеспечения регулярно разговаривает со своими клиентами… что не всегда так. Я знаю, что я не одинок в своем опыте менеджеров, которые просто детализируют списки пожеланий со спецификациями, которые никогда не выполнялись заказчиком.
Как вы можете удовлетворить клиента, с которым вы никогда не разговаривали?
Так что, хотя это звучит очень просто и очень просто, это не так. Необходимы фундаментальные изменения в том, как организация подходит к своему бизнесу, чтобы действительно «жить» по этому принципу.
Для начала, если это еще не сделано, важно, чтобы бизнес напрямую взаимодействовал со своими клиентами, искал рекомендации и отзывы, регистрировал и каким-то образом обрабатывал эти отзывы, а затем изменял ход проекта на основе этих отзывов.
Этот непрерывный и открытый диалог с клиентами и пользователями системы жизненно важен, но часто полностью игнорируется. Это не может быть сделано случайно. Должна быть регулярная запланированная обратная связь, которая следует какой-то структуре, чтобы ее можно было проверять, сравнивать и отслеживать на протяжении всего жизненного цикла проекта — начиная с того, как будет написана хоть одна строка кода!
Первые несколько недель разработки являются основополагающими и задают тон для остальной части проекта, поэтому этот процесс должен быть запущен задолго до начала процесса разработки. Процесс должен продолжаться на протяжении всего проекта с постоянными и быстрыми изменениями, основанными на постоянно меняющихся требованиях клиентской базы и рынка, на котором продается продукт.
Конечно, не все потеряно, если этот процесс модернизируется в рамках уже существующего проекта. Принципы остаются прежними, но внесение изменений в существующий код становится менее гибким, поэтому преимущества уменьшаются (или, возможно, для их реализации потребуется больше времени).
Моя самая настоятельная рекомендация для продвижения этого принципа в вашей команде — уделить первоочередное внимание набору UX-ресурса. UX часто считают «просто» созданием вайрфреймов, но это серьезное непонимание роли UX.
«UX» означает User eXопыт, поэтому их роль охватывает все аспекты взаимодействия пользователя с системой. Гораздо больше, чем просто каркасы и мокапы. Хороший UX-ресурс в корне поймет этот принцип Agile и приведет вашу команду в соответствие почти по определению — преимущества хорошего UX-ресурса невозможно переоценить.
Даже если предположить, что UX-ресурс был нанят, с клиентами консультируются, а обратная связь собирается, включается и встраивается в продукт, в этом гибком принципе есть очень важная «вторая часть». Во второй части говорится, что клиенты удовлетворены «благодаря ранней и непрерывной доставке ценного программного обеспечения». Это можно сделать вручную, но в наши дни выполнение этого требования будет означать создание конвейера CI/CD.
Построение конвейера CI/CD — это прежде всего техническая задача. Хотя в наши дни это довольно понятный процесс, это не делает его технически простым. С созданием и обслуживанием конвейера CI/CD связаны временные затраты, а также часто текущие финансовые затраты.
Самая большая проблема, с которой я столкнулся при работе с CI/CD, — убедить руководство поддержать эти усилия. Время, затрачиваемое на конвейеры, — это время, которое не тратится на функции. Несмотря на очевидную важность этого, получить разрешение на трату времени не всегда просто.
Традиционная модель примерно ежегодного выпуска означает, что «хорошие идеи» застревают в репозитории на срок до года, прежде чем они попадут в руки клиента. Хорошие идеи должны приносить пользу почти сразу же, как только они будут готовы.
Очень сложно дать конкретную рекомендацию по CI/CD, кроме «вы должны это сделать», потому что каждый проект очень уникален, и существует миллион способов его реализации. Я определенно рекомендую инвестировать в CI / CD, какой бы ни была конкретная реализация — по моему опыту, инвестиции окупятся сторицей в виде довольных клиентов.
На мой взгляд, это первый и самый важный пункт в списке из двенадцати agile-манифеста, и на практике его соблюдают хуже всего! Здесь есть много низко висящих фруктов, так что… чего же вы ждете!!
Второй принцип Agile-манифеста:
Приветствуйте меняющиеся требования, даже на поздних стадиях разработки. Гибкие процессы используют изменения для конкурентного преимущества клиента.
Вернитесь сюда в ближайшее время для этого.
Want to Connect? Andy is particularly interested in effective software project management, and the implementation of effective Agile. You can get in touch on Linkedin.
