Про взаимодействие в команде
Заметил такую штуку, что вначале разработки какой-либо задачи центр компетенций находится у аналитика. Он бегает по разработчикам, что-то уточняет и обсуждает реализацию, фиксирует это в ТЗ. В итоге, он "торжественно объявляет", что я вот все продумал, вот ТЗ для всех, мы делаем такую-то задачу. Разработчики пока разбираются в своих задачах, ходят к аналитику разъяснить что и как.
Дальше все уходят работать и по мере готовности отдают на тестирование. И чем больше степень готовности и больше кода отдано на тестирование, тем больше точка компетенции смещается к тестировщику. В случае возникновения вопросов разработчики начинают собираться уже вокруг тестировщика, потому что он в курсе у кого как что работает и как оно устроено в целом. Центром компетенций становится тестировщик.
По итогу, аналитик работает в режиме backmerge. Просто, спрашивает "Чего вы там сделали без меня?" и фиксирует это в своих документах. Ну, может быть, ходит к смежным командам что-то согласовать, но не более.
И чем дольше по времени задача и чем больше в целом нагружен аналитик, тем ярче выражен этот эффект. Оно и понятно. За время разработки аналитик переключается на другие задачи и выпадает из контекста. И чем дольше разработка, тем больше аналитик успевает позаниматься чем-то еще и опять же потерять контекст.
Не знаю хорошо это или плохо, но иногда кажется не очень хорошей ситуация когда способность синкнуть разработчиков растворяется и размазывается на всех. Как это должно быть правильно по AGILE я так и не понял.
Я работал в разных командах и везде такая ситуация. Возможно, потому что везде сильные взрослые опытные разработчики. Будь там какие-то джуны, они бы просто не дали своими постоянными вопросами аналитику выпасть из контекста.
tg: @frontend_love
· 1 ч
Тоде не знаю, как должно быть по agile-методичкам. Но знаю, что модульные тесты -- это копия ТЗ. Исходя из этого тезиса, работа над тестами (хоть разработчиков, хоть тестировщиков) -- это просто перевод ТЗ на другой язык. Очевидно, что сразу все нюансы в ТЗ не учтешь, да и не для этого ТЗ создано. ТЗ -- это верзнеуроаневый план. Поэтому на стадии разработки разработчик и тестировщик уточняют ТЗ граничными условиями, ошибочными сценариями и т.д. Записывают их в тесты (хоть рукописные, называемые тест-кейсами, хоть модульные или любые другие). Но это уточнение в обязательном порядке надо не забывать возвращать в ТЗ. Иначе, будут огромные проблемы позже, когда надо будет вернуться к текстовому описанию, а в нём -- меньше половины описания реального поведения.
Так что выглядит не просто логично, но и правильно.
Приветствую, коллега! 🤝
ответить
коммент удалён