Agile/scrum для начинающих. что такое гибкая методология?

Содержание

Мы постоянно открываем для себя более совершенные методы разработки программного обеспечения, занимаясь разработкой непосредственно и помогая в этом другим. Благодаря проделанной работе мы смогли осознать, что:

Концепция важнее новых требованийКачество важнее скоростиДелать как надо важнее, чем делать как просят

То есть, не отрицая важности того, что справа, мы всё-таки более ценим то, что слева. Наивысшим приоритетом для нас является плодотворная и продуктивная работа программиста, благодаря продуманному плану и следованию технологии разработки ПО

И, как результат всего этого, удовлетворение от результатов своей работы

Наивысшим приоритетом для нас является плодотворная и продуктивная работа программиста, благодаря продуманному плану и следованию технологии разработки ПО. И, как результат всего этого, удовлетворение от результатов своей работы.

Изменение требований возможно, но новые требования должны пройти те же стадии осмысления, которые прошли и все старые требования. Заказчик должен осознавать, что изменение требований может повлечь переработку продукта.

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

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

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

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

Качественный продукт — основной показатель успеха.

Никто не должен работать «на износ». Работать нужно спокойно, не следуя ничем не обоснованным «ритмам» и «циклам». Переработки недопустимы.

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

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

Полезно проводить доклады и семинары, чтобы повышать общий профессиональный уровень и степень вовлечённости в общий процесс.

Заблуждения о самоорганизующихся командах

На недавней конференции я вдоволь наслушалась разговоров трёх менеджеров о самоорганизующихся командах.
«Вы не можете просто так взять и дать волю людям, и предоставить команде всё решать самой. Они же всё испортят! Да, и к тому же, все эти Scrum-мастера, тренеры и самоорганизующиеся команды похоже могут оставить меня без работы», — говорил один из них с обречённостью в голосе.
«Ограничения по времени классная штука», — говорил другой. «Засуньте их всех в комнату, поддайте жару и они начнут творить», — утверждал он.
«О, так это означает, что я могу перетасовывать людей между проектами и они сами просто объединятся в команду и самоорганизуются. Я могу иметь подвижные Scrum команды по первому требованию!» — восклицал третий.
Время развеять некоторые заблуждения.

Лёгкое решение дорого обходится

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

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

Да, по моему опыту, примерно 5 из 10 команд после перехода на Agile уже в среднесрочной перспективе повышают производительность труда, удовлетворённость клиентов и качество разработки, а в долгосрочной — снижают общие затраты и улучшают другие KPI.

Но у тех команд, которые выбрали Agile сами (буквально каждый участник этого хотел), эти показатели улучшаются чаще: соотношение будет примерно 8 из 10 команд.

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

Главная фишка Agile в том, что это не готовая структура или некий свод правил, диктующий, что и как нужно делать. Нет, вся команда думает, что лучше для их проекта. Она может выбрать любую методологию (Scrum, Kanban, XP, Lean, SAfe…) или даже создать свою собственную. Это же касается и любых рабочих инструментов.

Не надо бояться неудач. Отныне это не повод для стыда и наказания и тем более не причина отменить Agile. Команда учится на своих ошибках и растёт. Пусть её участники свободно обсуждают и ставят под сомнение что угодно, пусть не боятся пробовать новое. Если их постигнет неудача, они извлекут уроки из своих ошибок — и в следующий раз добьются большего.

«Неудача — это возможность начать заново, на сей раз умнее».

ГЕНРИ ФОРД

Для чего внедрять гибкие методологии

Есть два подхода к разработке крупных проектов. Классический, или каскадный — это механика, в которой заранее готовится громадное техническое задание, учитываются все мелочи, предсказываются риски и затраты. И только потом начинается разработка. В digital такой метод работает неэффективно — когда команда разрабатывает большой проект, невозможно спрогнозировать все риски и проблемы.

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

Плюсы методологии:

• Нет нужды составлять длинное ТЗ — вместо этого формируется гибкий список задач на основе желаний клиента.
• Бюджет гибкий — если деньги закончились, заказчик все равно получит работающий проект, пусть и с меньшим количеством функций.
• Меньше бюрократии — нет нужды согласовывать сразу всю документацию по проекту, достаточно получить одобрение руководителя по одному вопросу. Разработка других задач в это время не прекращается.

