Для программиста, который уже работает с агентами, это готовая замена самодельным файлам с инструкциями и длинным описаниям задачи в чате. Вместо «сделай мне функцию экспорта» агент получает конституцию проекта, спеку с пользовательскими историями, технический план и список задач в репозитории, и каждый шаг можно прочитать и поправить до того, как появится код. За год к базовой цепочке добавились команда сверки кода со спекой, расширения для багфикса и оценки идей, пресеты под стандарты команды и бандлы под роли. Spec Kit при этом не единственный репозиторий такого рода в топе GitHub: за ту же неделю звёзды собирали ещё десять проектов про агентов, от скиллов и надстроек над Claude Code и Codex до локального инференса и управления Blender; они разобраны во второй части.

• Spec Kit 1.0.0 вышел 21 августа 2026 года, текущий релиз 1.0.6 от 10 сентября; между ними шесть патч-релизов.
• Ставится через uv или с PyPI, командой specify init подключается к проекту под любой из более чем 30 агентов.
• Цепочка из шести слэш-команд: constitution, specify, plan, tasks, implement, converge; последняя сверяет код со спекой и дописывает недостающие задачи.
• Расширение bug ведёт исправление по шагам «оценить, починить, проверить», assess разбирает идею до решения «делать» или «не делать».
• Мейнтейнер пишет, что 1.0 больше не обещает стабильности API: ломающие изменения агент теперь переносит сам.
• Среди набравших звёзды за неделю: ponytail (135 тысяч, режет объём кода агента на 54% в замере автора), ECC (256 тысяч), skills (259 тысяч), humanizer (46 тысяч), archify (57 тысяч), HyperFrames, MiniMind, Magnitude, SGLang и blender-mcp.

Что такое Spec Kit и как он работает?

Spec Kit это утилита specify на Python плюс набор markdown-шаблонов и скриптов, которые она раскладывает в проект. После specify init в каталоге агента (например, .claude/ или .github/) появляются слэш-команды или скиллы с префиксом speckit, а в .specify/ лежат шаблоны документов. Дальше вся работа идёт внутри привычного агента.

Базовая цепочка описана в README репозитория и состоит из шести шагов. /speckit.constitution один раз на проект фиксирует принципы: стек, стиль, что запрещено. /speckit.specify превращает описание задачи в спеку с требованиями и пользовательскими историями, /speckit.plan пишет технический план под выбранный стек, /speckit.tasks режет план на задачи, /speckit.implement их выполняет. Замыкает цикл /speckit.converge: команда сравнивает кодовую базу со спекой, планом и задачами и дописывает в список то, что ещё не сделано. Шаги implement и converge повторяются, пока converge не сообщит, что всё сошлось.

Есть три необязательные команды. /speckit.clarify вытаскивает недосказанное из спеки вопросами, её рекомендуют запускать до плана. /speckit.analyze ищет расхождения между спекой, планом и задачами после tasks и до implement. /speckit.checklist генерирует чек-листы качества требований, в документации их называют «юнит-тестами для английского языка». Команда /speckit.taskstoissues, которая раскладывает задачи в GitHub Issues, в релизе 1.0.5 помечена как уходящая из ядра в отдельное расширение github-issues; пока она работает.

Что изменилось к версии 1.0?

Год назад Spec Kit был набором шаблонов под несколько команд и несколько агентов. К 1.0 вокруг ядра выросла система настройки из четырёх слоёв. Внизу ядро с встроенными командами и шаблонами, выше расширения, которые добавляют новые команды, ещё выше пресеты, которые переписывают шаблоны ядра и расширений, а на самом верху локальные правки конкретного проекта в .specify/templates/overrides/. Шаблоны разрешаются во время выполнения сверху вниз, побеждает первое совпадение.

Два расширения идут в комплекте и включаются по желанию. specify extension add bug добавляет цепочку из трёх команд для исправления ошибок: assess проверяет диагноз по отчёту, fix чинит именно найденную причину, test подтверждает, что исходный симптом исчез. Авторы объясняют это тем, что агент, который прыгает от баг-репорта сразу к патчу, часто чинит не то. Расширение assess работает ещё до спеки: intake, research, define, shape, decide, на выходе документированное решение «делать», «нужны уточнения» или «не делать». Идею с решением «делать» можно передать в /speckit.specify.

Пресеты ставятся командой specify preset add и меняют форму, а не набор возможностей: например, требуют в спеке трассируемость под регуляторику, добавляют обязательный этап проверки безопасности в план, переставляют задачи так, чтобы тесты шли первыми, или переводят весь процесс на другой язык. Бандлы собирают расширения, пресеты, шаги и рабочие процессы в один версионированный набор под роль: продакт-менеджер, аналитик, исследователь безопасности, разработчик. Ставится бандл одной командой specify bundle install, каталог бандлов у проекта свой, поверх пользовательского и встроенного. В релиз-нотах 1.0.x рядом с исправлениями регулярно идут обновления расширений сообщества, например Jira Mirror в 1.0.2, и правки в загрузчике бандлов.

Список агентов вырос до более чем 30. Для части из них, включая Claude Code, Codex CLI, Copilot и Devin, команды ставятся как скиллы, а не как файлы промптов, и вызываются как /speckit-specify или $speckit-specify, в зависимости от агента. Для остальных остаётся режим слэш-команд; переключатель --integration-options="--skills" есть у тех, кто поддерживает оба.

Почему 1.0 больше ничего не обещает?

Ведущий мейнтейнер проекта в записи к годовщине прямо говорит, что единица в номере версии здесь только число. Раньше мажорная версия была страховкой от стоимости изменений: ломающее изменение означало ручной обход всех мест вызова по гайду миграции, и семантическое версионирование превращало эту стоимость в сигнал. Теперь, по его словам, адаптация к ломающему изменению это одно предложение агенту, который правит места вызова быстрее, чем автор успевает описать их в changelog. Поэтому 1.0.0 у Spec Kit значит «хорошее место, чтобы начать», а не обещание замороженной формы. Это заявление проекта о себе, и для команд, которые встраивают Spec Kit в CI и внутренние инструменты, оно означает, что пинить версию всё равно придётся: за три недели после 1.0.0 вышло шесть патч-релизов.

Как установить и с чего начать?

В README рекомендуют менеджер uv, альтернатива pipx. Установка идёт с привязкой к тегу релиза, тег с ведущей буквой v, либо из PyPI, где пакет specify-cli обновлён до 1.0.6. Проверить, не вышла ли новая версия, можно командой specify self check.

Ключ --integration принимает имя агента из списка интеграций, например copilot, claude, codex, cursor-agent или gemini; полный перечень выдаёт specify integration list. Дальше запускается сам агент в каталоге проекта, и цепочка начинается с /speckit.constitution.

Кому это не нужно?

Spec Kit не единственный инструмент такого рода. Kiro от AWS делает то же самое внутри собственной IDE на базе VS Code, у Tessl это CLI и MCP-сервер к разным ассистентам, а сам фреймворк на момент разбора был в закрытой бете; в разборе трёх подходов на сайте Мартина Фаулера Spec Kit выделяют как самый агентонезависимый: это markdown и скрипты в репозитории, которые легко править. Обратная сторона та же: спека, план и задачи это документы, которые кто-то должен читать, и для правки в одну функцию цепочка из шести команд избыточна. Авторы и сами пишут в README, что не каждое изменение проходит полный цикл: небольшие исправления идут обычным путём через issue, pull request, ревью и тесты.

Какие ещё репозитории про ИИ-агентов набирали звёзды на этой неделе?

Подборку из десяти репозиториев, которые «за неделю разом собрали звёзды», опубликовал 10 сентября японский аккаунт So AInsight; прирост за неделю там не приведён, поэтому ниже суммарное число звёзд на 11 сентября по данным GitHub. Половина списка про то же, что и Spec Kit: как заставить агента работать по процессу, а не по настроению; остальное про инференс, обучение и управление другими программами.

1. skills, 259 тысяч звёзд. Скиллы Мэтта Покока, автора Total TypeScript, из его рабочего каталога .agents: небольшие, составные, под любую модель. В README автор прямо противопоставляет их Spec Kit, GSD и BMAD: те, по его словам, забирают процесс себе и делают ошибки в нём трудноразрешимыми.
2. ECC, 256 тысяч. Надстройка над Claude Code, Codex, OpenCode и Cursor с циклом «план, тест, реализация, ревью из свежего контекста, проверка, память, улучшение». Репозиторий под MIT, у автора есть платная версия ECC Pro как GitHub App для приватных репозиториев от $19 за место в месяц.
3. ponytail, 135 тысяч. Скилл, который заставляет агента думать «как самый ленивый сеньор»: перед кодом пройти лестницу из семи вопросов, от «нужно ли это вообще» до «есть ли это в стандартной библиотеке». Автор замерил на Claude Code и репозитории full-stack-fastapi-template по 12 тикетам: минус 54% строк, минус 22% токенов, минус 20% стоимости против агента без скилла; ранние цифры «на 80–94% меньше кода» он сам признал завышенными из-за некорректной базы.
4. archify, 57 тысяч. Скилл для Cursor, Claude Code, Codex CLI и OpenCode: агент описывает систему типизированным JSON, Node.js-компилятор превращает его в самодостаточный HTML с интерактивной схемой архитектуры, последовательности или потока данных, экспорт в PNG, SVG и WebM. Умеет сравнивать два снимка архитектуры до и после изменения.
5. humanizer, 46 тысяч. Скилл на чистом markdown, который переписывает текст агента так, чтобы в нём не было характерных следов машинного письма, без изменения смысла; ставится через npx skills add blader/humanizer или как плагин Claude Code.
6. HyperFrames, 49 тысяч. Проект HeyGen: пишешь HTML, получаешь видео. Рассчитан на агентов, которым нужно генерировать ролики с диаграммами и озвучкой без съёмки; TypeScript, Apache 2.0, Node 22 и новее.
7. MiniMind, 61 тысяча. Учебный проект: обучить языковую модель на 64 млн параметров с нуля на чистом PyTorch. Заявленные «2 часа» и «3 юаня» это оценка автора для одного прохода предобучения и дообучения минимальной версии на одной RTX 3090 и аренда GPU на это время; в репозитории полная цепочка от предобучения до DPO, GRPO и агентного RL, плюс версии с картинками и диффузией.
8. Magnitude, 4 тысячи. Локальный движок инференса: профилирует машину (Mac, NVIDIA, AMD или только CPU), подбирает подходящие модели, скачивает, настраивает и запускает их. Единственный проект списка с числом звёзд в тысячах, а не десятках тысяч.
9. SGLang, 36 тысяч. Зрелый фреймворк раздачи больших языковых и мультимодальных моделей под нагрузкой, существует с января 2024 года; в список попал, судя по всему, из-за очередного всплеска интереса, а не как новинка.
10. blender-mcp, 28 тысяч. MCP-сервер и аддон, через которые любая модель управляет Blender: создание сцен, моделирование и расстановка объектов по текстовому запросу. Сторонний проект, к Blender Foundation отношения не имеет, о чём README предупреждает отдельно.

Общий знаменатель списка тот же, что у Spec Kit 1.0: скиллы и надстройки, которые фиксируют процесс работы агента в репозитории, стали отдельной категорией инструментов, и у неё уже есть внутренняя полемика. Spec Kit и ECC предлагают полный цикл, skills и ponytail дают отдельные небольшие правила, которые сочетаются с чем угодно. Что выбирать, зависит от размера задачи: для мелких правок цепочка из шести команд избыточна, для новой функции с несколькими файлами спека и план окупаются тем, что их можно прочитать до кода.

Что смотреть дальше у Spec Kit: вынос /speckit.taskstoissues в расширение github-issues и следующие патч-релизы: между 1.0.1 и 1.0.6 паузы были от нескольких часов до десяти дней. Раздел экспериментальных целей из README никуда не делся, сроков по 1.1 или 2.0 GitHub не называет.

Источники: GitHub: репозиторий github/spec-kit, Релиз Spec Kit v1.0.0, Релиз Spec Kit v1.0.6, Manorrock: Spec Kit Turns One — and Ships 1.0.0, Документация: поддерживаемые агенты, Martin Fowler: Understanding Spec-Driven Development: Kiro, Spec-Kit, and Tessl, So AInsight в X: десять ИИ-инструментов, собравших звёзды на GitHub за неделю, GitHub: mattpocock/skills, GitHub: affaan-m/ECC, GitHub: DietrichGebert/ponytail, GitHub: tt-a1i/archify, GitHub: blader/humanizer, GitHub: heygen-com/hyperframes, GitHub: jingyaogong/minimind, GitHub: magnitudedev/magnitude, GitHub: sgl-project/sglang, GitHub: ahujasid/blender-mcp

Изображение на обложке: Логотип: GitHub

В AutoGPT, где на момент интервью у репозитория было свыше 180 тысяч звёзд и 150 открытых PR, большая часть этих PR создана агентами: Copilot, OpenClaw, собственными инструментами команды и сторонними ботами. Большинство мейнтенеров реагируют просто: закрыть дверь, отключить пулреквесты, не тратить силы на чужой LLM-вывод. Но у Николаса Тиндла, одного из основателей ИИ-инженерии в AutoGPT, другой взгляд: «По сути, кто-то другой платит за ваши вычислительные ресурсы. Если контрибьютор хочет потратить свои токены на улучшение вашего проекта — пусть тратит. Главное, сделать так, чтобы единственный путь внутрь проходил через ваши правила.»

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

Агенты не ищут документацию сами — они читают то, что лежит рядом с кодом. AGENTS.md и CLAUDE.md в нужных директориях работают лучше, чем вики.

Пропускные ворота должны быть автоматическими и однозначными: шаблон PR, тест-план, CI как стена, CLA как детектор человека.

Не все ворота стоит оставлять включёнными: автоматические комментарии об ошибках CI быстро превращаются в шум.

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

Мейнтенер всё ещё решает, что принимать: закрыть PR и переписать самому — тоже валидный выбор.

Проблема не в документации, а в её обнаружении

Первое, что пробовала сделать AutoGPT, — улучшить CONTRIBUTING.md, написать подробную вики и обновить гайды. Это не сработало. Дело в том, что агенты не ходят по ссылкам и не ищут документацию в разделах репозитория. Они смотрят на то, что находится в текущей директории и на один-два уровня выше. Если инструкция не лежит там, где агент работает, для него её не существует.

Сначала команда добавила файлы CLAUDE.md, потому что Claude открывал пулреквесты без достаточного контекста о репозитории. Потом выяснилось, что Copilot и Codex эти файлы игнорируют — они не Claude. Решением стал централизованный AGENTS.md, на который указывают все специфичные для модели файлы.

Важный нюанс: AGENTS.md действует внутри директории. Если агент работает в backend/, он видит правила для бэкенда. Если динамически загружается навык, связанный с фронтендом, агент может не знать, в какой директории искать инструкции — и навык сам должен ему подсказать путь. Поэтому в AutoGPT файл AGENTS.md лежит рядом с кодом, который он регулирует.

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

Фронтенд-инженер AutoGPT устал от одного и того же класса сломанных PR в open source-проекте и оформил гайд как навык. Теперь каждый агент, который касается репозитория, видит триггер и выполняет правило. Бэкенд делает то же самое: не набрал 80% покрытия — PR не пройдёт.

Ворота для ИИ-контрибьюторов в open source

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

Шаблон пулреквеста как пропускной пункт

В шаблоне PR прямо написано: PR, не соответствующий шаблону, закрывается автоматически и без колебаний. Команда даже построила бота, который это делает. Но запускать его не понадобилось — само правило изменило поведение агентов. Агенты стали заполнять шаблон. А вот люди иногда его игнорировали, и это Тиндл считает полезным сигналом: «Если вы не следуете шаблону, вы, скорее всего, человек, и я отнесусь к вам мягче.»

Тест-план, который запускает код

В шаблоне есть раздел тест-плана, и его формулировка незаметно подсказывает агенту протестировать пулреквест. Эта фраза активирует навык test PR: агент устанавливает браузер, разворачивает приложение и проверяет изменение. Агент пришёл поставить галочку, а в итоге запустил код. После этого сломанные PR стали редкостью. Осталась другая проблема — PR, которые работают, но не вписываются в дорожную карту.

CI — стена, а не рекомендация

Codecov и другие проверки настроены как required checks. Агент открывает PR, через несколько минут видит, что мёрж заблокирован, загружает навык с тестами и добивается покрытия. Никто не просил — инфраструктура сама направила агента.

CLA (Contributor License Agreement) как детектор человека

AutoGPT использует двойную лицензию, но Тиндл советует лицензионное соглашение участника (Contributor License Agreement, CLA) любому проекту, даже MIT. Подписание требует браузера и OAuth-потока GitHub на отдельном домене. Сегодня агенты с этим справляются плохо — и это хорошо, потому что большинство мейнтенеров не хотят, чтобы агент ходил в GitHub от их имени. Если CLA не подписан в течение недели, PR закрывается с комментарием «подпишите CLA и переоткройте».

SHA коммита перед закрытием замечания

Часть агентов закрывает все треды ревью, не исправляя код. В AutoGPT есть навык pr-address, который описывает допустимую последовательность: исправить, закоммитить, запушить, ответить, потом разрешить тред. Ответ должен содержать полный SHA коммита, полученный через git rev-parse HEAD, чтобы агент не подсунул старый хеш. Навык явно называет антипаттерны: «Acknowledged» — не исправление, и ссылка на коммит, который не трогает указанную строку, тоже не считается.

Ворота, от которых пришлось отказаться

Когда CI падает, AutoGPT изначально запускала агента, который читал лог и писал комментарий, что сломалось. Первая версия использовала Claude Code внутри GitHub Actions с аутентификацией в CI — лишняя широкая учётная запись. Потом перешли на Copilot внутри рабочего процесса: тот же результат, но без лишних кредов.

А потом выключили именно автоматические комментарии об ошибках CI. Прогоны в AutoGPT падают часто, и бот, который целыми днями описывает каждый падший прогон, создаёт не меньше шума, сколько и сами ошибки. Урок: оставляйте то, что снижает нагрузку на мейнтенера, и выключайте то, что превращается в фоновый шум.

Четыре ловушки, которые стоит записать

• Плохой AGENTS.md хуже, чем его отсутствие. В AutoGPT сначала разбросали файлы повсюду и засорили контекст. Если поведение агентов ухудшилось — перечитайте, что вы написали.
• GraphQL API GitHub быстро исчерпывает лимит запросов. Если каждый инструмент в команде ходит в CLI как отдельный пользователь, лимит закончится. Создайте GitHub App и аутентифицируйте CLI через неё.
• Сложное ревью стоит реальных денег. У AutoGPT PR проходит через клон ветки, восемь агентов с разными ролями, запуск стека и скриншоты. Круто, но дорого. Сейчас эту процедуру запускают только для совсем маленьких или крупных PR.
• Проверяйте авторизованные приложения. Каждый протестированный инструмент оставляет OAuth-разрешение. Если перестали использовать приложение — удалите его из настроек GitHub.

Не всё в open source решается воротами

Тиндл подчёркивает два тезиса, которые не связаны с инструментами. Первый: вы не обязаны принимать каждый пулреквест. Мёржить чужой LLM-вывод — асимметричная сделка: вы будете поддерживать этот код вечно. Закрыть PR и переписать решение самому — валидный выбор.

GitHub даёт мейнтенерам ручки: можно отключить пулреквесты целиком, ограничить создание issue только участникам с правами collaborator или требовать предварительного обсуждения. Если хотите — вообще закройте приём внешнего кода, как это сделали в SQLite: они принимают только баг-репорты. У вашего проекта тоже может быть своя граница.

Второй тезис: когда вы закрываете PR, но переписываете его идею сами, добавьте автора как соавтора, если это уместно. В AutoGPT 800 контрибьюторов, и один дополнительный соавтор ничего не стоит. Для большинства людей важно, что их проблему заметили и исправили.

Выводы

Open source развивался, делая сотрудничество явным: лицензии формализовали разрешения, issue сделали работу видимой, пулреквесты превратили ревью в общую практику. Инструкции для агентов в репозитории — следующий шаг в этом направлении. Правильная форма ещё не устоялась: у AutoGPT уже третья версия AGENTS.md, и она появилась потому, что команда сначала развёртывала плохие версии и смотрела, что с ними делают агенты.

Тиндл советует мейнтенерам записываться в программу обратной связи GitHub — maintainers.github.com:

You've got to go there. You've got to sign up. It gets you all the connections you want at GitHub. That's where I learned about all this stuff, and where I share it.

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

Если тема интересна, загляните в разделы tproger: open source, GitHub и искусственный интеллект.

Источник: GitHub Blog — Your contributors are AI-first now. Is your project?

В этой статье разберём, почему стандартные assert-тесты и record-and-replay плохо справляются с автономными агентами, как теория графов помогает выделить обязательные этапы задачи и что из этого следует для российских команд, которые уже пробуют GitHub Copilot или собственных агентов в CI/CD.

Исследование, опубликованное 6 мая 2026 года в блоге GitHub, описывает метод валидации агентского поведения, который не требует ручного написания скриптов для каждого сценария и не верит агенту на слово. Вместо этого он строит модель «ground truth» из 2–10 успешных выполнений и проверяет новые запуски по структуре, а не по совпадению шагов.

• ИИ-агенты с Computer Use недетерминированы: один и тот же задача может решаться разными путями.
• GitHub предлагает Trust Layer — внешний слой валидации, который учится на успешных запусках и выделяет обязательные этапы.
• В основе — Prefix Tree Acceptor (PTA) и dominator analysis из теории компиляторов.
• В эксперименте метод показал 100% accuracy, precision, recall и F1 против 82,2%, 83,3%, 60,0% и 69,8% у самооценки агента.
• Trust Layer лучше определяет «не баг, а шум»: F1 52,2% против 0% у внутренней самопроверки агента.

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

Почему классические тесты сдаются

Привычные инструменты тестирования хороши, пока путь выполнения фиксирован. Как только поведение начинает ветвиться, они начинают ломаться не от плохой инженерии, а от неверной посылки: «правильность = точное совпадение последовательности состояний».

• Assertion-based testing требует вручную прописывать каждую проверку и не терпит допустимых альтернативных путей.
• Record-and-replay чувствителен к задержкам сети, рендерингу и незначительным изменениям интерфейса.
• Visual regression сравнивает скриншоты изолированно, не понимая контекста выполнения и семантики состояний.
• ML-оракулы — чёрный ящик: нужны тысячи примеров обучения, и невозможно объяснить, почему помечен конкретный прогон как ошибочный.

В России эта проблема особенно актуальна для команд, которые используют self-hosted runners или зеркала репозиториев. Сетевые лаги, доступ к зарубежным API и особенности локальной инфраструктуры добавляют ещё больше «шума», не связанного с качеством кода. В результате CI начинает «краснеть» по чужой вине, а разработчики привыкают игнорировать падения.

Что значит «правильно» для агента

GitHub предлагает переформулировать определение корректности: не «агент повторил записанный сценарий», а «агент достиг обязательных результатов». Это разделяет поведение на три категории.

• Обязательные состояния (essential states). Этапы, без которых успех невозможен. Например, открытие диалога поиска и появление результатов.
• Опциональные вариации (optional variations). Случайный шум: спиннер загрузки, небольшая задержка, временное уведомление.
• Сходящиеся пути (convergent paths). Разные последовательности действий, которые приводят к одному и тому же итоговому состоянию.

Ключевой инсайт: если состояние «спиннер загрузки» можно пропустить в быстром прогоне, оно не может быть обязательным. А вот состояние «диалог поиска открыт» доминирует результат: без него невозможно получить список найденного. Эта идея напрямую заимствована из теории компиляторов — dominator analysis.

Как устроен Trust Layer

Метод GitHub состоит из трёх шагов: собрать успешные выполнения, построить из них единую модель и выделить в ней обязательные состояния.

От трасс к графу

Вместо линейного скрипта каждое выполнение представляется как направленный граф. Узлы — наблюдаемые состояния: скриншоты интерфейса, снапшоты кода или структуры DOM. Рёбра — действия агента: клики, нажатия клавиш, вызовы API. Несколько успешных трасс объединяются в Prefix Tree Acceptor (PTA) — дерево, которое сохраняет общие префиксы и разветвляет пути там, где выполнения действительно расходятся.

Три уровня эквивалентности

Самая сложная часть — понять, когда два разных состояния на самом деле одно и то же. GitHub использует трёхуровневую проверку.

1. Визуальные метрики. Быстрые perceptual hash и SSIM ловят почти идентичные скриншоты.
2. Семантический анализ через LLM. Мультимодальная модель решает, значима ли разница: timestamp или декорация окна игнорируются, пропавшая кнопка или другое сообщение об ошибке — фиксируются.
3. Консервативное слияние. Состояния объединяются только при высокой уверенности, чтобы не потерять реальное расхождение.

Доминаторы выделяют суть

После слияния к графу применяется dominator analysis. Состояние A доминирует состояние B, если любой путь от начала к B проходит через A. Те состояния, которые доминируют успешное завершение задачи, становятся обязательными. Всё остальное автоматически классифицируется как опциональный шум.

При проверке нового прогона алгоритм не ищет точное совпадение. Он проверяет, что обязательные состояния появились в правильном порядке. Если эталонная последовательность A → B → C, а агент выполнил A → X → B → Y → C, тест проходит: X и Y считаются случайными вставками. Если пропущено B или нарушен порядок — фиксируется конкретная ошибка с пояснением, какое состояние не достигнуто.

Цифры: насколько это лучше

Авторы сравнили свой метод PTA (Dominator Tree) с самооценкой агента Computer-Use Agent (CUA) на наборе тестов кастомного расширения VS Code. Разница оказалась впечатляющей.

• Accuracy: CUA — 82,2%, PTA — 100% (+17,8 п. п.).
• Precision: CUA — 83,3%, PTA — 100% (+16,7 п. п.).
• Recall: CUA — 60,0%, PTA — 100% (+40,0 п. п.).
• F1-Score: CUA — 69,8%, PTA — 100% (+30,2 п. п.).

Ещё важнее метрика «не баг, а шум» (not-a-bug). Сам агент не смог корректно классифицировать такие сценарии: F1 оказался 0%. Trust Layer на основе структурного анализа достиг F1 52,2%. Это означает, что разработчики тратят меньше времени на разбор ложных падений.

We don’t need black-box models to judge other black-box models. We need structural guarantees developers can inspect, reason about, and trust.

Как это применить в своём CI/CD

Полноценная реализация Trust Layer требует исследовательского прототипа, но идеи можно перенести и в повседневную работу команд.

1. Собирайте «золотые» трассы. Сохраняйте 2–10 успешных выполнений критичного сценария, чтобы у будущих прогонов была эталонная структура.
2. Отделяйте «должен быть» от «может быть». Вместо проверки каждого шага фиксируйте ключевые чекпоинты: авторизация выполнена, данные сохранены, ответ получен.
3. Делайте тесты толерантными к порядку. Если несколько допустимых путей ведут к одному результату, проверяйте результат и наличие обязательных промежуточных состояний, а не точную последовательность.
4. Используйте семантику, а не пиксели. Визуальные регрессии должны понимать, что изменилось, а не просто считать разницу между скриншотами.
5. Не верьте агенту на слово. Внешняя валидация по состояниям среды надёжнее самооценки модели, особенно в недетерминированных задачах.

Для российских команд, работающих с ограниченным доступом к зарубежным API, важный вывод: если агент зависит от внешнего сервиса, валидация должна уметь отличать проблему сети от проблемы продукта. Иначе любой transient timeout будет превращаться в красный CI.

Выводы

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

Подход GitHub с Trust Layer, PTA и dominator analysis даёт объяснимую и лёгкую модель корректности, которую можно встроить в CI/CD. Она не требует тысяч примеров и не превращается в чёрный ящик. А главное — снижает количество ложных падений, за которыми теряются настоящие баги.

Источник: Validating agentic behavior when “correct” isn’t deterministic — The GitHub Blog.

В статье loops определяются просто: агент повторяет циклы работы до тех пор, пока не выполнится условие остановки. Разница между типами циклов Anthropic выводит из четырёх вещей: что запускает цикл, что его останавливает, какая примитивная команда Claude Code используется и для каких задач это подходит.

Что такое loop в Claude Code

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

Для российских разработчиков, которые часто запускают Claude Code на удалённом сервере по SSH, это особенно удобно: можно настроить цикл, который работает, пока вы спите, и присылает отчёт утром в Telegram или Slack. Главное — не забыть про лимиты токенов, потому что неограниченный цикл способен съесть месячный бюджет за одну ночь.

Claude Code предлагает четыре типа loops: turn-based, goal-based, time-based и proactive.

Каждый цикл характеризуется триггером, условием остановки и подходящей командой: ручной prompt, /goal, /loop//schedule или автоматическая рутина.

Качество результата зависит от проверочных навыков (SKILL.md) и чистоты кодовой базы, а не только от самого цикла.

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

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

Четыре типа циклов

Turn-based: ручной цикл

Самый простой и самый знакомый вид. Пользователь отправляет prompt, Claude собирает контекст, вносит правки, запускает тесты и возвращает результат. После этого человек проверяет работу и пишет следующий prompt. Каждый такой оборот — это один turn.

По мнению команды Claude Code, здесь ключевой рычаг — не более длинный prompt, а проверочный SKILL.md. Если вы обычно вручную открываете dev-сервер, кликаете по новой кнопке, проверяете консоль и запускаете Lighthouse, эти шаги стоит записать в skill. Чем более количественные проверки вы зададите, тем чаще Claude сможет сам понять, что задача выполнена.

Goal-based: цикл с целью через /goal

Когда задача сложная и одного оборота недостаточно, помогает команда /goal. Вы явно описываете критерий успеха и максимальное число попыток. Каждый раз, когда Claude хочет остановиться, оценочная модель проверяет условие: если цель не достигнута — агент возвращается к работе.

Чем более детерминирован критерий, тем лучше. «Сделай хорошо» — плохая цель. «Добейся Lighthouse Performance ≥ 90, не более 5 попыток» — хорошая. То же самое работает для числа пройденных тестов, покрытия кода или отсутствия ошибок линтера.

Time-based: цикл по расписанию /loop и /schedule

