Agile

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

All agile frameworks rely upon the principle of delivering working software frequently, but this principle takes it a step further.  Teams must deliver working software; not just a cog in the machine, so to speak.  

Consider the image below.  The left-hand side of the image represents the traditional way of delivering value to the customer, which is a large deliverable provided after everything envisioned in the final product is complete.  Contrast this with the right-hand side of the image, which shows an iterative (frequent), incremental (Done) approach for delivering value.  Each piece of what is delivered is usable, but it’s a smaller piece of the bigger puzzle.  

In Scrum, teams determine the frequency of value delivery by the length of the Sprint.  The purpose of each Sprint is to deliver a Done, usable increment of work at least once per Sprint.  The Product Owner then determines when to release the functionality to the customer.  The Sprint length should be just long enough to allow the Developers to deliver a usable increment of product, and no longer, with a preference towards the shorter timescale.

Преимущества Agile-подхода

1. Отсутствие бумажной волокиты

‍

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

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

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

при внесении изменений в ТЗ поддерживать большой слой документации, иначе потом заказчик не пройдёт внутренний аудит (если ТЗ не будет соответствовать реализованному), а исполнитель рискует не получить оплату;

не затягивать его написание на многие месяцы. Крупные клиенты часто не могут утвердить ТЗ — нужно согласование с большим количеством отделов. Каждый отдел генерирует новые требования и не заинтересован в соблюдении сроков (у них есть более важные дела). В итоге ТЗ на внедрение разрабатывается долго и уже в процессе разработки устаревает;

всё равно придётся устраивать регулярные демо, потому что тестирование всего функционала целиком занимает очень много времени, а лишнего времени обычно нет;

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

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

‍

2. Движение «маленькими шагами» обходится дешевле и быстрее приносит результат

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

‍

Agile реальная практика внедрения

Очень часто, при неправильном подходе в выборе целей на внедрение Agile компании на начальном этапе Agile трансформации могут столкнуться с хаосом и непониманием персонала — выход один:

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

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

5 преимуществ метода гибкого управления Agile

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

Agile (эджайл) от идеи руководителя к внедрению в компанию

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

Зачем внедрять Agile методы гибкого управления в компании

Успехов вам Дамы и Господа, особенно при внедрении Agile

Functional Managers

A functional manager is a person that have management authority over group of people. That authority comes from the formal position of that person in the organization (eg. director of the department, quality department manager, development team manager). Role of functional managers is different then Project Managers or ScrumMasters and is not project based.In more agile organizations different models exists. Functional manager often are responsible for developing people in their groups, securing budgets and time for people. However there are also some Agile company models where functions usually assigned to functional managers are distributed to other roles within organization (eg. Spotify model with Tribes, Guilds, Chapters, Squads).

Out in the traditional world of work companies organize people into a hierarchy. People with similar work roles are grouped into functional areas and led by a Functional Manager. The functional manager is generally responsible for the guidance and well-being of the employees who report directly to her.

Agile project teams will often work with functional managers who control the resources the team needs to get work done. An example would be working with a functional manager in procurement to assign a person to work with the team to procure software licenses.

Как работать по Agile?

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

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

Scrum

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

Kanban

Kanban — это инструмент менеджмента потоков работ, который основан на принципах визуализации, ограничения и оптимизации процессов. Так, kanban использует доску (board) с колонками (columns), отражающими статусы бизнес-задач (например, to do, in progress, done и т.д.), и карточки (cards), которые представляют собой конкретные задачи. Kanban предоставляет возможность руководителю и команде видеть весь объем работ и движение задач от начала до конца, устанавливать лимиты на количество рабочих задач в каждой колонке (work in progress limit), чтобы избежать перегрузки и снизить время спринта (cycle time), анализировать и улучшать процессы, используя метрики, диаграммы и правила. Kanban становится все более гибким и адаптивным, его можно применить к любому типу и сфере.

XP

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

• парное программирование (pair programming): два разработчика работают вместе над одним компьютером;

• разработка через тестирование (test-driven development): код пишется после написания тестов;

• рефакторинг (refactoring): код постоянно улучшается и оптимизируется;

• коллективное владение кодом (collective code ownership): каждый разработчик имеет право изменять любую часть кода;

• непрерывная интеграция (continuous integration): код регулярно собирается и проверяется;

• непрерывная доставка (continuous delivery): код регулярно доставляется заказчику;

• планирование на основе пользовательских историй (user stories), где требования к ПО формулируются в виде коротких описаний функциональности с точки зрения пользователя;

• планирование на основе игры (planning game): команда и клиент совместно определяют приоритеты, объем и сроки.

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

 Lean

Это философия, основанная на принципе постоянного стремления к совершенству, устранению потерь и созданию пользы для покупателей. Lean возникла в Японии в середине XX века на основе системы Toyota Production System (TPS), которая применялась на заводах автомобильной компании Toyota. Она использует ряд принципов и инструментов:

• определение ценности (value): то, что человек готов заплатить;

• поток ценности (value stream): все действия, необходимые для создания и доставки продукта или услуги покупателю;

• потоковое производство (flow): непрерывное и бесперебойное движение продукта или услуги от начала до конца без остановок или задержек;

• вытягивающая система (pull): система, в которой производство инициируется спросом, а не графиком;

• стремление к совершенству (perfection): постоянный процесс улучшения производительности, качества и безопасности.

Lean применяется не только в производстве, но и в различных областях и индустриях, включая разработку ПО.

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

Ценности Agile простыми словами

Ценности Agile родились в 2001 году в Agile-манифесте — в результате обобщения многих тогдашних «методологий разработки» их авторами.

Ценности — это то общее, что определяет приоритеты в работе, независимо от конкретного процесса и предмета работы. Каждая из 4-х ценностей Agile сформулирована в виде «X важнее Y», где X — это:

