Sustainable pace
Передбачуваний робочий темп, який можна підтримувати без системного overtime та приховування реальної capacity.
Як працювати на спокійному проєкті та з нав’язаними оцінками →Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Терміни, нюанси та джерела
Спроєктувати runner для одного UI-suite
Намалювати маршрут від runner до application і залежностей.
Зафіксувати потрібні credentials та мінімальні network rules.
Запустити suite з обраною concurrency й записати peak CPU/RAM.
Обґрунтувати hosted або self-hosted варіант фактичними даними.
Короткий capacity та access worksheet без універсальних припущень про RAM або вартість.
Сформулювати відповідь на нав’язаний estimate
Опишіть available capacity і підтверджені unknowns.
Сформулюйте, що безпечно завершити до deadline.
Запропонуйте явний вибір: зменшити scope, змінити deadline або прийняти перелічені quality risks.
Одне коротке повідомлення без звинувачень і без обіцянки прихованого overtime.
Ресурси runner для UI-тестів
Runner клонує репозиторій, встановлює або використовує залежності та запускає тестовий процес. UI-тести додатково піднімають один чи кілька браузерів; навіть headless browser споживає відчутну кількість RAM. Розмір runner слід визначати за реальною паралельністю, наборами браузерів і піковим споживанням, а не за вимогами звичайного application build.
Що робити, коли задачі оцінили без команди
[Дивитися з 14:25](https://www.youtube.com/watch?v=reaHS8_pZbU&t=865s). Якщо estimate нав’язано ззовні, команда не повинна регулярно рятувати його unpaid overtime: тоді management бачить лише формально виконаний plan і не отримує evidence, що estimation process зламаний. Потрібно фіксувати фактичний effort, невідомі залежності, скорочений testing scope та carry-over, а на retrospective вимагати участі виконавців в оцінюванні. Сильніша позиція виникає, коли кілька інженерів незалежно описують ту саму проблему фактами. Спочатку питання піднімають із tech lead/engineering lead, потім — на retro або з manager, якщо прямий канал не працює. Повідомлення має бути не «ми не хочемо встигати», а «за такого scope й available capacity безпечний результат потребує X; до deadline можемо завершити Y, решту переносимо або свідомо приймаємо перелічені ризики». У відео також звучить ідея зробити недооцінку видимою через накопичення нестабільних tests і technical debt. Навмисно ламати quality gate не варто: це створює product risk і послаблює аргументацію команди. Правильний еквівалент — не приховувати незавершену роботу, явно документувати deferred checks/debt, не позначати неперевірене як done і вимагати product decision про scope, deadline або quality.
Коли інтегрувати автотести в CI
Теза «тести без CI нікому не потрібні» занадто категорична. На ранньому етапі локальний запуск поруч із розробником може дати швидший і корисніший feedback, особливо коли deployment pipeline, runners або доступи ще нестабільні. Спочатку команда має довіряти тестам і вміти швидко зрозуміти причину падіння за report, trace, screenshot чи video. Довгі або нестабільні suites не можна бездумно ставити на критичний шлях hotfix deployment: зайняті runners і нестача ресурсів створять чергу для всієї команди. CI-інтеграцію варто нарощувати після того, як визначено мету набору, тривалість, стабільність і місце його запуску.
Масштаб і production-like перевірка
[Дивитися з 18:00](https://www.youtube.com/watch?v=jAl2Qf8Zlyg&t=1080s). Embedded event widget, який працює для кількох users, може отримати сотні тисяч visits під час рекламної кампанії. Backend повинен віддавати event, tickets, prices, promo rules і registration fields без зайвих calls та bottlenecks. Живий перегляд checkout одночасно виявляє дрібні validation/UI inconsistencies, які agent або author легко пропускає без manual exploration.