Ответ
Типичный рабочий процесс в Agile-команде (на примере Scrum) организуется вокруг итераций (спринтов) длиной 1-4 недели:
Ключевые артефакты и события:
- Бэклог продукта (Product Backlog): Приоритизированный список всех требований к продукту, которым управляет Product Owner (PO).
- Планирование спринта (Sprint Planning): Команда выбирает задачи из бэклога продукта в бэклог спринта — фиксированный объем работы на итерацию.
- Ежедневный стендап (Daily Scrum): 15-минутная встреча для синхронизации: что сделал вчера, что сделаю сегодня, какие есть препятствия.
- Работа в спринте: Разработка включает:
- Проектирование и написание кода.
- Code Review (через Pull/Merge Request) для поддержания качества.
- Написание и прогон автоматических тестов (unit, integration).
- Интеграция в основную ветку (часто через CI/CD).
- Ретроспектива спринта (Sprint Retrospective): Встреча для анализа процесса: что прошло хорошо, что можно улучшить.
- Обзор спринта (Sprint Review): Демонстрация готового функционала стейкхолдерам для получения обратной связи.
Технические практики, поддерживающие процесс:
- Git Flow или Trunk-Based Development: Модели ветвления для управления кодом.
- CI/CD (Continuous Integration/Continuous Deployment): Автоматическая сборка, тестирование и деплой при каждом изменении кода.
- Парное программирование / Mob Programming: Для сложных задач и распространения знаний.
Цель: Обеспечить предсказуемую, гибкую поставку ценности продукта короткими циклами с постоянным улучшением процесса.
Ответ 18+ 🔞
Ага, слушай, вот эта ваша Agile-магия, особенно Scrum, блядь. Ну, типа, представь себе цирк, но с дэдлайнами, ёпта. Работаем кусками, которые зовутся спринтами — от недели до месяца, не больше. А то, сука, мозги взорвутся от планирования на год вперёд.
Вот как эта кухня устроена, по полочкам:
-
Бэклог продукта (Product Backlog): Это типа священный свиток, список всех хотелок для продукта. Им заправляет один чувак — Product Owner (PO). Он его постоянно трясёт, перекладывает и орет: «Это в первую очередь, это — во вторую, а это, блядь, вообще на хуй пока не надо!».
-
Планирование спринта (Sprint Planning): Команда смотрит на этот свиток и говорит: «Окей, из этой овердохуищной кучи мы за следующие две недели вот ЭТОТ кусок, блядь, сожрём». И переносят выбранное в бэклог спринта. Всё, план утверждён, назад пути нет. Ну, почти нет.
-
Ежедневный стендап (Daily Scrum): Каждое утро, 15 минут, не больше. Все стоят (чтоб не растекаться) и отвечают на три вопроса, сука:
- Что вчера сделал?
- Что сегодня будешь делать?
- Что тебе мешает, как говно в унитазе? Главное — не начинать на них технические дебаты, а то продлится три часа, и всем будет пиздец как скучно.
-
Работа в спринте: А вот тут начинается магия, блядь. Все эти бесконечные:
- Писать код, ебать его в сраку, переписывать.
- Code Review — когда твой код смотрит другой чувак и говорит: «А тут, сука, у тебя говно, а не архитектура». Делается через Pull Request. Обидно, но полезно, чёрт возьми.
- Писать тесты, чтобы твой же код потом не выстрелил тебе в ногу. Юнит-тесты, интеграционные — вся эта хуйня.
- Заливать всё в общую ветку, где CI/CD пайплайн, этот трудяга-невидимка, всё собирает, проверяет и, если не сломал, даже на сервак выкатывает. Красота, ёпта!
-
Ретроспектива спринта (Sprint Retrospective): Спринт кончился. Все садятся и начинают рефлексировать, как на сеансе у психолога. «Что было хорошо? Что было пиздец? Как нам не наступать на те же грабли?». Иногда выясняется, что грабли — это тимлид, но вслух это не говорят.
-
Обзор спринта (Sprint Review): А это показуха, блядь. Приходят «дяди» (стейкхолдеры), а мы им демонстрируем, что не просто два недели пили кофе, а вот, смотрите, кнопочка стала синей и теперь ещё и пищит! Ждём похвалы или пиздюлей. Обратная связь, её же хотели.
А ещё есть технические плюшки, без которых — вообще пиздец:
- Git Flow или Trunk-Based Development: Чтобы десять человек не перетирали друг другу код в одной ветке, как последние мартышлюшки.
- CI/CD (Непрерывная интеграция и доставка): Чтобы не было как в том анекдоте — «а у меня на машине работает». Чтобы работало везде, сука.
- Парное программирование / Mob Programming: Когда задача такая, что одному страшно, берут второго, а то и всю толпу. Один печатает, остальные орут советами. Эффективно, но психику выматывает в хлам.
И вся эта, блядь, движуха с ритуалами и артефактами — она зачем? А чтобы не делать один раз монументальное говно на год, а потихоньку, итерациями, выдавать ценность. И постоянно улучшать процесс, чтобы в следующем спринте не орать «да как же так, опять всё просрали!». В идеале, конечно. В реальности иногда просто бегаешь по кругу, но уже по отлаженному, блядь, кругу.