Свой путь к гибким методологиям разработки организации часто начинают с того, что нанимают сертифицированного Agile-консультанта (Certified Agile Consultant™), изучают Agile-манифест разработки программного обеспечения и Scrum. Затем тратят время на то, чтобы наверстать упущенное за 20 с лишним лет, и, надеюсь, приходят к выводу, что главное — это поставка, а не процесс. Но почему все должны начинать сначала? Манифест был написан более 20 лет назад. И несмотря на то, что некоторые принципы уже устарели, большинство тренингов по Scrum только закрепляют то, что требует обновления. Например, "поставка каждые 2-4 недели" продолжает ограничивать большинство команд.
Сегодня мы знаем, что непрерывная поставка ценности приносит лучшие результаты. Появилась возможность получать обратную связь о качестве наших идей быстрее, с меньшим риском и меньшей нервотрепкой.
Я предлагаю Pull Request…
Код ревью комментарии для этого поста.
Преамбула
Мы постоянно открываем для себя более совершенные методы разработки программного обеспечения, занимаясь разработкой непосредственно и помогая в этом другим.
С момента написания этих строк появились практики, которые работают лучше других практически в любом контексте. Одна из таких практик — непрерывная поставка (Continuous Delivery). Мы должны сосредоточиться на том, чтобы стать лучше именно в ней.
Мы постоянно открываем для себя более совершенные методы непрерывной поставки ценности конечному пользователю и помогаем в этом другим.
Первый принцип
Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения.
Если мы просто поразмышляем о последствиях этого принципа, то поймем, что нам достаточно только его.
Второй принцип
Изменение требований приветствуется, даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества.
Давайте будем более откровенны.
Мы ожидаем, что требования будут некорректны, неправильно интерпретированы и постоянно изменяться. Мы принимаем это и разрабатываем систему поставки для повышения конкурентного преимущества заказчика.
Третий принцип
Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.
Здесь очень устарели цифры. В современной разработке у нас есть возможность реализовать первый принцип с помощью ...
Непрерывной поставки работающего программного обеспечения с периодом поставки от пары часов до пары дней.
Четвертый принцип
На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.
Мы не должны заниматься проектами.
Представители бизнеса и разработчики — это одна продуктовая команда, которая от рождения до смерти несет ответственность за результат.
Пятый принцип
Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.
Меня никогда не мотивирует сам проект. Мне нравится видеть и улучшать свои результаты. У меня может быть мотивация В начале работы над продуктом, но если я оказываюсь в окружении обвинений, похоронных маршей, отсутствия обратной связи от пользователей и т.д., я теряю мотивацию. И если теперь вы попросите меня помочь решить реальные проблемы и обеспечить непрерывную поставку ценностей …
Создавайте продуктовые команды, которые понимают и несут ответственность за миссию, за решения и за результаты, и окружение, которое привлекает, способствует росту и удержанию мотивированных людей.
Седьмой принцип
Работающий продукт — основной показатель прогресса.
Ну, почти …
Как часто вы сталкиваетесь с тем, что "работающий продукт" интерпретируется как "соответствует техническому заданию"? Наша цель — решение проблем бизнеса.
Показателем прогресса являются результаты, приносящие ценность.
Одиннадцатый принцип
Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.
Этот принцип часто понимают неправильно. Здесь требуется уточнение.
Лучшие архитектуры, требования и проекты появляются у продуктовых команд, которые принимают на себя ответственность за проблему, которую нужно решить, знают, как ее решить и отвечают за результат.
Двенадцатый принцип
Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.
Я часто вижу полугодовые ретроспективы. Почему улучшения не могут быть частью повседневной работы?
Команда постоянно размышляет о том, как для повышения эффективности и устойчивости сократить трудозатраты и размер батча. Соответствующим образом настраивает и корректирует свое поведение, используя данные для валидации изменений.
Четырнадцатый принцип Дуэны
Моя знакомая, Дуэна Бломстрем (Duena Blomstrom), в ответ на этот пост предложила еще один принцип. То, что мы делаем, в основном касается людей, а не технологий. Чтобы быть эффективными, нам нужно как можно больше идей от каждого члена команды. Давайте сформулируем этот принцип.
Чтобы быть устойчивыми, счастливыми и продуктивными, на первом месте должны быть комфортные условия труда и психологическая безопасность команды.
Куда я могу отправить свой PR?
Материал подготовлен в рамках курса «DevOps практики и инструменты». Если вам интересно узнать подробнее о формате обучения и программе, познакомиться с преподавателем курса — приглашаем на день открытых дверей онлайн. Регистрация здесь.