Agile — это подход к разработке большого проекта. Философия, которая позволяет создавать продукт с постоянно меняющимися требованиями.

Практика применения Agile в подборе и развитии персонала

Выстроить рабочий процесс согласно приведенным выше принципам — долгосрочная задача. Как и любые изменения в мышлении и культуре, Agile требует времени и усилий со стороны всех участников процесса. Главное, не терять фокус и регулярно «сверяться с ориентирами» на этом пути. А результаты не заставят себя ждать.

О чем важно помнить при работе над HR-проектами:

Работа на клиента

В зависимости от контекста клиентами могут считаться руководство компании, сотрудники, внешние организации. Работа над HR-проектом начинается с формулирования задачи клиента, которую наш проект должен помочь решить. Для этого хорошо подходит такой инструмент Agile, как Job Story (пользовательские, клиентские истории).

Эксперименты вместо долгого планирования

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

Проверка гипотез и масштабирование положительного опыта

Как показывает опыт, истина не рождается в переговорных — только гипотезы. И часть из них, скорее всего, окажутся ошибочными

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

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

Однако и положительный опыт не означает, что можно «зацементировать» HR-продукт: со временем условия внешней среды будут меняться, и потребуются доработки

Поэтому важно сделать эксперимент естественной частью рабочего процесса

А также уделять внимание обучению сотрудников и руководителей. 

Прозрачная работа

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

Пусть у команд будут доски со столбцами «Бэклог», «Очередь», «В работе», «Готово» и стикеры с задачами, работа спринтами по 1-2 недели с обязательной ретроспективой в конце и короткими ежедневными стендапами. Это поможет увидеть реальный объем задач и скорость их выполнения, нагрузку на каждого сотрудника, слабые места процесса, которые тормозят реализацию проектов.

Помощь вместо руководства

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

Обратная связь и мотивация

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

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

Чтобы всегда иметь под рукой основные тезисы, скачайте плакат «Agile HR в двух словах», который мы перевели для вас.

Активное, системное использование обратной связи

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

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

Agile предлагает системное использование такого подхода везде: в создании продукта (мы выпускаем его на рынок, или показываем заказчику, или проводим испытания и используем обратную связь для его коррекции), в построении процессов (периодически мы «останавливаем» работу и подвергаем анализу сам процесс, чтобы улучшить его, избавиться от потерь и проблем), даже в построении структуры организации и «тонкой» настройки взаимоотношений в командах.

Примеры, опять-таки, есть везде: ретроспективные встречи в Scrum, Kanban, Nexus и LeSS, циклы I&A в SAFe, подход к созданию продуктов Design Thinking, циклы обратной связи в DevOps и т.д.

Методы и средства реализации

Наиболее популярными Agile-подходами считаются Scrum (скрам) и Kanban (канбан).

В Scrum над проектом работает команда профильных технических специалистов (например, аналитик, программист, тестировщик, администратор) вместе с владельцем продукта (product owner) и модератором (scrum-мастер). Product owner аккумулирует бизнес-требования, соединяет команду исполнителей с заказчиком и следит за развитием проекта. Scrum-мастер управляет процессом организации разработки по Agile-принципам: проводит общие собрания (meetings, митинги), мотивирует и поддерживает команду.

В Scrum рабочий процесс делится на равные периоды от 1 до 4-х недель (спринты), в зависимости от проекта и команды. Перед стартом каждого спринта на митинге формулируются его задачи, а в конце обсуждаются результаты. Краткосрочность и измеряемость спринтов позволяет эффективно управлять проектной деятельностью, не перегружая участников проекта авралами .

Спринты в Scrum

В отличие от Scrum, в команде канбан отсутствуют роли владельца продукта и модератора, а процесс разработки делится не на универсальные спринты, а на стадии выполнения задач («Планируется», «Разрабатывается», «Тестируется», «Завершено»). Жизненный цикл задачи отображается на канбан-доске, физической или электронной

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