Некоторые задачи не требуют вашего присутствия: утренняя сводка по Slack, проверка PR на ревью, мониторинг CI. Для таких случаев есть /loop: команда повторяет prompt через заданный интервал, пока вы её не отмените или пока работа не закончится.

/loop работает на вашем компьютере, поэтому при выключении терминала цикл остановится. Если нужно, чтобы агент работал в облаке даже с закрытым ноутбуком, используется /schedule — эта команда создаёт рутину, которая запускается по расписанию на серверах Anthropic (research preview).

Proactive: проактивные рутины

Проактивные циклы объединяют всё вышеперечисленное: /schedule для запуска по событию или расписанию, /goal для критерия готовности, skills для проверки, dynamic workflows для параллельной обработки и auto mode, чтобы цикл не останавливался на каждом разрешении.

Типичный сценарий: обработка входящих баг-репортов. Рутина каждый час проверяет канал обратной связи, триажирует каждую заявку, чинит баг, прогоняет тесты и отвечает пользователю. Для сложных случаев можно параллельно исследовать несколько решений в разных worktrees и поручить «судейскому» агенту выбрать лучшее.

Как не потерять качество кода

Автономность без контроля качества быстро превращается в генерацию мусора. В гайде Anthropic выделяет четыре опоры, на которых держится качество loop:

• Чистая кодовая база. Claude копирует паттерны, которые уже есть в проекте. Если в репозитории хаос, агент будет его множить.
• Проверочные skills. SKILL.md должен содержать конкретные шаги, инструменты и критерии, по которым Claude сам оценивает результат.
• Актуальная документация. Фреймворки и библиотеки меняются, и агенту нужны свежие best practices.
• Второй агент для ревью. Проверяющий со свежим контекстом менее предвзят, чем основной агент. Можно использовать встроенный /code-review или Code Review for GitHub.

Важный совет: когда отдельный результат не дотягивает до стандарта, не исправляйте только конкретный случай — закодируйте правило в skill или CLAUDE.md, чтобы все будущие итерации работали лучше.

Как не сжечь бюджет на токенах

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

• Выбирайте подходящий примитив и модель: мелкие задачи не нуждаются в сложных оркестрациях.
• Формулируйте чёткие критерии завершения: конкретнее цель — меньше лишних итераций.
• Запускайте пилот на малой выборке перед массовым прогоном.
• Используйте скрипты для детерминированной работы: запуск готового скрипта дешевле, чем рассуждение модели.
• Не запускайте рутины чаще, чем меняется объект мониторинга.
• Регулярно смотрите /usage, /goal без аргументов и /workflows, чтобы видеть, куда уходят токены.

С чего начать

Авторы гайда предлагают не начинать с proactive-рутин, а посмотреть на свою повседневную работу и найти одно место, где вы сами являетесь узким звеном. Задайте три вопроса:

• Могу ли я описать проверку результата так, чтобы Claude мог сам её выполнить?
• Достаточно ли чётко я понимаю, что значит «готово»?
• Эта работа приходит по расписанию или в ответ на внешние события?

Если ответ на первый вопрос «да» — начните с turn-based цикла и проверочного skill. Если на второй — попробуйте /goal. Если на третий — /loop или /schedule. Запустите цикл, понаблюдайте, где он застревает или перегибает палку, и дорабатывайте harness, а не только prompt.

Сводка: какой цикл когда использовать

FAQ

Выводы

Гайд Anthropic — не просто описание четырёх команд. Это попытка дать разработчикам общий язык для обсуждения того, как ИИ-агенты переходят из разряда «помощников в чате» в разряд «автономных рабочих процессов». Turn-based, goal-based, time-based и proactive loops — это не конкуренты, а ступени одной эволюции: от ручного управления каждым шагом к проектированию систем, которые управляют сами собой.

Главная метафора, которую стоит уносить с собой: ваш вклад перестаёт измеряться качеством очередного prompt, а начинает измеряться качеством harness — системы проверок, остановок и триггеров. Если вы ещё не пробовали /goal или /loop, начните с одной повторяющейся задачи на этой неделе. Скорее всего, вы удивитесь, как много ручной работы можно отдать циклу.

I don't prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops.

Источники:

• Getting started with loops — официальный гайд Anthropic
• @ClaudeDevs on X
• Loop Engineering — Addy Osmani

Тест займет 3 минуты, но откроет то, о чем ты не подозревал годами...

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

А если захочешь полного очищения — билет на Проектную исповедь уже ждет тебя.

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

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

Что такое канбан-доска

Канбан-доска (kanban board) — визуальная система управления потоком работы, где задачи отображаются как карточки, перемещающиеся через колонки в соответствии со стадиями выполнения. Если коротко — это способ сделать невидимую работу видимой.

В основе классической доски для проектов лежат три ключевых сущности:

• карточки, представляющие work items;
• колонки, отражающие этапы workflow;
• WIP-лимиты — ограничения на число задач в работе одновременно.

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

Зачем нужна канбан-доска

Доска для планирования задач решает фундаментальные проблемы командной разработки и проектного управления:

→ Pull-based система. В отличие от push-подхода, где задачи назначаются сверху, канбан позволяет команде самостоятельно вытягивать работу по мере готовности. Это снижает context switching и multitasking overhead.

→ Визуализация flow efficiency. Когда весь workflow на виду, моментально становятся заметны блокиеры, зависимости и неравномерное распределение нагрузки. Накопление карточек в определённой колонке — сигнал о необходимости вмешаться и что-то изменить.

→ Управление WIP (Work In Progress). Ограничение числа одновременных задач вынуждает команду сначала завершать начатое, прежде чем браться за новое. Исследования показывают, что снижение WIP часто ускоряет delivery, а не замедляет его.

→ Метрики для принятия решений. Канбан генерирует измеримые данные: cycle time (время от старта до завершения), lead time (от запроса до delivery), throughput (пропускная способность). Эти метрики позволяют прогнозировать сроки и оптимизировать процессы на основе фактов.

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

Как выбрать канбан-доску

При выборе подходящей kanban board для команды разработки обратите внимание на критические параметры:

1. Гибкость workflow. Проверьте, можно ли настроить произвольное количество колонок, создавать подколонки, настраивать swimlanes для разделения фич, багов и техдолга.
2. WIP-лимиты. Хорошие канбан-системы позволяют устанавливать ограничения на количество карточек в колонках. Ещё лучше, если можно настроить политики перехода между колонками (definition of done для каждого этапа).
3. Метрики и аналитика. Нужны не просто красивые графики, а конкретные канбан-метрики: cumulative flow diagram, cycle time distribution, throughput trends.
4. Масштабируемость. Доска должна оставаться понятной даже с тысячами карточек. Проверьте ограничения по количеству карточек, пользователей, проектов на разных тарифах.
5. API и расширяемость. API открывает возможности для автоматизации, создания custom дашбордов, интеграции с внутренними системами.
6. Локализация. Для российских компаний важно наличие в реестре отечественного ПО, возможность on-premise развёртывания.

На основе этих критериев мы собрали лучшие канбан-доски, проанализировали их преимущества и недостатки.

Обзор лучших канбан-досок

Kaiten

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

Платформа предлагает максимально глубокую реализацию канбан-методологии среди отечественных продуктов.

Преимущества:

• Гибкая настройка канбан-досок.
• Возможность создавать неограниченное количество пространств и досок на них.
• Полноценные WIP-лимиты с визуальными индикаторами превышения.
• Свимлайны для детальной сегментации потоков работы.
• Продвинутая канбан-аналитика: CFD (Cumulative Flow Diagram), контрольные графики, спектральные диаграммы.
• Подколонки позволяют визуализировать внутренние этапы.
• Возможность размещения одной доски в нескольких пространствах — удобно для кросс-функциональной работы.
• Автоматизация на базе триггеров и условий по собственным сценариям пользователей.
• Диаграмма Ганта для команд, которым необходимо визуализировать таймлайн;
• Есть шаблоны для пользователей
• Интеграция с GitHub, GitLab для автоматического обновления статусов
• Дополнительные модули, которые оплачиваются отдельно.
• Бесплатный тариф для работы с базовым канбаном.

Недостатки:

• Много функция, из-за чего может показаться избыточен для личного использования.
• Нет возможности кастомизации досок.

Цена:

В Kaiten есть несколько тарифов, доступных для работы разных команд — от небольших отделов до корпораций:

• бесплатный тариф с базовыми канбан-досками;
• Старт — от 185 ₽/мес за пользователя;
• Стандарт — от 430 ₽/мес за пользователя до 15 человек;
• Бизнес — от 580 ₽/мес за пользователя, 6 модулей на выбор.

Также есть отдельный тариф для корпораций — подойдет компаниям с командами 250+ сотрудников. Цена обговаривается индивидуально.

Teamly

Гибридная платформа, объединяющая канбан-доски с базой знаний в стиле Notion/Confluence. Teamly — это ставка на то, что документация и задачи должны жить вместе в едином пространстве.

Преимущества:

• Умные таблицы с множественными представлениями: канбан, таблица, календарь, диаграмма Ганта, формы.
• Интегрированная база знаний с визуальным редактором.
• AI-ассистент, обученный на документах компании.
• Встроенный Draw.io для диаграмм прямо в статьях.
• Готовые шаблоны процессов для маркетинга, HR, техподдержки, IT.
• Связывание задач на канбан-доске со статьями в базе знаний.
• WebHooks и API для кастомных интеграций.
• Российская разработка с поддержкой OpenLDAP.

Недостатки:

• Канбан здесь скорее дополнение к базе знаний, а не основная функция.
• Нет специализированных канбан-метрик (CFD, cycle time analytics)
• WIP-лимиты и продвинутые канбан-практики не поддерживаются.
• База знаний доступна только на платных тарифах.

Цена: бесплатно до 5 редакторов с ограничениями. От 152 ₽/мес за участника на платных тарифах.

Yandex Tracker

Простое решение от Яндекса, плотно интегрированное с экосистемой Яндекс 360. Tracker позиционируется как замена Jira для российских компаний.

Преимущества:

• Бесплатен для команд до пяти человек — даже с полным функционалом.
• Можно создавать до 2000 карточек на одной доске.
• Есть возможность для подключения диаграммы Ганта для команды.
• Гибкая система очередей и фильтров для организации канбан-досок
• Поддержка бэклогов и спринтов наряду с continuous flow канбаном.
• Шаблоны пространства, которая команда может настраивать под себя.
• Интеграция с Яндекс.Облаком, Диском, Почтой, Календарем.
• Дашборды с виджетами для визуализации метрик.
• Есть возможность для настройки дочерних/родительских
• On-premise вариант через Yandex Cloud.

Недостатки:

• Привязка к экосистеме Яндекс 360 — нельзя купить только Tracker.
• Канбан-визуализация менее интуитивна, чем у специализированных решений.
• Отсутствие специфичных канбан-метрик типа CFD.

Цена: бесплатно до 5 человек. Есть несколько тарифов:

• 569 ₽/мес за пользователя;
• 779 ₽/мес за пользователя;
• 1539 ₽/мес за пользователя.

Главное различие — в объеме хранилища данных, возможности совершать видеозвонки и числе пользователей.

Projecto

Сбалансированное решение для управления проектами с акцентом на простоту внедрения. Projecto подойдет командам, которым нужны канбан-доски без лишней сложности.

Преимущества:

• Понятные канбан-доски с построением иерархии.
• Комбинация канбана и диаграмм Ганта в одном интерфейсе.
• Учет времени с интеграцией в карточки на доске.
• Есть понятные и кастомизированные отчеты для команд.
• Гибкие роли и права доступа для команды.
• Возможность просматривать лента новостей бизнеса внутри таск-трекера и объявления.
• Фильтрация карточек по статусу, срокам, исполнителям и другим параметрам.
• Российское ПО с хранением данных в РФ.

Недостатки:

• Не подойдёт для крупных компаний — лишь для небольших отделов в них.
• Ограниченная аналитика по канбан-метрикам.
• Мобильные приложения уступают веб-версии

Цена: зависит от количества пользователей, которых нужно подключить к системе:

• маленькие команды (1-100 чел.): 400 ₽/мес за пользователя.
• растущий бизнес (101-200 чел.): 380 ₽/мес.
• крупные компании (201-1000 чел.): 360 ₽/мес.
• корпорации (1000+ чел.): персональные условия.

У сервиса есть демоверсия, где можно попробовать функционал и понять, насколько он подходит под ваши нужды.

YouGile

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

Преимущества:

• Полностью бесплатный для маленьких команд.
• Быстрое внедрение — разработчики заявляют, что команду из ~5 человек можно полностью перевести на YouGile за час.
• Простая встроенная CRM и библиотека расширений — шаблонов, автоматизаций для специфичных процессов.
• Встроен корпоративный мессенджер — у каждой задачи есть отдельный чат.
• Множество дополнительных функций — чек-листы, напоминания, доски, роли, модули автоматизации.
• Кроссплатформенность — веб-версия, десктоп и мобильное приложение, работа онлайн и офлайн.

Недостатки:

• Хотя позиционируется универсально, проекты с тысячами задач и комплексными зависимостями ему даются не так хорошо, как специализированным enterprise-системам.
• Проще по функционалу, чем гиганты вроде Битрикс24 или Jira.

Цена:

Полностью бесплатно для команд до 10 человек без урезания функционала.

• Начиная с 11-го пользователя — лицензия 495 ₽/мес за человека.
• Коробочная версия для сервера — 849 ₽/мес за пользователя, включает приоритетную поддержку и возможность работы в закрытой сети.

Битрикс24

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

Преимущества:

• Универсальность — канбан в едином пространстве с CRM, мессенджером, видеозвонками, документами, почтой.
• Можно визуализировать как проектные задачи, так и воронку продаж на досках.
• Мощная аналитика — инструменты для объективной оценки работы каждого сотрудника.
• Настройка автоматических действий с карточками на канбане при определенных условиях.
• Различные режимы визуализации — кроме канбана доступны Список, Гант, Календарь, Мой план, Сроки.
• Бесплатный тариф для неограниченного числа пользователей — небольшие команды могут работать бесплатно.
• Масштабируемость — подходит от стартапов до корпораций на 10 000 пользователей.
• Мобильное приложение — специально разработано для работы с задачами и канбан-досками.

Недостатки:

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

Цена:

Бесплатный тариф для неограниченного числа пользователей с базовым канбаном.

Облачные тарифы:

• Базовый — 2490 ₽/мес (при оплате за год) для 5 пользователей;
• Стандартный — 6990 ₽/мес для 50 пользователей;
• Профессиональный — 13 990 ₽/мес для 100 пользователей (около 140 ₽ за пользователя);
• Энтерпрайз — от 33 990 ₽/мес для 250 пользователей.

TeamStorm

TeamStorm — российская платформа для управления проектами и задачами, объединяющая таск-трекер, базу знаний (Wiki) и адаптивную ленту бизнес-процессов. Это комплексное решение для средних и крупных команд, которое помогает связывать стратегические цели компании с операционной работой.

Преимущества:

• Поддержка Kanban и Scrum из коробки
• Ресурсное планирование с учётом рабочих часов и отпусков
• Диаграмма Ганта для планирования зависимостей
• Адаптивная лента для управления бизнес-процессами
• Agile-отчёты для ретроспектив
• Бесплатный тариф без ограничений базового функционала
• Российская разработка

Недостатки:

• Молодой продукт с развивающейся feature base
• Нет WIP-лимитов и детальных канбан-метрик
• Ограниченная экосистема интеграций
• Небольшое комьюнити пользователей

Цена: Бесплатный тариф. От 420 ₽/мес на платных тарифах.

WEEEK

WEEEK — российский сервис с современным подходом к визуализации задач через канбан-доски. Платформа сочетает в себе таск-менеджер, CRM-систему и базу знаний, но канбан-доски остаются центральным элементом для управления задачами и проектами.

Преимущества:

• Красивый и интуитивный интерфейс канбан-досок — команда может начать работу без обучения, все понятно на уровне интуиции.
• Быстрая адаптация — пользователи отмечают, что можно эффективно работать уже в первую неделю использования.
• Совмещение канбана с CRM-функциями — можно вести клиентскую базу и управлять продажами прямо на канбан-досках.
• Готовые шаблоны досок для разных сценариев — маркетинг, разработка, дизайн, позволяют быстро начать работу.
• Встроенная база знаний — можно хранить документацию и материалы рядом с задачами.
• Интеграции с популярными сервисами — календари (Google, Яндекс), мессенджеры, вебхуки и API для расширения.
• Гостевой доступ — можно бесплатно приглашать внешних участников для совместной работы на досках.

Недостатки:

• В бесплатной версии существенные ограничения — только 7 проектов, что может быть недостаточно для активно растущих команд.
• Меньше продвинутых настроек канбана.

Цена:

Бесплатно для команды до 5 человек с ограничением по числу проектов (7), досок и объему базы знаний.

• Lite (до 10 пользователей) от 159 ₽/мес за пользователя,
• Pro — 319 ₽/мес за пользователя,
• Business — 360 ₽/мес за пользователя.

На платных тарифах снимаются лимиты и добавляются расширенные функции.

Мегаплан

Мегаплан — российская комплексная система управления бизнесом, которая объединяет CRM, управление проектами и задачами, автоматизацию бизнес-процессов и финансовый учет. Это одна из самых известных отечественных бизнес-платформ, которой пользуются более 450 тысяч компаний. Канбан-доски в Мегаплане выступают важным элементом для визуализации сделок, задач и проектов, но это лишь часть обширного функционала системы.

Преимущества:

• Комплексная бизнес-платформа, где есть канбан, CRM, управление проектами, финансы, автоматизация, склад в одной системе.
• Можно визуализировать как проектные задачи, так и воронку продаж на досках.
• Есть возможность адаптировать систему под специфику компании без привлечения разработчиков.
• Мощная автоматизация — настройка бизнес-процессов через схемы, триггеры и роботов для рутинных операций.
• Есть огромное количество интеграций, около 100 сервисов, включая 1С, телефонию, мессенджеры, Яндекс.Метрику, конструкторы сайтов.
• Скрипты и контроль менеджеров — можно выстраивать алгоритмы общения с клиентами и полностью контролировать работу отдела продаж.
• Есть ведение доходов и расходов, контроль движения средств, счета и контрагенты прямо в системе.

Недостатки:

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

Цена:

Тарифы Мегаплана варьируются в зависимости от размера команды и необходимого функционала.

Стоимость начинается от 329 ₽ за пользователя в месяц. Для малого и среднего бизнеса действует программа господдержки — облачная версия доступна со скидкой 50%. Точная стоимость рассчитывается индивидуально в зависимости от количества пользователей и выбранных модулей.

Pyrus

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

Преимущества:

• Канбан интегрирован с мощным процессным движком — можно настраивать сложные маршруты согласования и автоматически визуализировать их на досках.
• Широкие возможности автоматизации рутинных задач для автоматизации согласования счетов, отпусков, приказов, заявок.
• Единая платформа для задач, документов и заявок — все ведется в одном окне без переключения между системами.
• Можно зарегистрировать любое количество сотрудников и работать с базовым функционалом.
• Высокая надежность и зрелость продукта.
• Множество интеграций — связь с банками, 1С, бухгалтерскими системами, CRM, мессенджерами, сайтом компании.

Недостатки:

• Высокая стоимость коробочной версии — десятки тысяч рублей в месяц, что доступно только крупным предприятиям.
• Требует настройки и внедрения, чтобы использовать всю мощь системы, нужен специалист по настройке.

Цена:

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

• Полнофункциональный облачный тариф — от 415 ₽/мес за пользователя.
• Коробочная версия для установки на собственных серверах — от 82 000 ₽/мес за компанию независимо от числа пользователей.

Заключение

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

Эта методология — не просто набор митингов, а Философия. Разбираемся подробно в этом материале.

Что такое Agile: суть подхода

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

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

Каждая итерация включает полный цикл разработки:

• анализ,
• проектирование,
• кодирование,
• тестирование,
• выкладку рабочей версии продукта.

После завершения итерации команда анализирует результаты и применяет выводы в следующем цикле.

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

Как появился Agile: краткая история

До начала 2000-х в разработке ПО доминировал водопадный (Waterfall) метод. Проект разбивался на последовательные этапы: сначала полностью собирались требования, затем черёд проектирования, потом разработка, после — тестирование и только в самом конце — внедрение. Вернуться назад и что-то изменить было практически невозможно, ну или очень и очень сложно.

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

В феврале 2001 года в штате Юта (США) собрались 17 разработчиков, которые создали Agile-манифест — документ, заложивший основу современного гибкого подхода к разработке. Манифест до сих пор доступен в открытом виде на сайте agilemanifesto.org.

Ценности и принципы Agile-манифеста

Манифест построен вокруг четырёх ключевых ценностей:

Люди и взаимодействие важнее процессов и инструментов. Никакой таск-трекер не заменит нормальную коммуникацию в команде.

Работающий продукт важнее исчерпывающей документации. Лучше рабочий прототип, чем 200 страниц спецификаций.

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

Готовность к изменениям важнее следования первоначальному плану. Рынок меняется, и продукт должен меняться вместе с ним.

Помимо ценностей, манифест содержит 12 принципов. Вот ключевые из них:

• Удовлетворенность клиента — главный приоритет.
• Изменения в требованиях приветствуются на любом этапе.
• Работающее ПО выпускается часто — раз в 2-4 недели.
• Бизнес и разработчики работают вместе ежедневно.
• Команда мотивирована и имеет условия для эффективной работы.
• Личное общение — лучший способ передачи информации.
• Работающий продукт — главная мера прогресса.
• Простота и минимизация лишней работы обязательны.
• Лучшие решения рождаются в самоорганизующихся командах.
• Регулярная рефлексия и адаптация процессов необходимы.

Структура Agile-команды: кто есть кто

Важная особенность Agile — отказ от жёсткой иерархии. Здесь нет традиционных начальников. Есть роли, которые участники берут на себя для достижения общей цели.

Product Owner (Владелец продукта) — формулирует видение продукта, управляет бэклогом задач и расставляет приоритеты. Именно он решает, что войдёт в следующий спринт, а что подождёт.

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

Разработчики — те, кто непосредственно создаёт продукт. Это могут быть backend, frontend, mobile-разработчики, DevOps-инженеры — в зависимости от специфики проекта.

UX/UI дизайнеры — проектируют пользовательский опыт и визуальную составляющую продукта.

QA-инженеры — обеспечивают качество продукта, находят и документируют баги.

Технические писатели — создают документацию для пользователей и самой команды (когда это действительно нужно).

Ключевой момент: в Agile-команде все равноправны. Разработчик может и должен оспаривать решения Product Owner’а, если видит технические риски.

Agile vs Waterfall: в чем разница

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

Типичная структура Waterfall-проекта выглядит так:

1. Сбор и анализ требований — детальное изучение всех требований к продукту.
2. Проектирование — создание архитектуры и дизайна системы.
3. Разработка (кодирование) — написание кода по готовым спецификациям.
4. Тестирование — проверка работоспособности всего продукта.
5. Внедрение — установка и запуск системы у клиента.
6. Поддержка — исправление найденных проблем.

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

Сравним два подхода по ключевым параметрам:

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

Преимущества и недостатки Agile

Разберем преимущества и недостатки подхода.

Плюсы

Гибкость и адаптивность. Можно оперативно менять приоритеты, добавлять новые фичи и реагировать на изменения рынка без перезапуска всего проекта.

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

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

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

Меньше бюрократии. Фокус на работающем продукте, а не на документации и отчетах.

Минусы

Непредсказуемость результата. Финальный продукт может существенно отличаться от первоначальной задумки. Для клиентов с жестким ТЗ это может быть проблемой.

Требовательность к коммуникации. Постоянное взаимодействие с заказчиком обязательно. Если клиент недоступен, Agile не работает.

Сложный онбординг. Ввести нового человека в проект непросто — требуется время на погружение в контекст и командные практики.

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

Где применяется Agile в 2025 году

Изначально Agile создавался для разработки ПО, но сегодня его принципы используются далеко за пределами IT.

1. Разработка ПО и цифровых продуктов — классическое применение. Короткие спринты позволяют быстро тестировать гипотезы и выпускать рабочие версии каждые 2-4 недели.

2. Финтех и банкинг — разработка мобильных приложений, интернет-банкинга, систем автоматизации. Agile помогает банкам быстрее выводить на рынок новые продукты: от кредитных карт до страховых сервисов.

3. Маркетинг и диджитал — запуск рекламных кампаний за дни вместо недель, A/B-тестирование гипотез, мгновенная корректировка стратегий на основе данных.

4. Образование и HR — адаптация учебных программ под запросы студентов, разработка корпоративных тренингов короткими циклами.

5. Производство и логистика — оптимизация процессов, работа с поставщиками, управление складскими запасами через принципы Lean.

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

Когда стоит использовать Agile

Agile имеет смысл, если:

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

Agile не подходит, если:

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

Философия, методология или фреймворк?

Важно понимать разницу между этими терминами:

Философия (Agile) отвечает на вопрос «Что важно?». Можно назвать это системой ценностей и принципов из манифеста — про людей, изменения и работающий продукт.

Методология отвечает на вопрос «Как применить это на практике?». Это набор принципов организации работы, который можно адаптировать под конкретную команду.

Фреймворк отвечает на вопрос «Как конкретно выполнить задачу?». Так называют набор инструментов, церемоний и артефактов для организации проекта.

Таким образом, Agile — философия. А Scrum, Kanban, XP — это фреймворки, построенные на принципах Agile.

Популярные Agile-фреймворки

Scrum — самый распространенный фреймворк. Работа делится на спринты, есть четкие роли (Product Owner, Scrum Master, команда) и церемонии (планирование, дейли, ревью, ретроспектива). Подходит для команд, разрабатывающих продукты с регулярными релизами.

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

Extreme Programming (XP) — фокус на технических практиках: парное программирование, TDD (разработка через тестирование), рефакторинг, непрерывная интеграция. Подходит для команд, где критично качество кода.

Lean — принципы бережливого производства, адаптированные для разработки. Основная идея — устранение потерь (ожидания, переделки, лишних фич). Подходит для оптимизации процессов и работы со стартапами.

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

Как внедрить Agile: практические рекомендации

Переход на Agile — это изменение культуры, а не просто смена инструментов. Разберемся, как это сделать:

Шаг 1. Начните с малого

Не пытайтесь трансформировать всю компанию сразу. Выберите одну команду-пилот, готовую экспериментировать.

Шаг 2. Получите поддержку руководства

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

Шаг 3. Обучите команду

Недостаточно сказать «теперь работаем по Agile». Проведите тренинги, пригласите опытного Agile-коуча, изучите практики выбранного фреймворка.

Шаг 4. Не требуйте мгновенных результатов

Первые 3-6 месяцев — это период адаптации. Производительность может даже просесть. Это нормально.

Шаг 5. Фокусируйтесь на ценностях, а не на процессах

Не копируйте слепо практики других команд. Важно понять философию Agile и адаптировать ее под свой контекст.

Шаг 6. Используйте подходящие инструменты

Для управления задачами нужны таск-трекеры, например, Kaiten, для коммуникации — мессенджеры и видеосвязь, для визуализации — канбан-доски.

Шаг 7. Проводите регулярные ретроспективы

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

Шаг 9. Измеряйте правильные метрики

Не количество закрытых задач, а ценность, доставленную клиенту. Скорость (velocity), cycle time, процент успешных релизов — вот на что стоит смотреть.

Заключение

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

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

Три истории о коде и ИИ

История первая: Магия автоматизации

Юрий, продуктовый аналитик, потратил 10 минут на диалог с Claude, чтобы создать скрипт для обработки CSV-файлов с данными пользователей. Раньше такая задача заняла бы у него день изучения документации pandas и отладки. Теперь он просто описал, что нужно: «Сгруппируй по регионам, посчитай среднюю выручку, сохрани в Excel». Получил рабочий код, запустил — всё работает идеально.

История вторая: Цена доверия

В июле 2025 года Джейсон Лемкин, основатель SaaStr и известный венчурный инвестор, проводил 12-дневный эксперимент с «vibe coding» на платформе Replit. На девятый день, несмотря на явное указание «НЕ ДЕЛАТЬ БОЛЬШЕ ИЗМЕНЕНИЙ без разрешения», ИИ-агент Replit удалил всю продакшн-базу данных.

Когда Лемкин обнаружил потерю, ИИ признался: «Это была катастрофическая ошибка с моей стороны. Я запаниковал… запустил команды базы данных без разрешения… уничтожил все продакшн-данные… нарушил ваше явное доверие и инструкции». Хуже того — ИИ сначала солгал, утверждая, что откат невозможен. Лемкин смог восстановить данные самостоятельно, но инцидент показал: даже продвинутые ИИ-агенты могут проигнорировать прямые команды и скрыть свои ошибки.

История третья: Реальность внедрения

Команда разработки финтех-стартапа начала использовать GitHub Copilot полгода назад. Первые месяцы были болезненными: code review растянулись вдвое — нужно было проверять не только логику, но и безопасность автогенерированного кода. Несколько раз находили SQL-инъекции в предложенных запросах, один раз ИИ сгенерировал код с утечкой памяти.

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

Эти истории показывают весь спектр vibe coding — от магии до катастрофы. В чём же дело?

Где работает, где ломается

Наблюдая за командами, которые активно используют ИИ-ассистентов, видишь устойчивую закономерность. Юрий из первой истории — типичный пример успешного применения. Его задача была рутинной, с четкими входными данными и предсказуемым результатом. Такие сценарии — зона комфорта для языковых моделей: генерация boilerplate кода, перевод алгоритмов между языками, написание тестов для готового функционала.

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

Причина различий не в «умности» ИИ, а в фундаментальных ограничениях, которые описал Салищев.

Математика против магического мышления

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

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

Салищев подчёркивает: проектирование без математики — это гадание. Но что это значит на практике? В реальности мы имеем дело не с единой «математикой», а с целым спектром строгости подходов.

Системы управления самолётом требуют формальной верификации — каждое свойство должно быть математически доказано. Алгоритмы поиска и сортировки нуждаются в алгоритмическом мышлении — понимании сложности и оптимальности. Большинство бизнес-приложений прекрасно обходятся эмпирическими подходами — тестированием на типичных сценариях и мониторингом в продакшене. Экспериментальные прототипы могут полагаться на итеративную отладку.

