Горшочек, не вари!

Был случай на одном проекте.

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

Тестеры поразбирались недельку с системой и начали заводить баги. Штук по 10 в день.

Менеджер через пару дней очнулся, пришел в ужас от количества багов и осознания того что заказчики вскоре увидят реальное состояние дел. Сперва пробовал заворачивать баги обратно тестировщикам с посылом: "не баг, а фича", но программисты по большей части не разделяли такое мнение, т.к. баги есть баги и лучше их сейчас пофиксить чем потом, когда заказчики увидят и если не уволят. Менеджер же устраивал долгие разборы тестировщикам, пытался унять их продуктивность, но те не особо поддавались.

Закончилось тем что тестеров отправили обратно на родной проект, менеджеру их проекта объявили что "тут вам не здесь", мол, рано им еще с такими задачами работать.

Из всех багов успели пофиксить всего несколько штук. Через пару месяцев проект закрыли без объяснений, программисты ушли на скамью запасных ждать следующего.

IT-юмор

5.6K пост52.4K подписчиков

Добавить пост

Правила сообщества

Не публикуем посты:
1) с большим количеством мата
2) с просьбами о помощи
3) не относящиеся к IT-юмору

Вы смотрите срез комментариев. Показать все
19
DELETED
Автор поста оценил этот комментарий

Пам-пам, и это ЕПАМ! фьюить!

раскрыть ветку (15)
10
Автор поста оценил этот комментарий

Такая фигня не только в ЕПАМе. Лет 5 назад работал в компании одной (люди душевные, но платить деньги не любили) в качестве QA на проекте. И багов серьёзных накопилось под сотню. Я начал долбить РМ на тему "хватит пилить фичи, давайте начнём баги править в конце концов", и двухнедельных спринт полностью отдали на фикс. Ну и через две недели счастливый РМ вопрошает:

- Ну, что сколько багов осталось?

- чуть больше 200

- но ведь было 100 всего?

- а мы не могли до части функционала из-за них добраться, вот добрались.


Проект так до сих пор и не сдали, на сколько я знаю.

Иллюстрация к комментарию
раскрыть ветку (1)
5
Автор поста оценил этот комментарий

Дааа! Было пару раз что давали никем не тещщщенный проект в надежде что я проверю, скажу что всё ок и закрою задачи... А вместо этого я заводила ещё кучу багов ^_^ Правда в моем случае большинство из них постепенно правились

Автор поста оценил этот комментарий
Все чаще натыкаюсь на хейт ЕПАМа, неужели там все так плохо?
раскрыть ветку (12)
10
DELETED
Автор поста оценил этот комментарий

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

раскрыть ветку (11)
4
Автор поста оценил этот комментарий

Любая крупная аутсорсная контора работает по принципу "набора в команду совершенно разных людей, зачастую которые видят друг друга первый раз на проекте, а также то, что их подбирают по матрице скилов". Ничего удивительного и плохого в этом, ибо некоторые заказчика предъявляют требования в стиле "хотим сеньора с 10+ лет опыта" (а на интервью задают вопросы на уровень джуна, да). Плюс некоторые проекты требуют 3-4 людей, а некоторые и 30-40.

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

И нет, в епаме я не работала :)

раскрыть ветку (8)
4
Автор поста оценил этот комментарий

ну, помимо этого есть и способы наладить нормальную разработку внутри команды (в епам не работал, но сейчас работаю на небольшую аутсорсинговую компанию):

1. CI/CD

2. Прогонка автотестов (юнит, интеграционные, e2e) на каждый коммит (в любой ветке)

3. Жесткие требования по стилю кода

4. Крэш репортинг с автоматическим заведением багов в тикет системе

4. Анальные кары за плохое покрытие кода тестами, за высокий рейт падений, за низкий рейт ci/cd пайплайнов.


В целом, у нас это работало на следующем стеке:

1. Gitlab (+ Gitlab CI/CD) - хостинг кода, плюс пайплайны с тестами

2. Sentry - крэш репортинг с автоматическим заведением тасков в редмайне

3. Codeception - PHPUnit (юнит тесты + интеграционные), Selenium (e2e тесты)

4. Мелкие проверки:

4.1 PHPCSFixer - кодстайл с жесткими правилами

4.2 Symfony Security Checker - проверка зависимостей на уязвимости

4.3 Unused scanner - проверка неиспользуемых зависимостей


Сам пайплайн состоял из следующих этапов:

I. Тестирование

1. Проверка кодстайла. Не там поставил запятую или микс/табов пробелов в одной строчке? Аварийное завершение пайплайна, иди переделывай.

2. Проверка уязвимостей. Хотя бы одна зависимость имеет минорную уязвимость? Аварийное завершение, иди переделывай

3. Неиспользуемые зависимости. Добавил что-то лишнее или зависимость для "потом доделаю"? Аварийное завершение, иди переделывай.

3. Юнит тесты, интеграционные тесты, e2e тесты. Хоть что-то упало? Аварийное завершение, иди переделывай.

II. Сборка

Расписывать не буду, использовали докер.

III. Деплой

Тоже не буду расписывать.


За покрытие кода тестами меньше 70% жестко имели тимлидов, а те - команду (меньше 90% - на пол-шишечки, среднее покрытие "по больнице" было 94-95%, у некоторых - 99.7-99.8%), за пайплайн рейт (отношение успешных пайплайнов к проваленным, в процентах) ниже 60% опять же жестко имели (этот рейт считался по всем веткам в репозиториях проекта, т.е. и dev и qa и master, поэтому такая цифра).


Звучит жутко? Некоторые при введении такой системы взвыли, но в целом за несколько месяцев приучились на ней работать. Стоит ли говорить про то, что качество и стабильность выросла в разы?

Важные моменты:

1. Время на тестирование изначально закладывалось в каждый проект (40% от времени на разработку, в особо сложных эпиках - 60%),

2. В проекте был минимум 1 QA (постоянный) и иногда (в зависимости от размера проекта) еще 1-2 QA подключались на время.

3. Разработка проектов велась с нуля (т.е. это не "вот мне тут другие ребята сделали такую штуку,но поддерживать не хотят, так что вот вам деньги, вот там штука - допилите по красоте", а весь цикл разработки был наш)


PS: названий не будет, nda

раскрыть ветку (7)
3
Автор поста оценил этот комментарий

Все правильно. CI/CD, автотесты обязательно, требования к стилю, типовые конструкции кода и тому подобное. Главное до абсурда не доводить. Вот на соседнем проекте смотришь переписку в пулл реквестах и плачешь: апруверы отказывают подтверждать изменения вплоть до "неправильно расставлены запятые в комментарии", и все это выливается у них в бесконечные портянки срача. Простейшие правки могут зависнуть на неделю: "ну, и что что это легаси код и нужно изменить только размерность поля для совместимости с новыми разработками? У нас сейчас принято по другому, поэтому эту процедуру нужно переписать и каждую строку сопроводить комментарием".  😀 Возможно в чем-то они и правы, но когда из-за этого разработка затягивается в 5 раз по времени, имхо, это не правильно. Нужно сохранять некий баланс.

3
Автор поста оценил этот комментарий

Качественный процесс, только однажды работал в таком месте.

Кроме субъективных страхов людей им тогда пришлось преодолеть еще и давление по поводу производительности: объем нового выпускаемого функционала упал и не поднялся. Как ни крути, нужно время на юнит тесты, код ревью, тестирование и поддержание инфраструктуры.

раскрыть ветку (2)
1
Автор поста оценил этот комментарий

угу, нам очень повезло в том плане, что позволили изначально в проект закладывать много времени именно на повышение стабильности и работу с техническим долгом. К сожалению, у меня тоже такое удалось только в текущей компании :(

Автор поста оценил этот комментарий

Просто не получится сразу и рыбку съесть, и кости сдать. Процесс перехода нельзя выполнить мгновенно, нужно постепенно (для нового кода) применять новые правила. Да, скорость разработки упадёт, но зато в долгосрочной перспективе будет большая экономия времени за счет уменьшения количества ошибок, более читаемого кода и так далее. Хотя Совы обычно этого не понимают, хотят всё и сразу, и ещё чтобы сеьорам платили как джуниорам. Очень многое зависит в итоге от ПМ.

2
Автор поста оценил этот комментарий

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

1
Автор поста оценил этот комментарий

Звучит, кстати, не жутко, очень многие проверки  легко автоматизируются на этапе сборки, а микс пробелов и табов вообще лечится настройкой IDE, достаточно один раз надавать по рукам и рассказать/кинуть ссылку на то как настроить.

Автор поста оценил этот комментарий
Что-то много текста. Лучше по старинке. Хуякхуяк и в продакшн
2
Автор поста оценил этот комментарий

епам - это такая галера?

раскрыть ветку (1)
2
Автор поста оценил этот комментарий
Ага
Вы смотрите срез комментариев. Чтобы написать комментарий, перейдите к общему списку