Сказка о двух ящиках и одной тестировщице

Жила-была маленькая тестировщица, и по неопытности своей считала, что белый ящик - для программистов, а черный - Мекка для тестировщиков.
Но однажды наступил момент, когда ей в Jira подключили FishEye, и она смогла видеть то, каким образом был пофикшен тот или иной баг, или каким образом был заимплеменчен тот или иной функционал. По началу все изменения выглядели как наскальная живопись - было понятно о чем речь лишь по мутным и примитивным очертаниям. Тогда она стянула себе из системы контроля версий репозиторий, и очертания стали больше напоминать то,что они значили, ибо в IDE можно было перемещаться по классам и методам, чтобы понимать, что происходит. И тогда коммиты стали понятней, и несмотря на практику код ревью, принятую в команде, маленькая тестировщица все равно заглядывала в новый код посредством FishEye.
Это привело к тому, что отныне делать impact анализ можно было основываясь не только на словах разработчика и собственных предположениях, но и на том, что она сама видела. И оказалось, что, как правило, изменения затрагивали гораздо больше того, что было сказано разработчиком, и тестов нужно было сделать гораздо больше, чтобы убедиться в правильности имплементации. Чек листы стали более полными, что позволяло отловить больше багов.
А маленькая тестировщица теперь при получении тикета в Jira первым делом открывает вкладку Source и смотрит изменения в файлах, а уж потом приступает к тестированию. А в случае, если на нее ассайнят тикет, где такая вкладка для нее отсутствует, она брезгливо морщится и тяжело вздыхает.

Не стоит брезговать выпрашивать открыть код любыми доступными способами и смотреть реализацию методов. Это поможет лучше понимать, у каких кейсов реально есть шанс отловить ошибки, а какие делаются просто для того, чтобы "погладить кота по шерсти" и убедиться, что все работает в тепличных условиях. Можно сколько угодно долго рассуждать о классах эквивалентности, граничных значениях и тому подобных вещах,

но это не имеет никакого смысла до тех пор, пока нет доступа к коду.

Lessons learned in SCRUM. Lesson 2 - Add new person to help или "Ой ли?"

Никогда не верила в тот постулат, что добавление нового человека в скрам команду по началу влечет за собой потерю производительности. Ведь человека добавили, дополнительный мозговой центр и обладатель рук может только помочь!
Но на практике оказалось,что есть большая разница между тем, кого именно добавляют. И речь идет не столько о скиле (что тоже немаловажно), сколько о персональных качествах нового члена команды.
Итак, к примерам из жизни, но в этот раз без графиков, к сожалению.

Пример 1. В команду добавили не очень опытного человека. Он хочет учиться, у него горят глаза, ему нравиться работать в команде опытных людей. В нашем случае это привело к тому, что производительность команды не упала, а незначительно увеличилась. Безусловно, часть времени тратилась на помощь новичку в освоении новых знаний, в то же время порученную ему работу он делал добросовестно, давая более опытным товарищам время на работу с более сложными задачами.  
Пример 2. В команду добавили опытного человека. Он мыслит рационально, спокоен и рассудителен. Первый спринт производительность незначительно увеличилась, но после первого спринта начался рост и стабильный прирост к производительности команды, которую она показывала ранее.
Пример 3. В команду добавили опытного человека. Он реформатор, стремится улучшать качество продукта и процессов, но делает это слишком настойчиво и рьяно, его трудно убедить, даже если он просто явно не понимает еще всех внутренних процессов и условий работы.
Первый спринт производительность немного просела, потом вернулась к прежнему значению. По мере вливания нового человека в процесс производительность команды повышалась, и остановилась примерно на той же отметке, что и при добавлении человека из второго примера. Несмотря на то,что потенциал человека из примера 3 значительно выше, ожидаемого эффекта улучшения не получилось по той причине, что в команде возникло некоторое напряжение, связанное с непривычной для команды манерой обсуждения спорных моментов и невозможностью положиться на опыт друг друга - новичок не может положиться на опыт команды, так как еще не доверяет ей, а команда не может еще положиться на опыт новичка, так как привыкла решать проблемы сообща и приходя к компромиссу на основании выбора лучшего варианта на данный момент.

Подытоживая, хочу отметить, что к выбору нового человека в сложившуюся скрам команду нужно подходить с большой серьезностью и оценивать не только профессиональные качества кандидата, но и личностные. То, насколько быстро и безболезненно он вольется в команду, и вольется ли, напрямую влияет на отношения внутри команды и ее производительность. Не гонитесь за скилами кандидата - сначала прикиньте, сколько времени и сил займет у обоих сторон сгладить углы во взаимодействии.