Всем привет!
Хочется сказать пару слов о практике T-Shape. Это когда помимо своей основной специальности - например, разработки, ты развиваешь навыки в чем-то еще. Какие именно - если рассмотреть состав типовой команды, то это будут аналитик или тестировщик. Если смотреть дальше - это могут быть DevOps, НТ. Даже может быть сопровождение ПРОМа. Насколько я знаю, такая практика применяется в лидере российского ИТ - Яндексе. Рассмотрим плюсы и минусы на примере разработчика-тестировщика.
Плюсы в целом очевидны:
1) взаимозаменяемость членов команды
2) упрощение найма за счет унификации
Но есть и минусы.
1) суть работы тестировщика - найти проблемы в коде, рассматривая его как черный ящик. Именно потому, что тестировщик не знает, что внутри, но знает, как оно должно работать - ему удается найти те баги, которые не увидел разработчик. У которого просто замылился глаз, т.к. код он знает, он его проектировал, рефакторил, отлаживал. По тому же принципу, к слову, работает ручное код-ревью. Код-ревью и тестирование можно рассматривать как 2 последовательных рубежа обороны. Конечно, можно ввести практик: код пишет один разраб, а тестирует обязательно другой. Но это уже усложнение и влияние человеческого фактора.
2) как я вижу развитие инженерных специальностей и ИТ в частности - все развиваются в сторону более узкой специализации. Да, любую технологию, фреймворк, библиотеку или платформу можно изучить. Проблема в том, что их очень много. Много и в разработке, и в тестировании. И "распыляя" свои усилия на 2 направления есть риск полноценно не научится ни тому, ни другому.
3) этот пункт субъективный из-за того, что я разработчик. Сравнивая разработку и тестирование как две области деятельности я бы всегда выбирал разработку. IMHO, подчеркну, что INHO, она сложнее, имеет больше направлений и поэтому интереснее. Отсюда риск, что на тестирование будет выделяться меньше времени. Вопрос в уровне инженерной культуры и дисциплине, но это снова человеческий фактор. В каких-то командах баланс будет найден, в каких-то нет и в итоге мы получим недотестированный код и баги ПРОМа.
Итог - практика интересная, но требует высокой инженерной культуры в компании и подвержена рисками человеческого фактора.
#t_shape #devops #testing #dev
Хочется сказать пару слов о практике T-Shape. Это когда помимо своей основной специальности - например, разработки, ты развиваешь навыки в чем-то еще. Какие именно - если рассмотреть состав типовой команды, то это будут аналитик или тестировщик. Если смотреть дальше - это могут быть DevOps, НТ. Даже может быть сопровождение ПРОМа. Насколько я знаю, такая практика применяется в лидере российского ИТ - Яндексе. Рассмотрим плюсы и минусы на примере разработчика-тестировщика.
Плюсы в целом очевидны:
1) взаимозаменяемость членов команды
2) упрощение найма за счет унификации
Но есть и минусы.
1) суть работы тестировщика - найти проблемы в коде, рассматривая его как черный ящик. Именно потому, что тестировщик не знает, что внутри, но знает, как оно должно работать - ему удается найти те баги, которые не увидел разработчик. У которого просто замылился глаз, т.к. код он знает, он его проектировал, рефакторил, отлаживал. По тому же принципу, к слову, работает ручное код-ревью. Код-ревью и тестирование можно рассматривать как 2 последовательных рубежа обороны. Конечно, можно ввести практик: код пишет один разраб, а тестирует обязательно другой. Но это уже усложнение и влияние человеческого фактора.
2) как я вижу развитие инженерных специальностей и ИТ в частности - все развиваются в сторону более узкой специализации. Да, любую технологию, фреймворк, библиотеку или платформу можно изучить. Проблема в том, что их очень много. Много и в разработке, и в тестировании. И "распыляя" свои усилия на 2 направления есть риск полноценно не научится ни тому, ни другому.
3) этот пункт субъективный из-за того, что я разработчик. Сравнивая разработку и тестирование как две области деятельности я бы всегда выбирал разработку. IMHO, подчеркну, что INHO, она сложнее, имеет больше направлений и поэтому интереснее. Отсюда риск, что на тестирование будет выделяться меньше времени. Вопрос в уровне инженерной культуры и дисциплине, но это снова человеческий фактор. В каких-то командах баланс будет найден, в каких-то нет и в итоге мы получим недотестированный код и баги ПРОМа.
Итог - практика интересная, но требует высокой инженерной культуры в компании и подвержена рисками человеческого фактора.
#t_shape #devops #testing #dev
Всем привет!
В комментариях к предыдущему посту (на Хабре) справедливо заметили, что T-Shape может быть вынужденный.
Это когда есть приложение на редкой технологии, а команда создавшая его разбежалась. Примеры технологий, которые вспомнил: Informatica, Erlang, хранимые процедуры в БД... Или legacy монолит и снова команды уже нет. А точнее остались 1-2 человека. На рынке людей или не найдёшь (редкая технология) или они не тянут распил незнакомого им монолита (второй кейс).
В этом случае оставшиеся члены команды поневоле становятся t-shape-ми.
Случай грустный. При выборе технологий была допущена ошибка, ее приходится исправлять. Но есть и плюсы. Опыт трансформации legacy, да ещё в T-shape режиме - задача очевидно сложная. А бизнесу нужны люди, умеющие решать сложные задачи.
#dev #t_shape
В комментариях к предыдущему посту (на Хабре) справедливо заметили, что T-Shape может быть вынужденный.
Это когда есть приложение на редкой технологии, а команда создавшая его разбежалась. Примеры технологий, которые вспомнил: Informatica, Erlang, хранимые процедуры в БД... Или legacy монолит и снова команды уже нет. А точнее остались 1-2 человека. На рынке людей или не найдёшь (редкая технология) или они не тянут распил незнакомого им монолита (второй кейс).
В этом случае оставшиеся члены команды поневоле становятся t-shape-ми.
Случай грустный. При выборе технологий была допущена ошибка, ее приходится исправлять. Но есть и плюсы. Опыт трансформации legacy, да ещё в T-shape режиме - задача очевидно сложная. А бизнесу нужны люди, умеющие решать сложные задачи.
#dev #t_shape