Как работать с неизвестностью и неопределенностью в разработке
Сталкиваясь с неопределенностью в процессе разработки, нам стоит пересмотреть взгляды на то, что для нас значит «двигаться быстро».
Создание новых продуктов связано с большим количеством неопределенности.
Нет понимания с чего начать, как начать, как подступиться. Знаешь только, что есть конкретная проблема, которую нужно как-то решать. Даже StackOverflow тебе тут уже не помощник.
Клепая простейшие CRUD приложения, проблеме планирования неоткуда взяться: общаемся с потенциальными пользователями, делаем несколько макетов будущего продукта, определяем требования, отправляем это всё команде дизайнеров и разработчиков. Готово – выпускаем.
Но когда мы разрабатываем продукты с большим количеством технических и бизнесовых неопределенностей — а это именно то, чем обычно занимаются стартапы и продуктовые команды — то такой план трещит по швам. Методология, призванная ускорить разработку, наоборот её замедляет, команда от этого стрессует и ловит фрустрацию, отставая от сроков всё больше и больше.
Это происходит, когда беспочвенный оптимизм разбивается о жестокую реальность неопределенности, свойственной процессу разработки продукта.
Неопределенности технических продуктов
Проблема классической системы планирования в том, что она не объясняет как работать с неизвестностью и неопределенностью, с тем, из чего состоит разработка сложных продуктов.
В RankScience, где мы делаем платформу для непрерывной оптимизации и CDN для SEO вебсайтов, мы сталкиваемся с довольно большим количеством технических неопределенностей – неудивительно, учитывая, что мы занимаемся тем, чего ещё никогда не было.
За последний год мы разработали систему планирования которая позволяет решать поставленные задачи, минуя проблемы классического подхода.
Основа нашей системы — это три техники, пришедшие из Agile/Scrum:
Анализ. Изучение проблемы и попытки найти способы её решить, учитывая их плюсы и минусы.
Спайк. Простая реализация на коленке, которая позже будет выброшена, но поможет понять область проблемы.
Трассер. Более предметная реализация не на выброс, для проверки, работает ли ваша идея в реальных условиях вообще или нет.
Мы идём по этим пунктам раз за разом, в зависимости от того, на каком уровне неопределенности мы находимся с текущей проблемой.
Эта методология помогает нам решать задачи, пока классическая система требует собственного обслуживания:
Мы можем продвигаться быстро, но не так быстро, чтобы закапывать себя в технических долгах.
Мы можем вносить коррективы на ходу, не привязываясь к дате начала следующего спринта.
Мы можем изучать вопрос итеративно, нежели надеяться, что команда знает все аспекты проблемы наперед.
Когда всё совсем непонятно – мы не знаем как приступить к задаче, – мы проводим анализ. Когда в результате приходит в голову возможное решение – мы делаем спайк, чтобы понять предметную область. Далее мы выпускаем трассер, чтобы убедиться, что текущее решение может слаженно работать с нашей текущей архитектурой. Если всё ок, двигаемся дальше. Если нет, то можем вернуться к самому началу.
На каждом шаге система дает новую информацию для следующего шага и для выхода из неопределенности в целом. Эта постоянная обратная связь, вероятно, самая важная деталь всего подхода.
Мы, конечно, можем составить план и попробовать его выполнить от начала до конца, но шаг влево, шаг вправо и он начнёт трещать по швам.
Идея нашей системы в признании, что системы рано или поздно дают сбой, нужно принимать план Б или даже план В. Просто нужно быть к этому готовыми.
1. Анализ
Начинайте с проведения анализа если:
У вас есть проблема
Вы не знаете как её решить
Не важно, пытаетесь ли вы перестроить всю архитектуру или просто добавляете новую кнопочку на свой сайт.
Без понимания как решить проблему не торопитесь писать код. Наоборот, вам нужно заняться анализом, продумать возможные пути решения, а после прикинуть все плюсы и минусы каждого из них.
Плюсы и минусы должны быть основаны на технических факторах типа:
Насколько трудоёмкая будет реализация
Насколько дорого это выйдет
Сколько времени потребуется
Какой гибкости мы лишаемся, принимая именно это решение
Насколько этим удобно будет пользоваться
Под разные команды значимость тех или иных факторов может быть разная.
В RankScience мы, на данный момент, оцениваем пути решений на основе трёх главных факторов:
Наша операционная нагрузка
Наш автобусный фактор
Скорость нашей команды
Мы анализируем каждый из путей, оценивая то, как мы можем уменьшить нашу операционную нагрузку, уменьшить автобусный фактор и улучшить скорость нашей команды.
Одним из распространенных результатов анализа — это документация типа такой:
Repository: плюсы и минусы
Это эффективный способ предоставлять доступ большому объему данных: записал один раз и читаешь отовсюду
Подсистемам не нужно думать как создаются и потребляются данные в других подсистемах
Это позволяет проще делать бэкапы, а ещё работать над безопасностью и восстановлением данных
Работа с данными происходит по общей схеме, поэтому легче подключать новые подсистемы
Подсистемы должны работать с общей схемой, что может влиять на производительность
Эволюция данных: «дорого» принимать новую модель данных, потому что (а) это нужно принять во всём репозитории и (б) все подсистемы должны быть обновлены, чтобы продолжать работать
Нет уверенности, что в вопросах безопасности и бэкапов репозиторий всегда будет удовлетворять некоторые подсистемы
Довольно сложно деплоить репозиторий на несколько машин, сохраняя видимость централизованного хранилища, из-за необходимости в избыточности данных и сохранении консистентности
Анализ, как целенаправленная деятельность, должен быть ограничен по времени (чтобы вы не тратить бесконечное количество времени, выбирая разные варианты) и предоставлять либо один конкретный из возможных путей решения, либо понимание, что не имеет большого смысла в это погружаться самостоятельно и лучше перепоручить это специалистам извне.
2. Spike
У вас есть проблема
У вас есть хоть какая-то идея как её решить
Спайк — это решение на коленочке на выброс. Иногда это может показаться пустой тратой времени, но хороший спайк может выявить детали, которые могут остаться незамеченными, бросайся мы прямиком к серьезному проектированию.
Хотя результат спайка и будет выброшен по завершению, но используя его правильно, мы можем глубже погружаться в суть самой проблемы.
Спайк сам по себе не поможет решить задачу быстрее, но даст понимание того, как с продуктом взаимодействуют люди в настоящих условиях, от чего мы сами сможем продвигаться к решению быстрее.
Хороший пример — это бумажный прототип.
Собирание бумажного макета может показаться бессмысленным, особенно сейчас, когда его можно по быстрому накидать в Sketch и экспортировать в любой удобный формат, но обыкновенным людям, тестировщикам продукта, может быть удобнее взаимодействовать с бумагой. Включаются тактильные взаимодействия с продуктом, а давать обратную связь становится ещё проще.
Минимальным вкладом в решение при обычном планировании является то, как мы начинаем фактически решать проблему. При спайках же минимальный вклад — это нечто, что помогает выяснить в чем на самом деле состоит проблема.
3. Трассер
У вас есть проблема
У вас есть решение, но вы не знаете как много времени это займет.
Впервые трассер как техника встречается в The Pragmatic Programmer by Andrew Hunt and David Thomas. В самом простом смысле трассер является решением проблемы, которое:
запускается в продакшен окружении
остается, а не выбрасывается
Представьте, что вам нужно сделать подписку на емейл рассылку с вашего сайта. В этом случае спайк может быть бумажным прототипом. Трассером может быть поле ввода на сайте и кнопка, которая:
успешно получает текст из поля ввода
отправляет этот текст в Segment
идёт в customer.io из Segment
обновляет список для рассылки
Может не быть валидации почты, да и любого количества улучшений, после которых мы будем считать дело сделанным, но если эта последовательность действий работает (в том числе в продакшен окружении), то она будет работать и после внесения финальных штрихов.
Трассер — это не конечный продукт, а нечто, что более приближено к готовому, нежели спайк, который почти всегда должен идти на выброс, когда мы получили всю необходимую информацию.
Трассер здесь для того, чтобы доказать, что решение действительно работает, захватив предметную область настолько широко, чтобы взглянуть на картину в общем, но не достаточно широко, чтобы тратить на это слишком много времени.
Цикл Анализ — Спайк — Трассер
Сталкиваясь с неопределенностью в процессе разработки, нам стоит пересмотреть взгляды на то, что для нас значит «двигаться быстро»
Быстрое движение не сводится к тому, чтобы как можно быстрее составить законченный план, потому что никто не знает реалистичен ли такой законченный план в принципе.
Работая над проектами с большим количеством неопределенности или технических рисков, нам следует анализировать, делать спайки и трассеры, чтобы шаг за шагом, итеративно рассеивать неизвестность — следовать лучикам света в темном лесу.
Остров, о котором забыл Scrum
На оригинал данной статьи я наткнулся случайно, разгребая почту и наткнувшись на новостную рассылку от ScrumAlliance. Тема метрик Scrum команд и непосредственно кода, меня интересует уже давно. Особенно любопытно, что с этими метриками делать дальше, и первостепенно — зачем они вообще нужны?
В данной работе автор поднимает важнейшую тему для молодых Scrum команд — почему со временем теряется продуктивность и как сохранить ее в долгосрочной перспективе?
Cкучные предисловия я припас для своего уютного блога, а тебе хаброчитатель предлагаю ознакомиться с самой сутью.
Чтобы расширить свой кругозор, а также получить ответ на свои внутренние вопросы, добро пожаловать под кат…
The Land that Scrum Forgot
Что не так со многими Scrum проектами? Почему сначала производительность команды подскакивает, а потом начинает падать? Почему некоторые Scrum команды периодически отказываются от Scrum? Что происходит?
Как один из тех, кого позвали чтобы спасти Scrum команды от подобного отречения, я говорю вам, что проблема не в том, что команды теряют мотивацию. Часто проблема в том, что программное обеспечение, которое команды разрабатывают становится сложнее и с ним становится сложнее работать.
Scrum дает вам быстрый старт! Это отлично. Часто первые спринты сталкиваются с первыми особенностями Scrum’а. Менеджеры и заказчики счастливы. Команда работает блестяще, и она тоже счастлива. Все счастливы и видят в Scrum огромный успех.
Это повторяется в следующей и в следующем за ним спринте. Производительность высока. Система постепенно строится, а весь функционал уже работает. Ожидания созданы. Планы построены. Энтузиазм парит над Scrum. Достигнута гиперпродуктивность!
Одна из причин гиперпродуктивности это маленький размер кодовой базы. Малой кодовой базой проще управлять. Исправления легко вносить; новые функции легко добавлять.
Но код растет быстро; и когда кодовая база становится больше, ее становится тяжело поддерживать. Программисты значительно замедляются из-за ухудшения кода. Команды «сдуваются» до невозможного из-за огромного груза плохо написанной системы. Если об этом не позаботились заранее, гиперпродуктивная Scrum команда впадает в болезнь, которая убивает множество софтверных проектов. Они породили беспорядок (Прим. пер.: mess).
«Подождите!» — слышу как говорите вы. «Я думал что Scrum нужен чтобы усилить команду! Я полагал, что команда сделает все возможное, чтобы удостовериться в качестве. Я думал, что укрепленная Scrum команда не создаст бардак!»
Да, вы правы. Проблема в том, что даже укрепленная команда состоит по-прежнему из людей, и они работают за то, что им дают. Они будут награждены за качество? Или их наградят за продуктивность? Как много значимого команда получит за хорошее качество кода? Как многое они получают за поставку рабочего функционала?
Здесь нет ответа. Причина в том, что scrum команда создает беспорядок, потому что она укреплена и стимулирована его создавать. И Scrum команда может создавать его быстро, очень-очень быстро! Scrum команда гиперпродуктивна по части создания бардака. Пока вы не знаете об этом, беспорядок будет становиться «таким большим и таким глубоким, таким высоким, что вы не сможете его устранить. Выхода нет».
И когда это наступает, продуктивность падает. Мораль падает. Заказчики и менеджеры становятся злыми. Жизнь плоха.
Так как же стимулировать Scrum команду, чтобы она не делала беспорядка? Можем ли мы просто попросить не создавать его? Мы пробовали. Это не работает. Стимуляция работать быстрее основана на осязаемости результата. Но наградить команду за хороший код, если вы не знаете способа объективно оценить его, невозможно. Без однозначного способа измерить беспорядок, его нельзя прекратить создавать.
Нам нужно двигаться быстро и оставаться чистыми, при этом сохраняя скорость. Как стимулировать команду достигнуть две цели? Просто. Мы измеряем и то и другое и награждаем одинаково. Если команда двигается быстро, но работает грязно, она не получит вознаграждения. Если команда остается чистой, но двигается медленно, никакого вознаграждения. Если команда двигается быстро и сохраняет чистоту, то она поощряется!
Мы можем измерить беспорядок, внедряя инженерные дисциплины и практики, как например разработка через тесты (TDD), непрерывная интеграция (Continuous Integration), парное программирование, коллективное владение кодом и рефакторинг; т.е. инженерные практики экстремального программирования (XP).
Обычно лучше всего начать с TDD просто потому, что любая кодовая база без тестов беспорядочна, как бы чиста она не была. Это резкое заявление, но оно строго рациональное, появившееся из более старой дисциплины: бухгалтерии. Точно также как бухгалтер может ошибиться в расчетах, так и программист может допустить ошибку в программе. Так как же бухгалтеры предотвращают ошибку? Они делают все дважды.
Бухгалтеры используют двойную запись, которая является частью Международных стандартов бухгалтерской отчетности. Бухгалтеры, которые не придерживаются МСБО быстро меняют профессию или остаются на обочине. Двойная запись это простая практика повторения одной операции дважды — один раз на стороне дебета, другой на стороне кредита. Два этих значения следуют различным математическим операциям, однако в итоге их разность должна стать равна нулю. Любая отчетность, выполненная без двойной записи будет признана бухгалтерами мусором, вне зависимости от того насколько тщательно и аккуратно эта отчетность была выполнена.
TDD это аналог двойной записи только для программного обеспечения, и должна стать частью МСПГ (Международных стандартов практик программирования). Символы, которыми оперируют бухгалтера не менее важны для компаний, чем символы, которыми манипулируют программисты. Могут ли программисты тогда делать меньше работы, чем бухгалтера, чтобы обезопасить свой код?
Программисты, практикующие TDD создают большое количество автоматически тестов, которые поддерживают друг друга и являются регрессионным набором. Это то, что вы можете измерить! Измеряйте покрытие. Измеряйте число тестов. Измеряйте количество новых тестов в спринте. Измеряйте количество дефектов, о которых сообщается в каждом спринте и используйте это чтобы определить адекватность покрытия кода тестами (Прим. пер.: the test coverage).
Задача в том, чтобы повысить уверенность в наборе тестов до такого состояния, чтобы вы могли доставлять продукт (Прим. пер.: deploy the product) сразу, как набор тестов прошел. Поэтому измеряйте количество «других» тестов, которые как вы считаете необходимо проводить, и сделайте сокращение их количества приоритетным; особенно если это ручные тесты!
Набор тестов придает огромную силу. С ними вы можете осуществлять рефакторинги без страха. Вы можете вносить изменения в код без опасения сломать его. Если кто-то видит что что-либо неочевидно или выглядит грязно, он может исправить это без опасения неожиданных последствий.
Недокументированные системы, или системы, где документация не актуализирована в соответствии с продуктовым кодом (Прим. пер.: production code) беспорядочны. Модульные тесты, получаемые в ходе TDD являются документами, описывающими низкоуровневую архитектуру системы. Каждый программист, которому требуется знать как так или иная часть системы работает, может полагаться на чтение тестов, как на однозначное точное описание. Эти документы никогда не потеряют актуальность, до тех пор пока они отрабатывают.
Измеряйте размер тестов. Тестовые методы должны быть от пять до двадцати строк кода. Общее количество тестового кода должно быть примерно равно количеству продуктового кода.
Измеряйте скорость тестов. Тесты должны отрабатывать быстро; минуты, а не часы. Поощряйте за быстрые тесты.
Измеряйте хрупкость тестов (Прим. пер.: test breakage). Тесты должны быть разработаны таким образом, чтобы изменения в продуктовом коде приводили к небольшим поломкам тестов. Если большая часть тестов падает, когда изменяется продуктовый код, то тесты требуют рефакторинга (Прим. пер. test design needs improving).
Измеряйте Цикломатическую сложность. Функции, которые очень сложны (например, cc > 6 или близко к этому) должны быть подвергнуты рефакторингу. Используйте средства наподобие Crap4J, чтобы определить методы и функции, нарушающие это правило и имеющие наименьшее покрытие тестами.
Измеряйте размер функций и классов. Средняя функция должна иметь менее 10 строк кода. Функции длиннее 20 строк надо разбивать. Классы более 500 строк следует разбивать на два и более классов. Измеряйте корреляцию Брейтвэйта, она должна иметь значение более 2.
Измеряйте метрики зависимостей. Убедитесь, что нет циклических зависимостей. Убеждайтесь, что поток зависимостей идет в направлении абстрагирования, в соответствии с принципом обращения зависимостей и принципом стабильных абстракций (Прим. Принцип стабильных абстракций: пакеты, которые максимально неизменчивы, должны быть максимально абстрактными. Изменчивые пакеты должны быть конкретными. Абстрагированность пакета должна быть пропорциональна его изменчивости.).
Используйте средства статического анализа как FindBugs или Checksty, чтобы определить очевидные слабые места. Эти средства позволяют также находить и измерять количество дублируемого кода.
Внедрите непрерывную интеграцию. Настройте билд-сервер наподобие Hudson, Team City или Bamboo. Пусть сервер собирает систему каждый раз, когда разработчик добавляет код (Прим. пер.: commits some code). Прогоняйте все тесты на этой сборке и устраняйте неисправности непременно.
Подсчитывайте количество комитов в день. Это число должно быть больше, чем число разработчиков в команде. Поощряйте частые комиты.
Подсчитывайте число дней в которые сборки упали в этом месяце. Поощряйте за месяцы без падений. Измеряйте время, пока неисправности остаются неустраненными.
Истории тестирования (Прим. пер.:Story tests) это высокоуровневые документы, разрабатываемые бизнес-аналитиками и тестировщиками. Они описывают поведение системы с точки зрения заказчика. Эти тесты, написанные с помощью средств наподобие FitNesse или Cucumber, это требования которые надо соблюдать. Когда эти тесты прошли, команда знает что она закончила истории, которые этими тестами описаны.
Измеряйте «завершенность», запуская тесты на системе непрерывной интеграции и следите за историями тестирования, которые прошли или упали. Используйте это как основу показателя производительности и прогресса команды. Внедрите правило, что user story не считается законченной, пока соответствующая история тестирования не пройдет тест, и никогда не позволяйте ломаться тестам, которые уже прошли.
Практикуйте парное программирование. Измеряйте время, потраченное в парах и время программирования в одиночку. Команды, работающие парами работают чище. Они создают меньше беспорядка. Они дополняют друг друга, т.к. знают предметные области друг друга. Они обсуждают между собой реализацию и архитектуру. Они учатся друг у друга.
А как после всех этих измерений поощрять команду? Опубликуйте огромные плакаты на стене с метриками в столовой, в кулуарах или проектной комнате. Показывайте графики заказчикам и исполнителям и кричите о сосредоточенности вашей команды на качестве и продуктивности. Организуйте вечеринки по поводу достижения milestone’ов. Выдавайте небольшие поощрения или вознаграждения. К примеру, один менеджер, которого я знал, раздавал футболки каждому в команде, когда команда прошла отметку в 1000 модульных тестов в проекте. На футболках было имя проекта и слова «1000 модульных тестов».
Как охранять Scrum команду от снижения продуктивности? Как быть уверенным в том, что гиперпродуктивность не завязнет в трясине? Убеждайтесь в том, что гиперпродуктивная команда не создает беспорядка! Убеждайтесь в том, что они используют практики, которые порождают измеримый результат. Используйте этот результат, чтобы измерять качество кода, который команда создает; и стимулируйте поддержание этого кода чистым.
Русские Блоги
Практика проектирования архитектуры Spike
Содержание этой статьи
— Трудности в спайк-бизнесе
— Теория архитектуры спайка
— Бизнес-дизайн и резюме
Отрывок: Жизненный цикл. У всего, что вы делаете в карьере, семье и даже, есть жизненный цикл. Вместо того, чтобы думать о том, когда закончить, лучше быть приземленным, думать о будущем и жить настоящим.
Из «Записи мыслей младшего брата-масона»
Каменщик сказал себе: «Убей эту штуку за секунды, и статью нельзя будет закончить». Я начал эту статью, а серия тренировок еще впереди, так что следите за обновлениями.
2. Трудности в спайковом бизнесе
Трудности в спайковом бизнесе, резюмированные в двух пунктах
-Подробнее
— писать меньше одновременно
Это отличается от некоторых сценариев.Система преференциального маркетинга может считывать несколько данных только одним пользователем, но она также будет считывать операции с большим трафиком. Но операции записи нет.
Одновременное чтение, несколько пользователей одновременно читают одни данные. Например, есть только один инвентарь мобильных телефонов Huawei, и активность резко возрастает. Десятки миллионов людей могут собрать эти данные инвентаризации. Это не включает много мясорубок в дикой природе. Многие пользователи читают продукт + данные инвентаризации этого продукта.
Пишите меньше одновременно, и меньше пользователей одновременно пишут одни данные. Например, как ограничить текущий поток, потому что для работы уровня данных существует всего несколько запросов на запись? Взять его может только один человек Как решить проблему перепроданности?
Например, 12306 захватывает билеты, красные конверты и мгновенный трафик. Тогда такую систему сложнее разработать.
Три, теория шиповой архитектуры
Подумайте о некоторых законах архитектуры: закон Мерфи, закон Конвея и т. Д. Любая практика проектирования должна исходить из определенных теорий и законов.
Некоторые архитектурные теории спайка (я думаю):
— Принцип высокого параллелизма
— Принцип высокой доступности
— Единый дизайн
а, принцип высокого параллелизма
1. Обслуживание
Как говорится в старой поговорке о сервис-ориентированности, существует также целый набор сервисно-ориентированных решений, таких как Spring Cloud и Dubbo с открытым исходным кодом Ali. Учитывайте изоляцию службы, ограничение тока, тайм-аут, повторную попытку, компенсацию и т. Д.
2. Кэш
Рассматривайте слой за слоем. Есть три общих момента: пользовательский уровень, уровень приложения, уровень данных и т. Д.
Пользовательский уровень: кеш DNS, кеш приложения (изображения и т. Д.)
Уровень приложения: статические страницы, MQ, Redis и т. д.
Уровень данных: NoSQL, MySQL поставляется с кешем запросов
3. Разделить
Если вы надолго разделяете, вы должны объединиться, а если вы вместе, вы должны разделиться. Различные сплиты:
4. Параллелизм
От последовательного к параллельному. Конкретная практика, анализ и оптимизация конкретных сценариев.
б. Принцип высокой доступности
1. Перейти на более раннюю версию
Используется для изоляции зависимостей сервисов и деградации отката для предотвращения лавинообразных эффектов. Специфический выбор: гистрикс и др.
Кроме того, его можно настроить для переключения на более раннюю версию службы. Основные функции гарантированы, а второстепенные функции оптимизированы как асинхронные или экранированные. Например: в Double Eleven некоторые функции оценки будут отключены.
2. Текущий предел
Предотвращение атак запросов или превышение системных пиков. Для получения дополнительной информации вы можете обратиться к некоторым текущим алгоритмам ограничения скорости Guava’s RateLimiter. Также напишите конкретные методы: доступ вредоносного трафика к Cache и т. Д.
3. Можно откатить
Если выпуск версии завершился неудачно или возникла проблема с кабелем, предыдущая стабильная версия будет возвращена в кратчайшие сроки. Мышление: у общей группы эксплуатации и обслуживания будет полный набор серых механизмов выпуска и отката.
В-четвертых, бизнес-дизайн и резюме
Следующие моменты (важные) также необходимо учитывать, когда речь идет о спайк-бизнесе:
Эта идея организована и запущена. То есть примерно несколько направлений: