Если вы видите, что описанные практики есть в вашей команде, то советую плотно задуматься об изменениях процессов или смене людей, которые стоят за этими процессами.
Agile — это про гибкость, скорость и эффективные команды... в теории. А на практике? Давайте разберемся, где кроются ловушки и почему одни команды процветают, а другие увязают в бесконечных митингах и KPI. Будет много практики, наболевших кейсов и честного разговора о том, как Agile работает (и не работает) в реальной жизни.
The 2020 Scrum Guide
Scrum Resources for Developers
Navigating SAFe with Professional Scrum - Building Bridges
SAFe® 6.0 big picture, Posters
Manifesto for Agile Software Development
The Agile Coach by Atlassian
practices-timeline
Subway Map to Agile Practices
Нарцисс
Критика и продажи
Criticism of Agile Methodology
The End of Agile
agile is dead, essence
The Tragedy of Craftsmanship
Flaccid Scrum
Makers Schedule
Бесплатные курсы, на всякий:
https://www.agile-academy.com/en/agile-insights/agile-fundamentals-online-course/
https://www.agile-academy.com/en/agile-insights/scrum-foundations-online-course/
The goal of Agile ... to heal the divide between business and programming.
— Kent Beck
Название: Красные флаги в Agile-разработке"
Серым — то, что подсказал Copilot.
Формат доклада в виде разговора. Не стесняйтесь поднимать руку и вставлять реплики.
Эмоциональная цель — развлечься с пользой, уложившись в тайминг.
Дисклеймер о том, что это содержимое очень субъективно и довольно желчно.
Содержательная цель — поделиться паттернами и практиками, которые указывают на нездоровые процессы в разработке.
Забегая вперёд, в нынешних процессах разработке, особенно в Scrum и SAFe, распространёно нечто типа карго-культа. И часто интровертный или неопытный разработчик, чувствуя, что процесс ему не помогает работать, а зажимает и мешает, оказывается беспомощным перед системой.
В гайдах, пособиях, статьях, очень много не вполне понятных слов, которые топят сознание. И есть сертифицированные специалисты, которые хорошо умеют оперировать этими словами и работа которых — поддерживать систему, не то, чтобы способствовать разработке, в нюансах которых они часто не разбираются.
И у разработчиков случается ощущение, что некомфортно, но ...
"You are not alone."
Если вы видите, что описанные практики есть в вашей команде, то советую плотно задуматься об изменениях процессов или смене людей, которые стоят за этими процессами.
Фронтендер. Прошёл школу мидл-бойца в Яндексе, после уехал в Германию, где работал в Каяке — поиск по авиабилетам и всякое — американской организации среднего размера. И довольно долго в Дикониуме — довольно крупном агенстве, делающем e-commerce для больших клиентов. В мою бытность в этой компании она была куплена Фольксвагеном. В Дикониуме часть моих обязанностей были лидовские и организационные. И в связи с этим я посещал много воркшопов по аджайлу и повидал много команд, которые довольно строго пытались следовать скраму.
At the Snowbird conference, in 2001, where the Agile Manifesto was written, Kent Beck said that one of our goals was to heal the divide between programmers and management.
The Agile movement abandoned that goal by turning Agile into a business that promotes “new-and-better” ways to manage. Instead of bringing managers and programmers closer together, the Agile movement focussed almost entirely on project management, and virtually excluded the programmers.
Scrum — трейдмарка.
Картинка SAFe. И про то, что прочитать о роли dev-команды невозможно, ибо доступ платный. Интересно то, что писать код — 1/10 обязанностей команды разработки.
As the ecosystem began to grow and Agile ideas began to spread, some adopters lost sight of the values and principles espoused in the manifesto and corresponding principles. Instead of following an “Agile” mindset, they instead began insisting that certain practices be done exactly in a certain way.
Авторы, которые критикуют: Robert C. Martin и Martin Fowler. Последний применил красивый термин Semantic Diffusion и указал на то, что процесс разработки лишён технических практик.
Scrum can degenerate into a highly overrated tool that generates more effort than benefit at a certain development stage of the product in development. For example, when a product has been well received by customers and the focus of the team lies on updates & maintenance instead of new features.
Бумажка на двери в кофе-пойнт:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
1. Люди и взаимодействие важнее процессов и инструментов
1. Работающий продукт важнее исчерпывающей документации
2. Сотрудничество с заказчиком важнее согласования условий контракта
3. Готовность к изменениям важнее следования первоначальному плану
И скрам-мастер в команде:
Scrum Masters are coaches, not managers. Their role is to defend the values and disciplines. Their role is to remind the team of how they promised themselves they would work. The role was supposed to be shared by the team, not usurped by managers. Every few weeks a new team member would volunteer to act as coach – if needed. The role was supposed to be temporary. A mature team doesn’t need a permanent coach.
Начиная с этого слайда перечисление паттернов и практик. Часть из них наверняка вам знакома. Смысл этого перечисления для меня в том, чтобы люди вспомнили, что эти практики не очень здоровы или просто не очень. И, возможно, набрались бы куражу бороться с ними.
5 основных дисфункций, которые представлены в виде пирамиды (снизу вверх):
Каждый уровень пирамиды базируется на предыдущем, поэтому решать проблемы нужно начиная с основания (доверия).
Проблема с доверием в том, что нередко оно манифестируется, но не зарабатывается.
Managers' Schedule (Расписание менеджеров):
Makers' Schedule (Расписание создателей):
Конфликт:
Решения:
Длинные встречи. После определённого времени нужно бодриться или менять контексты.
Психологически нормально и объяснимо, если после дня встреч программист не видит сделанной работы. Не нужно себя винить... :)
Отсутствие работы по тикету — отсутствие продуктивности — распространённое заблуждение менеджеров.
Если слишком много народу постоянно, нужно делить команды.
Стейкхолдеры, вообще, не приветствуются. Если они создают давление на команду.
Совы часто не учитываются. Вообще, убеждение о том, что со стендапа начинается день, тоже спорно.
И много, и написано очень много текста с точки зрения менеджеров. Я лишь отмечу самые для программистов.
Refactoring is a controlled technique for improving the design of an existing code base. Its essence is applying a series of small behavior-preserving transformations, each of which “too small to be worth doing”. However the cumulative effect of each of these transformations is quite significant. By doing them in small steps you reduce the risk of introducing errors. You also avoid having the system broken while you are carrying out the restructuring - which allows you to gradually refactor a system over an extended period of time.
Рефакторинг - это контролируемый метод улучшения дизайна существующей базы кода. Его суть заключается в применении серии небольших преобразований, сохраняющих поведение, каждое из которых “слишком мало, чтобы его стоило выполнять”. Однако совокупный эффект каждого из этих преобразований весьма значителен. Выполняя их небольшими шагами, вы снижаете риск возникновения ошибок. Кроме того, вы избегаете сбоев в работе системы во время реструктуризации, что позволяет выполнять постепенный рефакторинг системы в течение длительного периода времени.
Silent commitment: пример из жизни про PI Planning
Напутствие: делайте так, как вам подходит. Ориентируйтесь на фреймворки, но не старайтесь следовать им. Лучше всего понимать применимость разных подходов к конкретному проекту.
Вкладывайтесь в технические практики оптимизации разработки: Парное программирование, непрерывная интеграция (CI), разработка через тестирование, техники по уменьшению технического долга.