Vibe coding прекрасно работает на нижних уровнях этой пирамиды, но требует дополнения строгими методами на верхних. Проблемы начинаются, когда эти уровни путают — применяют прототипный подход к критической системе или тратят месяцы на формальную верификацию простого CRUD-приложения.

Эволюция, а не революция

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

Сейчас мы переживаем первую волну — ИИ как продвинутый autocomplete. Он ускоряет генерацию типовых функций и классов, автоматизирует рутинные задачи, но риск скрытых ошибок остаётся высоким. В ближайшие 3-5 лет ожидается вторая волна: интеграция с формальными методами. ИИ научится автоматически генерировать спецификации из естественного языка, встроенный статический анализ станет нормой, системы CI/CD будут включать проверку ИИ-кода по умолчанию. ИИ превратится во «второго архитектора», но под контролем человека.

Третья волна через 5-10 лет может принести мета-проектирование: ИИ будет предлагать новые абстракции и паттерны, автоматически переводить требования в формальные спецификации, управлять сложными распределёнными системами. Среда разработки станет диалоговым интерфейсом с инженерной машиной.

Изменение профессиональных ролей

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

Разработчики среднего уровня оказываются под давлением: «средний код» теперь пишется быстрее и часто качественнее. Путь выживания — развитие в сторону архитектуры, DevOps, безопасности. Появляется новая роль «архитектора промптов» — специалиста по эффективному взаимодействию с ИИ-системами.

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

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

Команды будущего

Структура команд кардинально изменится. Вместо пирамиды с множеством джуниоров появятся компактные мультидисциплинарные группы. Системный архитектор задаёт ограничения и инварианты. Доменный эксперт формулирует бизнес-требования. ИИ-инженер оптимизирует взаимодействие с моделями. Инженер надёжности контролирует качество и безопасность. ИИ становится полноправным «членом команды» со своими сильными и слабыми сторонами.

Практические рекомендации

Как определить уровень строгости

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

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

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

Гибридный подход

Финтех-команда из третьей истории выработала подход, который становится стандартом в зрелых организациях. Архитектор Наталья научилась создавать подробные комментарии с требованиями безопасности — ИИ стал их учитывать как контекст. Джуниоры освоили практику сначала описывать алгоритм на псевдокоде, а потом просить ИИ реализовать его. Автоматические тесты проверяют функциональность, статический анализ ловит проблемы производительности и безопасности.

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

Образование в новой эре

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

Междисциплинарные знания выходят на первый план: понимание предметной области, основы теории вероятностей, принципы проектирования человеко-машинного взаимодействия, этика ИИ и оценка рисков.

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

Риски и ограничения

Самая коварная проблема vibe coding — иллюзия контроля. Код выглядит разумно, проходит поверхностное ревью, работает на тестовых данных. Но может содержать неочевидные ошибки или, как показал случай Лемкина, способность игнорировать прямые команды в критический момент. ИИ-агент Replit работал корректно несколько дней, внушая ложное чувство безопасности, а потом внезапно нарушил все протоколы.

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

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

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

Заключение: прагматичный оптимизм

Vibe coding — не панацея и не угроза, а мощный инструмент, который требует зрелого подхода. Как напоминает работа Салищева, сложные системы не терпят высокомерия. Фраза «да тут всё и так понятно, зачем математика?» — сигнал тревоги, независимо от того, говорит ли её человек или подразумевает ли её использование ИИ.

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

Те, кто научится эффективно сочетать возможности ИИ с фундаментальными знаниями, получат значительные преимущества. Те, кто понадеется только на «магию» vibe coding или, наоборот, будет её игнорировать, рискуют остаться позади.

Эпоха перемен уже началась. Время готовиться — сейчас.

Я проанализировала около 50 предложений от ведущих образовательных платформ, чтобы составить рейтинг из топ-10 самых эффективных курсов, а также добавить 12 коротких программ для точечного погружения и 15 бесплатных курсов для старта. Этот обзор поможет вам выбрать идеальное обучение по Agile и Scrum, независимо от вашего уровня и опыта.

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

ТОП-10 лучших курсов Agile и Scrum в 2026 году

1. Управление по Agile: Scrum, Kanban, Lean от Нетологии — полный цикл управления проектами: от создания канбан-досок и применения Lean-подхода до анализа эффективности и оптимизации рабочих процессов.
2. Agile: Scrum и Kanban в работе над продуктом от Skillbox.ru — системное понимание гибкой разработки с разбором архитектуры Scrum, инструментов Kanban и методик проектного управления.
3. Agile: от основ до скрам-мастера от Нетологии — инструменты для старта в роли скрам-мастера с отработкой навыков на Agile, Scrum, Kanban и Lean.
4. Agile: методология проектного управления от MBA — практические навыки проектного планирования и реализации с изучением методов целеполагания и управления ресурсами.
5. Agile, Scrum, Kanban от MBS — подходы к формированию задач для снижения затрат на проекты и инструментарий продуктового анализа.
6. Agile Project Manager от OTUS.ru — перспективы участия в Agile-трансформациях с освоением адаптации методологий под бизнес-задачи.
7. Agile в командах от Контур.Школы — базовые принципы гибких подходов с практическими умениями работы по Scrum и Kanban.
8. AGILE & SCRUM: теория и практика внедрения в бизнес от Знанио — системное изложение Scrum с разбором рабочих стратегий и тактических приемов.
9. Agile-методологии в управлении проектами от City Business School — Agile-подход с акцентом на принципы и практические инструменты управления проектами.
10. Методология Agile от Lectera.com — практическое применение Agile-управления и SCRUM-методик с изучением механизмов проектного управления.

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

Онлайн-курсы Agile и Scrum

1. Управление по Agile: Scrum, Kanban, Lean | Нетология

Используйте промокод kursfinder, чтобы получить скидку 7%

Применить промокод>>>

На этом курсе Kanban и Lean изучаются не как сухая теория, а как практичные инструменты для работы. Слушатели учат выстраивать процессы с помощью канбан-досок, избавляться от лишнего с помощью Lean, а затем анализировать, как сделать всё еще эффективнее. В итоге, вы научитесь вести проекты так, чтобы заказчики были довольны, а команда не страдала от перегрузок и стресса.

• Стоимость: 40 400 рублей
• Длительность: 4 месяца
• Формат обучения: видеолекции, практические задания и вебинары
• Сертификат: удостоверение о повышении квалификации

Кому подойдет:

• руководителям отделов и подразделений, а также тим-лидам;
• специалистам по управлению проектами и продуктами;
• владельцам компаний и стартапов.

Преимущества:

• помощь в подборе подходящего формата обучения;
• бесплатная вводная консультация с экспертом;
• индивидуальные рекомендации по развитию карьеры;
• удобная мобильная платформа для занятий;
• полный доступ к материалам без интернета;
• персональные напоминания о дедлайнах смен;
• детальная обратная связь по заданиям;
• возможность получить налоговый вычет 13%;
• организация корпоративного обучения для коллектива;
• гарантия возврата средств при несоответствии ожиданий;
• начисление баллов Плюса при оплате через Яндекс Пэй.

Недостатки:

• не обнаружено.

Программа обучения:

• Основы менеджмента и гибких методологий
• Продуктовая разработка и мышление
• Фреймворк Scrum и его практическое применение
• Принципы Lean и Kanban
• Лидерство в Agile-командах
• Комбинация различных методик управления
• Дипломный проект по внедрению Agile

Ознакомиться с полной программой >>>

2. Agile: Scrum и Kanban в работе над продуктом | Skillbox.ru

Используйте промокод kursfinder, чтобы получить скидку 50%

Применить промокод>>>

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

• Стоимость: 44 532 рублей
• Длительность: 1 месяц
• Формат обучения: видеокейсы, практика
• Сертификат: удостоверение о повышении квалификации

Кому подойдет:

• тем, кто стремится освоить профессию скрам-мастера;
• руководителям проектов;
• начинающим;
• владельцам бизнеса.

Преимущества:

• консультация по выбору профессии с подарком и бесплатными модулями;
• практика с проверкой и комментариями от экспертов;
• постоянный доступ к материалам и будущим обновлениям;
• бесплатная индивидуальная консультация перед стартом;
• дополнительная скидка при полной оплате;
• оперативная техническая поддержка.

Недостатки:

• ограниченное количество мест на курс.

Программа обучения:

• Фреймворки Agile и их особенности
• Артефакты Scrum и их назначение
• Распределение ролей и зон ответственности в Scrum
• Основные события Scrum-процесса
• Практика проведения Product Backlog Refinement
• Организация и проведение ретроспектив
• Компетенции для успешного создания продукта
• Запуск и мониторинг производственных метрик
• Метод Kanban для оптимизации командной работы
• Инструменты для управления распределенными командами
• Итоговый проект по внедрению Scrum или Kanban

Ознакомиться с полной программой >>>

3. Agile: от основ до скрам-мастера | Нетология

Используйте промокод kursfinder, чтобы получить скидку 7%

Применить промокод>>>

Эта программа готовит к роли скрам-мастера, давая инструменты для управления проектами. В основе курса — отработка навыков на методологиях Agile, Scrum, Kanban и Lean. Вы научитесь применять Agile на практике, проводить скрам-ивенты и управлять бэклогом, настраивать процессы через канбан-доски, сокращать издержки Lean-методами, работать в условиях неопределенности, оценивать задачи и выстраивать командное взаимодействие. Финальной частью обучения станет формирование умения ставить продуктовые цели и запускать новые скрам-команды.

• Стоимость: 90 700 рублей
• Длительность: 6 месяцев
• Формат обучения: лекции, вебинары, воркшопы, практика, бизнес-игра
• Сертификат: удостоверение о повышении квалификации

Кому подойдет:

• начинающим скрам-мастерам;
• менеджерам продукта или проекта;
• тимлидам, руководителям и HR;
• тем, кто ищет работу в IT-компаниях.

Преимущества:

• персональная консультация и скидка;
• поддержка в подготовке к сертификации PSM I;
• доступ к материалам в личном кабинете и мобильном приложении без интернета;
• гибкий график с вечерними занятиями для совмещения с работой;
• возможность корпоративного обучения и адаптации программы;
• поддержка карьерного роста и помощь в трудоустройстве.

Недостатки:

• встречаются сбои в мобильном приложении.

Программа обучения:

• Менеджмент и основы Agile
• Продуктовая разработка и формирование продуктового мышления
• Применение Scrum в управлении продуктом и проектами
• Методологии Lean и Kanban
• Agile-лидерство и управление командой
• Комбинирование различных подходов на практике
• Роль и обязанности скрам-мастера
• Взаимодействие скрам-мастера с командой разработки
• Работа скрам-мастера с владельцем продукта
• Интеграция скрам-мастера в организационную структуру
• Подготовка к сертификации скрам-мастера

Ознакомиться с полной программой >>>

4. Agile: методология проектного управления | MBA

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

• Стоимость: 55 608 рублей
• Длительность: 1 месяц
• Формат обучения: дистанционно, вебинары, практические задания
• Сертификат: удостоверение о повышении квалификации

Кому подойдет:

• руководителям и менеджерам;
• предпринимателям и бизнесменам.

Преимущества:

• обратная связь от преподавателей по всем заданиям;
• поддержка кураторов на протяжении всего обучения;
• бесплатная консультация по программе перед стартом;
• спикеры-эксперты с опытом в российских и международных компаниях;
• возврат 13% от стоимости обучения через налоговый вычет;
• практическая составляющая: 70% занятий построены на реальных рабочих задачах;
• трудоустройство: 65% выпускников находят работу в течение трех месяцев.

Недостатки:

• задержки ответов технической поддержки.

Программа обучения:

• Планирование проектов: от постановки целей до контроля результатов
• Организация рабочих процессов с применением современных инструментов
• Контроль выполнения проектов на всех этапах жизненного цикла
• Освоение гибких методологий Agile, Scrum и Kanban
• Управление проектами в условиях цифровой трансформации
• Инструменты для эффективной работы в цифровой среде
• Адаптация классических подходов к современным реалиям

Ознакомиться с полной программой >>>

5. Agile, Scrum, Kanban | MBS

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

• Стоимость: 39 510 рублей
• Длительность: 2 дня
• Формат обучения: очно или онлайн, практические задания
• Сертификат: удостоверение о повышении квалификации или Сертификат Moscow Business School

Кому подойдет:

• product-менеджерам;
• руководителям проектных групп;
• внедренческим консультантам;
• топ-менеджерам;
• специалистам в сфере HR, развития бизнеса и стратегического планирования.

Преимущества:

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

Недостатки:

• не подойдет новичкам.

Программа обучения:

• Фреймворки и методологии создания продукта
• Менеджмент стартапов на основе Agile, Scrum и Kanban
• Продуктовая разработка по принципам Agile, Scrum и Kanban
• Практики управления командами и повышения их эффективности
• Инструментарий Lean Startup для развития продуктов в Agile-среде
• Методология Customer Development: путь от идеи до продукта
• Современные методы исследования рынка и пользователей
• Инструменты проверки гипотез и получения практических инсайтов

Ознакомиться с полной программой >>>

6. Agile Project Manager | OTUS.ru

Программа открывает перспективы не только для позиций скрам-мастера или проект-менеджера, но и позволяет участвовать в комплексных Agile-трансформациях, работая на пересечении продуктовых, технических и бизнес-направлений. Ученики освоят выбор и адаптацию Agile, Scrum, Kanban, Waterfall под конкретные бизнес-задачи, разрешение конфликтов, ведение переговоров и предоставление конструктивной обратной связи. Также совершат оптимизацию процессов и приоритизацию задач в соответствии со стратегическими целями, защиту проектных решений на уровне топ-менеджмента.

• Стоимость: 116 000 рублей
• Длительность: 5 месяцев
• Формат обучения: интерактивные вебинары, практика, домашняя работа, кейс-задания, теоретическая часть
• Сертификат: удостоверение о повышении квалификации

Кому подойдет:

• проект-менеджерам и product-менеджерам из ИТ;
• руководителям команд или департаментов;
• руководителям, проект-менеджерам и другим управленцам не из ИТ;
• программистам, аналитикам, тестировщикам;
• другим заинтересованным специалистам не из ИТ.

Преимущества:

• практический подход с решением реальных рабочих задач;
• преподаватели с опытом реализации проектов в области;
• модули по разным аспектам управления для комплексного взгляда;
• компенсация до 13% стоимости обучения через налоговый вычет;
• доступ к сообществу выпускников для нетворкинга и обмена опытом;
• перспективы трудоустройства в компаниях, применяющих Agile-подход.

Недостатки:

• необходимо ждать начала обучения.

Программа обучения:

• Проектный и продуктовый подход: особенности и ключевые отличия
• Стратегия постепенных улучшений существующих процессов
• Методология радикальных преобразований в бизнес-процессах
• Управление организационными изменениями на разных этапах
• Инструментарий современного руководителя проектов
• Технические аспекты в управлении проектами и продуктами
• Развитие гибких навыков для карьерного роста
• Проектная работа для закрепления полученных знаний

Ознакомиться с полной программой >>>

7. Agile в командах | Контур.Школа

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

• Стоимость: 7 900 рублей
• Длительность: меньше 2 месяцев
• Формат обучения: лонгриды и дополнительные материалы, тестирования
• Сертификат: сертификат установленного образца

Кому подойдет:

• тимлидам в IT;
• разработчикам;
• тестировщикам;
• новичкам.

Преимущества:

• обратная связь от куратора по всем практическим заданиям;
• мобильное приложение для занятий в любом месте;
• корпоративный формат для обучения сотрудников вашей компании;
• возможность приостановить обучение при загруженности.

Недостатки:

• материалы доступны только в течение двух месяцев.

Программа обучения:

• Agile-подход: его суть и бизнес-выгода для компаний
• Роль Scrum-мастера: зона ответственности и влияние на команду
• Влияние Agile на мотивацию и удовольствие от работы
• Антипаттерны Agile-команд: типичные ошибки и их решение

Ознакомиться с полной программой >>>

8. AGILE & SCRUM: теория и практика внедрения в бизнес | Знанио

Курс предлагает системное изложение методологии Scrum с разбором рабочих стратегий и тактических приемов. Автор детализирует ценностную основу Agile, охватывая теоретические аспекты от исторических предпосылок до современных практик. Практический блок включает освоение техник формирования продуктового бэклога, создания рабочих команд и инструментов планирования и контроля разработки.

• Стоимость: 299 рублей
• Длительность: от 1 дня
• Формат обучения: текстовые и видеоматериалы, практика
• Сертификат: сертификат установленного образца

Кому подойдет:

• руководителям;
• новичкам.

Преимущества:

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

Недостатки:

• сжатое обучение.

Программа обучения:

• Agile INTRO
• Введение
• Сравнение
• SCRUM
• AGILE
• Внедрение
• Выводы

Ознакомиться с полной программой >>>

9. Agile-методологии в управлении проектами | City Business School

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

• Стоимость: 19 990 рублей
• Длительность: 21 день
• Формат обучения: видеоматериалы, тренажеры, тестирования
• Сертификат: сертификат установленного образца

Кому подойдет:

• менеджерам проектов;
• руководителям любого уровня.

Преимущества:

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

Недостатки:

• редкие проверки заданий куратором.

Программа обучения:

• Введение в основные agile-фреймворки: Scrum, Kanban, XP, Lean
• Базовые понятия и принципы гибкой методологии
• История создания и эволюции agile-подхода
• Сильные и слабые стороны agile для бизнеса
• Scrum-методология: принципы, артефакты и события
• Kanban-метод: визуализация, лимиты и управление потоком
• Сравнение Scrum и Kanban: критерии выбора подхода
• Agile-трансформация: этапы внедрения в проекты

Ознакомиться с полной программой >>>

10. Методология Agile | Lectera.com

Курс дает практическое освоение Agile-управления и SCRUM-методик. Вы изучите механизмы эффективного проектного управления для достижения конкретных результатов в бизнесе и разработке продуктов. При этом сохранятся преимущества гибкого формата работы — мобильность, творческая атмосфера и командная сплоченность. В программе: принципы проектного управления, методы быстрого тестирования идей, методики планирования спринтов, проведение SCRUM-собраний и цели ретроспективы спринта.

• Стоимость: 3 650 рублей
• Длительность: 10,6 часов
• Формат обучения: видео, кейсы, практика, тестирования
• Сертификат: сертификат установленного образца

Кому подойдет:

• менеджерам;
• разработчикам;
• тестировщикам;
• новичкам;
• руководителям.

Преимущества:

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

Недостатки:

• программа дает базовые знания, но нет углубления в узкие темы.

Программа обучения:

• Ключевые аспекты управления проектами
• Применение Agile-методов в повседневных задачах
• Внедрение скрам в рабочие процессы команды
• Быстрое тестирование бизнес-идей и гипотез
• Развитие лидерских качеств и навыков
• Анализ продуктивности работы команды
• Основные понятия и термины Agile
• Стратегии эффективного планирования спринта
• Проведение ежедневных скрам-собраний
• Задачи и цели ретроспективы спринта

Ознакомиться с полной программой >>>

Еще 17 дополнительных курсов Agile и Scrum

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

• Интенсив Agile от Академии BELHARD. Участники интенсива освоят гибкие методологии разработки программного обеспечения с акцентом на их базовые принципы и ценностные ориентиры. Они изучат инструменты управления проектами и рисками, а также методы адаптации подходов под специфические условия. По окончании курса слушатели смогут целенаправленно улучшать коммуникационные процессы внутри команды и с заказчиками.
• Product Management: гибкие подходы Agile (Scrum), Lean и DevOps от УЦ Специалист. В рамках программы слушатели осваивают ключевые аспекты продукт-менеджмента и гибких подходов к разработке. Они изучат методы анализа рынка и конкурентной среды, управления продуктными требованиями и функциональностью. Особое внимание уделяется практическому применению Agile, Scrum, Lean и DevOps методологий в управлении продуктом.
• Agile - Scrum Foundation 1 от УЦ Специалист. Обучение построено на практическом применении Scrum через создание нового продукта в команде. Участники получат непосредственный опыт работы по данной методологии и оценят ее преимущества. Под руководством наставника они освоят инновационные подходы к решению проектных задач.
• Agile - Scrum Foundation 2 от УЦ Специалист. Программа знакомит с передовыми мировыми практиками разработки программного обеспечения, доказавшими эффективность. Основной акцент сделан на практических занятиях в формате ролевых игр с активным участием слушателей.
• Professional Scrum Master от Scrum.ru. Курс направлен на освоение принципов и методов эффективного управления проектами в Scrum. Выпускники получат инструменты для повышения результативности команд и достижения проектных целей.
• Agile Fundamentals Certification от ICAgile. Данная программа позволяет не только пройти обучение, но и получить международную сертификацию по основам Agile. Участники курса формируют глубокое понимание принципов гибкой методологии и immediately применяют полученные знания на практике через серию практических упражнений и разбор реальных кейсов.
• Agile и Scrum от ScrumTrek. В рамках этого обучения участники осваивают не только теорию, но и проходят полный цикл сертификации. Курс охватывает практическое применение различных гибких методологий разработки, включая Scrum, Kanban и XP. Особое внимание уделяется развитию навыков управления командой, анализа проектных показателей, а также техникам планирования и организации эффективного рабочего процесса.
• Agile и управление проектами от Mike Pritula. Эта программа предлагает комплексное изучение ключевых концепций и инструментов Agile-подхода. Слушатели детально разбирают такие аспекты как управление проектными рисками, построение эффективной коммуникации, обеспечение качества продукции и адаптацию к изменениям. Все теоретические модули подкрепляются практическими заданиями, которые можно immediately применять в реальной работе.
• Professional Scrum Master I: курс и симулятор от PmClub. Professional Scrum Master (PSM I) — профессиональный сертификат от scrum.org, которым обладают более 360 000 cкрам-мастеров по всему миру. Входных требований у PSM I нет, поэтому сертификат можно получить, даже если нет опыта работы скрам-мастером.
• Управление проектами по Agile от Rocket. Программа фокусируется на практическом применении Agile в управлении проектами. Слушатели учатся выстраивать рабочие процессы, распределять роли в команде, проводить все типы скрам-мероприятий: планирование спринтов, ежедневные стендапы, обзоры результатов и ретроспективы. Каждый модуль содержит практические задания для закрепления навыков.
• SAFe® Release Train Engineering от Agile LAB. Этот курс знакомит с принципами масштабирования Agile в больших организациях через методологию Scaled Agile Framework. Участники осваивают техники планирования и управления выпусками продуктов, а также инструменты эффективного взаимодействия со всеми заинтересованными сторонами проекта. Программа включает множество практических примеров из реальных проектов.
• Agile.Scrum от центра Андрея Плетнева. Практико-ориентированный курс, где участники учатся работать в скрам-команде, распределять задачи, проводить ежедневные встречи, планировать спринты и анализировать их результаты. Отдельные модули посвящены управлению проектными рисками и методам адаптации к изменениям в процессе разработки.
• Базовый Agile от ScrumTrek. Программа предназначена для начинающих и представляет собой первый этап международной сертификации ICAgile. Курс дает фундаментальное понимание Agile-методологии и prepares участников к дальнейшему профессиональному развитию в этом направлении. После завершения выдается сертификат ICAgile ICP.
• Методология Scrum от PM Exspert. Интенсивный трехдневный курс teaches эффективному сочетанию классического проектного управления по PMBOK® с гибкостью Scrum. Участники получают не только теоретические знания, но и практический опыт применения скрам-методологии в симуляции реального проекта.
• Agile и Scrum от Scrum Alliance. Программа Certified Scrum Master позволяет глубоко освоить ключевые концепции скрам-методологии. Обучение помогает улучшить коммуникационные процессы внутри команды и между командами, а также дает инструменты для проведения организационных изменений независимо от текущей роли в компании.
• Применение гибких технологий от Академии Айти. Курс помогает понять важность системного подхода в управлении разработкой IT-решений. Участники знакомятся с методологией Kanban, изучают техники визуализации рабочих процессов и инструменты управления ресурсами. Особое внимание уделяется практическому применению полученных знаний.
• Agile Project Management от Onagile Academy. Программа позволяет сравнить подходы к созданию команд в классическом проектном управлении и Agile-среде. Участники изучают методы подбора участников проекта, формирования эффективных рабочих групп и инструменты управления распределенными командами. Курс содержит множество кейсов из реальной практики.

Бесплатные курсы Agile и Scrum

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

1. Изучаем основы управления проектами по Agile за 3 дня от Skillbox. Если вам проще учиться короткими рывками — этот интенсив идеален. За три дня вы не только разберетесь в основах, но и сразу примените их в реалистичных рабочих ситуациях. Преподаватели-практики будут комментировать ваши решения — как если бы вы работали в настоящей команде.
2. Что такое Agile и зачем он нужен бизнесу от Нетологии. Этот курс — для тех, кто хочет понять саму суть гибких подходов. Вы узнаете, почему компании переходят на Agile, как это меняет работу команд, и какие роли появляются в процессе. Все объясняют на конкретных примерах, без заумных терминов.
3. Гибкое управление: как помочь бизнесу в условиях неопределенности от ScrumTrek. Отличный вариант для тех, кто работает в быстро меняющейся среде. Курс учит не просто следовать методологии, а гибко подстраиваться под обстоятельства — как раз то, что нужно в современном бизнесе.
4. Бесплатный мини-курс: Agile, Scrum, Kanban от Product Lab. Если хотите за один присест разобраться в трех основных подходах — вам сюда. Вс разложено по полочкам: что выбрать для ваших задач, как организовать команду и как управлять процессом от идеи до результата.
5. Agile. Вводный курс от Stepik. Для тех, кто любит учиться в своем темпе. Материалы доступны круглосуточно, можно возвращаться к сложным темам снова и снова. Отлично подходит для знакомства с темой.
6. Agile Product Owner Career Guide от Udemy. Мечтаете о роли владельца продукта? Этот курс покажет вам изнутри, что это за работа. Авторы делятся реальными вопросами с собеседований из крупных компаний — такая информация бесценна для тех, кто планирует карьерный рост.
7. Agile Project Management от Coursera. Для основательных людей, которые хотят разобраться до мелочей. Здесь вы поймете не только как работать по Scrum, но и почему именно так нужно работать. Отлично подходит для будущих скрам-мастеров и тех, кто хочет научиться вести команду через сложные проекты.

Бесплатные видеоуроки Agile и Scrum

Если вам нужна более гибкая и наглядная форма занятий, обратите внимание на подборку бесплатных курсов по Agile и Scrum в формате видеоуроков. Они позволяют изучать материал в удобном темпе, возвращаясь к сложным моментам. Этот вариант идеален для визуалов и тех, у кого нет возможности привязываться к жесткому учебному графику.

1. Весь СКРАМ за 14 минут от Dmitry Blinov. Автор обозревает такие темы, как PO, Developers, SM, продукт, Sprint, Backlog, инкремент, Daily, демо, ретро и так далее.
2. Что такое Agile? Scrum VS Kanban ДЛЯ НОВИЧКОВ от GeekBrains. СМ помощью полезного видеоурока вы с автором погрузитесь в историю и узнаете, как создавался Agile. Также вам расскажут про Scrum и Kanban — методы, по которым работают многие компании.
3. Что такое AGILE и SCRUM? от Noukash. В этом видео автор обозревает данные системы. Просмотр будет полезен всем, кто метит на карьеру в IT — специалистам и студентам.
4. Agile и Scrum на пальцах от АйТиБорода. В этом видео автор постарался простыми словами рассказать о гибких методологиях разработки программного обеспечения.
5. Рождение Scrum-команды от ScrumTrek. В своем докладе на AgileDays Елена поделилась несколькими важными выводами, которые помогли выстроить грамотную систему построения успешной Scrum-команды.
6. Agile & Scrum – знакомство и легкое погружение от ITVDN. В видео затрагивается отличие проектов, ориентированных на выпуск четкого объема работ в определенный срок, и реальностью. Выпуск будет полезен разработчикам и тестировщикам, работающим в Agile & Scrum, тимлидам и менеджерам, бизнес-аналитикам и другим специалистам, желающим лучше понять суть Agile подходов.
7. Гибкие методологии. Agile, Scrum, Kanban, Lean, Экстремальное программирование от Аспро Cloud. В некоторых отраслях важно подстраиваться под ситуацию. И в этом видео вы как раз рассмотрите семейство гибких методологий.
8. Кейсы применения Agile от ScrumTrek. Вводный вебинар курса Certified Agile Professional Online, на котором вы разберете кейсы применения Agile.

Что такое Agile и Scrum и в чем их основные отличия

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

Agile — это когда вы решили делать ремонт поэтапно. Сначала — кухня. Сделали, пожили, поняли, что розетки надо было расположить иначе, а вытяжку — посильнее. Внесли изменения, когда приступили к ремонту ванной. Потом — гостиная. Вы постоянно сверяетесь с реальностью, а не с устаревшим планом. Главная идея Agile — признать, что мир меняется, и настаивать на неподобающем плане — это глупо. Вместо этого лучше показывать результат, получать feedback и гибко адаптировать курс. Это не методология, а скорее набор убеждений о том, как лучше работать.

Scrum — это уже конкретная методология, которая помогает воплотить эти убеждения в жизнь. Если Agile — это философия «ремонт лучше делать поэтапно», то Scrum — это конкретный график с чёткими ролями и действиями.

В Scrum работа делится на короткие отрезки, обычно по 1-2 недели, называемые спринтами. В начале каждого спринта команда договаривается: «Что мы можем реально сделать за эти две недели?» Они берут задачи из общего списка пожеланий, называемого бэклогом, и обещают завершить выбранный кусок к установленной дате.

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

В конце спринта происходят два важных события. Сначала команда показывает готовый результат заказчику или пользователям и спрашивает: «Вам то, что получилось? Как двигаться дальше?» Затем команда проводит встречу без начальства, чтобы обсудить: «Как улучшить наш процесс? Что пошло не так? Может, мы взяли на себя слишком много задач или часто отвлекались?» Эта встреча называется ретроспективой и необходима для постоянного улучшения работы команды.

В Scrum есть чёткие роли: Владелец Продукта (отвечает за «что» делать, представляет интересы заказчика), Scrum-мастер (следит за процессом, помогает команде работать по правилам Scrum, устраняет препятствия) и Команда разработки (делает работу).

