В современном быстро меняющемся и постоянно развивающемся мире разработки программного обеспечения гибкость стала модным словом. Кажется, почти каждая компания утверждает, что использует методологии Agile! Но если вы спросите почему, многим из этих компаний будет трудно дать убедительный ответ.
Прежде всего, я не являюсь экспертом в Scrum или какой-либо конкретной методологии Agile, но в этой статье я стремлюсь поделиться своей личной интерпретацией Scrum и поразмышлять о своем опыте инженера-программиста. Важно отметить, что предоставленные идеи основаны на моей точке зрения и могут отличаться от взглядов опытных практиков Scrum. Тем не менее, я считаю, что обмен нашим личным опытом и пониманием принципов Agile может способствовать более широкому обсуждению его применения в индустрии разработки программного обеспечения.
Гибкие методологии обещают повышение производительности, адаптивности и удовлетворенности клиентов. Однако важно помнить, что гибкость — это инструмент, а не конечная цель. В этой статье мы рассмотрим сущность гибкости и проиллюстрируем ее важность на примере из реальной жизни с точки зрения инженера-программиста.
Понимание Agile:
Agile — это итеративный и совместный подход к разработке программного обеспечения, который делает упор на гибкость, частую обратную связь и постоянное совершенствование. Он направлен на поставку высококачественного программного обеспечения, отвечающего растущим потребностям клиентов. Гибкие методологии, такие как Scrum или Kanban, предоставляют рамки и процессы, которые позволяют командам принимать изменения и эффективно реагировать на отзывы клиентов.
- Agile — это процесс, а не цель.
- Дело в покупателе, а не в продукте!
Другими словами, все дело в том, как мы можем работать вместе как одна команда, чтобы поставлять более качественные продукты быстрее, чем когда-либо прежде!
Всегда помните следующие 4 основные ценности для понимания Agile:
- Предпочитайте людей и взаимодействия процессам и инструментам
- Предпочитайте рабочее программное обеспечение исчерпывающей документации.
- Предпочитайте сотрудничество с клиентами переговорам по контракту
- Предпочитайте реагировать на изменения, чем следовать плану
Ловушка погони за Agile как за целью:
Хотя гибкие методологии предлагают множество преимуществ, они также могут привести к непредвиденным последствиям, если преследовать их исключительно как цель. Одной из распространенных ловушек является тенденция сосредотачиваться на соблюдении процессов и церемоний, связанных с Agile, а не на основных принципах, лежащих в их основе. Команды могут чрезмерно зацикливаться на планировании спринта, стендап-совещаниях и других ритуалах, не понимая в полной мере основополагающих концепций гибкости.
Например, я помню время, когда наша команда впервые перешла на методологию Agile. Мы с энтузиазмом восприняли идею проведения ретроспективы спринта в конце каждого спринта. Сначала мы были поглощены выбором идеальной ретроспективной техники, размышляя между вариантами, такими как Безумно Грустно Рад или Начать, Стоп, Продолжить и т. д. В процессе мы почти потеряли из виду истинную цель, стоящую за ретроспектива.
Вместо того чтобы сосредоточиться на ценной информации и улучшениях, которые можно было бы извлечь из этих сессий, мы зациклились на самой методологии. Выбор метода ретроспективы стал нашей главной заботой, затмив суть ретроспективы: способствовать культуре непрерывного обучения и совершенствования.
Излишне сосредоточившись на процессе и конкретной технике, которую мы будем использовать, мы пренебрегли основной целью ретроспективы: осмыслить нашу работу, определить области для роста и внедрить изменения для повышения нашей будущей эффективности. Наши намерения были искренними, но мы непреднамеренно сместили акцент с желаемых результатов на механику Agile-фреймворка.
Я думаю, что менеджеры должны действовать так, как будто есть еще две «agile-ценности», настолько очевидные, что нет необходимости их официально считать:
5. Предпочитайте бизнес-цели гибкости как таковой
6. Предпочитайте фактические ценности agile гибким инструментам/механизмам/протоколам
–Майкл К. Линднер
Пример из реальной жизни: дело корпорации XYZ
Чтобы проиллюстрировать важность отношения к гибкости как к инструменту, а не цели, давайте рассмотрим гипотетический случай корпорации XYZ, компании-разработчика программного обеспечения. Руководство компании приняло решение внедрить методологию Agile, чтобы улучшить процессы разработки и ускорить выпуск программного обеспечения. Они представили Scrum и обучили все команды работе с ним.
Первоначально корпорация XYZ заметила положительные изменения в своей практике разработки. Однако со временем команды стали больше сосредотачиваться на выполнении Scrum-ритуалов, а не на основных ценностях гибкости. Они стали больше заботиться о своевременном завершении своих спринтов, чем о выпуске ценного программного обеспечения.
Например, во время сессий планирования спринтов команды расставляли задачи по приоритетам, исходя из простоты их выполнения, а не ценности для клиентов. Стоячие встречи превратились в простое обновление статуса, потеряв свою цель поощрения сотрудничества и решения проблем. Ретроспективные сессии, предназначенные для постоянного совершенствования, рассматривались как рутинные ритуалы без реальных результатов.
В результате пострадало качество программного обеспечения, а заказчики стали недовольны. Несмотря на усердное соблюдение методов Scrum, корпорации XYZ не удалось достичь желаемых результатов, потому что они упустили из виду истинную цель гибкости.
Agile как инструмент: понимание сути
Чтобы избежать ошибок, связанных с отношением к гибкости как к цели, важно понимать, что Agile — это просто инструмент, средство для достижения цели. Его истинная ценность заключается в его способности способствовать сотрудничеству, адаптивности и постоянному совершенствованию.
Чтобы по-настоящему использовать гибкость, разработчики программного обеспечения и команды должны сосредоточиться на основных принципах:
- Сотрудничество с клиентами. Активно привлекайте клиентов на протяжении всего процесса разработки, запрашивайте их отзывы и адаптируйтесь соответствующим образом. Цените удовлетворенность клиентов выше соответствия процесса.
- Итеративная и поэтапная разработка: разбивайте проекты на управляемые итерации и доставляйте работающее программное обеспечение на каждой итерации. Принимайте изменения и уделяйте приоритетное внимание обратной связи, чтобы постоянно улучшать конечный продукт.
- Уполномоченные и самоорганизованные команды. Поощряйте самостоятельность и доверие внутри команд, предоставляя им возможность принимать решения и брать на себя ответственность за свою работу. Воспитывать культуру сотрудничества и обмена знаниями.
- Непрерывное улучшение. Регулярно анализируйте процесс разработки, определяйте области для улучшения и вносите соответствующие изменения. Поощряйте установку на обучение и адаптацию.
Заключительные слова:
Гибкие методологии произвели революцию в индустрии разработки программного обеспечения, предоставив командам гибкий и клиентоориентированный подход. Однако важно помнить, что гибкость — это не самоцель, а скорее инструмент для улучшения программного обеспечения и удовлетворения клиентов. Приняв суть гибкости и сосредоточившись на ее основополагающих принципах, инженеры-программисты могут использовать ее истинный потенциал и добиваться выдающихся результатов.
Спасибо за прочтение!
Ресурсы:
https://www.linkedin.com/pulse/agile-tool-goal-michael-q-lindner/
