Когато екипът доставя бавно, причината почти никога не са инженерите. Обикновено са четири или пет конкретни триения, които никой не е измерил.
«Екипът е бавен» е симптом и основателите обикновено го диагностицират погрешно като проблем с хората. По наш опит почти винаги е системен проблем: работата чака на опашки, промените са големи и рискови, разгръщането плаши, а никой няма числа, с които да спори.
Започнете с четири измервания
Тези четири са добре утвърдени и, което е по-важно, диагностични: всеки лош резултат сочи към конкретен клас проблем.
| Метрика | Какво разкрива, когато е лоша |
|---|---|
| Честота на разгръщанията | Твърде голям размер на партидата, разгръщанията се третират като събития |
| Време за доставяне на промяна | Време на опашка — обикновено code review или чакане на QA, а не писане на код |
| Дял на неуспешните промени | Слабо тестване или липса на съответствие между staging и продукция |
| Време за възстановяване | Няма репетиран rollback, слаба наблюдаемост |
Обичайните констатации
Code review е тясно място, а не врата за качество
- Pull request-ите са твърде големи, за да бъдат прегледани смислено, така че review-то се превръща в театър на одобрението
- Няма очакване за време за отговор при review, така че промените стоят с дни
- Един сениор инженер е единственият одобряващ — опашка с едно гише
Разгръщането е събитие
- Ръчни стъпки, които знае само един човек
- Няма rollback, на който някой да вярва, затова release-ите се трупат на пакети, което ги прави по-рискови, което ги прави по-редки
- Разгръщания, планирани за спокойни часове — силен сигнал, че екипът не вярва на процеса
Работата всъщност не е дефинирана
- Задачи, които изискват разговор, преди някой да може да започне
- Няма споделена дефиниция за завършено, така че работата се люлее между разработка и QA
- Твърде много работа в процес — всички са заети, нищо не завършва
Какво да промените първо
- Направете разгръщанията скучни — автоматизирайте, добавете rollback, упражнете го. Всичко останало се подобрява, щом пускането стане безопасно.
- Намалете размера на партидите — по-малките промени се преглеждат по-лесно, пускат се по-безопасно, диагностицират се по-бързо.
- Задайте SLA за review — часове, не дни, с втори одобряващ, за да не бъде един човек тясното място.
- Ограничете работата в процес — завършването бие започването.
- Инструментирайте това, което клиентите усещат, за да се откриват инцидентите вътрешно, а не да идват като сигнали.
Скоростта и безопасността не са компромис в доставянето на софтуер. Екипите, които разгръщат най-често, имат и най-нисък дял откази — защото малките, чести, обратими промени са едновременно по-бързи и по-безопасни.
Изследвайте работата без класиране на хора
Съпоставими задачи разкриват ограниченията на системата. Обяснявайте чакане и преработка, без да бъркате активност с продуктивност.
- Изберете няколко завършени промени, включително спешна поправка.
- Измерете опашки, прегледи, предавания и затруднения при внедряване.
- Изпробвайте подобрение с начална стойност и дата за оценка.
Често задавани въпроси
Колко време отнема одит на инженерните процеси?
Обикновено една до две седмици: събиране на данни за доставянето, интервюта с екипа, наблюдение на реален release и преглед на инструментите. Резултатът трябва да е малък брой приоритизирани промени с очакван ефект, а не оценка по модел на зрялост.
Ще ни кажете ли да въведем Scrum?
Не. Методологията рядко е ограничението — такива са времето на опашка, размерът на партидата и рискът при разгръщане. Екипи са доставяли добре при всеки фреймуърк и зле при всички; смяната на церемонията без промяна на тези три неща не постига нищо.
Екипът казва, че са нужни повече инженери. Вярно ли е?
Понякога, но наемането в процесно тясно място първо влошава нещата — повече хора произвеждат повече незавършена работа срещу същите опашки за review и разгръщане. Първо измерете накъде наистина отива времето; ако по-голямата част е време на опашка, наемането не е решението.
Може ли да сравняваме екипи по сурови показатели?
Само с контекст за продукт, задачи и оперативни ограничения. Тенденциите помагат за диагноза; броят действия сам не доказва ефективност.
Екипът доставя по-бавно, отколкото трябва?
Измерваме накъде наистина отива времето и отстраняваме основните ограничения — обикновено за седмици, не за тримесечия.
Още по темата
Постмортем: добри практики за документ, който хората наистина четат
Повечето постмортеми са археология: точен запис на нещо, което никой няма да промени. Полезният произвежда малък брой неща, които наистина се случват.
Технически одит на MVP: какво проверяваме през първите 48 часа
Повечето одити на MVP произвеждат документ. Полезният произвежда решения: какво гори, какво може да чака и колко струва поправката.