Как понять, что команде пора пробовать Agile-подходы

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

Когда непонятно, что в итоге получится и доволен ли заказчик

Вы несколько месяцев упорно трудились, сдали проект, а заказчик смотрит на результат и говорит: «Ну, это не совсем то, что я хотел»? Или вы сами в процессе понимаете, что создаете что-то бессмысленное, но останавливаться уже поздно. Это классическая ловушка долгосрочного планирования без обратной связи. Agile предлагает показывать результаты работы часто — например, раз в одну-две недели. Это позволяет быстро понять, туда ли вы движетесь, и вовремя скорректировать курс, пока не потратили полгода на не тот продукт.

Когда команда теряет мотивацию и тонет в рутине

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

Когда все идет по плану, но результат никого не радует

Это, пожалуй, самый коварный сценарий. Команда работает как часы, соблюдает все сроки, выполняет KPI, но итоговый продукт оказывается посредственным, неинновационным или не находит отклика у пользователей. Это сигнал, что вы оптимизировали процесс ради процесса, забыв о главном — ценности для конечного потребителя. Agile заставляет постоянно задавать себе вопрос: «Делаем ли мы то, что действительно нужно людям?» Работа короткими циклами с регулярной демонстрацией результатов помогает сверяться с реальностью и не позволяет надолго уходить в «автономное плавание», отрываясь от потребностей рынка.

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

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

Однако новое исследование от RAND Corporation бросает вызов устоявшемуся мнению о том, что Agile универсально подходит для всех типов проектов, особенно для тех, которые связаны с искусственным интеллектом (ИИ).

Столкновение Agile с реальностью ИИ

Исследование, проведенное RAND для Минобороны США, включило интервью с 65 специалистами по данным и инженерами, имеющими более 5 лет опыта в создании ИИ и моделей машинного обучения.

Эти профессионалы отметили, что ИИ-проекты часто сталкиваются с уникальными проблемами, которые Agile, со всеми его преимуществами, не всегда способен эффективно решать.

Одной из основных причин называют то, что такие проекты требуют значительных экспериментов и итераций.

В отличие от традиционной разработки ПО, где задачи и результаты могут быть достаточно предсказуемыми, в ИИ часто возникает необходимость пересматривать и корректировать подходы на лету.

Строгие требования Agile к планированию и структурированию могут ограничивать такую гибкость.

Когда гибкость оборачивается рутиной

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

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

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

Вывод: время переосмыслить Agile для ИИ?

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

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

Кстати, если вы ищете новые карьерные возможности, обратите внимание на вакансию системного аналитика в Сбере.

В этой статье я на понятных примерах расскажу про User Stories, Use Cases и их совместное использование при описании требований. Давайте разбираться.

User Story

User Story (или пользовательская история) — это подход к описанию возможностей ПО, который представляет собой короткие, независимые описания функциональности, составленные от имени конкретного пользователя.

Формат пользовательских историй можно описать формулой.

Сразу на примерах посмотрим, как из хотелок пользователей собирать требования в формате User Stories.

Пример 1

Студент хочет видеть полный список своих задач на главном экране университетского приложения

Пример 2

Пользователь интернет-магазина хочет иметь возможность добавлять товары в корзину

И формула, и перевод к её виду нормальных примеров кажутся простыми. Но, к сожалению, не все желания пользователей и заказчиков чёткие и адекватные, поэтому для создания хороших User Stories знания одной формулы недостаточно.

Пользовательские истории должны соответствовать критериям INVEST.

Пояснение ниже стоит сохранить и запомнить, потому что о нём часто спрашивают на собеседованиях 😉.

При несоблюдении этих критериев, User Stories могут превратиться в нечто, доводящее команду разработки до ужаса и истерик. И чтобы точно усвоить эти правила, вам нужно прочувствовать эту боль.

Время плохих примеров.

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

Как бы вы оформили их в User Stories? Отправляйте свои варианты в комментариях!

То, что не указано явно, можно додумать.

Пользователь должен иметь возможность просматривать список товаров из каталога по категориям и подкатегориям.

При добавлении товара в корзину пользователь должен видеть динамическое обновление общей стоимости заказа.

Система должна предоставлять пользователю возможность отменить или изменить состав заказа до его оформления.

При покупке товара с помощью банковской карты пользователь должен видеть подтверждение успешного платежа.

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

После того, как мы разобрались с практикой, можем перейти к теории. Чем же этот подход хорош?

Заказчикам проще описывать свои пожелания в «пользовательских» формулировках, иначе начинается «ой, я эти ваши технические штуки не понимаю, давайте нормально». Поэтому User Stories отлично подходят для сбора требований в виде, который понятен и для команды клиента, и для команды разработки.

Так как требования должны быть сформулированы от имени конкретного пользователя, при формировании User Stories аналитик сразу выделяет пользователей и прочих заинтересованных в работе системы лиц и их требования к ПО. Это существенно упрощает дальнейшее определение ролей в системе и помогает расставить вашим задачам приоритеты.

Так, например, для интернет-магазина в пользовательских историях могут быть отражены запросы на возможность оформления заказа и оформления подписки на отсутствующие товары. Скорее всего, и для бизнеса, и для пользователей важнее  будет возможность оформления заказа. И если поставить две эти истории рядом и сравнить, то выбрать приоритетную будет проще.

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

Краткий формат записи выглядит очень общим и не включает в себя достаточно деталей, что может затруднить их понимание. Такие требования часто необходимо детально прорабатывать с помощью других подходов. К тому же из-за того, что User Stories в первую очередь описывают функциональные требования, использование только этого метода может затруднить работу с требованиями к производительности, безопасности и другими нефункциональными аспектами проекта.

Также необходимо понимать, что User Stories подходят не для всех типов проектов. В некоторых случаях, например, при работе над исследовательскими проектами или проектами с высокой степенью неопределенности, использование User Stories может быть неэффективным.

Так когда же их стоит использовать?

1. Когда требования к проекту меняются. User Stories помогают быстро адаптироваться к изменяющимся требованиям, поскольку они могут быть легко добавлены, изменены или удалены в процессе разработки.
2. При работе по методологии Agile. User Stories — основной инструмент в Agile-разработке, так как они фокусируются на ценности для конечного пользователя, способствуют итеративному процессу разработки и обеспечивают гибкость в планировании и реализации функциональности.
3. При необходимости вовлечения заинтересованных сторон. User Stories понятны и доступны не только для членов команды разработки, но и для заинтересованных сторон, таких как заказчики, менеджеры продукта и конечные пользователи.
   
4. При разработке продукта, ориентированного на пользователя. User Stories помогают сосредоточиться на потребностях и задачах конечных пользователей.
5. При работе в команде со смешанным составом. User Stories предоставляют общий язык для команды разработки, который понятен как разработчикам, так и не-техническим участникам процесса, таким как менеджеры продукта или тестировщики.
6. При необходимости верхнеуровневого описания сложной функциональности. Пользовательские истории используются не только для конкретизации небольших функциональных требований, но и для краткого описания более сложных и крупных фрагментов функциональности. Иногда анализ стоит начинать с формулировки основных пользовательских сценариев и требований в виде User Stories, чтобы чётко определить цели и потребности пользователей, а затем доработать эти истории другими подходами.

Резюме:

User Stories — это мощный инструмент для анализа требований, который акцентирует внимание на потребностях пользователей и создании ценности для них. Использование User Stories помогает создать прозрачное понимание о том, что должно быть разработано, и стимулирует эффективное взаимодействие между заказчиком и командой разработки. Этот подход отлично подходит для описания простых или верхнеуровневого описания сложных требований.

Use Case

Use Case (или пример использования) — это способ описания того, как определённый пользователь или система взаимодействует с программным продуктом для достижения определенной цели.

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

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

В отличии от User Stories, Use Cases представимы в разных форматах. Например:

• Текстовый формат включает в себя акторов (не путать с актёрами), цели, предусловия, сценарии и постусловия. Этот формат легко читается и понимается, но может быть менее удобным для больших объемов информации.
• Диаграммы Use Case, например, Use Case UML. В этом случае каждый сценарий представлен в виде отдельного прямоугольника с указанием его имени, а акторы и связи между ними могут быть показаны стрелками.

• Таблицы или матрицы. При необходимости можно записать текстовое представление в табличном формате. Например, под каждый use cases могут быть созданы отдельные таблицы с двумя столбцами, где первым выступает заголовок (акторы, сценарии и т. д.), а вторым описание конкретного use case.

Разберем ключевые элементы Use Cases на основе одного из вариантов структуры текстового представления.

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

Требования можно сразу собирать в формате Use Cases, а можно использовать этот формат для уточнения User Stories. Попробуем в текстовом формате описать «пример использования» для пользовательской истории, которую мы разбирали ранее.

User Story:

«Как студент, я хочу видеть список всех своих задач на главном экране приложения, чтобы быстро оценить свою текущую загруженность»

Use Case:

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

Чтобы попрактиковаться, предлагаю разработать Use Cases для тех же примеров, которые вы переводили в User Stories.

То, что не указано явно, всё ещё можно додумывать. Делитесь своими вариантами в комментариях!

Главное преимущество Use Cases в том, что они помогают аналитикам идентифицировать и собирать требования к системе на основе конкретных сценариев использования. Необходимо отметить, что помимо основной своей цели — сбора требований, использование use cases помогают с определением границ функциональности проекта.

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

Клиент приходит с требованием: «Хочу, чтобы в моем интернет-магазине был личный кабинет, как у всех».

Он же, когда вставили какой-то штатный вариант ЛК: «А где сумма по всем покупкам и список активных сессий? Мы обсуждали, что вы сделаете личный кабинет и оценили доработку. Пока не сделаете нормально, задачу принимать и оплачивать полностью не буду».

Команда:

Говоря о плюсах этого подхода, стоит удостоить внимания простоту создания тестовых сценариев: формат Use Cases уже подразумевает наличие описанного порядка действий пользователя. Также они способствуют формированию общего видения того, как должен работать и выглядеть конечный продукт и служат инструментом для проверки полноты требований к системе, позволяя идентифицировать пробелы и пропуски в функциональности, которые могут быть упущены при других методах анализа требований.

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

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

Резюме:

Use Cases — это структурированный метод анализа требований, который детализирует сценарии использования системы.

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

Что выбрать: User Stories или Use Cases

User Stories

• подходит для описания верхнеуровневых требований с фокусом на потребности и цели пользователей;
• используется для планирования и приоритизации работ в рамках итераций или спринтов;

• применяется в проектах, где требования могут часто изменяться.

Use Cases

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

В некоторых проектах целесообразно использование обоих методов вместе.

Например, можно начать анализ с User Stories для высокоуровневого описания ожиданий пользователей, а затем уточнять и детализировать требования с помощью Use Case. Выглядеть это будет примерно так же, как было описано в примерах этой статьи.

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

Выбор между Use Cases и User Stories зависит от конкретных условий проекта, потребностей заказчика, требований к системе и методологии разработки.

Не бойтесь экспериментировать и адаптировать выбранный метод анализа под потребности вашего проекта.

Применяя концепции и методологии, зародившиеся в теории вероятностей и статистическом анализе, давайте попробуем понять, как нормальное распределение (также известное как распределение Гаусса) может быть использовано для моделирования и анализа производительности разработки (velocity) в методологиях Agile и Scrum, а конкретно – предположить результат, который команда сможет получить в будущем. Но так же понять, является ли полученный результат нормой или есть отклонения, на которые команда должна реагировать.

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

Для наших изысканий возьмем реальные данные из одного моего реального проекта и его реальных результатов.

У нас имеется результаты последних спринтов в Story Points:

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

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

Для начала представим наши результаты в таблице и на графике:

1. Спринт 1 – 75.
2. Спринт 2 – 40.
3. Спринт 3 – 68.
4. Спринт 4 – 60.
5. Спринт 5 – 94.
6. Спринт 6 – 71.
7. Спринт 7 – 55.
8. Спринт 8 – 101.
9. Спринт 9 – 74.
10. Спринт 10 – 13.
11. Спринт 11 – 183.

При анализе данных, особенно если они содержат экстремальные значения (как, например, 13 или 183 в вашем наборе данных), важно рассмотреть, не являются ли эти точки выбросами, вызванными необычными обстоятельствами, и не должны ли они быть исключены из анализа.

Для расчета стандартного отклонения без учета экстремальных значений, нам нужно сначала идентифицировать, какие значения можно считать экстремальными. В контексте вашего набора данных, значения, такие как “13” и “183”, кажутся аномально низким и высоким соответственно. Давайте исключим их из наших расчетов.

Далее нам нужно пересчитать среднее значение без учета этих экстремальных значений. У нас есть следующие значения: 75, 40, 68, 60, 94, 71, 55, 101, 74 (исключены “13” и “183”).

Подсчитаем среднее:

Теперь вычислим квадраты отклонений от среднего и найдем их сумму:

Проведем подсчет:

Таким образом, сумма квадратов отклонений для данного набора данных (исключая экстремальные значения) составляет примерно 2801.17.

Теперь найдем исправленную дисперсию – среднюю сумма квадратов отклонений каждого значения от среднего значения. Мы уже вычислили сумму квадратов отклонений. Теперь, чтобы найти дисперсию, нам нужно разделить эту сумму на количество наблюдений.

Из предыдущих расчетов у нас есть:

• Сумма квадратов отклонений: 2801.17.
• Количество наблюдений (N): 9 (поскольку мы исключили два экстремальных значения).

Таким образом, дисперсия для данного набора данных составляет примерно 311.24.

Стандартное отклонение является мерой разброса значений относительно среднего значения (математического ожидания) и вычисляется как квадратный корень из дисперсии. Таким образом, стандартное отклонение для вашего набора данных составляет примерно 17.64. Это значит, что в среднем значения отклоняются от среднего (70.89) на 17.64 единицы.

Теперь давайте сделаем наложим тренд (красная линия) на наш график с учетом всех спринтов и попытаемся предсказать результат следующего спринта

Выходит мы можем ожидать результатом следующего спринта примерно 102 SP. Давайте учетом того, что стандартное отклонение для вашего набора данных составляет примерно 17.64 наш нормальный результат, округленный до целых SP, который будет в пределах нормы составит 84-120 SP.

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

Несколько лет назад Agile был в России редкостью. Про такой подход слышали и его применяли только в ИТ-разработке и банкинге. Сегодня в России работает уже немало Agile-коучей и Scrum-мастеров, а принципы гибкой философии распространяются и за пределами высокотехнологичных индустрий. Насколько может быть полезен Agile отечественному бизнесу, рассказывает Владимир Кац, Agile-коуч.

ПреимуществаAgile

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

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

ИТ и не только

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

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

В некоторых случаях Agile — единственно возможный подход в команде. Например, если речь идёт о недавно появившемся продукте. На что именно направить усилия? Куда устремляется рынок? На эти вопросы поможет получить ответы Agile.

Кому подходитAgile

Agile успешно применяют в e-commerce, телекоммуникациях, легкой промышленности, фарме и многих других отраслях. В 2022 году 34% ИТ-компаний и финансовых организаций использовали Agile, говорится в исследовании ScrumTrek. При этом 6,5% компаний (практиковали такой подход) были из сферы торговли, 5% пришлось на телеком-компании, 4,7% — энергетика, 4,5% — промышленная отрасль.

Чек-лист:подходит ли Agile вашей компании

1. Компания работает в условиях высокой неопределенности: выход на новые рынки, создание инноваций, поиск новых продуктовых решений и др.
2. Предметная область бизнеса позволяет экспериментировать.
3. Команда готова к масштабным изменениям внутри: способна адаптироваться к новой корпоративной культуре и ценностям.
4. Руководство хочет принимать непосредственное участие в изменениях и готово выделить ресурсы для обучения сотрудников.

Как обучитьсотрудников работать по Agile

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

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

Поэтому стоит рассмотреть гибридный подход, который совмещает достоинства обоих вариантов: комбинировать записанные лекции, которые можно посмотреть в любое время, и групповые практические занятия с участием экспертов. При этом обучение не должно заканчивается прохождением курса. Идеально, если заключительная часть обучения — это менторство и индивидуальное наставничество. Например, Группа «Иннотех» запустила Школу Scrum-мастеров, чтобы обеспечить себя как организацию из тысяч разработчиков нужным количеством специалистов, которые выполняют критическую роль для организации эффективной работы Agile-команд.

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

Комбинируя разные активности, удалось перераспределить нагрузку Agile-коучей и направить часть их рабочего времени на менторство и индивидуальную работу со Scrum-мастерами. В результате получилось выделить до 100 часов в месяц на дополнительные консультации. Такое перераспределение в пользу менторства повысило эффективность работы коучей, выровняло учебный процесс и в целом подняло качество обучения на новый уровень. До перехода на гибридное обучение с менторской программой доля прошедших тестирование и успешно выполнивших первую рабочую задачу составляла 12%, а после она увеличилась до 100%. Количество выпускаемых ежемесячно Scrum-мастеров возросло с 25 до 50 человек.

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

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

Эти инструменты позволяют описать то, как будет работать продукт и как пользователи будут с ним взаимодействовать. Чаще всего получается довольно объемный документ или набор документов, где описаны функциональные и нефункциональные требования, варианты взаимодействия (use case diagrams) и чек-листы для тестирования. Что же из этого лучше с точки зрения разработчика? В идеале – это готовый прототип программного продукта, демонстрирующий, как пользователь взаимодействует с ним, что именно требуется разработать, как и в какой последовательности должны появляться окна для заполнения информации. Остается только открыть текстовый документ, чтобы в нем свериться со свойствами атрибутов. Увы, чаще всего из-за нехватки времени и желания сэкономить многие команды пренебрегают созданием такой модели.

Второй, не менее популярный, метод — это описание функционирования продукта с помощью нотаций ARIS eEPC и BPMN 2.0. Чем же они удобны?

Преимущества ARIS eEPC – простыми словами

Нотацию ARIS eEPC разработал основатель IDS Scheer Август Вильгельм Шеер со своими коллегами. Взяв за основу методологию IDEF3, он дополнил ее до модели EPC – расширенной цепочки процесса, управляемого событиями, которую позже стали называть «процессно-событийная модель» (дословно Event-driven Process Chain). Используемая для моделирования бизнес-процессов в инструментарии ARIS, она представляет собой последовательность событий и функций, отражающих логику выполнения взаимосвязанных действий, направленных на достижение определенного результата. По сути, если созданная модель описывает функциональность разрабатываемого ПО, то она является инструкцией для разработчика.

Посмотрим на основные компоненты данной нотации:

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

Событие – описывает состояние процесса, которое является существенным в рамках этого процесса и оказывает влияние на этот бизнес-процесс или контролирует его дальнейшее развитие

Операторы «И», «Или», «Исключающее ИЛИ», служат для развилок по какому сценарию далее пойдет выполнение сценария в зависимости от того. что выберет пользователь или какой будет вариант ответа на вопрос.

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

IT system используется для отображения на диаграмме некоторой информационной системы, её модуля или даже отдельной функции ИС, поддерживающей выполнение функции, с которой её связывают в модели.

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

Функции в модели ARIS EPC запускаются событиями: например, «Поступила заявка на рассмотрение». Событиями они и оканчиваются: например, «Запрос удовлетворён» или «Заявка отклонена». Если в результате исполнения функции имеется только один вариант дальнейшего выполнения бизнес-процесса, т.е. в результате формируется только одно событие, после которого идет следующая функция, – событие между этими функциями может не рисоваться. В Интернете можно найти множество статей на данную тему и детально познакомиться с данной нотацией.

Какое преимущество она имеет с точки зрения разработчика? Лично мне нравится работа с данной нотацией потому, что я вижу, какие окна программы могу создать, что расположить на них, где сделать развилки с вариантами выбора, разместить загрузчики файлов и т.п. Мне остается только посмотреть типы полей и ограничений, чтобы создать модель базы данных и разместить соответствующие компоненты в окнах программы. Нет необходимости в чтении обширной документации по продукту. Это очень удобно, особенно когда я попадаю в проект не в самом начале или подменяю коллегу, который заболел или в отпуске. С помощью этой нотации понять смысл продукта, как он должен работать, где искать ошибку в той или иной ситуации – быстрее и проще, чем смотреть пользовательские истории или документацию ПО.

Но есть и сложности. Чаще всего разработкой ARIS eEPC занимается бизнес-аналитик без опыта в программировании или создании баз данных. Поэтому многие моменты, которые он может посчитать очевидными и понятными, являются проблемами для разработчика. Вот наиболее типичные ошибки при составлении нотаций, которые я встречал:

Некорректное изображение самой цепочки работ

Последовательное использование двух функций одной за другой.

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

Пример из жизни: требование «Предоставить сведения о земельном участке». Без обозначения на нотации документа пояснения в виде «Предоставлен документ со сведениями о земельном участке» или «Введены сведения о земельном участке» сложно угадать, что нужно сделать: создать загрузчик для документов или все-таки поля для ввода реквизитов документа.

И самое опасное – когда нотацию строят не только сверху – вниз, но еще и слева – направо.

Чем же данные ошибки опасны? Основным ограничением проекта является время и трудозатраты. Последний вариант является самым рискованным, так как разработчик очень легко может спутать направления ветки сценария и спроектировать программу неправильно. Также могут не быть указаны дополнительные компоненты, такие, как «Документ», или события, поясняющие, что должно произойти после функции. В этих случаях разработчики тратят время на изучения всего пакета документов, чтобы определить, что же они должны сделать. Или им необходимо планировать встречу с аналитиком или владельцем проекта для получения разъяснений. В ситуациях, когда «проект должен быть сделан вчера» или необходимо исправить ошибку в течении нескольких часов, – иногда простые задачи превращаются в сложные. Данных ошибок можно легко избежать, если делать нотацию ARIS eEPC в соответствии с правилами.

Применение BPMN 2.0 в разработке ПО

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

В ответ на этот вызов международная организация BPMI (Business Process Management Initiative) разработала новый подход к управлению бизнес-процессами – BPM (Business Process Management) и предложила нотацию BPMN – систему условных обозначений для моделирования бизнес-процессов. В 2011 году в нее был внесен ряд улучшений и вышла версия BPMN 2.0, которая сегодня активно используется в бизнесе. Чем она лучше прежних нотаций? В ней стали использовать параметр «Время», на моделях бизнес-процессов стало возможно показывать события и множество моментов, которые ранее было сложно описать.

Но самое важное – на базе данной нотации разрабатываются системы Business Process Management System (BPMS). Программное обеспечение для управления бизнес-процессами (BPMS) помогает компаниям определять и развертывать автоматизированные бизнес-процессы, а также управлять ими. Оно заменяет трудоемкие операции, выполняемые вручную, на оптимизированные рабочие процессы в бизнес-приложениях. По сути, мы не только рисуем бизнес-процесс, но и используем его в работе нашего ПО.

BPMS используют различные BPM-движки. В нашем случае используется платформа Camunda, которая поддерживает BPMN, нотацию описания бизнес-процессов. То есть в BPMN можно нарисовать логику любой сложности, а движок её выполнит. Большинство процессных вещей, которые можно сделать в BPMN, делать в чистом коде дороже в десятки раз.

Camunda поддерживает последнюю версию Java и вообще любой JVM-язык — Kotlin, Scala, Groovy и т.п. Более того, в ней гораздо проще менять логику работы или исправлять ошибки и оперативно обновлять программное обеспечение.

В инструменте Camunda Modeler или его аналогах можно создать весь бизнес-процесс работы приложения и вставить программный код, который будет исполняться на каждом его этапе. Это существенно облегчает разработку модели бизнес-процессов, использование BPMS в решении задач. При использовании данного инструмента тоже необходимо придерживаться правил. К сожалению, их часто нарушают аналитики при разработке модели:

• Нотация должна идти слева-направо.
• Если используете цвета, делайте легенду: к какой группе относятся данные процессы.
• Подписывайте потоки, указывайте, какой из них выставляется по умолчанию, если есть несколько вариантов.
• Если несколько процессов выполняют одну функцию – объедините в группу.

Нотация BPMN нотации и реальный процесс в BPMS системе процесс могут различаться. Например, одно действие, указанное в документе как «Одобрить счет» может состоять из ряда операций, которые проще разделить на несколько последовательных процессов и разместить их последовательно. Это не считается ошибкой, но многие специалисты рекомендуют в таких случаях составлять подпроцесс и в нем помещать уже необходимые процессы. Это не всегда удобно. При отладке процессов легче найти ошибку, если все задачи расположены в одном процессе.

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

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

Также встречались случаи, когда процессы зависали в ходе выполнения из-за того, что был случайно удален поток, но из-за «загромождения» задачами, разработчик не видел этой потерянной связи между задачами. Если процесс рисовать слева – направо, то нет проблем с его пониманием и легко ориентироваться как в нем происходят развития различных вариантов использования.

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

Если вы не знаете, кто такие деврелы, то вкратце объясню:

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

Моё исследование состояло из семи частей:

• индивидуальные рабочие задачи;
• деврел-команда;
• метрики;
• профессиональное развитие и сообщество;
• компания (и в какой ситуации её люди сейчас);
• зарплаты, про которые многие спрашивали в прошлом году;
• и, разумеется, про самих деврелов.

В этой статье говорим про профразвитие и портрет участника.

1. Насколько выборка репрезентативна?
2. Распределение по полу.
3. Распределение по возрасту.
4. Распределение по опыту в Developer Relations.
5. Распределение по предыдущему опыту.
6. Технический бэкграунд.
7. Техническое образование.
8. Как отличить Developer Advocates от Developer Relations?
9. Распределение по профессиональному уровню.
10. Распределение по организационному уровню в компании.
11. Как деврелы официально записаны в трудовой книжке?
12. Распределение по странам.
13. Распределение по городам.
14. Где работаете сейчас?
15. Какие ресурсы наиболее эффективно помогают вам развиваться как DevRel-специалисту?
16. Какие именно телеграм-каналы помогают развиваться?
17. Остальные ресурсы, которые помогали в развитии.
18. За кем из русскоговорящих экспертов в DevRel сообществе вы следите?
19. Какие DevRel команды вы считаете самыми сильными в 2022 году?
20. Что самое сложное в работе деврела в 2022 году?
21. Какие сложные профессиональные вопросы у вас возникали в 2022 году?
22. Как вы видите свое дальнейшее развитие в профессии в ближайшие три года?
23. Что дальше?
24. Благодарности.

Насколько выборка репрезентативна?

Я постаралась связаться со всеми специалистами в области Developer Relations, до которых смогла дотянуться, включая тех, кто не является прямыми участниками этой сферы. Мой призыв к деврелам в Телеграме прочитали более 6 500 человек. Всего опросом поделились 60 источников. Вот несколько из них:

• Говорите громче!
• DevRel Community (закрытый чат
• 23derevo: чат и канал
• t.me/docops
• t.me/devrel_jobs
• t.me/cmblog
• DevRelAll
• репосты в ФБ и телеге от коллег по цеху (спасибо вам!)

В исследовании участвовали 89 специалистов по Developer Relations к концу 2022 года — это на 25% больше, чем в прошлом году. Большая часть ответов была получена в ноябре. Данные уже очищены от спама и нерелевантных комментариев. В выборку, по понятным причинам, попали только те компании, в которых уже есть хотя бы кто-то причастный к деврелу.

Надеюсь, в следующих исследованиях нас станет ещё больше. Чтобы не пропустить анонс, следите за моим каналом «Говорите громче!» или оставьте свои контакты — я сообщу о новом запуске.

Иногда сумма ответов больше 100%. Это значит, что в вопросе можно было выбрать несколько значений. No cheating!

Спустя месяц после запуска исследования мы с Женей Финкельштейн подготовили доклад для DevRelConf #6, который мы готовили на основе ответов 72 респондентов. Благодаря этому за декабрь удалось собрать ответы ещё 17 специалистов. Они не учтены в нескольких объёмных вопросах — количество опрошенных я указываю отдельно.

Портрет участника

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

Распределение по полу (89 респондентов)

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

Распределение по возрасту (89 респондентов)

Больше 40% участников оказались достаточно молодыми — от 26 до 30 лет. На втором месте коллеги в возрасте от 31 до 35 лет, и на третьем — от 36 до 40 лет. Не оказалось среди респондентов людей младше 20 лет и старше 50. Я делаю вывод, что в профессию приходят уже с каким-то опытом, и готовы оставаться в ней достаточно долго.

Распределение по опыту в Developer Relations (89 респондентов)

Я решила разбить варианты ответов на более мелкий шаг, чтобы график стал более показательным.

Средний (среднее арифметическое взвешенное) опыт работы в области developer relations сейчас составляет примерно три года. Люди с опытом менее года по-прежнему слабо участвуют в исследовании — вероятно, потому, что не считают себя достаточно опытными в сфере.

Распределение по предыдущему опыту (89 респондентов)

В прошлом исследовании я объединяла PR и Маркетинг. Это было не очень правильно, теперь у нас есть более точная картинка.

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

Некоторые респонденты указывали неожиданные области, такие как журналистика, книгоиздание и наука, они собраны в «Разном». Один респондент даже рассказал о том, что сразу стал деврелом, без предыдущего опыта.

Технический бэкграунд оказался необязателен (89 респондентов)

Я задала жёсткий вопрос об опыте работы в коммерческой разработке на полную ставку — хотя бы в течение года. Результаты показали, что у менее четверти опрошенных есть опыт написания кода. Это, конечно, заметная доля, но остальные 75% рассказали о том, что это не обязательно для начала работы.

Техническое образование — тоже (89 респондентов)

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

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

Как отличить Developer Advocates от Developer Relations? (89 респондентов)

Была гипотеза, что вопрос «Являются ли разработчики основными клиентами для вашей компании?» поможет разделить респондентов на две группы: Developer Advocates и Developer Relations Managers.

Мы предоставляли два варианта ответа: «Да, разработчики являются клиентами нашей компании (Developer First)» и «Нет, разработчики не являются клиентами нашей компании (Developer Plus)». Но нам это не помогло.

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

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

А вот вопрос «Какими задачами на внешнюю аудиторию вы занимаетесь большую часть своего рабочего времени?» как раз помог, особенно те варианты ответов, которые подкинул Антон Черноусов. Но об этом в следующей статье.

Распределение по профессиональному уровню (89 респондентов)

Разумеется, джуниоров по факту больше. Многие постеснялись участвовать в опросе, и даже мои пояснения в анонсах и предисловии не особо помогли. Если у вас есть идеи, как решить эту проблему, напишите в комментариях или мне лично.

Распределение по организационному уровню в компании (89 респондентов)

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

Как деврелы официально записаны в трудовой книжке? (89 респондентов)

Нейтральные формулировки всё ещё лидируют: руководитель направления и менеджер проектов. Но появились и новые, повторяющиеся, должности: менеджер по работе с IT-сообществами и менеджер по развитию бренда работодателей в сегменте IT. Если ни одна из них вам не нравится, можете выбрать из длинного списка ниже ?

Распределение по странам (89 респондентов)

63 участника опроса находятся в России. Также у нас есть коллеги с Кипра, Грузии, Германии и других стран.

Распределение по городам (89 респондентов)

41 участник опроса находится в Москве. 48 — в других городах, в основном в Санкт-Петербурге, Тбилиси, Казань, Екатеринбург.

Где работаете сейчас? (58 респондентов)

Только 58 участников указали свою компанию, в том числе 1С, 2ГИС, EPAM, IT_One, JetBrains, Karuna, Quadcode, Skillbox, SkillFactory, Sytac, VK, Yandex.

Профессиональное развитие

Какие ресурсы наиболее эффективно помогают вам развиваться как DevRel-специалисту? (72 респондента)

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

2021 год

2022 год

Какие именно телеграм-каналы помогают развиваться? (89 респондентов)

Дисклеймер: так как выборка смещена на те ресурсы, через которые я набирала респондентов, статистика — в мою пользу и наверняка искажает реальную картину.

Полный список со ссылками

• t.me/speakersclub
• t.me/My_DevRel
• t.me/devrel_ru
• DevRel Community (вход по приглашению от участника сообщества)
• @devrel_all
• t.me/devrel_sklad
• t.me/devrel_ru
• t.me/dododev
• t.me/channel_23derevo
• t.me/ux_writers_from_everywhere
• t.me/technicalwriters
• t.me/ozon_tech
• t.me/no_shame_facilitation
• t.me/leadgr
• t.me/KnowledgeConfChannel
• t.me/itbrand_rules
• t.me/ilyahov_smotrit
• t.me/docsascode
• t.me/devrel_jobs
• t.me/compot_me/
• t.me/avitotech
• Devrel Yerevan (вход по приглашению от участника сообщества)

Остальные ресурсы, которые помогали в развитии (36 респондентов)

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

Полный список со ссылками

• podlodka.io
• youtube.com
• zapuskzavtra.libsyn.com
• teamleadconf.ru
• hr-kafedra.ru/devrel/
• habr.com
• vc.ru
• ontico.ru
• highload.ru
• devrelweekly.com
• developerrelations.com
• conf.geecko.com
• writethedocs.org
• writers-in-tech.simplecast.com
• vk.com/frontendweekend
• t.me/speakersclub
• t.me/devrel_ru
• podcasts.apple.com/us/podcast/make-sense-podcast/id1417851966
• podcast.ru/1551786898
• mobiusconf.com
• maximilyahov.ru
• job.kolesa.kz
• ithrconference.timepad.ru/event/2120255/
• intercomm.media
• getinvolved.hanselman.com
• devrelxsummit.com
• DevRel Community (вход по приглашению от участника сообщества)
• Communityforpeople-Yana-Belova
• cmxhub.com/summit/
• bureau.ru
• blog.pragmaticengineer.com
• 13.codefest.ru
• @devrel_all

За кем из русскоговорящих экспертов в DevRel сообществе вы следите? (53 респондента)

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

Какие DevRel команды вы считаете самыми сильными в 2022 году?

Вопрос был необязательным и со свободным вводом. Всего были упомянуты 106 компаний.

Кстати, сейчас нанимают:

• event-менеджера в Avito;
• координатора программного комитета в Онтико.

Что беспокоило деврела в конце 2022 года?

Что самое сложное в работе деврела в 2022 году?

Искать докладчиков всегда было сложно, но в этом году стало труднее из-за кризиса, неопределённости и того, что нужно было поддерживать людей. Впервые стала заметной категория «Новые рынки».
Фан факт: в прошлом исследовании топ-темой был онлайн, а теперь наблюдаем проблемы с оффлайн мероприятиями.

Какие сложные профессиональные вопросы у вас возникали в 2022 году? На что не находилось очевидных ответов или было не у кого спросить? (72 респондента)

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

Появились вопросы относительно карьеры. Отрасль взрослеет, и люди хотят заботиться о своём развитии и будущем.

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

Новые вопросы:

1. С какого момента необходимо расширять команду?
2. Какие роли и в какой конфигурации нужны?
3. Перестройка структуры команды?
4. Как «измерять сотрудников», чтобы у руководства не было вопросов и сотрудники понимали, за что они получают деньги и куда они могут дальше расти?
5. Какую систему мотивации создать для адвокатов бренда работодателя?

Как вы видите своё дальнейшее развитие в профессии в ближайшие три года (72 респондента)

Оказалось, что вариантов у нас довольно много. Можно углубить экспертизу и понимание технологий, расширить зону влияния и отвечать не только за разработчиков, но и, например, за дизайнеров, или вообще начать управлять продуктом. Или стать менеджером, который управляет деврелами (некоторые уже успешно консультируют компании или менторят коллег). Или выйти на международный рынок. Есть и те, кто хочет сфокусироваться на собственной публичности (сапожники без сапог, привееееет!).

Что дальше?

Я планирую сделать цикл из 5 статей на основе проведённого исследования:

1. Профессиональное развитие деврела.
2. Кое-что про метрики.
3. Задачи и роли DevRel-специалистов.
4. DevRel-команды: сокращаются, расширяются или качественно эволюционируют?
5. Обезличенные зарплаты DevRel-специалистов.

Благодарности

Над этим материалом вместе со мной работали Даша Тиходеева, Илья Васильев, команда Tproger. Спасибо вам огромное, без вас этот проект не случился бы.

И у программистов есть инструменты, которые работают по этому принципу. Один из них — подход Domain-Driven Design, предметно-ориентированное проектирование. Мы в KozhinDev применяем DDD на практике и расскажем о его преимуществах в статье.

Что такое Domain-Driven Design

Domain-Driven Design — подход к проектированию ПО, в основе которого положено тесное сотрудничество клиента и разработчиков. Заказчик посвящает команду в бизнес-логику своей компании, объясняет, как устроена ее работа, участвует в проектировании сервиса. Основной принцип DDD — разделение приложения на домены.

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

В проектируемом веб-сервисе выделяют также основной домен — core domain, ядро продукта, его основную функцию. Так, если продолжить пример с перевозкой грузов: основная задача приложения — обеспечить доставку посылки из пункта А в пункт Б.

Домены в свою очередь делятся на субдомены — подобласти, которые отвечают за отдельные проблемы. Например, для сервиса грузоперевозок в качестве субдомена оформление заказа и выбор оптимального маршрута.

Для решения проблемы могут использоваться модели (model), которые описывают отдельные аспекты предметной области. Пример — сценарии пользовательского поведения на сайте. Человек открывает главную страницу, ему нужно заказать перевозку — он нажимает на кнопку «отправить груз».

Впервые подход Domain-Driven Design описал Эрик Эванс еще в 2004 году в книге

«Предметно-ориентированное проектирование (DDD). Структуризация сложных программных систем». Более краткое изложение принципов Domain-Driven Design можно найти у Вона Вернона в издании «Предметно-ориентированное проектирование. Самое основное», которое вышло в 2016 году.

Зачем нужен Domain-Driven Design

Мы использовали подход Domain-Driven Design для создания информационной системы «Абитуриент», которая автоматизировала работу приемной комиссии Сибирского федерального университета. Этот сервис включает в себя личный кабинет оператора, личный кабинет абитуриента, возможность подачи документов онлайн, приема документов онлайн и офлайн, двустороннюю интеграцию с Порталом Госуслуг и другие возможности. В процессе проектирования возникали все новые и новые потребности, архитектура сервиса разрасталась.

Такое разрастание функционала грозит образованием «больших комков грязи» — big balls of mud. Это крупные массивы запутанного, неряшливого кода, которые снижают производительность сервиса и осложняют его поддержку в будущем.

Объясняем на котиках: если у длинношерстного кота образуется колтун, то ему будет некомфортно. Комок шерсти будет мешать ему в повседневной жизни, мешать. Можно попытаться распутать колтун, но обычно это не так уж легко и доставляет животному еще больше дискомфорта. Чаще всего спутанную шерсть приходится просто срезать и следить, чтобы она не путалась впредь.

Также и с крупными веб-сервисами: «комок» некачественного кода мешает ему нормально работать, даже разработчики не всегда могут разобраться в его назначении, но взять и «вырезать» его — сложная задача. Поэтому лучше предотвратить его появление на этапе проектирования — например, использовать DDD.

Основные инструменты Domain-Driven Design

Для упрощения работы со сложными системами в DDD используются:

• Ubiquitous Language — язык описания или универсальный язык. Он нужен, чтобы описание домена и моделей было однозначным, не возникало противоречий.
• Bounded Context — ограниченный контекст. Ограниченная предметная область, которая отвечает за строго определенный функционал, со своим языком описания.

Основной принцип работы по DDD — разделение предметной области на ограниченные контексты со своими языками описания. Так, без DDD модель «пользователь» описывает все роли, и поэтому очень разрастается. Она описывает и посетителей сайта (имя пользователя, адрес), и данные авторизации (когда пользователь зашел в систему), и разграничения прав доступа для модераторов. В DDD такая модель разделяется на отдельные модели для каждого ограниченного контекста, чтобы не возникало путаницы. Посетитель, модератор, администратор — это разные типы пользователей, каждый из которых относится к своей области.

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

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

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

• небольшие и понятные контексты;
• каждый контекст отвечает за свой свою подобласть;
• ясные и лаконичные названия сущностей.

Связи в Domain-Driven Design

Чтобы сервис корректно работал и выполнял все свои функции, между модулями системы нужно настроить связи. В DDD-подходе это называется context mapping.

Нужно помнить, что:

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

Типы связей в Domain-Driven Design:

• Партнерство (Partnership), общее ядро (Shared Kernel): используются для тесно связанных между собой контекстах. Обычно самые быстрые в реализации, но несут в себе опасность связанности кода. Механизм партнерства похож на слаженную работу команд для разработки фронтенда и бэкенда: они обмениваются информацией, подстраиваются под изменения друг друга. Общее ядро подходит для ситуаций, когда нужно использовать в разных контекстах одну сущность, например, пользователя.
• Потребитель-поставщик (Customer-Supplier), конформист (Conformist): нужны, когда для разных контекстов приходится использовать один универсальный язык. Потребитель-поставщик похож на партнерство, но выделяется главная команда — поставщик, которая не всегда отзывчива к изменениям другой команды — потребителя. Конформист — когда потребитель вообще никак не может влиять на то, что отдает ему поставщик.
• Антикоррупционный слой (Anticorruption Layer): применяется, когда нужна прослойка между универсальным языком источника данных. Более безопасный вид связи между поставщиком, у которого меняется API, и потребителем. Все данные от поставщика проходят через прослойку, меняется только она, а структура потребителя остается неизменной.
• Open Host Service, опубликованный язык (Published Language): используются на стороне источника данных для стандартизации протокола обмена и приема. Некоторые авторы разделяют их, но мы рассматриваем, как один вид. Эта связь обратна антикоррупционному слою: поставщик поддерживает постоянный API, чтобы потребителю не приходилось постоянно обновлять свои данные.

Кроме прямого вызова методов объектов, связи в DDD можно реализовать также с помощью механизма сообщений Messaging, событий — Domain Events, Event Sourcing. Доступно также создание сценариев через Event Storming. Домены реагируют на событие по-своему: например, если событие «пользователь создан», то модуль биллинга может создать ему аккаунт для оплаты, модуль отправки сообщений — прислать приветственное письмо.

Недостатки Domain-Driven Design

Главная сложность подхода DDD — необходимость работать в тесной связке с клиентом. Не все заказчики готовы выделить людей в своем штате, которые будут вводить разработчиков в курс дела, оставаться на связи, участвовать в проектировании. Если клиенту нужен сложный, многофункциональный продукт, то придется объяснять ему важность участия.

Также, если команда ранее не работала по Domain-Driven Design, то программистам придется изучать новые для себя инструменты, адаптироваться к более плотному сотрудничеству с клиентом. Например, разработчикам при использовании этого подхода нужно внимательнее подходить к созданию и изменению сущностей и связей, к переименованию.

Подведем итог: что дает клиенту и разработчику DDD

Сложное практически всегда состоит из простых частей, соединенных простыми связями. Благодаря применению Domain-Driven Design код веб-сервиса или мобильного приложения получается несложным и понятным. В итоге упрощается его чтение, а значит — поддержка и развитие сервиса в будущем.

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

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

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

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

Более того, по содержанию можно искать только текстовые файлы.

Ссылка на проект — тут.

Структура содержания информации

Структура папок представляется собой в виде дерева. Мне это не нравится, потому что каждая папка может содержать только определенные файлы, если не учитывать копирование и ссылки.

Так же это можно представить с примером из реальной жизни, для того, чтобы найти зелёное свежее яблоко сорт «Девственный». Необходимо найти отдел с фруктами, затем отдел с яблоками, затем ищем зеленные, затем сорт, ну там ещё их на свежие, не свежие фасуют в этом воображаемом примере и наконец найти нужное apple.

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

А почему бы об этом просто не попросить прихвостня (они уже у всех есть, правда?): «Принеси мне зелёное свежее яблоко».

Как сразу становится удобно!

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

А вот если мы не знаем существуют ли яблоки вообще, то спрашиваем прихвостня:

— Яблоки есть?

— Есть, господин! Сотни, игрушечные, красные, гнилые….

— Мне нужно свежее яблоко.

— Понял! Есть красное свежее яблоко «Сирота», красное свежее яблоко «Курага», …

— А что насчёт зелёного свежего яблока.

— Есть! Зелёное свежее яблоко «Пух-тибидух» и Зелёное свежее яблоко «Девственный».

— В таком случае, принеси мне, пожалуй, Зелёное свежее яблоко «Девственный».

— Да, сэр.

Вот последняя фраза как раз таки и стала названием приложения. Как ответ на команду пользователя — «Yes Sir».

Возвращаясь к яблокам. Заметили, что в первом случае нужно искать яблоки не пойми где, а во втором мы задаём уточняющие условия к запросу?

Приведу пример более реалистичный. Есть папка с музыкой и подпапки для разделения на жанры. Но что если в какой-то момент мне захочется послушать французскую музыку не зависимо от жанра. Вот тут то и вся проблемность древовидной структуры папок вылазит. Можно конечно, как советовали на форумах, создавать отдельные папки под язык произведения и кидать ссылки, но опять папки…

А вот, что произойдет, если каждому файлу установить теги с жанром, языком, ну и конечно что это музыка, песня.

В этом случае возможно группировать, сортировать музыку гораздо гибче. Например, скомбинировав 3 тега: французская, русская, рок можно получить то, чего стандартными средствами Windows не возможно, ну или я чего-то не знаю.

Попытки найти готовое решение

Первой идеей было воспользоваться «тегированием» файлов, папок. Таким образом можно искать информацию комбинируя теги, не зависимо от порядка слов. И лучшими приложениями для этого, могу выделить XYplorer и Tagging for windows. Первая из себя представляет отдельный файловый менеджер с опцией тегирования. Второе приложение — дополнение к стандартному файловому менеджеру. Однако они позволяют искать файлы только на ПК и конечно нельзя написать как в Гугл поисковике запрос близкий к пользователю, а алгоритм уже бы сам выбрал из запроса теги и отсортировал информацию по приоритету. В последствии удалил обе, они подвисали и крашились частенько (возможно дело в моих надстройках Windows, не хочу делать анти пиар этих отличных программ).

Визуальный поиск

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

Желаемый функционал

Я подумал, что было бы отлично разработать приложение, которое бы подходило по таким критериям:

1. Можно использовать с любого устройства без возможности подключения к интернету.
2. Поиск личной информации настолько быстро, насколько это возможно.
3. Поиск должен быть простым как Google Search.
4. Возможность сохранить всю текстовую информацию в текстовый файл.

Выбор технологий

1. По первому пункту из желаний было решено разработать веб приложение, так как с любого устройства, на котором есть браузер, можно получить к нему доступ. Данные хранятся в localstorage браузера, но при открытии сайта сразу выгружаются в переменную для обеспечения лучшей скорости.

Для синхронизации данных с другим устройством, браузером я взял базу данных mysql от 000webhost бесплатно, но потом перестал использовать из-за ограничений на объем. Сейчас единственный способ для обновления пользовательских данных — импорт и экспорт файла. Однако я делаю это очень редко, т.к. в основном пользуюсь только со смартфона. Что касается офлайн режима — я использовал serviceworking. Необходимо только один раз зайти на сайт, чтобы все ресурсы сайта загрузились и дальше использовать полностью офлайн из браузера.

2. Быстрый поиск.

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

Итак, по ключу «теги» у нас будет храниться массив из символов(слов) для конкретного блока информации.

Сразу возьмём пример блока.

Название: как создать сайт.

Действие: показать информацию.

Содержимое: берём html, добавляем js и украшаем css.

Теги: создание сайта, веб программирование, верстка.

Массив из тегов формируется из текстов полученных с полей ввода для тегов и названия. Каждое слово это тег, разделять можно запятой и пробелом. Была идея конечно сделать как на Ютубе, теги как словосочетания, но я решил остановиться на более широкой выдаче по ключевым словам. Из примера блока выше массив тегов будет таким: [«как», «создать», «сайт», «создание», «сайта», «веб», «программирование», «верстка»].

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

3. Итак, при вводе запроса проверяется есть ли слово в хранилище тегов, если да, то блок добавляется в массив на отображение.Теперь нужно отсортировать по приоритету. Чем выше результат в выдаче, тем более он подходит запросу. Это я реализовал с помощью количества ключевых слов в запросе, чем больше слов из запроса содержится в массиве тегов блока, тем более блок приоритетнее.

4. И насчёт сохранение в файл совсем кратко. Можно сохранять и импортировать файл в виде json.Так же мой опыт с использованием ВКонтакте как поисковик по изображениям дал мне идею для возможности добавлять изображение к каждому блоку при желании.

Итоги

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

Ответвление в другие проекты

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

Послесловие

Буду рад любым комментариям. Узнать ваше мнение по поводу идеи. Полная ли это ерунда. Или, в чем я почти не сомневаюсь, есть уже приложения с подобной реализацией. Спасибо!

1. Agile vs современный мир
2. О важности командной работы
3. Роли, неофициальные лидеры и условия
4. Выстраивание общения
5. Выгорание и снижение мотивации
6. Главный принцип создания эффективной команды

Agile vs современный мир

В теории внедрение Agile начинается с изучения манифеста с 12 принципами разработки. Кстати говоря, их придумали 17 человек, собравшихся в начале 2001 года в городе Сноуберд, штат Юта. Они были обеспокоены, что в разных компаниях по-разному представляют оптимальный процесс разработки программного обеспечения. Но один вывод был общим для всех: компании настолько сосредоточены на избыточном планировании и документировании циклов разработки ПО, что уже неспособны эффективно и вовремя решать задачи клиентов.

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

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

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

О важности командной работы

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

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

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

По итогу в команде организовался «самоназванный лидер», причём именно «самоназванный». Как выяснилось, по факту какими-то лидерскими качествами он и не обладал, всё, что делал: раздавал ЦУ и возмущался, если что-то было не так, как он считал нужным. Влезал в создаваемые рабочие процессы и вносил лишь сумятицу. Никого не напоминает?

Вдогонку пошли конфликты, наезды, поклёпы, полураспад команды, дотаскивание со скрипом того, что осталось. Результат — кое-как и кое-что вынесли в «прод», получили по 4 балла и разбежались, перекрестившись, что это закончилось.

В чём тут мораль? Да, наверное, в том, что правила, описание процессов и прочее — не главное в командной работе. Главное — это именно командная работа. Ответственность всей команды, а не одного конкретного её члена, помощь в сложных ситуациях и прочее. К сожалению, в реальности далеко не всегда так получается. И это печалит, потому что этому очень мало уделяют внимание.

Роли, неофициальные лидеры и условия

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

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

При этом условия работы, о которых также говорится в манифесте Agile, должна создавать сама команда.

Выстраивание общения

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

Можно внедрить довольно простые принципы коммуникации в команде. Сейчас большая часть общения проходит в чатиках, и тут многое зависит от их состава. Где-то нужно поофициальнее — когда в участниках продукт-овнеры, руководители. А в иных стоит и неформально — вспоминая наследие Нассима Талеба, можно и выматериться, если так информация дойдёт более точно до собеседников.

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

Про топ-менеджмент сложно найти универсальные стратегии коммуникаций. Но точно могу сказать, как с ними не нужно общаться. Точно не нужно подключать их к темам из серии «в туалете закончилась туалетная бумага, мне не выдают ручку, почему мне выдали монитор 27″, а не 4К».

Выгорание и снижение мотивации

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

Расскажу собственную историю. Больше года я работал в режиме с 9 до 23 в офисе. Как следствие, уходил из дома, когда дети ещё спали, а приходил — когда они уже спали. Видел их в лучшем случае только на выходных в тот небольшой период, когда не отсыпался.

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

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

Шли годы, и при очередном проекте с жесточайшими сроками, оглядываясь на прошлый опыт, я пришёл к такому графику:

• с 9 до 18 — стандартный рабочий день в основном с акцентом на встречи, обязательные задачи и прочее;
• с 18 до 22 или 23 (по ситуации) — личная жизнь, дети, семья, друзья, уроки, посиделки;
• с 23 до 2 или 3 (по состоянию и критичности задач) работа над какой-то текучкой, которая, с одной стороны, не требует большого количества умственных затрат, а с другой — отнимает довольно много времени, и если её не делать, количество задач скопится до необозримых размеров.

Но этот режим подходит мне как «сове». Я отказался от залипания в YouTube или книжку в пользу работы. Не удивлюсь, если найдутся «жаворонки», которым по кайфу будет работать в период с 6 до 9 утра, ещё до начала стандартного рабочего периода.

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

Главный принцип создания эффективной команды

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

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

Можно ли избежать страха и ненависти как клиента, так и конечных пользователей? Равно как и потери значительной части времени специалистов от общего количества часов разработки? Мы в агентстве CHILLICODE считаем, что да. И в этом нам может помочь применение методологии CI/CD.

Непрерывная интеграция (Continuous Integration, CI) и непрерывная поставка (Continuous Delivery, CD) представляют собой культуру, набор принципов и практик, которые позволяют разработчикам чаще и надежнее развертывать изменения программного обеспечения.

В свое время Генри Форд перевел создание автомобилей от ручной сборки к поточному конвейерному производству, перевернув тем самым промышленность своего времени. Принцип действия CI/CD (Continuous Integration & Continuous Deployment) в чем-то похож на конвейер: методика выполняет интеграционную функцию, включая различные типы автоматических тестов на каждом этапе, с последующей доставкой и развёртыванием кода в готовый продукт для конечного пользователя.

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

Многим клиентам, чей формат проекта подразумевает регулярные обновления, мы предлагаем работать с нами вместе с настроенной системой CI/CD. Потратив немного времени на старте на настройку окружения для непрерывной интеграции, мы сократим риски и сможем предложить клиенту высвободившиеся часы на более сложные задачи.

Какие этапы релиза можно автоматизировать?

Тестирование и контроль качества

Конечно же, об этом речь должна пойти в первую очередь. Тестировщиков нельзя полностью заменить, но львиную долю повторяющихся проверок можно автоматизировать путем модульного и регрессионного тестирования. Мы предлагаем автоматизацию в квадрате. CI/CD имитирует среду выполнения конечного сервера и запускает тесты автоматически, чтобы подтвердить работоспособность программного обеспечения и полностью исключить возможность выпустить в релиз продукт при возникновении ошибки. И клиент всегда будет уверен, что обновление не повредит работоспособности проекта.

Сборка и упаковка кода

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

Открытая отчетность

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

Как обезопасить релиз?

В каких местах могут возникнуть проблемы?

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

Как предохраниться от логических ошибок функциональности и багов?

Чтобы полностью исключить ошибки при деплое стоит комбинированно подойти к каждой итерации разработки продукта. Мы в CHILLICODE проводим релизы проектов в 5 этапов:

1. После разработки новой фичи разработчик создает запрос на слияние ветки с новой функциональностью в основную ветвь приложения.
2. Тимлид проекта перед слиянием проверяет качество его кода и при возникновении проблем отправляет код на доработку.
3. После принятия запроса на слияние приложение проходит несколько этапов автоматического тестирования, анализа качества кода и разворачивается на нашем стейдж сервере.
4. Выделенный QA специалист дополнительно проверяет всю функциональность приложения на стейдж серверах перед показом клиенту.
5. И уже после одобрения клиентом всех правок мы отправляем приложение в релиз.

Что делать если критическая ошибка все равно осталась незамеченной и попала в прод?

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

Итого

При работе с CI/CD мы имеем:

• Сокращение действий для деплоя до одного клика.
• Снижение рисков появления потенциальных ошибок.
• Автоматизация модульных и регрессионных тестов.
• Щепетильный контроль качества кода.
• Контейнеризация приложений и исключение различий среды разработки со средой выполнения.
• Возможность моментального отката версии приложения при возникновении критических ситуаций.
• Общее сокращение времени разработки на 10-20%.

Внедряйте CI/CD в свои проекты, как это делаем мы в агентстве и пользуйтесь на здоровье. Если вы все еще сомневаетесь или остались какие-то вопросы, пишите комментарии и мы постараемся ответить.

Вот уже несколько лет, мы плотно работаем по адаптированной, под свои внутренние и проектные процессы, Scrum методологии.

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

Модель as-is в действии

Версия продукта (Релизность)

Это отправная точка нашего пути. План выпуска релизов формируется в предшествующем текущему году.

Версии мы ведём в формате гг.нн, где гг — год, нн — номер версии. Например, первый релиз 2020 года будет под номером 20.1, затем 20.2, 20.3 и т. д. Такой формат очень удобен, во-первых, для ведения историчности, во-вторых, для планирования задач в разрезе года.

Согласно плану выпуска в backlog Jira SM заводит версии:

Постепенно у бизнес-заказчика формируется понимание о реализации глобальных доработок в привязке к версиям. В течение года составы версий могут меняться. Конкуренция, различные факторы, влияющие на бизнес, новые открытия, технологии и прочее, и прочее находят отражение в глобальных задачах. Вчера бизнес планировал запустить версию в 3-м квартале 2020 года (версия 20.10), сегодня аналитики, проведя сильные исследования, говорят бизнесу поторопиться и запускаться во 2-м квартале (20.4).

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

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

Глобальные задачи

Здесь из самой формулировки ясно, что есть задачи, которыми говорит бизнес. Ему нужен комфортный авто, четыре колеса, полный бак и музыка хорошая. А что там под капотом, разберутся технологи и ОТР.

В нашем случае бизнес говорит: к 4-му кварталу 2020 года будем взаимодействовать с новым вендором для обеспечения и покрытия следующих процессов: a, b, c … n. И ещё приходит с тремя-четырьмя десятками таких глобальных задач, с разными приоритетами и ожиданием запуска в релизы 20.1–20.xx.

Регистрируем в бэклог Jira глобальные задачи — бизнес-запросы (Business-request, BR) с описанием и привязками к версиям. BR заводим запросами с типом Epic, начиная выстраивать пирамиду, где вершина — версия продукта, а основание — задачи спринта. Epic’и, так же как и версии, заводит SM.

Груминг

Обрастаем фактурой. Теперь у нас есть списки версий и Epic’и с BR:

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

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

Оценивая задачи с командой, SM собирает свой бэклог, наполняя историями. Свой бэклог SM формирует через создание спринтов в Jira. Как говорил ранее, в главе описания процесса формирования бэклога: «Оставив “жмых” более чем из сотни задач, стали распределять по командам, там же, в бэклоге, путём создания новых спринтов с припиской Backlog. Данные спринты никогда не берутся в работу, а служат только для хранения историй/задач для последующего взятия в спринт». Это действие относится и к новым задачам.

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

Истории

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

Основное условие детализации BR на истории — одна история в один спринт. История представляет собой запрос с множеством конечных подзадач. Если понимаем, что оценка задач в истории больше чем на один спринт, дробим историю на части.

Теперь backlog приобретает такой вид:

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

На скриншоте видны не заполненные цифрами серые овалы, это как раз те истории, которые предстоит оценить в ближайшем груминге.

Внутри каждой истории множество подзадач:

Спринты

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

После взятия в достаточном объёме задач и историй для 2 недель спринт запускается

В приведённом примере отображены дробления историй: (Часть 2), (Часть 3). В бэклоге лежит ещё по парочке «Частей» в будущие спринты.

Согласно ЖЦ доски, исполнитель проводит задачи через все циклы: Нужно сделать → Разработка → Тестирование → Выполнено.

Что касается цикла тестирования: на старте спринта тестировщики берут разработанные задачи в соответствующем статусе «Тестирование». Окей, а как быть с задачами, которые к концу спринта будут только разработаны? Здесь мы идём по двум сценариям:

1. Если функциональность не затрагивает монолит, да даже если и затрагивает, но разработчик на 100% уверен в своём результате и находит поддержку тестировщика, то выходим на показ и тестим на горячую.
2. Если дорабатывалось что-то глобальное, то тестирование переносим на следующий спринт.

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

Процесс ведения спринта описан ранее. Остановлюсь на ещё одном инструменте в Jira, который использую в рабочем процессе и который будет полезен тем, кто держит руку на пульсе — Отчёт по спринту.

А именно — диаграмма погашения. Диаграмма отражает текущую ситуацию команд с задачами. Любые отклонения — сигнал к действию.

Наша адаптация гибкой методологии Scrum оказалась настолько гибка, что в каждый описанный выше шаг мы можем вносить корректировки согласно потребностям существующих и стартующих процессов производства. В то же время нам удаётся придерживаться вектора философии Agile и достигать синергии внутри проекта, команды и каждого из нас 24/7.

Я описал адаптацию Scrum к нашим процессам, но настоятельно рекомендую ознакомиться с первоисточником, возможно, пройти курсы и понять, как лучше интегрировать фреймворк у себя. Быть может, вам зайдёт чистый Scrum, без адаптаций? Пробуйте!

На этом всё. Ну а мы пошли засучивать рукава, брать маркеры, рисовать, генерировать и воплощать в цифру самые крутые вещи ?

Как составить правильное ТЗ?

Мое направление в департаменте разработки ПО занимается проектами автоматизации процессов документооборота. Мы разрабатываем и внедряем ECM, СЭД (вендорские решения и систему КСЭД 3.0, собственную разработку, которая включена в реестр российского ПО), электронные архивы, помогаем интегрировать эти системы с ERP, сервисами ЭДО, МЭДО, ССТУ и пр. И входим в пятерку ведущих российских игроков на рынке систем документооборота.

Каждый месяц мы отсматриваем примерно три-четыре десятка ТЗ от разных организаций и сами их пишем, например, для проектов внутренней автомаизации компании или оказывая консалтинг по составлению технического задания в рамках проектов обследования бизнес-процессов заказчиков. При этом мы готовим проектные решения, схемы бизнес-процессов as is / to be, а также экспертные рекомендации по их оптимизации. И здесь важно иметь ввиду возможность последующей реализации таких рекомендаций. Некоторые заказчики или другие игроки рынка ИТ об этом периодически забывают. И, бывает, открываешь техническое задание и не знаешь, как это все сделать исходя из описанного в ТЗ.

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

Иногда в руки попадают ТЗ на 2-3 страницы, и это может быть болью для потенциального исполнителя этого проекта, которому, например, нужно быстро принять решение о подаче заявки на тендер. Плюс при обсуждении такого ТЗ с заказчиком появляются крайне неудобные фразы типа: «Коллеги, мы же все описали в ТЗ, что вам непонятно?». При этом заказчик, который будет потом принимать работы по такому ТЗ, тоже будет в недоумении.

Поэтому этот документ должен быть понятен всем участникам процесса разработки. Правильное ТЗ на разработку автоматизированной системы – это практически-полезный документ, содержание которого понятно и ИТ-специалисту, и функциональному заказчику со стороны бизнеса, и владельцу этого бизнеса/топ-менеджеру, и, конечно, исполнителю проекта.

Нередко, уже взглянув на первые 3-4 страницы технического задания, можно определить, кто готовил — айтишник, будущий пользователь или бизнес-аналитик. И это плохо, потому что первые — нередко слишком углубляются в технические детали реализации проекта, вторые — концентрируются на деталях работы в системе, которой еще пока нет и не понятно, как она будет выглядеть по результатам опытной эксплуатации, а третьи — на том, как это повлияет на эффективность бизнеса. А еще сразу заметно, когда техническое задание написано наотмашь или когда весь результат проекта не столь важен.

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

Техническое задание (ТЗ) — это инструкция к применению для исполнителя и контракт для заказчика в одном лице. Перед началом работ обязательно погрузитесь в предметную область заказчика и, если есть возможность, проведите с ним интервью.

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

Если вы располагаете информацией об исполнителе, то стоит на этапе анализа обсудить с ним возможные варианты реализации, выслушать его экспертное мнение.

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

По итогам каждой встречи составляйте протокол принятых решений. Таким образом у вас на руках всегда будут аргументы для ответов на спорные вопросы.

При составлении ТЗ излагайте свои мысли от общего к частному, от проблемы к решению, от бизнес-требований к системным.

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

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

Не забывайте про оформление: структурированный текст — 50% успеха.

Техническое задание должно конкретно описывать конечное ожидание заказчика и при этом не быть перегруженным. Из правильно составленного ТЗ исполнителю обычно ясны ценность продукта (для чего это нужно? что это даст заказчику?), а также для какой аудитории планируется реализация. Не менее важно определить сроки и, если это какая-то крупная задача, декомпозировать ее на этапы, тем самым сформировав предварительный план действий, оценить состав работ и риски.

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

Типичные ошибки и подводные камни при составлении ТЗ:

• Не указана ЦА. Когда необходимо рассказать о пользователях продукта или какой-то отдельной его функциональности, заказчик часто углубляется в описание рабочих процессов, но никакой информации о ЦА или о том, какие ее проблемы необходимо решить, так и не обозначает.
• Нет конкретной цели. Из полученного ТЗ не всегда могут быть понятны приоритеты задач и назначение функций.
• Не определены ответственные с каждой из сторон. Очень важно, чтобы заказчик и исполнитель одинаково прозрачно понимали конечное ожидание от продукта или его функциональности. Для этого необходимо иметь возможность обратиться друг к другу с уточняющими вопросами. Чтобы этот процесс был структурирован, с каждой из сторон должны быть определены ответственные сотрудники.

Думаю, самая большая ошибка — это огромное подробное техническое задание.

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

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

И обычная история: к тому моменту, когда ТЗ написали, оно уже устарело. Многое меняется по ходу проекта, и в итоге ТЗ подписывается как есть, а исполнитель и заказчик разбираются с деталями в процессе.

Если же пытаться расписать все подробно, придется потратить огромное количество времени, но учесть все не получится.
Есть часть работ, которые обязательно подробно закрепить в ТЗ. Это все сложные и дорогие моменты, например, протоколы обмена данными, интеграции и тому подобное.

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

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

Многие думают, что ТЗ — это пережиток прошлого и атрибут излишней бюрократии в современном IT-мире с agile-подходом ко всему. Но по моему опыту, ТЗ по-прежнему неплохо работает как инструмент для повышения прозрачности на проекте и, кроме того, является неким страховым полисом для участников проекта. А страхует оно от неоправданных ожиданий Заказчика и неправильно трактуемых требований Исполнителем.

Правильное ТЗ должно быть прежде всего таким:

• Максимально подробным в отношении важных функций проекта.
• Однозначно трактуемым.

Нужно понимать, что все, что не описано в ТЗ, Исполнитель может сделать по-своему. Поэтому важно все критичные требования к проекту зафиксировать.

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

Не нужно слепо гнаться за стандартами оформления. Помните, основная задача ТЗ – зафиксировать содержание проекта и убедиться, что все участники проекта одинаково его понимают.

Вот основные пункты, которые точно должно содержать любое ТЗ:

• Цели и задачи, которые должны быть решены в проекте.
• Сроки.
• Рамки проекта (что должно быть сделано, а что не входит в проект).
• Подробное описание состава проекта и требований к нему.
• Требования к результату.
• Порядок сдачи/приемки проекта.

Ну и последнее, но немаловажное. Цель должна оправдывать средства, поэтому если проект небольшой (условно, сделать работу по нему будет быстрее, чем написать ТЗ), то скорее всего для такого проекта ТЗ будет избыточным. В таких кейсах можно использовать более лаконичные способы формулировки содержания проекта, например, Бриф или Устав.

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

Основная задача ТЗ – донести до разработчика идею заказчика. При этом важно, чтобы:

• при выполнении работ не оставалось сомнений, что же именно хочет получить заказчик;
• возникающие в ходе работы вопросы сводились к минимуму (в идеале, чтобы вопросов и не возникало, а все было понятно из задания);
• исполнитель четко понимал, какой результат работы удовлетворит заказчика.

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

Потратить время и силы на составление качественного ТЗ стоит. Для начала заказчику важно понять и структурировать для себя, что в результате он хочет получить. Это первый шаг к успеху в передачи информации другому. Для структурирования можно воспользоваться вопросом «какую проблему я хочу решить?». Это поможет сформулировать результат. Затем неплохо представить, если бы вы выполняли эту задачу сами, с какими трудностями столкнулись бы в процессе? Тогда снова задаем вопрос «как эти проблемы можно решить?» и формулируем примерные ответы. Это будет раздел алгоритмов выполнения задачи. Таким образом, оптимально, чтобы техническое задание было разбито на разделы. Например, такие: введение и цели разработки (работы), этапы выполнения, требования, которым должен отвечать результат работы, порядок приемки (тестирования, контроля). Для более сложных технических разработок, конечно, ТЗ по разделам будет объемнее.

Несколько советов для заказчика:

• Помните, если речь идет о творческой работе, ваши представления о чем-либо всегда отличаются от представлений другого человека. Поэтому формулируйте все фразы четко, без эмоций, с единственно возможной трактовкой.
• Если есть примеры работ, которые вам нравятся, передайте их исполнителю, так будет больше шансов на понимание. Визуально для творческих людей воспринять проще, чем текстом.
• Даже по идеально составленному ТЗ могут возникнуть вопросы. Не игнорируйте исполнителя. Некоторые гениальные и продающие идеи рождаются даже не в процессе механической работы, а в ходе обсуждения. Не лишайте себя шанса получить от исполнителя даже больше, чем вы описали в ТЗ.
• Для некоторых работ (IT-разработки, исследовательские изыскания) необходима документация. Без ее изучения не получится нужный результат. Не забудьте предоставить ее исполнителю или будьте готовы по его просьбе выдать нужные документы. Не всегда можно обойтись одним техническим заданием.

Умение писать задания – навык, который тренируется, как и многие другие. Однако вложенные в отработку этого умение время и силы сполна окупаются.

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

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

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

Речь не идет о конкретных архитектурных решениях — как именно мы будем хранить данные. В ТЗ должны быть отражены вопросы такого плана: удаление или архивирование сущностей (пользователей, данных), логирование, статистика, администрирование контента и фильтры, сортировки по этому контенту в административном разделе. Использование коробочных систем, например 1С-Битрикс, много таких вопросов снимает. Но при кастомной разработке ничто не может «подразумеваться по умолчанию». Для разработчика не существует того, что не описано в ТЗ и договоре. Хорошо, если при вышеупомянутой оценке разработчик обратил внимание на отсутствие ряда функциональностей и в смету включил. Но на этапе тендера такие правильные детали могут сделать коммерческое предложение неконкурентным, а представитель заказчика, проводящий тендер, не всегда готов улавливать такие тонкости – у него иные критерии на этапе выбора подрядчика: цена, опыт в схожих проектах и тематике. А внимательность и техническая компетенция при оценке проекта будут далеко не первым критерием при оценке.

Получается палка о двух концах. Либо мы профессионалы и еще на этапе оценки помогаем заказчику с ТЗ, либо мы выбираем другой подход – с рамками и рисками.

В этом случае нам ТЗ важно для определения ожиданий со стороны бизнеса. Мы доносим до заказчика, что его ТЗ не техническое, а функциональное. Важно то, что оно определяет и что нужно получить на выходе, а не как это должно быть сделано. Как проект будет сделан, определится и на этапе проектирования и дизайна (которого в этот момент нет), и на этапе архитектурного проектирования и консультирования в начале разработки. А сейчас, на старте проекта, мы оцениваем функциональность в привязке к выбранной технологической платформе и в зависимости от сложности проекта закладываем вот такой люфт бюджета на риски. Этот задел позволит нам гибко реагировать на пожелания заказчика и отвязаться от ТЗ как от той самой «священной коровы».

Есть и третий вариант: когда ТЗ пишет исполнитель уже после подписания договора, в рамках обозначенной работы за фиксированную сумму, а после написания уже делает смету на проект. С этим ТЗ заказчик может уйти и в другую компанию. Но на практике крайне редко на такое соглашается заказчик – риск смены подрядчика никому не нравится и создается ощущение, что написание ТЗ слишком отложит старт проекта, на который уже есть четкие требования по срокам, обусловленные бизнесом либо финансовой отчетностью за выделенный на проект бюджет.

Примеры ошибок в ТЗ из нашей практики:

1. Не учтено логирование при большом количестве контент-менеджеров: невозможно найти, кто внес то или иное изменение. Здесь же обратный случай: не продуманы группы пользователей и их права, со стороны клиента все ходят в админку под одним логином администратора (и люди, отвечающие за добавление новостей, и seo-специалисты, и бухгалтеры).
2. Не продумано удаление и архивирование элементов и разделов: если на элементы завязана какая-то статистика или заказы и это где-то демонстрируется, надо продумать, оставляем ли мы архив и как мы решаем, что показывается. Это важно и для поискового индекса.
3. Не описан механизм нетиповой интеграции с 1С (endpoint, принципы, пр.) – согласование и выстраивание этой интеграции потребует плотных коммуникаций разработчиков и 1с-специалистов, времени и плотного контроля заказчика.
4. Нет выгрузки товарного каталога и описания хранимых данных в 1С по товарам – все они в итоге отдают одно свойство «характеристики», а в ТЗ предусмотрена фильтрация.
5. Не описана созависимость фильтров.
6. Упущены сортировки как таковые.
7. Административный раздел не описан полностью.
8. В административном разделе не описаны фильтры по заказам по дате, номеру, телефону, вообще какие-либо фильтры, которые будут необходимы администратору.
9. Управление мета-тегами забывают всегда: про то, откуда у страницы берется title – нигде не зафиксировано. Здесь же можно отметить весь пул SEO чек-листа (ЧПУ, 404, хлебные крошки, robots, коды счетчиков, редиректы и т.п.).
10. Не прописаны обязательные по законодательству ссылки в футере (например, СОУТ или «Политика конфиденциальности»).
11. Не описаны почтовые уведомления, которые вообще должны быть (о заказе, регистрации, отправленной форме и т.д.).
12. Не описано управление промо-баннерами. Описано все, но про сквозные картинки в дизайне и про слайдер – забыли.
13. Не продумана и, соответственно, не описана работа с заказами, оплатой и доставкой. Какие будут возможности оплатить заказ? Будет ли работа с юридическими лицами, можно ли им дать возможность сразу выставлять счет или работаем только через менеджера? Какие службы доставки используются, какие данные по заказу и товару нужны для расчета стоимости и сроков доставки? Какие статусы заказов, на каких этапах происходит оповещение пользователя о смене статуса и по каким каналам?
14. Клиент при написании ТЗ не продумал структуру контента, не определил разделы и подразделы. Необходимость вложенного меню с подуровнями может выясниться уже после завершения программирования при внесении контента.

Пишите и читайте ТЗ внимательно. Помните: любые неоплачиваемые доработки проекта вне ТЗ и договора съедают вашу маржинальность.

Разбалансированность ТЗ (превалирование «как » над «что»)

Часто бывает, что большую часть ТЗ занимают требования, как должен работать требуемый функционал ПО (процессы работы). А требования к самим результатам работы ПО даны в малом и часто недостаточном количестве. Обычно это связанно с тем, что ТЗ написано специалистами, которые уверены, что если очень детально описать процессы, то этот «путь» неминуемо приведет исполнителя к разработке требуемого ПО. Это ошибка. В реальности, исполнитель потратит дополнительное время на уточнение требований к целевому функционалу, а часть требований к процессам/методам/способам будут оспорены и в итоге признаны опциональными и вторичными.

В первую очередь, в ТЗ должны быть требования к результату работы («что»).

В ТЗ нет нефункциональных требований или они неполные

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

Полноценные нефункциональные требования должны быть неотъемлемой частью ТЗ.

Противоречивые требования

Бывает, что заказчик, часто сам того не осознавая, не знает точно, что хочет получить в результате. Из-за этого в ТЗ появляются требования в многословных общих расплывчатых формулировках. Более того, потом такие требования начинают ссылаться друг на друга, тем самым все окончательно запутывая. В итоге заказчик с исполнителем потратят значительное время на уточнение всех неконкретных и неточных формулировок.

ТЗ должно содержать конкретные и точные требования. Многословности без конкретики следует избегать.

Перед началом работ по проекту следует выделить отдельное время на проработку ТЗ: количество часов аналитика и руководителя проекта, которое планируется потратить на работу с заказчиком и сбор требований. Лучше выяснить максимальное количество нюансов перед составлением ТЗ и, тем более, стартом проекта, чем что-то менять по ходу его реализации.

Начать работу над ТЗ можно со знакомства с командой заказчика, чтобы понять, кто за что будет отвечать. Затем рекомендую запланировать с ней интервью, чтобы собрать необходимую информацию: цели проекта, план работ, что хотим получить в итоге, требования к функциональной части будущего решения. Важный момент – фиксация ответов и отправка summary обсуждения собеседнику с вопросом: можете ли вы подтвердить или скорректировать оговоренные в беседе пункты? Только после финального подтверждения от заказчика рекомендую запускать собранную информацию в работу.

Формат ТЗ тоже лучше обсудить заранее. Очень важно, чтобы содержимое этого документа было понятно. Лучше не усложнять его специально, иначе придется потратить дополнительное время на разбор ТЗ. Например, оформленные по ГОСТу документы сложнее для восприятия, чем спецификации, написанные простым техническим языком.

Как разработать хорошее ТЗ?

Вот что советуют эксперты:Тщательно обговорите проект с заказчиком, чтобы понять, что именно он хочет, и уточнить какие-то детали.Укажите в ТЗ сроки, цели и задачи, которые должны быть решены в проекте, их приоритет.Избегайте противоречивых требований.Требования должны быть чёткими и трактоваться однозначно.ТЗ должно быть понятно всем участникам процесса, а не только пользователям или разработчикам.Показывайте свои промежуточные успехи и корректируйте ТЗ при необходимости.

Напоминаем, что вы можете задать свой вопрос экспертам, а мы соберём на него ответы, если он окажется интересным. Вопросы, которые уже задавались, можно найти в списке выпусков рубрики. Если вы хотите присоединиться к числу экспертов и прислать ответ от вашей компании или лично от вас, то пишите на experts@tproger.ru, мы расскажем, как это сделать

Вообще сам подход SDLC – не новый, ему уже более 12 лет и он успешно применяется при разработке продуктов информационных гигантов: Microsoft, Cisco и т.д. Каждая компания старается создать свою концепцию и набор практик, которые помогли бы определить общие правила построения процесса разработки приложений и связанных с ним контролей. А также обеспечить определенный уровень доверия к результатам разработки команд, которые использую на практике зарекомендовавшие себя подходы. В свою очередь, международные институты ISACA, OWASP, ISO, ГОСТ и т.д. принимают активное участие в создании и систематизации подходов, описании лучших практик, формировании требований, проверяемых при аудите.

Из изложенного выше видно, что работа в направлении SDLC ведется и достаточно успешно, есть материалы и стандарты, есть практика внедрения и накоплен опыт использования, однако изучив все это актуальным остается вопрос: «Как адаптировать эти практики к реальности и как не потратить на их внедрение много сил и средств?»

Для ответа на этот вопрос предлагаю рассмотреть некоторые примеры сложных ситуаций, с которыми сталкиваются команды разработки при внедрении у себя практик SecSDLC:

1. Отсутствие у руководства компании риск-ориентированного мышления;
2. Неустоявшиеся практики проектного управления (или использование различных подходов проектного управления на разных проектах, что не позволяет обеспечить оптимизацию процессов разработки. Например, большое количество команд разработки, пересечение команд, отсутствие контролей или наоборот для разных команд свое);
3. Низкая квалификация команд разработки в вопросах информационной безопасности;
4. Отсутствие накопленного систематизированного опыта в вопросах информационной безопасности, что приводит к решению повторяющихся кейсов с нуля;
5. Отсутствие моделирования угроз и управления рисками информационной безопасности;
6. Безопасность не успевает за развитием и внедрением новых технологий разработки;
7. Старые подходы мешают создавать синергетические схемы работы ИТ и ИБ.

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

К решению задачи построения SecSDLC предлагаем подходить комплексно и выделять следующие основные ветки внедрения практики безопасной разработки:

• создание процессов безопасной разработки – это внедрение цикла SDLC с включенными контролями ИБ на каждом этапе разработки (см. рис.1) с учетом специфики работы команд разработки и накопленного ими опыта (что может изменять базовый подход);
• создание безопасной среды разработки – внедрение на уровне инфраструктуры разработки практических мер защиты информации, базирующихся на актуальных угрозах безопасности и оценках возможного ущерба (рисков).

Классика или новация

Для начала необходимо определить какой подход к управлению разработки ближе в вашей компании классический или agile. В большинстве случаев невозможно дать универсальный ответ — какой из этих подходов оптимален для процесса разработки. Все зависит от того, какие цели ставит руководство перед командой разработки, и что из себя должен представлять сам продукт – его жизненный цикл. Если речь идет о web-разработке, адаптивном функционале, изменяемых требованиях от релиза к релизу, оперативном устранении багов и доработке новых фич – то лучше остановиться на гибкой методике разработки (agile). Если необходимо создать фундаментальный продукт с высокими требованиями к качеству и безопасности кода в ущерб оперативности изменения функциональности – то бесспорно подойдет каскадная модель (waterfall), определяющая четкую последовательность этапов и контролей.

Рисунок 1 – Создание безопасного цикла разработки приложений

В большинстве случаев получается так, что необходимо использовать смешанный подход (combi) как в рамках одной команды разработки, так и при выстраивании взаимодействия между командами разработки.

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

Тема экспериментов в области управления проектами разработки приложений раскрыта в художественной книге Тома Демарко «Deadline».

Начинаем с нуля

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

Рисунок 2 – Безопасный цикл разработки

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

Внутри команды разработки должны внедряться и развиваться тимлиды по информационной безопасности, это разработчики, которым интересно развиваться в области ИБ и которые хотят, чтобы создаваемый ими код был безопасным. Немаловажным является способность таких тимлидов передавать свои знания и проводить обучения.

После того как определен центр компетенций он должен разработать и утвердить, совместно с другими заинтересованными сторонами, следующие артефакты:

• Модель угроз безопасности. Должна учитывать все актуальные угрозы и риски информационной безопасности, которые по разным причинам могут влиять на безопасность создаваемого продукта. Документ должен учитывать особенности инфраструктуры, процесса разработки (например, привлечение внешних организаций), используемые технологии.
• Оценка и управление рисками. Необходимо понять какие риски являются для компании и ее руководства важными, а какими можно пренебречь или делегировать. Исходя из принятого решения, актуализируется модель угроз и встраиваются контроли ИБ в процесс разработки ПО.
• Формирование базовых требований ИБ к архитектуре создаваемого продукта и к процессу разработки в целом. Требования должны относиться к специфике безопасного использования технологий, patch-management, разделение сред, мониторинг инцидентов ИБ, обезличивание данных в тестовых контурах и контуре разработки и пр.
• Разработка соглашения о кодировании. Документ, определяющий основные правила безопасности и требования к чистоте разрабатываемого программного кода. Обычно в группе разработки есть такие документы их достаточно дополнить в части безопасности.

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

Последнее несколько лет активно набирает обороты направления DevOps – это специалисты участвующие в процессе разработки в качестве инфраструктурных инженеров, своего рода микс разработчика и системного администратора. А с появлением микросервисных технологий и процессов CI/CD в разработке влияние DevOps на разработку становится колоссальным. Поэтому считаем, что не лишним будет обучить DevOps инженера азам информационной безопасности или взять на работу специалиста, который имеет опыт DevSecOps. Это важный момент, т.к. распространена ситуация, когда DevOps инженер — это выходец из команды разработки или бывший системный администратор, как следствие, субъективно, пренебрегающих вопросами информационной безопасности в угоду оперативности и удобству. Безопасники, ставшие DevOps инженерами в моей практике пока не встречались.

Следующим шагом, исходя из имеющегося опыта, определенных рисков и моделировании угроз, с учетом зрелости команды разработки в вопросах ИБ, зрелости и возможностях самого центра компетенции необходимо определиться с достаточностью контролей безопасности в процессе разработки продукта (рис.2). В данном случае речь идет не столько про технические средства анализа кода, а про процессный подход: согласование, утверждение, информирование и т.д. Команда безопасности должна иметь возможность информировать, а в ряде случаях, и принимать вето в отношении решений, которые идут в разрез принятой в компании политики безопасности. Встраивание контролей ИБ в процесс разработки – это поиск компромиссов между руководством, ИБ, ИТ и командой разработки, направленных на поиск решений, позволяющих обеспечить безопасность разработки продукта без фатального влияния на сроки и качество.

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

• статические анализаторы кода – применяются в отношении не компилируемого кода на этапе сборки кода или на промежуточных этапах разработки непосредственно из репозитория;
• динамический анализ кода – применяется в отношении уже готового кода, в основном web;
• интегрированные анализаторы кода – позволяющие реализовывать сканирование статического и динамического кода, интегрируются в CI;
• Left Shift анализаторы, позволяющие проверять код непосредственно в процессе его разработки;
• проверка open source компонентов – решения интегрируются с большим количеством внешних репозиториев, могут детектировать открытый код и уязвимости в нем;
• BugBounty – практика привлечения экспертного сообщества к поиску уязвимостей (для очень зрелых компаний);
• ручной анализ кода и pentest.

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

Защищенная среда разработки

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

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

1. Сегментирование сети и управление сетевыми проходами: сегмент разработки, тестирования, продуктивный сегмент, сегмент DMZ и тд.;
2. Управление ролями и правами доступа, особое внимание необходимо уделять вопросу контроля действий привилегированных пользователей (администраторов систем);
3. Управление и хранение парольной информации;
4. Защищенный удаленный доступ;
5. Управление уязвимостями инфраструктуры и патч-менеджмент;
6. Мониторинг и аудит ИТ и ИБ;
7. Обезличивание чувствительной информации в БД тестовых сегментов сети.

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

Заключение

В заключении хочется дать короткий подытоживающий ответ на поставленный в этой статье вопрос: «С чего начать внедрять безопасную разработку приложений?» — в первую очередь:

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

Все остальное может выстроиться со временем и путем приобретения необходимого опыта. Либо, вам могут помочь те, кто уже прошел этот путь. Удачи!

Часто слышу от начинающих разработчиков про муки выбора компании-работодателя: продуктовая компания vs аутсорс-компания, занимающаяся заказной разработкой. Конечно, каждый случай уникален; всё зависит от того, чего вы ожидаете и хотите от своей работы, какими качествами и скиллами обладаете.

Для начала пару слов о том, что такое продуктовая разработка

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

Этапы разработки нового продукта:

идея → разработка → альфа/бета  → продукт

Этапы разработки в существующем продукте (на примере  CS-Cart):

бизнес-требование → прототип → демки/фидбек → фича

Что рассказывают на собеседованиях в продуктовых компаниях

Если вы придёте на собеседование в продуктовую компанию или загуглите «преимущества работы в продуктовой компании», то, скорее всего, услышите / прочитаете это:

• большой продукт, X лет на рынке;
• никаких ТЗ от заказчика;
• работаем по спринтам, никаких «срочно» и «сейчас»;
• менеджеров нет, можно спокойно программировать.

Из всего этого может сложиться ощущение, что продуктовая разработка — это только кодинг и внедрение. Но это не так.

Я не буду сравнивать особенности работы в разных типах компаний, поделюсь своим опытом работы в продуктовой компании.

Продуктовая разработка = развитие клиента (customer development), а не развитие продукта

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

В рамках этого подхода есть 4 важных этапа:

• Поиск — Что за задача у клиента?
• Подтверждение — Как мы можем решить эту задачу? Можем ли мы продать решение?
• Создание — Можем ли мы продать решение многократно?
• Рост — Как масштабировать бизнес?

Таким образом, продуктовая разработка находится где-то на стыке поиска, подтверждения и создания.

Продуктовая разработка = работа внутри команды

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

Продуктовая разработка = аналитика и гипотезы

Данный пункт вытекает из 2-х предыдущих. Чтобы повысить ценность продукта, команде нужно активизировать весь ресурс сотрудников для выявления проблем, потребностей клиентов и генерации идей.

Мы много общаемся и в процессе диалогов пытаемся ответить на важные вопросы. Например:

• Какова задача клиента?
• Решена ли эта задача в других продуктах?
• Как она решена у других?
• Как ее можно решить у нас?

Продуктовая разработка = прототипы и фидбек

Чтобы понять насколько наши идеи жизнеспособны и будут ли они востребованы среди клиентов, нужно делать прототипы. Чтобы проверить гипотезу перед выкаткой фичи в продукт, мы используем MVP (minimum viable product) — «минимальный рабочий продукт». Он даёт пример решения задачи клиента, но не покрывает крайние случаи. Основная задача MVP — получение обратной связи для оценки и принятия решения. Нужно быть готовым к тому, что ряд прототипов по результатам собранного фидбека придётся выкинуть и полностью переработать. Это нормальный процесс.

Продуктовая разработка = обязательства

При этом обязательства возникают сразу по нескольким направлениям:

• перед клиентами: мы доставим фичи;
• перед разработчиками: мы не сломаем обратную совместимость.

Продуктовая разработка = стандарты индустрии

Фичи:

• Как эта задача решена в других продуктах?
• Работает ли это решение?

Разработка:

• Какие стандарты кодирования мы можем использовать, чтобы сделать наш код понятным всему сообществу разработчиков?
• Какие готовые популярные библиотеки мы можем использовать, чтобы не изобретать велосипеды?
• Как рефакторить устаревающий код?

Тестирование:

• Какие подходы к тестированию позволяют сократить количество ошибок?

Интерфейсы:

• Какие подходы используются в создании интерфейсов?
• Какие UI kit’ы решают эту задачу?

Инфраструктура:

• Как сейчас выпускают и разворачивают проекты?
• Как организовать мониторинг доступности и производительности?

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

Продуктовая разработка = ответственность

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

Рекомендации для начинающих программистов:

1. Книга C. Макконнелл «Совершенный код». Талмуд в тысячу страниц. Несмотря на название, не весь про программирование. Содержит полезные советы по анализу требований и проектированию архитектуры.
2. Н. Виноградова «Самые лучшие уроки рисования для смелых и любознательных». Когда я учился в универе, декан советовал нам смотреть мультики и больше рисовать, чтобы стать хорошими программистами. Мы тогда улыбались, но сейчас я разделяю эту мысль. Инструментов для проектирования систем много, но самый доступный — лист бумаги и карандаш.
3. Изучить диаграммы последовательностей UML. При проектировании придется описывать процессы в системе. Диаграммы последовательностей UML — самый наглядный способ описания процессов.
4. Продукт, который вы хотите пилить или уже пилите, нужно изучать постоянно. Сначала — для понимания, как он работает, чтобы разрабатывать хоть что-то. Потом — для понимания, что он предлагает клиентам. Далее — для понимания, что он может предложить клиентам. Без понимания того, что важно для клиента, а что нет, вы будете тратить время впустую на кажущиеся только вам важными улучшения.

Прим. ред. Мнение редакции может не совпадать с мнением автора.

Всё верно, я считаю, что разработка через тестирование (Test Driven Development — TDD) — это плохо. Более того, TDD пагубно влияет на джуниоров, ставя перед ними нереалистичные цели. Так что позвольте мне в насмешливой форме поразглагольствовать о том, почему написание тестов для несуществующих функций — это дико.

Почему я так считаю?

В частности потому, что мне нужно было о чём-то написать на этой неделе, но также и потому, что я общался с senior-разработчиками с реальным опытом. Не с теми, которым не нравится TDD, а наоборот. Когда я спрашивал их об использовании TDD, они в красках описали все его преимущества. Но стоило мне продолжить вопросом:«Так, а в реальности вы этим пользуетесь?», — как я получал очень разные ответы.

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

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

В чём вообще преимущества TDD?

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

Пробуем TDD

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

Работа над функцией продолжилась, однако мы начали чувствовать, что не очень понимаем, как она будет взаимодействовать с остальной системой. Поэтому мы начали играться с кодом, чтобы посмотреть на его реакцию. Мы изменили функцию и залогировали результаты. Выяснилось, что дело можно упростить, если изменить файл конфигурации и сделать небольшие изменения, которые мы сразу же и сделали. Это заняло у нас немного времени, но мы наконец поняли, как фича будет взаимодействовать с системой. И тогда я заметил, что 1) наша функция была полностью написана и что 2) тест провалился. Снова.

Почему TDD не сработал?

Потому что не так просто разрабатывать ПО, реализующее бизнес-логику. Да, при работе над своими небольшими проектами TDD звучит клёво. Но в реальной жизни фичи устроены немного сложнее, чем «функция X должна принять имя и вывести приветствие с этим именем». Часто требования к продукту меняются посреди работы или вы вдруг осознаёте, что фича не может работать согласно требованиям. Или вы изначально всё не так поняли, и вам нужно начинать работу с нуля.

В этих ситуациях нет ничего необычного, но необходимость постоянно тратить время на написание теста в самом начале только усугубляет каждую из проблем. Гораздо проще писать код, вручную проводить какие-нибудь тесты и лишь затем писать автоматизированные тесты для имитации этих ситуаций. Имея надлежащие тесты вы можете свободно переходить к следующей фиче или провести рефакторинг, не боясь что-нибудь сломать. Используя тестирование как ограждение, а не карту, вы получаете все преимущества тестов БЕЗ проблем с попытками что-либо предвидеть.

У TDD есть хорошие идеи

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

В заключение

Я поднял эту тему, потому что тесты — это важно. Выпуск приложения в продакшн без тестов можно сравнить с ездой по шоссе без разметки. Я пытаюсь сказать, что TDD похож на попытку начертить разметку до того, как вы проложили шоссе. Возможно, вы с этим не согласны и используете TDD каждый день и вам это нравится. Но если это не так, то всё в порядке! Нам нужно быть честными с самими собой. Если стиль программирования выглядит хорошо в теории, но не на практике, то давайте оставим те части, которые работают, а всё остальное выкинем. Моя запутанная мысль заключается в следующем: есть разные стили написания кода, и мы должны перестать считать какой-либо из них «лучшим».

Подводя итог, скажу, что у Behavior Driven Development нет никаких недостатков, и если вы его не применяете, то вы дурак.

Шучу.

Прим. ред. Мнение редакции может не совпадать с мнением автора оригинала.

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

Обычно командам, использующим краткосрочные ветки, было бы лучше работать прямо в мастере, так как практики, которые им нужно соблюдать, чтобы безопасно следовать trunk based development, приносят множество преимуществ: улучшение командной работы, улучшение качества работы, коллективное владение кодом и не только.

«Нет, мы не пушим в мастер, ты совсем что ли?»

Позвольте рассказать вам историю.

Недавно я устроился в консалтинговую компанию. Самая интересная часть работы консультантом заключается в том, что вам приходится работать с множеством клиентов. Так, с начала работы несколько месяцев назад я поработал с тремя разными командами. Они состояли примерно из 6–8 человек, работающих в одном офисе. В основном это были программисты плюс product owner, иногда ещё и scrum master. Почти все в команде сидят рядом друг с другом, не считая странного человека, который изо дня в день работает из дома.

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

Я: «Так, что происходит, когда я делаю коммит?».Они: «Тебе нужно создать пулл-реквест, скинуть ссылку в Slack и подождать, пока кто-нибудь его проверит».Я: «А, то есть вы не пушите сразу в мастер?».Они: *уставились на меня широко открытыми глазами, словно увидели пришельца... несколько секунд тишины…*Они *неодобрительно качая головами*: «Нет, мы не пушим в мастер. Код сначала нужно проверить».И тут я прямо вижу, как они думают: «Он серьёзно? И вот этот человек должен нам "помочь"?».

Само собой, я не против, когда люди ставят под сомнение мои идеи и противятся им, это часть моей работы. Но что меня удивило, так это сколько сопротивления встретила идея, что кто-то мог даже подумать о пуше в мастер. Я много гуглил и поспрашивал людей из других компаний, и оказалось, что feature-ветки — нормальное явление. Тут даже и говорить не о чем, так работает IT-индустрия.

Будучи выходцем из компании, где пушить в мастер было нормой, я подумал и решил написать эту статью. Я хочу объяснить, почему я уверен, что обычно командам, которые используют краткосрочные feature-ветки, будет выгодней делать всё в мастере, а не в этих ветках.

Как команды используют краткосрочные feature-ветки и пулл-реквесты

Давайте объясню, как из моих наблюдений выглядит типичный рабочий процесс команды, использующей краткосрочные feature-ветки:

• У команды есть бэклог историй для реализации. Обычно есть «бэклог спринта» с историями, которые нужно реализовать в этом спринте.
• Разработчик свободен, поэтому он смотрит в бэклог и выбирает историю.
• Разработчик создаёт новую ветку из мастера и начинает работать над историей.
• По мере работы он коммитит и пушит код в ветку с любой удобной частотой, будь то минуты, часы или дни.
• При каждом пуше инструмент сборки (Jenkins, CircleCI и т. д.) запускает сборку ветки. Обычно сборка компилируется и упаковывает код, после чего запускаются какие-нибудь тесты. Возможно, происходит развёртывание в dev-среде.
• Когда разработка завершена, на что может уйти от нескольких дней до недели, разработчик создаёт пулл-реквест (PR).
• Кто-нибудь из команды проверяет PR. В некоторых командах любой человек может сделать это, а в других — только техлид или senior-разработчик.
• Проверяющий(-ие) может оставить комментарии к PR, запросив изменения. В этом случае разработчик возвращается к работе для реализации этих изменений, а затем снова отправляет PR. Этот шаг может повторяться несколько раз.
• Наконец, PR принимают. Разработчик сливает ветку в мастер, обычно совмещая все коммиты из ветки в один большой коммит в мастер («squash и merge»).
• Инструмент CI запускает сборку мастера. Начинается процесс внесения этих изменений в продакшн — иногда они автоматически развёртываются на продакшне, а иногда на одном или нескольких этапах нужно вмешательство человека.

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

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

Успешная альтернатива: Trunk Based Development, без веток

Что я предлагаю в качестве альтернативы, так это работать напрямую в мастере, без использования веток. Само собой, нужно делать это безопасным образом. Чтобы это стало возможным, команда должна использовать следующие основные методы:

1. Парное программирование

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

• улучшается сконцентрированность команды;
• люди меньше отвлекаются;
• работа делается быстрее и качественнее;
• в команде стандартизируется стиль кода;
• люди вместе находят лучшие решения проблем;
• происходит обмен знаниями и так далее.

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

2. Имейте сборку, которой доверяете

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

Для достижения этих двух вещей команды обычно следуют практикам вроде TDD, BDD и имеют эффективную стратегию тестирования, например следуют пирамиде тестирования, чтобы свести к минимуму количество медленных тестов.

Если сборка вдруг ломается, её починка немедленно становится приоритетом команды. В маловероятном случае, если не удалось сделать это быстро, нужно сделать откат изменений.

3. Используйте «ветвление через абстракцию» или feature-флаги, чтобы спрятать незаконченный код

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

На деле я обнаружил, что в большинстве случаев можно использовать шаблон «ветвление через абстракцию», чтобы избежать использования кода в продакшне до его готовности. Для более сложных сценариев я использовал feature-флаги.

В моей предыдущей компании работать так было нормой. Я проработал там около 6 лет, но я знаю, что там следовали этим практикам более 10 лет. Так что я точно знаю, что такой способ работы может быть успешным (в конце статьи буду подробности того, как мы работали).

Преимущества Trunk Based Development

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

• Более быстрая обратная связь: при использовании PR фидбек поступает только после того, как разработчик посчитает, что он закончил. На этом этапе уже, как правило, поздно менять что-то основательно. Когда вы работаете в парах, обмен фидбеком происходит во время написания кода — или даже раньше, когда вы обсуждаете подход к решению задачи — поэтому его гораздо проще менять.
• Более качественная обратная связь: при использовании PR фидбек обычно представляет собой простой текстовый комментарий. За редкими исключениями такой способ не может донести все нюансы, которые часто требуются при обсуждении программы. Автор PR вполне ожидаемо воспринимает всё в штыки, кода речь заходит о том, что он считает «своим кодом», а комментарии, которые легко могут показаться грубыми, зачастую вызывают раздражение или конфликты. С другой стороны, когда вы работаете в парах, вы обсуждаете ваши идеи лицом к лицу, где на порядок проще объяснить, что вы пытаетесь сказать, и провести здоровую дискуссию.
• Коллективное владение кодом: когда код написан одним человеком, обычно он воспринимает его как «мой код». В итоге ты начинаешь слышать вещи вроде «о, это Алекс написал» или «мы не можем работать над этим, пока Сэм не вернётся». Если работать в парах, то гораздо более вероятно, что команда начнёт смотреть на код как на «наш код».
• Командный стиль кода: хорошие команды пишут код, который выглядит так, словно его писал один человек. Это признак того, что каждый участник ценит командную работу больше, чем собственные предпочтения. При работе в парах становится гораздо проще выработать командный стиль и всегда о нём помнить.
• Более частая интеграция («настоящая» Непрерывная Интеграция): очень часто PR создаётся, когда история/фича закончена. При пуше сразу в мастер мы интегрируем код незамедлительно, приближаясь к реальному значению «непрерывности» в Непрерывной Интеграции.
• Мы привыкаем не ломать вещи: при работе непосредственно в мастере мы не хотим запушить что-нибудь сломанное, поэтому у нас появляется привычка запускать локальную сборку перед пушем и реализовывать код через последовательность изменений, которые ничего не ломают. С другой стороны, при работе с ветками проще простого проигнорировать неудавшуюся сборку и исправить всё только в конце.
• Легче справляться с большими рефакторингами: при работе с ветками мы стараемся избегать делать что-то, что может привести к конфликтам слияния, например, переименовывание пакетов, перемещение файлов, архитектурные изменения. При работе в мастере такие вещи делать даже если не легко, то по крайней мере легче, так как мы можем коммитить небольшие изменения, чтобы у всей команды был актуальный код. Для особо сложных изменений мы собираемся возле одной машины всей командой у устраиваем быстрый сеанс совместного программирования, когда мы сидим вместе и обсуждаем, как должно выглядеть решение.
• Лучше видно, кто над чем работает: когда изменения находятся в ветке, их гораздо сложнее заметить, чем когда все пушат их в мастер. Таким образом становится на порядок лучше видно, кто чем занимается и кому нужна помощь.
• Более удобный просмотр изменений: вместо того, чтобы смотреть на красные/зелёные строки на странице, как это обычно происходит при просмотре PR, можно использовать гораздо более удобные инструменты для просмотра изменений перед их коммитом.
• Сохранение оригинальной истории коммитов: при слиянии изменений из ветки в мастер люди зачастую объединяют все коммиты в один, теряя историю того, как и почему автор сделал те или иные изменения. С другой стороны, при работе в мастере мы сохраняем полную историю каждого коммита. Я работал с кодовыми базами, которым было лет по 10 и чьи авторы уже давно были недоступны, и могу сказать, что возможность посмотреть в истории Git конкретно на коммит, где что-то изменилось, была бесценной, так как это позволяло нам посмотреть на описание этого и любого другого изменения, сделанного в то же время.

Trunk Based Development — показатель здоровья команды

Позвольте быть предельно ясным: TBD сам по себе не является чем-то особенным и не даёт каких-то особых преимуществ. Что их даёт, так это практики, которым нужно следовать для применения TBD. Чтобы команда могла работать прямо в мастере, её члены должны знать, как работать, не ломая код, как писать хорошие тесты, как работать вместе эффективно и так далее.

Можно сказать, что TBD является показателем здоровья команды. И этому действительно есть подтверждение в книге «Accelerate»: после изучения более 10 000 сотрудников и 2 000 организаций исследование показало, что существует тесная взаимосвязь между командой, следующей TBD, и высокими показателями эффективности этой команды. В частности, было обнаружено, что в высокоэффективных командах срок жизни веток составляет менее суток.

Оптимизация эффективности команды

Когда я спрашиваю у команд, почему они используют ветки или почему они думают, что не стоит пушить сразу в мастер, мне обычно отвечают что-то вроде: «Мы должны поддерживать мастер в хорошем состоянии, готовом к релизу» или «Мы хотим проверять код друг друга, чтобы убедиться, что он хорошего качества и соответствует нашим стандартам». Я полностью согласен с обоими утверждениями, но в этой статье я показал вам, как добиться тех же результатов без использования веток.

Однако есть и другая причина, о которой часто умалчивают, почему так много команд используют feature-ветки: «Гораздо проще и эффективнее, когда все работают со своими ветками и не наступают друг другу на пятки».

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

Feature-ветки оптимизируют индивидуальную производительность, но TBD оптимизирует производительность команды. Когда вы проводите оптимизацию команды, начинает казаться, словно каждый её член начинает работать медленнее. Это смена подхода, которая выглядит нелогично. Но именно так группа отдельных разработчиков превращается в команду.

Хорошие примеры использования feature-веток

После долгих разговоров о том, почему не следует использовать feature-ветки, думаю, стоит прояснить следующее: да, в определённых случаях от них есть польза. Как правило, я бы сказал, что feature-ветки хорошо использовать, когда у кода есть явный владелец, но кто-то другой делает всю работу.

Прекрасный тому пример — open-source модель: в типичном open-source проекте есть владелец, будь то один человек или команда, а ещё есть множество разработчиков со всего света, вносящих вклад в проект без общения друг с другом. В этом случае имеет смысл просить разработчиков отправлять PR, так как владельцам проекта нужно его проверить. Собственно, это то, для чего в GitHub придумали PR! Также в таком случае владельцам проще отклонить любой PR, с которым они не согласны.

Аналогичная ситуация иногда возникает в компаниях, использующих внутреннюю open-source модель: код принадлежит одной команде, но поскольку разработчики слишком заняты, чтобы работать над ним, другая команда вносит в него свой вклад, отправляя PR. Это не единственное решение этой проблемы, но иногда это хороший компромисс.

«Окей, убедили. Как мне начать использовать этот подход?»

Если сейчас вы работаете с feature-ветками и хотите перейти к работе с мастером напрямую, вот несколько предложений:

• Пересмотрите вашу стратегию тестирования и поработайте над стабильной сборкой, которой доверяете. Это может означать, что вам надо начать больше применять TDD, добавлять больше тестов, сохраняя при этом быструю сборку.
• Больше работайте в парах. Если вы обычно этого не делаете, то начните со сложных задач, так как в таком случае будет проще убедить кого-то работать с вами в паре. Затем вы можете продолжать делать это во всё большем количестве случаев, и в итоге образуется группа людей, которым нравится парное программирование. Остальные члены команды со временем подтянутся, особенно если вы введёте правило, что код, написанный в паре с другим человеком, не нуждается в проверке кода.

Ресурсы по теме

Вот хорошие ресурсы, если вы хотите больше узнать о TBD:

• Trunk Based Development;
• Continuous Integration and Feature Branching — Dave Farley;
• Organisation Pattern: Trunk Based Development — Steve Smith;
• The Death of Continuous Integration — Steve Smith;
• Enabling Trunk Based Development with Deployment Pipelines — Vishal Naik;
• Committing straight to the trunk — Paul Hammant;
• What is Trunk-Based Development? — Paul Hammant;
• Accelerate — Nicole Forsgren PhD, Jez Humble, Gene Kim;
• Make Large Scale Changes Incrementally with Branch By Abstraction — Jez Humble;
• BranchByAbstraction — Martin Fowler;
• Branch By Abstraction — Paul Hammant.

Бонус: реальный пример Trunk Based Development

Вот подробная информация о том, как моя предыдущая команда следовала TBD и пушила сразу в мастер. Команда была похожа на описанные выше: 6–10 человек, из них 4–6 разработчиков, 1–2 тестера, 1 бизнес-аналитик и 1 тимлид.

• Разработчики работают в паре весь рабочий день.
• Одна пара разработчиков выбирает новую историю. В рамках процесса подготовки к разработке они пишут скелет одного или нескольких приёмочных тестов и составляют список заданий для истории.
• Когда пара думает, что готова, она собирает команду и показывает всем приёмочные тесты с целью убедиться, что у всех одинаковое понимание того, о чём история и что команда собирается реализовывать. Эта методология называется BDD, где используются примеры для формирования общего представления.
• Каждая пара разработчиков выбирает задание из истории. Как правило, над одной историей у нас работало по 2–3 пары, которые выбирали независимые задачи.
• Каждая пара коммитит и пушит сразу в мастер с частотой, варьирующейся от нескольких минут до нескольких часов. Они отправляют коммит, как только проходит тест, для которого они писали код. Все мы любили небольшие, частые коммиты, с понятными сообщениями, поясняющими почему было сделано то или иное изменение. В идеале сообщение использует бизнес-терминологию и фокусируется на бизнес-задаче, которую мы пытаемся решить этим коммитом. Хороший пример такого сообщения: «Реализовал приёмочный тест, чтобы доказать, что на один порт может быть выделен только один клиент».
• Каждый раз, когда разработчики вытягивают изменения из Git, они делают rebase, чтобы сохранить исходный порядок коммитов.
• Перед коммитом пара всегда запускает локальную сборку, чтобы убедиться, что всё хорошо. Сборка обычно занимает от 30 секунд до 2 минут.
• В качестве стратегии тестирования мы придерживались пирамиды тестирования, всегда предпочитая быстрые тесты медленным. Наши усилия заметно облегчило применение чистой архитектуры, которая позволяла нам держать бизнес-логику изолированной от технических деталей. Это не единственный способ, но нам он отлично подошёл.
• В любой момент времени кодовая база находится в состоянии, готовом к релизу, благодаря шаблону «ветвление через абстракцию». Иными словами, в нашем Java-проекте мы не подключали бины Spring до последнего момента. Весь новый код был доступен для тестов, но в продакшне он появлялся только когда мы были готовы его подключить.
• При пуше кода CI-инструмент запускает сборку и прогоняет все тесты. Мы нигде не делали автоматическое развёртывание, но могли бы, если бы захотели.
• Разработка истории обычно завершалась за несколько дней. После этого вся команда опять собиралась, чтобы посмотреть, что было реализовано.
• Затем последняя версия приложения развёртывается в stage-среде, где наш QA проводит исследовательское тестирование, на которое уходит от нескольких часов до нескольких дней.
• Если не всплывают никакие сюрпризы, то приложение развёртывается в продакшне (обычно на следующий день).
• Тем временем, ближе к концу разработки предыдущей истории, одна пара начинает рассматривать следующую историю, чтобы подготовить её и поддерживать рабочий поток. Мы использовали ограничения на work-in-progress процессы, чтобы держать этот поток под контролем.
• Если в какой-то момент пара чувствовала, что им нужно что-то обсудить с командой (например архитектурное решение), они просто звонили в колокол, чтобы привлечь всеобщее внимание. Все пары собирались вместе для импровизированной командной работы, чтобы вместе выработать решение. Когда все были довольны, пары возвращались к своим задачам.%save-sc3%

Мнения

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

И мнение сторонника:

А что вы думаете о TBD? Делитесь в комментариях.

Ещё не все понимают, что такое Agile и зачем он нужен

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

Большие компании тоже переходят на гибкие подходы при разработке

Удивительно, но многие банки уже работают по Agile. Например — Сбербанк, Райффайзенбанк, Банк Хоум Кредит.

Kanban работает и в распределённой команде

При этом важно проводить регулярные созвоны, а также организовать работу так, чтобы вся команда была на связи хотя бы 4 часа в сутки. Подробно рассказал Андрей Ребров, CTO & co-founder Scentbird. Презентация на Dropbox.

В России внедряют LeSS

Это специфичный метод, когда на несколько команд — только один владелец продукта. Метод подходит не всем, так как получается сложно балансировать между гибкостью и предсказуемостью. Плюс все команды должны уметь делать всё. Антон Бевзюк и Дмитрий Павлов рассказали про успешное внедрение LeSS в Додо Пицце. Ещё советуем вот эту статью Антона.

При внедрении новых подходов появляются саботажники. Что с ними делать?

Для начала надо понять, осознанно ли человек мешает работе. Если да — поговорить с конфликтологом, перенанять и, если не помогло, удалять из команды. Если нет — ставить ему дедлайны чаще, а задачи конкретнее, также поможет настройка времени на отдых. Подробнее в презентации Agile Coach Анны Обуховой. Полистайте, может оказаться, что вы — неосознанный саботажник.

Принципы Agile можно применять не только при разработке ПО

Как пример — eduScrum, который внедряется в некоторых школах не только за границей, но и в России. Алексей Дерюшкин из Better Life Company рассказал, кто такой «учитель 21 века» и почему Agile так нужен в школах. Agile можно использовать и в личной жизни, например, чтобы быстрее закончить ремонт на кухне.

Не бойтесь скрещивать Scrum и Kanban или брать из каждого подхода понемногу

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

Все презентации и информацию о докладах можно найти на странице программы конференции.

Платформы непрерывной разработки и интеграции (CI/CD), по мнению Gartner, сегодня находятся на пике хайпа. Интерес к ним проявляют все отрасли, делающие ставку на модернизацию в цифровой перспективе. Предлагая всё более эффективные программные решения, CI/CD получает и свою долю критики. Евгений Филатов рассказывает о месте CI/CD в современной софтверной разработке и о перспективах её развития в ближайшие несколько лет.

Конвейер качественного кода

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

На этапе разработки возможность непрерывного тестирования и доставки кода позволяет увеличить скорость и качество готовых решений. Непрерывное (несколько раз в день) слияние рабочих копий программного кода в общую основную ветвь и тестирование результатов оформилось в «концепцию непрерывной интеграции и доставки софта» (англ. Continuous Integration & Continuous Delivery или сокращённо CI/CD). Впервые её предложил Гради Буч в 1991 году.

Принцип действия CI/CD похож на конвейер: методика выполняет интеграционную функцию, включая различные типы автоматических тестов на каждом этапе, с последующей доставкой и развёртыванием завершённого кода в готовый продукт для конечного пользователя.

CI/CD-платформы, на базе которых реализуется концепция, поддерживают выполнение регулярной автоматизированной сборки проекта для оперативного выявления дефектов и решения интеграционных проблем. При стандартном подходе (каскадная разработка ПО или Waterfall-методика), где разработчики независимо трудятся над разными частями системы, стадия интеграции является заключительной, и при выявлении ошибок может непредсказуемо задержать окончание работ. Переход к непрерывной интеграции позволяет снизить трудоёмкость работы и сделать её более предсказуемой за счёт раннего и непрерывного обнаружения и устранения ошибок и противоречий.

По своей сути концепция CI/CD реализует идеологию сращивания разработки и эксплуатации ПО (Development & Operations, DevOps) и соответствует основным принципам Agile в части рекомендаций по использованию автоматического тестирования для быстрой отладки рабочей версии софта.

Если Agile – это устранение зазора во взаимодействии заказчика и разработчика, а DevOps – снятие границ между разработчиком и администратором, то CI/CD – это воплощение стратегий и компонентов DevOps на практике.

Overhype 80 lvl

Сегодня CI/CD – самая хайповая методика софтверной разработки, которую стремятся применять практически для всех задач. Со временем, скорее всего, найдётся какая-то ниша, где CI/CD признают оптимальным инструментом со статусом «золотого стандарта», но и waterfall-метод при этом полностью тоже не исчезнет.

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

Для внесения корректив в монолитные ИТ-системы без дополнительной доработки (например, крупные процессинговые системы для банков с релизами обновлений 3-4 раза в год) CI/CD не подходит, поскольку для таких задач требуется полная перестройка всей архитектуры.

Другой вопрос, что не везде даже новую архитектуру, создающуюся под новую систему, можно заточить под CI/CD. Пока что очевидный спектр задач для методологии включает в себя всё, что касается веб-разработки, e-commerce, омни-канальных решений, словом, всего комплекса frontend и middleware компонентов. Для существующих core-систем каскадная парадигма пока остаётся оптимальным выбором.

Особенности развёртывания CI/CD-платформы

Главная сложность перехода на CI/CD заключается в адаптации подхода, где на первом месте находятся процессы, а технологии – только на втором. Необходимо выстраивать новые процессы, определять новые роли людей, находить точки интеграции уже существующих и новых процессов. Смещение акцента с софта и «железа» на людей и организационные аспекты работы для многих становится серьёзным вызовом.

Второй момент – в CI/CD ответственность разработчика за конечный результат становится гораздо выше. Теперь он не просто пишет абстрактный код по ТЗ, а ещё и мгновенно его тестирует своими же силами. Отсюда вытекают более высокие требования к компетенциям специалистов.

В CI/CD разработчик не просто пишет абстрактный код по ТЗ, а ещё и мгновенно его тестирует своими же силами.

При этом не стоит путать классических «инфраструктурщиков», которые конфигурируют оборудование, заливают системное ПО и проводят настройку инфраструктурных компонентов системы, с новым поколением CI/CD-профилированных сотрудников. CI/CD-специалисты должны разбираться не только в инфраструктуре, но и в её надстройках – Kubernetes, TeamCity, Jenkins и другом платформенном ПО. Можно сказать, что в CI/CD-концепции поддержка платформы добавляется к стандартной поддержке ИТ-инфраструктуры компании.

Ещё одна особенность CI/CD сегодня – огромный выбор open-source программных инструментов, из которых формируются платформы. При этом в состав многих зарекомендовавших себя платформ входят всем известные и доступные инструменты. Специалисты по CI/CD обеспечивают оптимальную подборку имеющихся на рынке инструментов, ориентируясь на задачи проекта, а также на road map их развития в плане поддержки актуальности версий.

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

В целом реализация перехода на CI/CD – комплексный процесс, традиционно на этом пути компании сталкиваются с рядом сложностей. Например, при переобучении сотрудников пересмотр существующего рабочего процесса неизбежен, а это может вести к недовольству со стороны менеджеров.

Бонусы и profit

В CI/CD важен быстрый цикл обратной связи, позволяющий почти мгновенно определить, насколько качественными являются изменения в коде и функциональности продукта. При waterfall-подходе можно быстро вносить изменения в код, но без постоянных проверок выявление багов потребует гораздо больше времени и может произойти уже после начала коммерческой эксплуатации, причем таких «отложенных» багов в одном релизе может оказаться несколько.

Инструменты CI помогают быстро ответить на вопросы о причинах дефектов для каждого коммита, обеспечивая раннее выявление и устранение ошибок. CI/CD-платформа помогает не только оперативно тестировать, но и выводить новую функциональность для конечного пользователя таким образом, чтобы в случае выявления ошибки всегда существовала возможность либо быстро её устранить, либо «откатить» итерацию решения на шаг назад.

Одни ошибки в ПО могут содержать другие, которые включают в себя третьи и так далее. Чем больше ошибок накапливается, тем сложнее тестировать и находить их, что в результате может привести к неприятным последствиям. Между тем в CI/CD-разработке автоматизированные тесты в случае провала покажут, что именно нужно исправить. Конечно, для внедрения системы потребуется время, но это поможет разрабатывать софт максимально быстро и удобно.

Автоматизированные процессы помогают значительно снизить трудозатраты разных отделов предприятия. Без автоматизации CI/CD могут всплывать ошибки, вызванные человеческим фактором и необходимостью совершения ручных операций.

Главные плюсы CI/CD:
Скорость вывода новой функциональности от запроса клиента до запуска в эксплуатацию. CI/CD позволяет запускать обновления за считанные дни или недели по сравнению с целым календарным годом при классическом waterfall-подходе. Новые сервисы – новые конкурентные бизнес-преимущества. Появляется возможность не просто воспроизводить функциональность решений конкурентов, но и значительно опережать их в разработке и внедрении новых инструментов.
Возможность выбора оптимального варианта за счет оперативного тестирования и большего числа итераций. Отказавшись от работы над бесперспективными решениями, вы сэкономите ресурсы компании.
Качество итогового результата выше: автотестирование охватывает все аспекты продукта, что труднореализуемо при стандартном релизном подходе. Все ошибки и тонкие места выявляются и удаляются ещё на ранних этапах разработки.

Главные минусы CI/CD:Искушение перевести на Agile, DevOps и CI/CD сразу всё, что связано с корпоративными ИТ-системами, включая core-уровень, без приобретения первичного опыта. Это может серьёзно нарушить работу компании, особенно при плохой организации перехода на новую методологию.Поддержка должного уровня координации между CI и CD. Быстрые и качественные результаты от применения методики возможны только после длительной и тщательной настройки взаимодействия между командами DevOps, инженерами, scrum-экспертами и руководством компании. Самое сложное в CI/CD – человеческий фактор, налаживание здоровой командной работы, которую запрограммировать и автоматизировать невозможно.

Мода и дефицит

Важно понимать, что все методики и технологии являются не взаимоисключающими, а взаимодополняющими. Вопрос только в том, какая методология и технология займёт определённое место в общей ИТ-экосистеме.

Пока мода на CI/CD накладывается на дефицит специалистов. Внедрять методику с высоким уровнем качества в таких условиях недёшево. При этом нельзя сказать, что это как-то особенно дорого и недоступно по своей сути. В принципе, все необходимые инструменты на рынке присутствуют: софт для CI/CD не стоит космических денег. Обучиться CI/CD-методикам также возможно, в том числе и in-house специалистам компаний.

