Ответ
На проекте использовалась гибридная методология Scrum/Kanban.
Ключевые практики:
- Планирование: Двухнедельные спринты с планированием и оценкой задач в story points.
- Ежедневная синхронизация: Короткие стендапы (до 15 минут) для обсуждения прогресса и блокеров.
- Ретроспектива и демо: В конце спринта — демонстрация функциональности заказчику и ретроспектива для улучшения процессов.
- Гибкое управление задачами: Бэклог продукта приоритизировался Product Owner'ом. Задачи перемещались по упрощенному workflow в Jira, но без жестких ограничений по объему работ в спринте (подход Kanban).
Инструменты и workflow:
- Управление задачами: Jira. Пример workflow для задачи:
Backlog -> Ready for Dev -> In Progress -> Code Review -> QA -> Done - Тест-менеджмент: Тест-кейсы и тест-планы хранились в TestRail.
- Система контроля версий: Git (GitLab/GitHub).
- CI/CD: Jenkins для запуска автоматических сборок и тестов (Continuous Integration).
- Автоматизация тестов: Основной фокус на автоматизацию регрессионного тестирования с использованием Selenium WebDriver и Python.
Ответ 18+ 🔞
А, ну вот, слушай, гибридная методология, блядь! Scrum/Kanban, ёпта! Это когда от одного взяли совещания до усрачки, а от другого — возможность впихнуть задачу в любой момент, потому что «срочно, нахуй».
Основные пизделки, которые мы практиковали:
- Планирование: Каждые две недели собирались, чтобы посудачить, насколько эта фигня сложная в этих ваших стори-поинтах. Поинты, блядь, как будто мы в казино.
- Ежедневная синхронизация: Короче, стендап на 15 минут, где каждый говорит, что вчера сделал, что сегодня будет делать и какие у него проблемы. Главное — не начать реально обсуждать проблемы, а то затянется на час, и всем насрать.
- Ретро и демка: В конце спринта — цирк. Сначала показываем заказчику, что мы там накодили. Он обычно делает вид, что понял, и кивает. А потом ретроспектива, где все дружно говорят «ну в целом норм», но один чувак всегда вспоминает, что «коммиты кривые, блядь».
- Гибкое управление задачами: Product Owner, этот царь и бог, расставлял приоритеты в бэклоге. А мы таскали задачи в Jira по какому-то подобию workflow, но если очень надо было, то могли и из «Backlog» сразу в «In Progress» перекинуть, потому что «ну это же Kanban, ёпта, гибкость!».
Чем пользовались, чтобы этот бардак как-то организовывать:
- Управление задачами: Jira, мать её. Workflow у задачи был примерно такой, блядь:
Backlog -> Ready for Dev -> In Progress -> Code Review -> QA -> DoneИдея в том, что «Code Review» и «QA» — это священные этапы, которые все стараются проскочить побыстрее.
- Тест-менеджмент: Тест-кейсы, эти священные скрижали, хранились в TestRail. Туда же писали результаты, чтобы было чем тыкать в лицо разработчикам, когда всё падает.
- Система контроля версий: Git, куда ж без него. GitLab или GitHub — место, где разворачивались настоящие драмы в комментариях к пулл-реквестам. «Чё за хуйню ты закоммитил?»
- CI/CD: Jenkins, этот старый добрый костыль, который орал, если сборка падала. Запускал автоматические тесты, чтобы мы хотя бы знали, что сломали на самом раннем этапе.
- Автоматизация тестов: Вот тут был наш конёк, блядь. Основной упор — на автоматизацию регресса, чтобы не проверять вручную всю эту лапшу каждый раз. Юзали Selenium WebDriver с Python. Писали скрипты, которые сами кликали по кнопкам и орали, когда что-то не так. Экономия времени — овердохуищная, но когда падает — пиздец, разбираться почему.