Системное мышление - это ключевой принцип, который может вдохновлять и направлять команды разработчиков программного обеспечения, особенно те, которые работают в гибкой среде. Среди различных увлекательных аспектов системного мышления весьма интересна идея обнаружения общих паттернов проблемного поведения системы. Эти закономерности настолько очевидны и в то же время так неуловимы - в зависимости от того, рассматриваете ли вы их с точки зрения систем или нет. Один из таких распространенных паттернов - Tragedy of the Commons.

Вот один простой способ описать Tragedy of the Commons в контексте разработки программного обеспечения:

  • Представьте, что четыре команды Agile работают вместе над созданием мобильного приложения. Каждая команда обрабатывает набор функций в приложении, таких как аутентификация, управление пользователями и т. Д.
  • Хотя каждая группа фокусируется на создании своих функций, им по-прежнему необходимо вносить изменения в одни и те же репозитории кода - внешний и внутренний уровни приложения, базы данных и т. Д. Фактически, эти четыре команды работают над системой общих ресурсов (общая база кода). Назовем эту общую базу кода "Общей".
  • Работая над этим обычным, каждый разработчик в этих группах будет испытывать типичные нагрузки повседневной рутинной работы - срочные «тактические» исправления критических производственных дефектов, исправления для соблюдения жестких сроков, установленных руководством, неспособных выполнить сосредоточиться на работе из-за разрыва в предыдущий день с кем-то особенным, ужасного на вкус кофе в понедельник утром и т. д.
  • Будучи человеком, вполне вероятно, что найдутся короткие пути, чтобы справиться с давлением. В результате эти разработчики время от времени будут вносить некоторые не очень идеальные изменения в Common, игнорируя все стандарты кодирования и передовые методы, согласованные в командах.
  • Каждый раз, когда разработчик прибегает к такому ярлыку, он обычно думает: «Что ж, позвольте мне сейчас отметить это небольшое изменение. Я вернусь и проведу рефакторинг, когда у нас будет больше времени после завершения этого большого релиза. В любом случае, компонент в настоящее время находится в хорошем состоянии »или что-то вроде« Это небольшое изменение без надлежащих модульных тестов не приведет к снижению общего тестового покрытия компонента, поэтому позвольте мне хоть раз расслабиться »или что-то вроде« Разрешите развернуть это исправление быстро. В следующий раз, кто бы ни работал над этой частью кода, он реорганизует ее в более чистую форму »и т. Д.
  • Со временем таких ярлыков накапливается. По отдельности они кажутся относительно безвредными и небольшими по размеру. В совокупности они могут нанести серьезный ущерб. Поскольку обратная связь об уровне ухудшения Common слишком мала, чтобы ее можно было заметить, нет никаких сигналов тревоги, которые срабатывают каждый раз, когда выполняется такое сокращение.
  • В конце концов, Обычный достигает состояния, близкого к поломке или окончанию срока службы. Он становится неуправляемым и помечается как устаревший код, с которым больше никто не хочет иметь дело. Когда приходит осознание этого, люди задаются вопросом: «Как мы оказались в таком состоянии?» Общая трагедия!

Таким образом, Tragedy of the Commons влечет за собой постепенное ухудшение общего ресурса, когда пользователи не получают четкой обратной связи о состоянии этого ресурса при выполнении своих действий. Обратная связь с отдельными пользователями слабая, потому что ущерб, нанесенный ресурсу, разделяют все остальные, использующие этот ресурс.

Так как же нам справиться с трагедией общин в контексте описанных выше программных команд? Вот что можно попробовать:

  • Парное программирование. В то время как один из разработчиков в конкретный день может испытать соблазн сократить путь, проверка кода в реальном времени посредством спаривания поможет предотвратить это во многих случаях.
  • Наставники компонентов - поощряйте членов команды становиться наставниками компонентов через волонтерство. Наставник компонента может действовать как проводник и активно заботиться о состоянии компонента.
  • Контрольные точки качества и стандарты кодирования - как часть конвейеров автоматизированного развертывания, создавайте строгие контрольные точки качества и стандартные проверки кода, которые запускаются при каждом внесении изменений.
  • Запросы на вытягивание и экспертные проверки - в экстремальных ситуациях установите строгие модели запросов на вытягивание и правила для экспертных проверок. Однако будьте осторожны, так как усиление контроля в конечном итоге замедлит вас и может создать еще один набор проблем, с которыми нужно справиться.
  • Определение «готово». Скрам-команды обычно работают с определением «готово» для своих элементов спринта. Хорошей практикой является создание четкого определения «готово», которое включает в себя факторы хорошей гигиены, которые могут предотвратить ухудшение состояния компонентов.

Прежде всего, расскажите своим командам о Tragedy of the Commons и дайте им понять, что они не попадут в эту ловушку!