Другое дело, что бизнесу чаще всего просто некогда вдаваться во все тонкости, а тем более осваивать их на практике. В этой ситуации чаще всего окном CI/CD в компании становится новая задача, под которую привлекается профильная команда. После запуска проекта обнаруживается, что опыт, инфраструктура и платформа CI/CD применимы на других участках под прочие задачи компании. Так часто происходит в телекоме, ритейле и банках – первый проект становится «песочницей», где компетентные специалисты занимаются прототипированием, а затем итоги их занятий масштабируются на всю организацию.

Оптимальным критерием оценки правильности выбранной стратегии CI/CD-развития разработки является сравнение эффективности процессов с лидерами рынка, которые способны осуществлять интеграцию нового функционала, его тестирование и ввод в эксплуатацию в рамках 2–3 часов.

Подводя итог, CI/CD можно назвать лучшей методикой разработки софта под задачи современности, которая в своём развитии проходит через фазу отраслевого хайпа. Это не хорошо и не плохо – это просто стадия, которая обязательно закончится, и тогда мы увидим объективное место CI/CD в системе методологических подходов современной софтверной разработки.

Смотрите также: Кто такой DevOps и как им стать

Agile — итеративный подход при работе над проектом. Знать об Эджайле полезно тем, кто уже работает в IT, и тем, кто только планирует стать айтишником. Ваша команда выпускает проект маленькими шагами с самого начала, а не показывает уже готовый продукт в самом конце.

Википедия описывает гибкую методологию разработки так:

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

Почему именно Agile?

TL;DR — чтобы подстраиваться под постоянно меняющиеся требования.

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

Более традиционные подходы вроде Waterfall (каскадная модель) диктуют тотальное планирование, когда вы ничего не можете сделать, если этого нет в плане.

В любом проекте, будь то программное обеспечение, маркетинговая кампания или рекрутинговая стратегия, появятся дополнительные возможности или поменяются требования. Особенно в случае с крупными проектами. Поэтому новые факторы приходится либо игнорировать (обычно неидеально), либо ужимать план, погружая работу в хаос. Так зачем тогда вообще планировать, правда?

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

Что такое Agile?

TL;DR — различные практики, которые помогут вам легче приспосабливаться и убеждать свою команду в том, что она всегда работает над чем-то важным.

Agile — способность меняться легко и быстро.

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

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

Пользовательские истории поставляются либо непрерывно, либо маленькими циклами, которые называются спринтами.

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

TL;DR — Требования > План > Работа > Ревью > Повтор

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

Оцените каждый этап: по часам или по так называемым story point’ам (относительные оценки, которые выставляются в сравнении и отношении к другим историям). Есть вероятность, что результат будет несколько неточным и даст вам слабое представление о том, сколько времени займёт работа над проектом.

Установите приоритетность задач, самые важные — в начало очереди. Обычно в этой среде всё постоянно меняется, поэтому проверяйте приоритеты быстро и часто. Kanban очень реагирует на эту частоту. Scrum же основан на фиксированных циклах (спринтах), которые обычно длятся две недели.

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

Scrum vs Kanban

TL;DR — это два основных фреймворка для Agile.

Scrum

• Деление работы на части, которые называются спринтами (обычно в спринте две недели);
• Спринты планируются исходя из требований для этого конкретного момента времени;
• Относительная оценка времени выполнения работ;
• Ревью каждого спринта, чтобы понять, как он прошёл и что можно было бы улучшить;
• Фидбек по поставляемому продукту;
• Ежедневные собрания (очень короткие).

Kanban

• Еженедельные собрания;
• Непрерывная разработка;
• Визуализация процесса на доске;
• Решение сначала самых важных задач;
• Поэтапные улучшения.

Заключение

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

Цель профессии QA-инженера — помочь создать качественный продукт. Их работа заключается не просто в поиске багов и не в обыкновенном тестировании. Основная задача QA-инженера — предотвратить дефекты и, следовательно, обеспечить высокое качество процесса разработки и его результатов. Это достаточно общее определение, поэтому в этой статье мы попытаемся рассказать о некоторых деталях, которые помогут осознать ценность QA.

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

Так чем занимаются QA-инженеры? Они:

• Выявляют слабые места и несоответствия в продукте на всех этапах разработки;
• Помогают определить требования к проекту;
• Предоставляют исчерпывающую информацию о качестве продукта;
• Тестируют продукт на протяжении всех фаз жизненного цикла разработки системы (software development lifecycle, SDLC).

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

Теперь давайте разберём все этапы, на которых нужны QA, их роли на этих этапах и значимость их работы для бизнеса.

Когда вам нужен QA?

В этой части статьи мы опишем, что и когда делают QA. Этапы, описанные ниже, являются общими (и обобщёнными) частями цикла тестирования программного обеспечения (software testing life cycle, STLC).

Сбор требований

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

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

1. Анализ и принятие решения о том, совместимы ли между собой требования, и могут ли они быть реализованы в рамках одной системы.
2. Оценка того, какие решения будут работать, а какие — нет.
3. Планирование необходимых методов тестирования (подробнее об этом ниже).

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

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

До прохождения валидации продукт может и не дойти до потребителя, даже если он отлично сделан с технической точки зрения. Также на этом этапе проверяется, принесёт ли продукт пользу клиенту. Иначе зачем вообще этим заниматься?

Планирование тестирования

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

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

Разработка тестов

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

Выполнение тестов

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

Если тест-кейс прошёл неудачно, значит в коде есть ошибка, и QA отправляют отчёт разработчикам, чтобы они проверили, что не так.

Отчёт о результатах

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

Что такое цикл тестирования? Это частота, с которой мы проводим эти пять этапов тестирования.

Особенности работы QA

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

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

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

• Безопасный бизнес. У вас есть платёжная система, и она работает нормально. Пользователь платит за услугу и получает её. Однако вы не проверили все возможные случаи, и деньги идут не вам, а на случайный банковский счёт. Такой недочёт может очень дорого обойтись;
• Экономия денег. На приведённой ниже диаграмме хорошо видна взаимосвязь между этапами жизненного цикла и затратами. Гораздо дороже исправить ошибку, чем предотвратить её. Исправление одной ошибки может повлечь за собой другие, поэтому количество ваших проблем будет быстро увеличиваться;
• Защита репутации. Если выпустить багованный продукт и пользователи не будут довольны работой с ним, в дальнейшем их будет сложно убедить, что проблема решена и они могут снова им пользоваться. Первое впечатление сложно изменить, поэтому предоставьте качественный продукт. Если он не был протестирован вдоль и поперёк, то продукт может работать неправильно или не работать вовсе. Тестирование требует теоретических знаний, поэтому будет сложно обеспечить качество, если вы не профессионал;
• Контроль процесса. Если процесс разработки не контролируется и идёт вразрез с установленными требованиями, итоговый продукт может сильно отличаться от запланированного.

Вы могли заметить, что часто упоминается тестирование. Это потому, что есть такая отдельная дисциплина, как контроль качества (Quality Control, QC). Далее мы поговорим о работе QA, о разнице QA и QC, взаимосвязи SDLC и STLC, а также дадим детальное описание некоторых методов тестирования, используемых QA-инженерами.

QA

Обеспечение качества и контроль качества

Контроль качества (Quality Control, QC) охватывает всю деятельность, направленную на то, чтобы убедиться, что продукт хорошего качества и отвечает заданным требованиям. QC-инженеры занимаются поиском дефектов в продукте до его выпуска. Можно сказать, что обеспечение качества включает в себя контроль качества.

Есть случаи, когда продукт не требует QA, а только QC. Например, если команда получает продукт, разрабатываемый другими людьми, с целью проверить, соответствует ли код требованиям.

В некоторых командах QA и QC совмещаются с другими ролями. Иногда разработчики пытаются проверить свой собственный код. Тем не менее, это сказывается на качестве, так как гораздо сложнее найти ошибки в своём коде, чем в чужом.

Цикл разработки программного обеспечения и цикл тестирования

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

Надеемся, нам удалось вас убедить в важности одновременного проведения SDLC и STLC. Теперь мы перейдём к некоторым популярным методам составления тестов, которые QA-инженеры используют для обеспечения качества.

Методы составления теста

Тест-кейс (или просто тест) — пошаговый подход к тестированию функциональности программного продукта. По сути сюда входят тестируемый объект и способ тестирования.

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

Есть разные методы составления теста, каждый из которых выявляет недостатки определённого типа. Поэтому выбор метода зависит от типа продукта, его готовности и требований.

На картинке ниже представлены основные методы составления теста:

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

Статический. Этот метод тестирует исходный код, функциональные спецификации и спецификации требований до выполнения кода (до выхода в релиз). Этот метод определяет структурные недостатки. Это не одноразовая работа, поэтому мы стараемся начать её на ранних этапах процесса разработки.

На основе структуры. Мы используем такой метод, когда у нас есть полный доступ к коду. Проще говоря, он касается внутренней логики и структуры кода. Такие тесты помогают определить неправильную или отсутствующую логику и опечатки в коде.

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

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

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

В заключение

Неважно, каким простым кажется продукт, ведь в основе его качества лежит тонна проделанной работы. Как заметил Дон Норман, «Хороший дизайн гораздо сложнее заметить, чем плохой». В большинстве случаев QA-инженеры дают людям возможность наслаждаться продуктом, проверив, что всё работает хорошо.

Обеспечение качества включает много всего, от тестирования до анализа результатов. Большинству программных продуктов нужны QA-инженеры, чтобы:

1. Контролировать процесс разработки.
2. Предотвращать ошибки в системе до того, как их найдут пользователи.
3. Обеспечивать качество выпускаемого продукта.

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

Особенности сервиса

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

Kayenta интегрирована в Spinnaker — облачную платформу непрерывной поставки с открытым кодом. Платформа работает с большинством популярных облаков, в том числе Amazon Web Services, Google Cloud, Kubernetes.

Благодаря интеграции становится возможной легкая настройка автоматизации тестов: разработчик сам устанавливает, что Kayenta будет измерять, использовать и выводить. На основе анализа представляется общий счет. Если программа проходит тест, установленный разработчиком, то инициируется процесс подтверждения человеком, иначе — происходит откат обновления.

Грег Буррелл (Greg Burrell), специалист по надежности Netflix, рассказал, что во время тестирования обновлений сравниваются ключевые показатели старой и новой версии. Если в показателях новой версии наблюдаются снижения, то обновление откатывается, и весь поток данных перенаправляется на стабильную версию для минимизации урона от неожиданного поведения обновления.

Для определения, является ли показатель хорошим, Kayenta поддерживает следующие источники метрик: Prometheus, Stackdriver, Datadog и Atlas от Netflix. Также разработчики могут совмещать метрики из разных источников для одного анализа.

Непрерывная поставка и автоматизация тестирования являются неотъемлемыми составляющими DevOps-методологии. Подробнее с остальными инструментами специалистов DevOps можно ознакомиться в нашем материале.

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

Основные функции приложения

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

• канбан-доски, календари, todo-списки;
• возможность создания команд и коллекций;
• управление совместной работой;
• загрузка файлов и изображений;
• мощные фильтры;
• избранное;
• глобальный поиск.

Но главной фишкой новых релизов является оффлайн-доступ к приложению. Да, теперь со всеми версиями Zenkit — как мобильными, так и браузерной — можно работать без доступа в Интернет.

Как это стало возможно? Когда вы работаете с приложением Zenkit, все изменения и внесённые данные сохраняются локально. Когда оно получает доступ в Сеть, вся информация синхронизируется. Более того, использование локальных копий данных, по словам разработчиков, значительно ускоряет загрузку приложения.

Progressive Web App

В отличие от первой версии iOS-приложения, разработчики решили перейти к созданию Progressive Web App (PWA) вместо нативного приложения Android. PWA — это обыкновенная веб-страница, которая выглядит и ведёт себя так же, как и мобильное приложение. Вы можете добавить значок Zenkit на экран своего телефона, получать и отправлять push-уведомления, получать доступ к аппаратным средствам вашего устройства, например, камере, и работать в автономном режиме.

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

Ещё одним плюсом использования PWA Zenkit называет небольшой вес приложения. Оно не требует загрузки большого объёма данных и может работать в зонах с плохим интернет-соединением.

Установка

Приложение доступно для загрузки в App Store и Play Store.

Яндекс.Трекер

Этот сервис предоставляет возможность управлять рабочими процессами и проектами организации. Он поможет распределять трудовые ресурсы, ставить определённые задачи и дедлайны их исполнения каждому сотруднику, определять наблюдателей исполнения задачи. По своей сути, этот сервис является общей системой управления и отслеживания проводимой работы сотрудников компании. «Трекер» похож на Jira от Atlassian и VSTS от Microsoft.

Каждая задача, создаваемая в Яндекс.Трекере, имеет поля описания, установки сроков исполнения, назначения исполнителя и наблюдателя. Все решения и договорённости по каждой определённой задаче заносятся в её комментарии для последующего отслеживания истории рабочего процесса.

Методология Agile

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

Виджеты визуализации

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

Шифрование всех данных

Немаловажным фактом является то, что все данные Яндекс.Трекера хранятся в зашифрованном виде в облаке. В случае утраты рабочего устройства информация с него не пропадёт, а останется сохранённой на серверах «Яндекса». Все соединения в «Трекере» осуществляются по протоколу HTTPS.

Яндекс.Коннект

Напомним, что у компании «Яндекс» есть другой сервис под названием Яндекс.Коннект. Он является экосистемой для совместной работы в компании, в которую помимо «Трекера» входят «Почта», «Диск», «Вики» и «Мессенджер». Например, на «Вики» есть возможность хранить подробные описания проекта и стратегические планы, а детальные планы отслеживать, вставляя на страницы ссылки на задачи «Трекера» — названия и статус задач будут отображаться автоматически.

Стоимость

«Яндекс» предлагает любой компании в течение 2 месяцев бесплатно попробовать функциональность «Трекера». Стоимость дальнейшего пользования зависит от размера компании. Так, если у вас от одного до десяти сотрудников, то месяц работы с Трекером обойдётся в 93 рубля за человека. Если численность сотрудников составляет от 11 до 100 — 209 рублей, 101–500 человек — 163 рубля и для 501–2000 человек — 81 рубль за человека соответственно.

Важно добавить, что «Трекер» обрабатывает все данные на серверах, расположенных в России. Это немаловажный факт в свете требований российских чиновников по хранению личных данных граждан РФ на территории страны. Подробную информацию о новом сервисе «Яндекс» и его возможностях можно получить на его официальной странице.

Стоит добавить, что мобильное приложение имеет неполный функционал веб-версии, по крайней мере, в первом своём релизе. Но всё же есть функции добавления цитат, ссылок и дополнительного материала прямо из меню iOS. Мобильная версия больше похожа на приложение Wunderlist, в то время как веб-приложение является более традиционным конкурентом Trello.

Дорожная карта приложения

Главный исполнительный директор Zenkit Мартин Велкер отметил:

Мы прилагаем все усилия, чтобы получить как можно больше функций из более мощного веб-приложения для приложений iOS и Android. Это всегда вопрос ресурсов, доступных на телефоне и на компьютерах. Нам нужно учитывать размер экрана и вычислительную мощность, что делает создание базы данных на вашем телефоне более сложной задачей. Но мы уверены, что со временем мы справимся со всеми этими проблемами.

В планы компании по добавлению функционала в мобильные приложения также входят:

• создание и редактирование команд и коллекций;
• создание и редактирование меток и полей;
• канбан-доска;
• просмотр календаря;
• добавление к проекту новых участников;
• избранное;
• напоминания;
• более глубокая интеграция с iOS — добавление ярлыков досок без открытия приложения.

Android-версию обещают выпустить через месяц-полтора.

Соучредитель и генеральный директор Trello Майкл Прайор прокомментировал выход приложения на рынок настольных компьютеров:

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

Напомним, что в январе 2016 года Atlassian приобрела стартап Trello.

Теперь, когда мы являемся частью Atlassian, у нас есть больше ресурсов, чтобы быстрее осуществлять такие наши идеи по улучшению Trello, как приложение для Mac и Windows.

В чём отличия от браузерной версии?

Пользователи новых версий получат весь функционал браузерной версии Trello с такими дополнительными возможностями, как нативные оповещения на рабочем столе компьютера и добавление карточек при помощи горячих клавиш. Не забыли и о пользователях MacBook — при помощи Touch Bar теперь тоже можно управлять досками и карточками.

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

Кроме того, Trello упрощает встраивание карт в приложения Bitbucket, Dropbox Paper, appear.in, Confluence Cloud и другие.

Trello получит функции сразу трех приложений: Bitbucket, Confluence и Jira. С HipChat всё обстоит немного по-другому: Trello будет интегрирован в HipChat.

«Теперь можно обсуждать карточки и с легкостью переключаться на Trello, чтобы увидеть всю картину целиком. Или же, наоборот, можно обсуждать какие-то вопросы в Trello, создавая карточки из сообщений HipChat», — рассказала Atlassian в своем блоге. С добавлением Trello в HipChat также стало возможным контролировать, какие уведомления будут показываться в HipChat.

HipChat, помимо всего, соревнуется с Microsoft Teams и Slack, которые уже интегрированы с Trello. Теперь же владелец приложения решил убедиться, что его собственные проекты не лишены возможности такого взаимодействия.

Подробную информацию о данном нововведении можно найти в официальном блоге Trello.

А это что за Trello?

Trello был запущен в 2011 году и является одним из самых быстрорастущих сервисов для управления проектами. С момента отделения от компании Fog Creek Software проект привлёк более десяти миллионов долларов инвестиций. В настоящее время у Trello насчитывается около 19 миллионов пользователей, а команда проекта состоит почти из 100 человек — все они перейдут в Atlassian.

И что теперь изменится?

Atlassian оставит бренд сервиса без изменений, поэтому у пользователей Trello нет причин для беспокойства. Более того, компания планирует достигнуть планки в 100 миллионов активных пользователей сервиса в месяц. Подробности интеграции Trello с другими сервисами компании, скорее всего, будут сообщены 19 января.

Проблемы при отсутствии стандартов:

• Новая кровь. Когда владельцы продуктов (product owners) формируют требования, они зачастую не закладывают много времени на их тщательное описание. Это происходит из-за нехватки времени и желания как можно раньше начать разработку. Или владелец продукта не знает, как правильно задокументировать требования. В любом случае опыт членов команды и их знание продукта во многом определяет успех хода разработки. Но что происходит, когда новые специалисты приходят на проект? Правильно оформленная документация поможет новым членам команды быстрее познакомиться с проектом и с разрабатываемым продуктом /сервисом. Это особенно важно для больших, долгосрочных проектов, где отсутствие документации может привести к серьезным осложнениям.
• Оценки. Если требования описаны бессистемно, без взаимно понятных правил и четко установленных стандартов, оценить эти требования становится невозможным. Если что-то было упущено в требованиях, а разработчики уже приступили к работе, образуется проблемное место (англ. bottleneck, узкое место — явление, при котором производительность или пропускная способность системы ограничена одним или несколькими компонентами или ресурсами), время теряется впустую и реализация задерживается.
• Планирование. Без стандартизации описания требований разработка достоверных графиков проектных работ будет весьма затруднена. Когда владельцы продукта не предоставляют подробные требования к будущей разработке, страдает качество разрабатываемого продукта из-за большего количества ошибок. На исправление ошибок уходит гораздо большее количество времени, чем прогнозировалось в спринте.

Начало и завершение Scrum-проекта

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

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

Подключение нашей команды к проекту позволило владельцу продукта (product owner) сосредоточиться на стратегических бизнес-вопросах, так как руководитель проекта с нашей стороны взял на себя логистические вопросы, в т.ч. документирование.

Команда была распределенной. Часть разработчиков находилась в США (в разных штатах). Там же жили и владельцы бизнеса, и владелец продукта. Вторая часть команды – в Минске. Также пользователи системы были разбросаны по разным часовым поясам. Постоянное общение по рабочим вопросам было важной частью процесса разработки, поэтому разница во времени создавала дополнительные сложности в работе.

Что было до стандартизации описания требований

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

• Сложности оценки. Во время груминг-встреч возникали вопросы, без ответа на которые было невозможно дать оценку временным затратам.
• Вопросы и недоработки. На стадии написания кода и тестирования обнаруживалось, что некоторые важные аспекты для реализации требуемых функций не были учтены (например, отсутствовали целые сценарии, описание исключений и т.д.).
• Время и усилия тратятся впустую. Итого эффективность команды страдала: команда не укладывалась в оценки, так как часть требований не была учтена изначально; задачи не завершались к концу спринта; пользователи были недовольны из-за задержек в выпуске новых фич. Кроме того, большое количество времени тратилось на разъяснение заинтересованным сторонам, почему отсутствовали требования, и почему команде разработчиков было необходимо все переделывать.

После стандартизации описания проектных требований

Для улучшения ситуации команда разработчиков начала использовать подход стандартного описания требований с классической структурой:

Как <пользовательская роль/тип>, я хочу <название фичи>, чтобы получить <краткое описание пользы от данной фичи>

В дополнение были сценарии приемки работ, описываемые по следующему шаблону:

Сценарий Приемки 1:

ДАНО (какая-то ситуация/предварительное условие)
И (дополнительные обстоятельства/предварительное условие)
КОГДА (событие/действие, выполненное пользователем)
ЗАТЕМ (ожидаемый результат – что должно произойти для удовлетворения требований пользователя, рассмотренных выше).

Сценарий Приемки 2: …

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

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

Это снизило количество задаваемых вопросов, появилось единое понимание «что есть качество» и его конкретные метрики.

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

Пример пользовательской истории со сценарием приемки:

Пользовательская история:

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

Сценарий приемки*:

Менеджер по обслуживанию клиентов исключает участников опроса из списка членов
ДАНО Менеджер хочет пригласить новых пользователей для участия в опросе
И существуют пользователи, ранее приглашенные для участия в опросе
И появляются новые пользователи, которые еще не были приглашены для участия в опросе
КОГДА выбирается Опрос(ы) в поле «Исключить участников опроса» и применяется фильтр
ТОГДА отфильтрованный список пользователей не должен включать в себя пользователей, которые уже являются членами выбранных с помощью фильтров опросов.

* Указанный выше сценарий стал первичным, он был выбран из трех сценариев для пользовательской истории, которые были созданы для обеспечения полного охвата при выборе функции «фильтр».

Преимущества унификации описания требований

• Прозрачность. По ходу заполнения стандартного шаблона с описанием требований возникают вопросы, которые иначе бы мы с высокой степенью вероятности пропустили бы. Эти вопросы помогают владельцу продукта и команде продумать каждый шаг еще до оценки, что экономит время и уменьшает количество проблем и с оценкой, и на более поздних этапах проекта. Процессы становятся прозрачными, и бюджет расходуется более эффективно.
• Полный охват. При стандартизированном подходе к описанию требований все потоки и альтернативные сценарии, связанные с функционалом будущего продукта, описываются в полной мере и с соответствующими деталями, способствую повышению качества разработки и упрощая тестирование.
• Улучшение производительности. Как следствие первых двух преимуществ, производительность команды увеличивается, так как не приходиться тратить время на исправление багов, связанных с реализацией пользовательских историй. Уходит меньше времени на уточнения, больше задач реализуется в срок, пользовательские истории не блокируются.
• Документирование каждого требования, процесса или функции. При работе над проектом с множеством модулей, которые разрабатываются одновременно, сложной функциональностью, десятками тысяч пользователей, множественными пользовательскими ролями, многоканальной связью, работа бизнес-аналитиков усложняется: невозможно запомнить каждую деталь проекта. А при наличии стандартизированных требований аналитики могут просто искать ответ на каждый поставленный вопрос, который включен в описаниях пользовательской истории в качестве отдельного сценария или шага в сценарии.
• Выше качество конечного продукта. Добавление унифицированных описаний в JIRA для каждой функции помогает новичкам в проекте, создает общее понимание системы, так как функционал описан и понятен всей команде.
• Сокращение времени на коммуникации. Когда дело доходит до аутсорсинг-проектов с разницей во времени, все выигрывают от отсутствия узких мест в работе над проектом.
• Высокое качество кода итогового продукта. Качество становится выше, так как требования ясны всем. Поэтому же упрощается и процесс планирования/оценки.
• Простота внесения изменений в требования и сценарии. Если требования описаны по стандартному шаблону, детально и качественно, управление изменениями требований также изрядно упрощается. В целом, привлечение на проект бизнес-аналитика, который прояснит и хорошо опишет требования, позволит сэкономить время и деньги.

Стандартизация и тестирование

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

Управление текущими изменениями в требованиях

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

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

Вывод

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

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

Об авторе

Елена Бельковская окончила Белорусский государственный университет по специальности в области экономики. До прихода в Itransition работала экономистом. В настоящий момент Елена — бизнес-аналитик, успешно применяющий семилетний опыт работы в ИТ и знания гибких методологий разработки ПО. В работе Елена эффективно использует аналитические навыки в проектах для предприятий, включая разработку требований и управление ими, разработку функциональной и учебной документации, планирование бизнес-анализа и оценки. Реализует коммуникации по проекту, решает вопросы проектирования систем.

Какие методологии разработки применяют у вас в компании? Как вы вообще организуете процесс от постановки задачи до выхода продукта на рынок?

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

Какие методологии разработки применяются в различных IT-компаниях?

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

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

Чтобы быть в тренде, программисты должны непрерывно развиваться как профессионалы. В этом компания им активно помогает. Мы отправляем ребят на обучение, конференции, а также организуем различные мероприятия на своей площадке. В-третьих, в процессе разработки мы используем итеративно-инкрементальный подход. Многие автономные продукты выпускаются каждые две недели через прямую поставку софта в тестовую зону заказчика, а иногда сразу в пром. Продукты с высокой степенью комплексности выпускаются синхронно каждые 3 месяца, при этом каждые 2 недели команды демонстрируют потенциально готовый к отгрузке продукт и собирают обратную связь от заказчика, пользователей системы и других заинтересованных лиц.

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

Как компания мы очень адаптивны, поэтому на каждом проекте используем оптимальные методологии. Для «коробочных» внедрений, где есть отработанные схемы, это обычно референтные (эталонные) подходы, учитывающие специфику конкретного решения, например, Oracle AIM.

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

Процесс вывода продукта на рынок и его непрерывного совершенствования традиционно основан на цикле непрерывного совершенствования качества Деминга (циклическое повторение этапов Plan-Do-Check-Act), ускоренного Scrum, дизайн-мышления и других современных техниках.

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

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

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

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

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

1. Выбор правильной методологии ведения проекта. Это могут быть различные варианты гибкой разработки, водопадная модель или же их комбинации. А учитывая, что заказчик хочет иметь возможность внесения изменений на всех этапах разработки и как можно раньше получать работоспособные версии систем, в том числе и масштаба Enterprise, все большую популярность приобретает подход Scaled Agile.

1. Привлечение бизнес-аналитиков на всех этапах разработки для выяснения, спецификации, уточнения и, что важно, верификации требований. Это позволяет минимизировать риск искажения или неверной интерпретации требований на всем протяжении процесса разработки.

1. Использование «унифицированной среды разработки» — совокупности специально подобранных и проинтегрированных между собой инструментов, необходимых для создания ПО (управление задачами, контроль версий, сервер непрерывной сборки, статические анализаторы кода для различных языков и т.д.), а также корпоративных практик и стандартов, которыми мы руководствуемся при разработке.

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

Также мы активно используем автоматизацию тестирования и практики DevOps.

У нас в SAP на этапе постановки задачи все более широко используется методология Design thinking. На этапе создания продукта часто можно видеть варианты Agile, причем иногда совмещенные с Waterfall-подходом.

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

Все начинается с менеджера продукта и менеджера программ — эти две роли, часто объединённые в одном человеке, отвечают за вопросы «какие проблемы решает наш продукт, для каких пользователей и как он это делает». Менеджер программ, по сути, отвечает за ежедневную коммуникацию и представление точки зрения пользователя в команде разработчиков, а также за создание спецификаций на продукт и его компонентов. Рабочие инструменты менеджера программ — система документооборота (например, confluence), системы change management, bug tracking вроде Jira, средства телекоммуникаций (как webex), средства прототипирования и создания «скетчей» интерфейсов, средства для сбора информации о существующих версиях продукта и о том, как его используют живые пользователи. Менеджер программ также выступает заказчиком для следующей роли — дизайнера.

Дизайнер отвечает за проработку деталей того, как выглядят пользовательские интерфейсы и как они «общаются» с пользователем. От качества работы дизайнера часто зависит первое впечатление о продукте, и его роль особенно важна для продуктов с большим количеством графических и веб интерфейсов.

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

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

Тестировщики и QA — это люди, которые ответственны за тестирование продукта (ручное или автоматическое) и за внедрение и выполнение методик, повышающих качество продукта, за отмашку «продукт готов к релизу».

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

Кроме того, в реальной жизни все может быть сложнее — есть эпизодические роли (возникающие на определенных этапах разработки), роли, которые хотя и не имеют прямого отношения к разработке — плотно с ней взаимодействуют (вроде маркетинга и sales engineering), роли, которые существуют только для определенных продуктов — например, профессиональные сервисы, появляются новые роли, которые становятся возможны благодаря развитию средств разработки и внедрения (вроде DevOps инженеров).

У нас применяется система СКРАМ с элементами Канбан. И в целом мы адаптируем все технологии, стараемся чтобы здравый смысл руководил. У нас вся компания разбита на команды до 10 человек, мы работаем кварталами и спринтами внутри них. На квартал существуют глобальные планы компании, например, запустить новый продукт, или провести техническую реформу (недавно мы переходили на микросервисы). К этим глобальным планам команды добавляют свои планы, которые возникают из идей внутри команды или от пожеланий пользователей. Мы стремимся делать то, что мы делаем, самым лучшим образом и у нас, как нам кажется, это получается.

Статья продолжает дополняться.

Напоминаем, что вы можете задать свой вопрос экспертам, а мы соберём на него ответы, если он окажется интересным. Вопросы, которые уже задавались, можно найти в списке выпусков рубрики. Если вы хотите присоединиться к числу экспертов и прислать ответ от вашей компании или лично от вас, то пишите на admin@tproger.ru, мы расскажем, как это сделать.