«Неработающий 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).  В этом сочетаются простота и красота подхода: оставлять только то, что эффективно и очень быстро, пока оно еще не успело дать корни, избавляться от всего лишнего и мешающего выпускать действительно классные продукты!

FacebookTwitterGoogle+LinkedInVKShare

ProDevOps

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

Начнем.

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

Быстрый способ «восстановить» пароль администратора в Jenkins

Если вы забыли или не знаете админский пароль от Jenkins.

Найдите config.xml, например так:

$ mdfind “jenkins.security.ApiTokenProperty”

В моем случае, на MacOS, путь к файлу admin’а: /Users/Shared/Jenkins/Home/users/admin/config.xml

Замените hash пароля

<passwordHash>#jbcrypt:$2a$10$BjBouLN.W0Olv8ObQte6Eu9ihFcMceWq5RBHwtSFpbB3akAxE3vPC</passwordHash>

на

<passwordHash>#jbcrypt:$2a$10$razd3L1aXndFfBNHO95aj.IVrFydsxkcQCcLmujmFQzll3hcUrY7S</passwordHash>

Перезапустите Jenkins и заходите с паролем test.

 

О логистике, поставщиках и DevOps

Идея статьи возникла из нарастающего интереса к Agile и, в частности, к DevOps в сфере производства. Несмотря на то, что сейчас любая деятельность так или иначе круто завязана на IT, людям, занимающим высокие должности в сфере производства реальных товаров, может быть трудно понять наш профессиональный язык, в котором к тому же что ни термин, то англоязычный.

Постараюсь провести параллель между созданием программного и физического продуктов и сопоставить ряд важных терминов из двух миров. Keep Reading

Особенность DevOps‬ в крупных ‪компаниях

Прежде чем перейти к особенностям DevOps, стоит разобраться, в чем отличие крупных компаний и систем, поддерживающих их работу. Это и командообразование по технологиям (часто называют silos), и жесткие требования регуляторов, и большое количество согласований и, безусловно, крупные, масштабные релизы.
Такие системы имеют долгую историю, соответственно, аккумулируют занния, костыли и решения от нескольких поколений разработчиков, архитекторов, аналитиков; технологических изменений в мире. Приходилось вам видеть монолит, в котором часть кода на java 1.4, часть на 1.6, часть на 1.7?
И разумеется, грандиозные размеры и колоссальные инвестиции, вследствие чего и страшно и жалко.

Теперь немного конкретики.
Keep Reading

Зачем проводить Code Review?

Linus’s Law: «given enough eyeballs, all bugs are shallow»

«Зачем проводить Code Review?», — вопрос достаточно распространенный.

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

Wikipedia о code review нам говорит следующее: «улучшение качества программного продукта и совершенствование навыков разработчика. …могут быть найдены и устранены такие проблемы, как ошибки в форматировании строк, состояние гонки, утечка памяти и переполнение буфера, что улучшает безопасность программного продукта»

Всё верно, но ревью кода решает еще две очень важные задачи, которые невозможно решить никаким иным путем:

  • Синхронизация ментальных моделей
  • Распространение знаний о коде

Все остальное: качество, корректность и т.д. так или иначе, костылями и/или автотулами можно сделать, а вот понять код можно только просмотрев код и никак иначе.
Keep Reading

Цикл Деминга, Scrum и Toyota Production System

Нередко про цикл Деминга, Scrum и Toyota Production System рассказывают дискретно, будто несколько историй в одном фильме под эгидой одной идеи. И как они между собой связаны — не всем и не всегда очевидно.

Выгдядит это примерно так. Долгий рассказ о PDCA. Затем долгий рассказ о Тойоте и MURI, MURA, MUDA. После чего долгий рассказ про скрам: плаирование, спринты, ретро и т.д.

Попробуем разобраться, как эти три модели между собой соотносятся.
Keep Reading