1. люди,
2. работающий продукт,
3. сотрудничество с заказчиком,
4. готовность к изменениям.

Посмотрим, зачем нужны эти ценности Agile.

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

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

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

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

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

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

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

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

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

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

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

Чтобы не откладывать риски проектов на последние стадии разработки (когда будет уже поздно уменьшать содержание работы, сдвигать срок или усиливать команду), Agile предлагает не только итеративность работы, но и готовность к изменениям на всех стадиях.

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

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

Главное отличие Agile от других методологий

Важно понять, что, хотя к Agile используют термин «методология» по аналогии с предыдущими подходами, все же он не похож на них. Главное отличие Agile в его краткости — 4 основных ценности и 12 принципов

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

В отличие от прочих методологий в подходе Agile нет никаких алгоритмов, но входящие в Agile подходы могут предписывать конкретные приемы. К примеру, гибкий подход экстремального программирования или ХР включает в себя такие приемы, как игра в планирование и парное программирование, где есть конкретные алгоритмы действий.

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

Отличия Agile от других методологий

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

Гораздо заметнее отличия систем, где расходятся концептуальные подходы к организации управления рабочими процессами: скажем, каскадная методология Waterfall и Agile:

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

На чем основывается концепция Agile

Создание Agile Manifesto в 2001 году было революционным моментом для всей IT-отрасли. Однако сама концепция была создана под влиянием разнообразных методологий, каждая из которых внесла свой вклад в формирование ключевых принципов и ценностей гибкой разработки

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

1. Спиральная модель (Spiral Model)

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

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

2. Экстремальное программирование (Extreme Programming, XP)

XP было разработано Кентом Беком, Уордом Каннингемом и Роном Джеффри в конце 1990-х годов. Эта методология разработки опиралась на практики, которые позволяли в сжатые сроки создать рабочий продукт. Проект должен иметь частые релизы с минимальным функционалом, чтобы клиенты могли видеть прогресс и давать обратную связь.

Экстремальное программирование подарило Agile-манифесту понятие коротких итераций, непрерывной интеграции и тестирования

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

3. Спецификация и разработка формальных систем (Formal Methods)

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

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

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

4. Scrum

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

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

5. Теория ограничений (Theory of Constraints, TOC)

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

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

***

Daily Stand-Up and Daily Scrum

The Daily Stand-Up (DSU) or Daily Scrum meeting is one of the integral parts of scrum methodology.

As the name suggests, you hold the meeting daily, at the same time and, for a co-located team, in the same location. The meeting should be brief, finished in less than 15 minutes.

Only members of the Development team are required to attend the Daily Stand-up. Typically, the Scrum Master and Product Owners will also attend, but they are not required.

The standard agenda for each person is:

• What have you done since the last DSU
• What are you doing after this DSU
• What are the major obstacles that are stopping your progress, and where do you need help

Team members are to listen carefully to each other’s contributions and attempt to identify areas where they can assist each other’s progress. The standup meeting will also surface more lengthy topics of discussion that need to take place between different members of the team. These lengthier discussions that arise should then be halted and taken outside of the standup, involving only the relevant participants, and not the entire team.

Code Smells

A Code Smell in computer programming is a surface indication that there might be a problem regarding your system and the quality of your code. This problem might require refactoring to be fixed.

It is important to understand that smelly code works, but is not of good quality.

Examples

1. Duplicated code — Blocks of code that have been replicated across the code base. This may indicate that you need to generalize the code into a function and call it in two places, or it may be that the way the code works in one place is completely unrelated to the way it works in another place, despite having been copied.
2. Large classes — Classes having too many lines of code. This may indicate that the class is trying to do too many things, and needs to be broken up into smaller classes.

Основные принципы Agile

Кроме четырех монументальных ценностей Agile базируется на 12 принципах. В основном они относятся к работе с ИТ-проектами, но вполне применимы и к другим сферам:

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

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

При таком подходе важно постоянное общение в команде.
В течение всего проекта важно, чтобы разработчики и клиент постоянно коммуницировали. В Agile получение обратной связи от клиента — это краеугольный камень.
В проекте должны быть задействованы мотивированные специалисты. Для этого нужно создать подходящие условия и обеспечить поддержку.
Для эффективной работы члены команды должны иметь возможность общаться открыто. Даже, если большинство работает удаленно, вероятно, на некоторых этапах разумно будет организовывать личные встречи.
Работающий продукт — главный показатель эффективности. Цель команды всегда одна — дать клиенту качественный наилучший результат. Если клиент удовлетворен, значит, проект успешен.
Гибкость подхода помогает наладить процесс разработки
Исполнитель и заказчик должны поддерживать согласованный темп.
Гибкость можно повысить, уделяя постоянное внимание техническому усовершенствованию и качеству проектирования. В этом подходе каждый новый проект рассматривается как возможность найти что-то новое вместо того, чтобы постоянно внедрять одни и те же идеи.
Важно минимизировать работу, без которой можно обойтись, и по возможности сделать все итерации проще.
Лучшие продукты могут создавать только те команды, где есть лидер, дающий каждому члену группы свободу самовыражения.
Для достижения успеха важно постоянно анализировать и искать новые способы для улучшения эффективности работы
Суть гибкости в том, чтобы сделать проще и эффективнее.

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

Agile как инструмент в конкурентной борьбе

Очень часто мы сталкиваемся с коварный ситуацией:

Agile в производстве

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

Но есть довольно интересный нюанс:

Объедините в Agile команды специалистов по маркетингу и продажам вместе с конструкторами и специалистами по производству.

Управление по Agile: создаем стандрат

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

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

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

Agile риски внедрения

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

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

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

Рекомендация экспертов по Agile в этом случае проста: