Наша команда совершенно не кроссфункциональная. У нас есть тестировщики и программисты, программисты тоже не все одинаково полезны, Есть программисты под Windows, есть программисты под Unix. Все это приводит к тому, что у нас есть задачи, выполнить которые может только определенная часть команды.
И поскольку работы во многом взаимосвязанны, то часть из них заблокирована. Тестировщики не могут начинать тестирование, пока не написан код. А пока тестировщики тестируют первую фичу - программисты уже пишут следующую. Вот против этого я и хочу немного восстать.
Вся работа команды состоит из последовательности фич. При таком рассмотрении это конвейер. Время выполнения работы на разных этапах не равно. Программисты могут справляться со своей работой быстрее тестировщиков. Но это совершенно не повод забегать вперед. Они могут пилить следующую фичу, чтобы для тестировщиков была работа. Но все последующие фичи должны быть заблокированы.
Программисты начинают ныть - нам нечем заняться, дай нам третью фичу. Они начинают говорить, что я не забочусь о сроках выхода и специально затягиваю выполнение эпика. Но они забывают, что без тестирования эпика нету. А тот код, который программисты успевают накодить мешает тестированию просто самим фактом своего существования.
Не понимают, что у них появляется возможность сделать то, что нельзя включать в планы. Программисты всегда могут найти чем заняться. Написание тестов, рефакторинг. В конце концов можно пойти к тестировщикам и помочь им с тестированием.
Это приводит к снижению ежедневных сторипоинтов, но они и так исчисляются не часами.
Программисты не хотят думать маленькими фичами... Они начинают сразу решать эпические проблемы. А что, говорят, мы будем по 10 раз возвращаться к одному и тому же коду. Лучше, говорят сразу написать все, что надо. В то же время написать эпик мы успеваем только за полтора месяца... при двухнедельных итерациях это совершенно неприемлемый срок достижения результата. Результаты должны быть маленькими и быстрыми. И такая разработка замедляет достижение краткосрочного результата.
Нашел замечательную аналогию. наш путь - это набор наших фич. И весь его надо пройти, но кто-то проходит его быстрее, кто-то двигается в конце.
В начале у нас бегут аналитики. Они уже почти зарелизились. Чем они занимаются сейчас - лично мне не понятно, но чувствую, что когда мы дойдем до очередной фичи, аналитики уже забудут кто и зачем писал эти требования.
Дальше бежит архитектор, он тоже витает в облаках, в смысле забегает вперед. По долгу службы. За архитектором гонятся прораммисты.
Программисты торопятся, больше накодить.. но результата то больше не станет, потому что результат определяется тем, как быстро бегут тестировщики.
Тестирощики бегут медленно, спотыкаются через баги, но программистам некогда исправлять баги, они уже далеко. Но смысл в том, что команда сдает только то, что сделали тестировщики. Они Определяют результат.
Комнада не должна разбегаться по дистанции. Надо поддерживать тех, кто бежит медленнее, и тогда все вместе финишируют быстрее.
И поскольку работы во многом взаимосвязанны, то часть из них заблокирована. Тестировщики не могут начинать тестирование, пока не написан код. А пока тестировщики тестируют первую фичу - программисты уже пишут следующую. Вот против этого я и хочу немного восстать.
Вся работа команды состоит из последовательности фич. При таком рассмотрении это конвейер. Время выполнения работы на разных этапах не равно. Программисты могут справляться со своей работой быстрее тестировщиков. Но это совершенно не повод забегать вперед. Они могут пилить следующую фичу, чтобы для тестировщиков была работа. Но все последующие фичи должны быть заблокированы.
Программисты начинают ныть - нам нечем заняться, дай нам третью фичу. Они начинают говорить, что я не забочусь о сроках выхода и специально затягиваю выполнение эпика. Но они забывают, что без тестирования эпика нету. А тот код, который программисты успевают накодить мешает тестированию просто самим фактом своего существования.
Не понимают, что у них появляется возможность сделать то, что нельзя включать в планы. Программисты всегда могут найти чем заняться. Написание тестов, рефакторинг. В конце концов можно пойти к тестировщикам и помочь им с тестированием.
Это приводит к снижению ежедневных сторипоинтов, но они и так исчисляются не часами.
Программисты не хотят думать маленькими фичами... Они начинают сразу решать эпические проблемы. А что, говорят, мы будем по 10 раз возвращаться к одному и тому же коду. Лучше, говорят сразу написать все, что надо. В то же время написать эпик мы успеваем только за полтора месяца... при двухнедельных итерациях это совершенно неприемлемый срок достижения результата. Результаты должны быть маленькими и быстрыми. И такая разработка замедляет достижение краткосрочного результата.
Нашел замечательную аналогию. наш путь - это набор наших фич. И весь его надо пройти, но кто-то проходит его быстрее, кто-то двигается в конце.
В начале у нас бегут аналитики. Они уже почти зарелизились. Чем они занимаются сейчас - лично мне не понятно, но чувствую, что когда мы дойдем до очередной фичи, аналитики уже забудут кто и зачем писал эти требования.
Дальше бежит архитектор, он тоже витает в облаках, в смысле забегает вперед. По долгу службы. За архитектором гонятся прораммисты.
Программисты торопятся, больше накодить.. но результата то больше не станет, потому что результат определяется тем, как быстро бегут тестировщики.
Тестирощики бегут медленно, спотыкаются через баги, но программистам некогда исправлять баги, они уже далеко. Но смысл в том, что команда сдает только то, что сделали тестировщики. Они Определяют результат.
Комнада не должна разбегаться по дистанции. Надо поддерживать тех, кто бежит медленнее, и тогда все вместе финишируют быстрее.
2 коммент.:
Второй абзац: "то честь из них заблокирована".
Наверное, "часть".
Спасибо, поправил.
Отправить комментарий