Канбан, как и другие практики бережливого производства, пришедшие из Японии, направлен на достижение баланса и выравнивание нагрузки исполнителей. Эффективность работы оценивается по среднему времени жизни задачи, от начальной до конечной стадии. Если задача прошла весь путь быстро, то команда проекта работала продуктивно и слаженно. Иначе – необходимо решать проблему: искать, где и почему возникли задержки и чью работу надо оптимизировать 4.

Задачи на Канбан-доске

Сегодня наблюдается некоторое слияние Scrum и Kanban, например, канбан-доски стали практически обязательным элементом популярных систем управления проектами (Jira, Trello, Битрикс.24, Basecamp, Мегаплан и т.д.), которые, в том числе, поддерживают методологию скрам [5.

Манифест по-прежнему актуален?

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

Таннер Уортэм, тренер по agile и старший менеджер по техническим программам в LinkedIn, говорит, что он тоже часто цитирует Манифест. Уортам, который провел 10 лет в морской пехоте, сказал, что начал практиковать методологию agile еще до того, как узнал, что для нее есть название. Для себя он называл ее просто «ведущий морской пехотой». Однако Уортем считает, что присвоение имени чему-либо является большим первым шагом на пути к решению проблемы.

«Любому явлению нужно дать название, чтобы понять, что с ним делать. По-моему, именно эту задачу и выполнил Манифест — он дал методологии название, и все стали называть ее agile. Наверняка, она существовала и раньше, но когда для нее появилось название, всем стало легче ее идентифицировать».

Мистер Уэст, генеральный директор scrum.org, отмечает, что на самом деле принципы agile не новы. Просто они стали применяться по-другому.

Agile — это не конечное состояние, а образ мышления и жизни

Этот пункт о том, что применение Agile в целом — путь, а не цель. Нельзя «внедрить» Agile и расслабиться. Если вы выбираете этот путь, у вас всегда будет что-то ещё, что можно сделать лучше, какой-то ещё вызов, которому надо ответить, какая-то ещё проблема, которую надо решить, ещё одна высота, которую надо покорить… Это движение бесконечно, потому что нет идеального процесса или продукта, развитие и конкуренция не останавливаются никогда, как никогда не прекращается борьба за выживание в природе.

И если всё удалось: люди в компании понимают и разделяют ценности и принципы Agile и работают согласно им, — тогда менеджменту не придётся «тащить» на себе любые изменения или «пинать» работников, чтобы они начали что-то делать по-другому. Предприятие станет единым организмом, управление которым будет отнимать меньше сил и приносить больше удовольствия.
А там, где больше удовольствия от работы, и результат выше. Это касается не только специалистов, но и менеджмента, причём в ещё большей степени.

На этом наше обзорное знакомство с принципами Agile заканчивается. Какие цели ставятся перед Agile в России и каких реальных результатов достигают компании, переходящие на гибкие методологии, можно узнать, познакомившись с отчётом исследования ScrumTrek об использовании Agile в России от 2017 года.

«Красная» корпоративная культура – главная проблема российского бизнеса (Часть 2)

Мы поговорили о недостатках «красной» корпоративной культуры в первой части статьи. Но нужно понимать, что живучесть её объясняется тем, что такой тип культуры не только является самым большим, но и, одновременно, самым невидимым препятствием на пути развития российского бизнеса.

Система 5С Юрского периода

Хочу привести случай из своей практики. На одном из предприятий промышленной компании новое руководство с помпой объявило о внедрении Бережливого производства. Много говорилось о том, как этот новый подход выведет предприятие на новый уровень эффективности. И первым инструментом БП для внедрения была выбрана система 5С на пилотном участке производственного склада.
Начальник склада встретил нас с большим энтузиазмом и вместе с его командой мы приступили к первой стадии — сортировке, но под завалами старого хлама и ненужных деталей мы вдруг наткнулись на интересное археологическое открытие — старые выцветшие таблички с инструкциями и плакатами 5С и остатки специфической разметки краской на полу.
— Так это мы уже один раз внедряли 5С три года назад! – радостно пояснил начальник участка, увидев немой вопрос в моих глазах. – Просто со временем как-то всё забылось…
Я поинтересовался, а нужно ли внедрять этот инструмент, если он всё равно его не применяет.
«Ну как же не внедрять? Дело-то хорошее», — ответил он.

Размышления об Agile

Из песочницы

The measure of intelligence is
the ability to change.
Albert Einstein

Предисловие

Представляю ИТ-сообществу “Размышления о Agile” или можно назвать данную статью так, “Agile, это все же философия или проектная методология?”.
Цель данной статьи — обсудить с ИТ-сообществом вопрос о Agile, который у меня возник после многолетней проектной практики, выводы и резюме, к которому пришел, по результатам анализа этого вопроса.
Сам Вопрос привожу несколько ниже, так как, чтобы к нему перейти, имеет смысл изложить некоторые доводы и выводы.
Похожие темы уже поднимались на Хабре в различных ветках обсуждения, так что вопрос насущный и имеет свою историю.
На мой взгляд большинство статей не дает однозначного ответа на мой вопрос, поэтому настоящая статья, возможно, будет интересна многим.
Несколько статей на Хабре по теме:

• Agile: крупнейшая идеологическая проблема в IT.(19 апреля 2019 )
• Почему Agile не работает и что с этим делать. (20 декабря 2017)
• Кризис Agile. Что делать? (23 июня 2019)

Кому подойдёт Agile

В заключении следует ещё раз подчеркнуть: Agile – это методология, философия организации рабочего процесса. Она не решает задачи, зато даёт площадку для формирования важных для заказчика продуктов в максимально короткие сроки.

В первую очередь, Agile необходима в сферах, где происходит разработка новых продуктов. Чаще всего, это IT или производство, но список можно продолжать и дальше – результатом работы должен может стать любой процесс, если виден его конечный продукт. Ключевая особенность Agile – ценный результат – стирает ограничения в сферах использования методологии. Есть примеры, когда её не менее эффективно применяют в маркетинге или рекрутинге. Agile — это методология управления проектами.

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

Автор статьи: Александр Григорян, Директор по развитию агентства digital-трансформации «Улей».

There is no silver bullet, или как мы от водопада до Канбана через скрамовые аджайлы дошли

В данной статье я бы хотел поделиться опытом использования разных методик управления разработкой (Waterfall, Scrum, Kanban) в компании Acronis и рассказать, чем был обусловлен выбор той или иной методики или практики.
Для начала пара вводных слов. Цикл разработки продукта у нас в Acronis, как правило, длится от полугода до года. В разработке принимает участие команда из 40-45 человек. Сам продукт является системным приложением, а основная разработка идет на C++. Важный момент: продукт должен быть выпущен точно в срок не позднее фиксированного момента времени (да-да, и такое бывает).
Последнее детище нашей компании – ATI, в миру известный как Acronis True Image. Этот продукт довольно давно в разработке – настолько, что мы успели написать о нем на Хабр не одну, не две и даже не три статьи (четвертую найдите сами). Команда разработчиков ATI достаточно внушительная, а потому у нас накопился большой опыт управления подобными проектами.
Итак, когда-то очень давно у нас была классическая «водопадная» модель разработки:
Требования -> Дизайн -> Реализация -> Тестирование и стабилизация -> Поддержка.

IV Применение гибких методологий

5. Как не надо использовать Agile

1. Лидером в моем антирейтинге является ситуация, когда Agile, а вернее некоторые ее принципы, пытаются использовать не для достижения каких-то конкретных целей, которые они позволяют обеспечить, а просто #ПОТОМУШТО. Потому, что это тренд, это у всех на устах. Например, кто-то поделился на ИТ тусовке положительными отзывами, немного эфемерными и даже заносчивыми, но пошла молва, появился антураж. И вот уже назвавшиеся последователями Agile, ощущают в общении с остальными — принадлежность к некому элитарному клубу. Всему этому способствует кажущаяся простота методологии и туманные очертания ее границ. Внедрения по такому принципу происходит бездумно и формально. Люди, формально и беспринципно внедряют принципы, призванные снизить формализм.
   Вот например, один из совсем свежих случаев. В одной фирме проводя Ретроспективы, запретили их посещение тимлидами. Вот такая фишка. Неожиданно. Первая мысль: ну может быть они и правы, чтобы типа не было давления авторитетов на коллектив при обсуждении проблем и т.п. Но тимлиды обижаются, они в недоумении и хотят разобраться. Я попытался переубедить, что мол может так то оно и лучше, главное, чтобы Вам по итогу выдали список пожеланий, с перечнем, что надо менять, что улучшать и т.п. И вот тут-то и открылась страшная тайна. А ни каких итогов и пожеланий к улучшению процессов в результате этих посиделок не возникает. Господа ИТ_шники, а зачем же тогда такая ретроспектива? Просто похвалить друг друга и поднять командный дух? Сказали А, говорите и Б. Ведь основная цель этого процесса методологии и заключается в том, что: «Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы».
2. Вторая в моем рейтинге ситуация, когда команды решают сэкономить на подготовке требований в проектах со сложными поведенческими или логическими алгоритмами. То есть, когда пользовательская история является лишь небольшой вершиной айсберга проблемы, а его основная часть не видна и для реализации требует детального, тщательного анализа и проектирования. Что при этом происходит?
   Перед началом работ ни заказчик ни разработчики даже приблизительно не понимаю, тот объем работ, который им необходимо проделать. А соответственно: либо заказчик будет платить, платить и платить, каждый раз, когда ему будут растолковывать, что все оказалось горазда сложнее и теперь еще конца и края работам не видно. И ведь бросить будет жалко и постепенно начнет гложить суровое понимание, что этот «золотой» продукт уже никогда не окупится. Либо разработчики, подрядившись выполнить работы за определенную сумму/время, будут за свой счет (бесплатно) доделывать и переделывать продукт, пока у заказчика не иссякнет фантазия, или он не сжалится над жертвами гибкого подхода.
3. Почетное третье место занимает ситуация, когда в большом многофункциональном проекте (а вдруг еще и интеграционном) команда решает сэкономить на проработке архитектуры решения и начинает короткими итерациями реализовывать отдельные пользовательские истории. С большой долей вероятности случится так, что через 3-5 итераций, при попытке создать новый функционал, окажется, что надо переделывать весь предыдущий, так как не учли фундаментальные принципы, на которых этот функционал должен был базироваться. Еще хуже, если уже после 10_ой итерации обнаружится, что выбранные технологии не позволяют удовлетворить все потребности заказчика и надо начинать все сначала. Возможно, поменяв команду.
4. Не попала в тройку ситуация, в которой резкий и неимоверно гибкий стратап врывается на просторы вялого сегмента рынка. Стартап, он на то и стратап, что в нем нет ни каких устоев, скрепов, привязанностей, а вместе с тем устойчивости и стабильности. А проще говоря, нет почти никакой документации, коллектив не слажен и часто меняется. Рынок буквально рвет команду, требуя все новых и новых решений в застолбленной области, а все последующие проекты просто разваливаются на глазах. Чаще всего, все объясняется тем, что в команде нет понимания процессов промышленного производства ПО, организации поставки и поддержки продукта.

What is Agile Software Development?

Agile software development is more than frameworks such as Scrum, Extreme Programming or Feature-Driven Development (FDD).

Agile software development is more than practices such as pair programming, test-driven development, stand-ups, planning sessions and sprints.

Agile software development is an umbrella term for a set of frameworks and practices based on the values and principles expressed in the Manifesto for Agile Software Development and the 12 Principles behind it. When you approach software development in a particular manner, it’s generally good to live by these values and principles and use them to help figure out the right things to do given your particular context.

One thing that separates Agile from other approaches to software development is the focus on the people doing the work and how they work together. Solutions evolve through collaboration between self-organizing cross-functional teams utilizing the appropriate practices for their context.

There’s a big focus in the Agile software development community on collaboration and the self-organizing team.

That doesn’t mean that there aren’t managers. It means that teams have the ability to figure out how they’re going to approach things on their own.

It means that those teams are cross-functional. Those teams don’t have to have specific roles involved so much as that when you get the team together, you make sure that you have all the right skill sets on the team.

There still is a place for managers. Managers make sure team members have, or obtain, the right skill sets. Managers provide the environment that allows the team to be successful. Managers mostly step back and let their team figure out how they are going to deliver products, but they step in when the teams try but are unable to resolve issues.

Код, в котором мы живем

Перевод

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

• Если мы делаем какой-то физический объект или продукт, то почему ПО никогда не считается законченным?
• Если мы говорим об инженерных решениях, то почему мы никогда не можем уверенно планировать наперед?
• Если мы — архитекторы или строители, то почему так много проектов заканчиваются полным провалом?
• И наконец, при наличии множества советов, best practices, принципов, книг и докладов о разработке ПО, почему так много проектов превращаются в невыносимое место для работы?

Предлагаю близкий к тексту перевод блестящего доклада Сары Мэй «Livable code», где она рассматривает все эти вопросы.

Как мы решали проблему трех монолитов

В стратегиях большинства компаний все чаще упоминается цифровизация: одни компании пытаются внедрять современные технологии (например, Big Data, IoT, AI, blockchain), другие — повсеместно автоматизируют свои внутренние процессы. Несмотря на растущие усилия и инвестиции во внедрение систем, многие считают результаты посредственными. В идеале современным организациям надо уметь быстро создавать новые цифровые продукты или интегрироваться с популярными сторонними сервисами; выводить процессы за пределы своей организации; уметь эффективно взаимодействовать с партнерами, сохраняя при этом обособленность своих процессов. Также надо уметь не только собирать данные, но и быстро получать к ним доступ и управлять ими. Тем не менее даже «зрелые» компании сталкиваются со сложностью преобразования и управления данными, с постоянной конкуренцией бизнес-приоритетов. Что же мешает им достичь совершенства? 
Опыт нашей команды DTG в создании цифровых продуктов и сервисов позволяет утверждать — решению перечисленных задач мешает проблема трех монолитов: монолита приложений, интеграционного монолита и монолита данных. Они являются результатом унаследованных парадигм традиционной архитектуры, культуры полагаться на имеющиеся данные и работать в «слоеной» системе, где обособленность IT-департамента и бизнеса ведет к потере данных и знаний о них. Решением же данной проблемы мы видим переход от традиционных подходов разработки и управления к распределенным, что предполагает серьезные технические и культурные изменения в организации.
Но обо всем по порядку. Опишем кратко, что представляют из себя пресловутые монолиты, а затем перейдем к предлагаемым нами решениям для преодоления порождаемых монолитами сложностей.

Karma Driven Development (KDD)

Из песочницы

В качестве предисловия

Началось все в феврале 2014 года с приглашения посетить конференцию AgileDays2014. Вечером того же дня я засел на сайте конференции, чтобы выделить интересные мне темы и спланировать посещение докладов. Через 5-10 минут я уже смотрел запись выступления с AgileDays 2013 «Свобода и ответственность» Антона Волкова из Alternativa Platform.
Основная проблематика, освещенная в докладе, заключается в том, что многие сотрудники просто проводят время на работе, мало у кого есть чувство ответственности. Тем более нет командной ответственности, зато есть отговорки, много отговорок. Тут появляются проблемы с эффективностью, качеством, требуется постоянный контроль над сотрудниками. Всех все устраивает, нет желания меняться.
Для того, чтобы взрастить чувство ответственности нужно:

• Добровольное принятие ответственности. Например, когда человек сам называет срок выполнения задачи, он принимает ответственность. А если срок спускают сверху ни о каком принятии ответственности речи не идет, она на том, кто спустил срок;
• Свобода выбора — люди в праве решать какую работу брать, выбирать стратегию решения задачи, с кем работать (определяют состав команд);
• Последствия (положительные и отрицательные) от принятых решений, действий и бездействий. Например, сдал качественно выполненный функционал в срок, получил признание коллег и, возможно, дополнительное денежное вознаграждение. Или, допустил баг в продуктовой среде, получи нагоняй и порицание от коллег.