Признаки того, что ваш процесс разработки является Agile только на бумаге и как это исправить

1656486012 priznaki togo chto vash proczess razrabotki yavlyaetsya agile tolko na

Ловкость приходит с практикой, а не на бумаге. Использование Jira не делает процесс разработки программного обеспечения гибким. Сказать, что мы делаем scrum, не значит быть гибким.

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

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

QsoP-waDxNwWENV8yaNFopJLAAHUEZvEdBg5
Изображение Agile доски от Unsplash

TLDR;

  • Если вы пишете документы > 5 страниц, можно улучшить.
  • Должно быть четкое определение Готово к развитию и Готово.
  • Сюжет/проблема должна основываться на ценностях, предоставленных заказчику, а не только на техническом аспекте.
  • Выпуск новой версии программного обеспечения раз в месяц и заявление о том, что мы ловкие, должно быть преступлением.
  • Не заботиться о команде – это не правильно работать.

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

Документы длиннее 5 страниц

Будут большие особенности (эпосы), и их следует объяснить. Это не дает вам лицензии на написание 50-страничных документов. Если документ больше 5 страниц, многие члены команды не прочтут его. Примите этот факт.

В один прекрасный понедельник вы получаете записку на 30 страницах о новой функции, которую компания хочет, чтобы мы разработали. Вы прочтете это тщательно? Ответ – нет.

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

Решение

Напишите документы, объем которых меньше или равен 5 страницам. Сделайте это лаконичным и чётким. Начните создавать наглядные пособия для пояснения процесса. Создавайте макеты и используйте такие инструменты, как Balsamiq. Выскажите требования так, чтобы они поняли всем, кто не читает или не читает. Затем при необходимости создайте дизайн интерфейса пользователя и обсудите. После этого реализуйте это в коде.

Нечеткое определение «Готово к разработке» и «Готово».

Четкое определение готовности к развитию и сделанному является решающим для успеха команды. Отсутствие этих или нечеткость помешает производительности команды.

Инженер-программист должен четко знать, когда история готова к разработке. То же касается сделанного.

Готова ли она к развитию, когда история создана, но описания нет? Сделано ли это, как только я разверну его в рабочем состоянии и перемещу свою задачу в столбец «выполнено»? Если возникает такая неразбериха, это вопрос, который нужно решить.

Решение

Иметь четкий пункт «Определение готового» и «Определение готового». Это поможет вам оценить и улучшить результативность команды. Это также поможет всем причастным понять значение этих вещей в равной степени.

Истории основаны на технических аспектах, а не на ценностях для клиента

Гибкая разработка программного обеспечения – это всегда придание ценности клиенту. Ценность в виде работающего программного обеспечения, а не груды документов.

Скажем, есть история типа «Как менеджер по обслуживанию клиентов мне нужно знать, кто создал возмещение, чтобы я мог отслеживать и проверять возврат средств в будущем». Эта задача может предусматривать добавление поля «created_by» в таблицу возмещений, например. Но это не должно привести к появлению истории с надписью «Добавить поле created_by в таблицу возврата средств». Конечно, это может быть задача/подзадание как часть основной истории. Основная история приносит ценность, но эта задача базы данных является тем, что помогает этому процессу.

bEDuLU1nTvT3YZAeZaxaIVHshWGUXbVjNg5X
Рассказ имеет ценность и баллы, задача часть рассказа.

Решение

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

Главное здесь – «всегда сосредотачиваться на доставляемых клиенту ценностях».

Выпуск новой версии программного обеспечения раз в месяц

Первое, что следует учитывать здесь:

Развертывание – это техническая задача, а выпуск новой версии программного обеспечения – бизнес.

Развертывание не является выпуском. Если вы не в состоянии сделать это отличие, нужно что-нибудь исправить. Кроме того, если вы почти не упускаете по одной новой версии ежемесячно, вы делаете agile неправильно. Досрочный релиз часто является великолепной философией для раннего получения обратной связи. Благодаря ранней обратной связи вы можете внести новый набор изменений в следующем выпуске, чтобы улучшить программное обеспечение.

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

Решение

Создайте культуру и технический процесс, позволяющий развертывать и выпускать несколько раз в день.

Обеспечьте хорошее качество кода и отличные методы разработки программного обеспечения. Следуйте проверенным наилучшим практикам, таким как обзоры кода, автоматическое тестирование, CI/CD, ведение журналов, мониторинг и автоматическое развертывание.

Назовите это DevOps, SRE или Platforms Engineering – как угодно. Но делайте это и разворачивайтесь без страха, когда захотите.

Не заботиться о мотивации команды

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

Мотивация команды и счастливые члены команды важны для высокой производительности.

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

Решение

Формировать культуру постоянного усовершенствования. Подумайте о том, что было сделано и как можно улучшить процесс. К примеру, если 60% новых функций и 40% ошибок не работают хорошо, найдите лучшее соотношение. Занимайтесь командными мероприятиями и вещами, повышающими командный дух.

Вывод

Быть ловким на бумаге и быть ловким на практике – это две разные вещи. Не позволяйте вашему гибкому программному процессу походить на модель водопада с так называемой agile skin. Будьте ловкими и исправляйте эти признаки, чтобы иметь высокую производительность команды и фантастическую производительность.

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

Вы можете прочитать больше моих сообщений в блоге на geshan.com.np.

Добавить комментарий

Ваш адрес email не будет опубликован.