Dev vs Ops

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

Вертикальная черта символизирует барьер в передаче информации, знаний и артефактов. Один из способов повысить эффективность организации — размыть эту черту.

Системный подход в основе DevOps говорит о том, что локальная оптимизация может привести к глобальной деградации. Поэтому, планируя изменения, мы должны смотреть на организацию как целостную систему, не упуская из внимания стратегическое планирование, маркетинг и продажи, административные функции, планирование, работу с требованиями и дизайном, разработку, поставку, эксплуатацию, поддержку и т.д.
Разделение обязанностей Dev и Ops

Share

Зачем нарезать пользовательские истории?

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

Keep Reading

Share

Метафора системы и архитектура

У архитектуры множество определений. Одно из наиболее емких — представление о компонентах системы и их взаимосвязях между собой. В качестве компонентов могут выступать как достаточно крупные куски системы, например, интернет-банк, мобильный банк, смс-банк, процессинг, так и более мелкие, — компонент по работе с карточными лимитами, модуль конвертации валют, компонент уведомлений.

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

Водопадный подход максимально пытался обеспечить целостность архитектуры за счет BDUF/BRUF (Big Design Upfront/Big Requirement Upfront). Это были два грандиозных по своим масштабам этапа — сбор требований и проектирование, плавно перетекающее в детальный дизайн. Выхлопом этапов были железобетонные требования и нерушимый, крепкий как скала дизайн.

В Agile все несколько иначе — мы работаем короткими итерациями, каждая из которых включает в себя и уточнение требований и дизайн и тестирование. BDUF/BRUF не подходит ни под каким углом.

Как же при таком подходе обеспечить целостность архитектуры системы?
Keep Reading

Share

«Неработающий Agile»

Навеяно множественными утверждениями «[У нас] Agile не работает»

С чего все начиналось?

То, что мы сейчас называем Agile, берет своё начало в 70-е годы. Еще тогда Винстон Ройс в статье «Managing the Development of Large Software Systems» указал на необходимость циклов обратной связи между различными этапами (фазами) разработки в Waterfall-модели, попытавшись представить процесс как итеративный вместо существующего на тот момент последовательного.

Циклы обратной связи

В 1986-м в Harvad Business Review выходит статья «The New New Product Development Game» за авторством Hirotaka Takeuchi и Ikujiro Nonaka. Анализ, проведенный авторами показал: системы, которые для внешнего наблюдателя выглядели хаотичными, оказалась эффективными и позволяли выпускать продукты в значительно быстрее. В этой статье они впервые сравнили кросс-функциональные, активно взаимодействующие, разрабатывающие продукты от начала и до конца команды с командами Регбистов.

Последовательные и «наслаивающиеся» фазы

Настал 2001-й год. 17 признанных во всем мире профессионалов в разработке собрались, проанализировали чего у них общего, но отказались описывать это общее в виде процесса, а сформулировали четкие и понятные цели и принципы, которые, по их мнению, должны лежать в основе эффективного процесса. Так появился «Manifesto for Agile Software Development». Например, Scrum — фреймворк, который построен на этих ценностях и принципах.

Как Agile работает?

Вначале следует дать несколько определений:

  • Ценности — это то, что важно для отдельных людей в организации и для организации в целом
  • Принципы — некоторые правила, которыми мы руководствуемся при ежедневном принятии процессных решений
  • Контекст — это совокупность свойств организации, например: «сколько людей вовлечено в работу?», «насколько рискованный проект?», «насколько быстрая реакция на изменения рынка требуется и как часто необходимо поставлять новую версию продукта?», «насколько сложна решаемая  с помощью продукта проблема?», «что мы понимаем под качеством?» и так далее
  • Новое знание — то, что мы узнаем на основе полученного ранее опыта и что позволяет постоянно улучшать процесс

На основе ценностей, принципов и контекста можно начинать строить процесс и внедрять конкретные практики. Если важной является возможность быстрой реакции на изменения рынка (готовность к изменениям..) и следование тому, что в принципах представлено как «technical excellence», возможно следует посмотреть в сторону практики Test-Driven Development.

Процесс объединяет практики, используемые различными ролями в компании. Практики дополняющие и усиливающие эффект друг друга. То есть позволяет большому числу людей координировать действия для достижения общей цели. Крупные компании могут посмотреть в сторону Portfolio Management.

Какие практики и какой процесс использовать — зависит от целей, принципов и контекста. Как они будут развиваться, что оставить, а что убрать — зависит от новых знаний, получаемых от потребителей продукта, командами в процессе рефлексии, компанией через анализ собственных показателей.

screen-shot-2016-09-14-at-11-59-32

В настоящий момент существует великое множество проверенных временем практик и инструментов: Impact Mapping, Story Mapping, C4, Specification By Example, Behaviour-Driven Development, ….
Равно как и подходов, в которые эти практики органично встраиваются, например Scrum, KanbanSAFe, LeSS.

 

XP Practices

 И что это значит?

Это означает, что Agile не может работать или не работать. Это набор ценностей и принципов. Они просто есть. А дальше компания, руководствуясь ценностями, принципами и контекстом выстраивает собственную модель или берет существующую, которую вполне может адаптировать под себя.

После чего подбирает практики и связывает их через процессы. При этом компания как живой организм — постоянно развивается и ищет пути повышения своей эффективности через процесс непрерывного обучения (цикл PDCA).  В этом сочетаются простота и красота подхода: оставлять только то, что эффективно и очень быстро, пока оно еще не успело дать корни, избавляться от всего лишнего и мешающего выпускать действительно классные продукты!

Share

ProDevOps

Статья служит цели дать понимание того, что такое  DevOps, как это культурное движение появилось и из чего оно состоит.

Начнем.

Шел 2009-й год. Постепенно осознание в необходимости избавиться от «бункеров», ставших причиной обособленности между разработчиками и админами, стало настолько очевидным и четким, что мысли переросли в нечто осязаемое, получившее в последствии название «Культурное движение DevOps».
Keep Reading

Share
  • 1
  • 2