Порядок - прежде всего!

Tags: 
Сидят Маугли и Каа. Маугли видит банан.
- Каа, этот банан никто не может достать?
- Да, Mаугли, его никто не может достать.
- Каа, даже сильный Балу не может его достать?
- Да, даже Балу не может.
- Каа, даже быстрая Багира не может его достать?
- Даже она не может.
- И даже ты, мудрый Каа, не можешь его достать?
- Да, Mаугли, даже я не могу.
Маугли задумался.
- Тогда я его достану!!!
- Да, Маугли, ты достанешь. Ты кого хочешь достанешь...
Анекдот
Началось все где-то в конце третьей недели с того момента, как я приступил к работе в офисе UBS. Примерно к этому времени я окончательно осознал, что в проекте творится полный бардак, куда ни ткнись. Особенно с учетом того, что я теперь на работе дурака не валяю, я очень хорошо чувствую значимость своего времени - а на что оно уходит, понять я никак не могу.

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

В результате мне приходится идти либо к автору, либо к менеджеру и допытываться, о чем тут речь. Человек, как правило, пару минут чешет затылок, пытаясь вспомнить, о чем тут шла речь. Потом его озаряет:
- А! Вспомнил! Это уже давно исправлено.
- Замечательно, только я не привык в таких вопросах верить на слово. Как это воспроизводилось?
- Э-э-э... а я не помню.

В результате тратилась куча времени (моего и собеседника) на то, чтобы вспомнить подробности. И, помимо всего прочего, примерно в каждом третьем случае оказывалось, что дефект либо не исправлен, либо исправлен не до конца - как правило, потому, что разработчик толком не знал, что именно надо исправлять.

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

Третьей (хотя по хронологии - самой первой, с которой я столкнулся) проблемой был тот факт, что с тестовой машиной все творят, что хотят, и никого не волнует, что я там тестирование провожу. К примеру, возникает у меня глюк. Я по привычке делаю несколько скриншотов и пытаюсь это дело воспроизвести. Никак. Посылаю скриншоты разработчикам:
- Как это получилось?
- Не обращай внимания, это мы сервис на тестовой машине перезапустили, поэтому и глюк возник.
- И что, на клиентской системе тоже все будет падать от малейшего перезапуска?
- А на клиентской мы так делать не будем.

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

Последней каплей стала следующая ситуация. Наткнулся на багу в состоянии "исправлено". Даже проставлена версия - как раз та, что у меня стоит на тестовой системе. Вроде даже вполне приличное описание, по крайней мере, понятно, что тестировать. Минут двадцать пытаюсь ее воспроизвести разными способами - не воспроизводится. Со спокойной совестью закрываю. Через пять минут приходит сообщение от разработчика, который над ней работал:
- Ты зачем ее закрыл?
- Я ее протестировал - на QA-билде она не воспроизводится.
- А у меня воспроизводится.
- Как? Расскажи шаги?
- Не знаю, я просто вижу, что в коде ошибка, а как воспроизвести - не знаю. Я как раз над ней работаю.
- Ладно, а почему ты ее пометил как "исправлено"?
- А я ее для себя пометил. Ты тестируй только те, что мы тебе в списке, прилагавшемся к билду выдали.
- А какого ж черта ты версию указал ту, которая уже в QA?
- А какая сейчас в QA?

В общем, стало ясно, что так дальше нельзя, поэтому на ближайшем собрании команды я поставил вопрос о процессе. Поскольку я сам в руководителях какое-то время побывал, больные точки менеджмента примерно представляю, поэтому знал куда бить: напирал на продуктивность и прозрачность. Записал в книжечку все эпизоды, когда из-за неразберихи в процессе неэффективно тратилось время, на пальцах объяснил, откуда это все пошло и показал, что корень зла - в отсутствии формального процесса. Да, мол, я понимаю, что у нас сейчас идет ускоренная черновая разработка, но это означает, что нужно использовать упрощенный процесс, а не отвергать все процессы полностью. Иначе все сэкономленные усилия не окупят тех рисков, что мы огребем ближе к концу проекта.

К моему удивлению, особых препятствий эта мысль не встретила, и на следующий день была назначена встреча, посвященная обсуждению процесса. Я подготовился к встрече основательно, даже задержался на полтора часа на работе. В итоге на свет появилась черновая презентация, где я расписал основные преимущества использования формального процесса, предлагаемую схему самого процесса и распределение ответствености. Для красоты даже понадергал цитат из статьи давно мною любимого Джоэла Сполски. Утром мы с моим непосредственным руководителем QA-щиком еще немножко эту презентацию подкрутили и получилось вполне достойно.

Встреча прошла гладко. Были долгие споры - но все конструктивные. Правда, я допустил пару чисто дипломатических ляпов. Во-первых, чуть не оттер на задний план собственного руководителя (поскольку процессы - это мой конек, и я действительно неплохо в них разбираюсь), во-вторых - в запале заявил, что "худшее описание дефекта - это то, которое содержит copy-paste из поля Summary". Да, это действительно так, только я забыл, что самый большой любитель создавать такие описания - наш менеджер проекта. Надо было все-таки как-то помягче :-)

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

И вот мы уже неделю работаем по новому процессу - вроде пока полет нормальный. Конечно, возникают мелкие недопонимания и сложности, но все это решаемо в рабочем порядке. Зато есть четкая видимость: кто за что в данный момент отвечает и насколько та или иная стадия проекта близка к завершению.

Я доволен :-)

Current Music: Dire Straits - Sultans Of Swing
Tags: testing, job

From: [info]yusup Date: 02/20/2008 00:53:37  

слушай, а как вообще можно работать без чёткого описания процесса?? как они до тебя там жили? :)
From: [info]svalivshiysja Date: 02/20/2008 05:35:28  

Юр, ты что, с луны? Не, это ж я оттуда:) Поверь мне - именно так и обстоят дела в большинстве софтверных контор, особенно на этапе бурной разработки и захвата рынка, т.е. тогда когда продано еще то что даже не придумано:)
From: [info]_myx Date: 02/20/2008 07:14:42  

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

Но все равно, меня очень сильно удивило, что в банке такой бардак. Это, кстати, касается не только процессов разработки. Вспомни, как я плутал по зданию :-)
From: [info]yusup Date: 02/20/2008 13:18:01  

верю :) но поскольку я с самого начала попал в компанию с очень солидными заказчиками, мне трудно себе представить что такое бывает :))
From: [info]_myx Date: 02/20/2008 07:09:21  

Разбаловался ты в своем Майкрософте :-)

Гм, а я - соответственно, в CQG :-)
From: [info]yusup Date: 02/20/2008 13:17:06  

да у нас не только Microsoft :) мы вот начинаем Linux тестировать с понедельника :) попробовали бы мы расслабиться и не следовать нашим процессам хоть на минуту :))
From: [info]lansun Date: 02/20/2008 06:01:18  

Да, непросто обстоят дела на чужбине.
Начинаю понимать, что у нас процессы поставлены практически идеально =)
From: [info]_myx Date: 02/20/2008 23:20:05  

Кстати, а как вам удается сохранить целостность? Вроде же вы тоже аутсорсинговая компания?
From: [info]lansun Date: 02/21/2008 07:59:43  

Думаю, на этот вопрос тебе vittt ответит лучше, чем я =)
From: [info]allucinazione Date: 02/20/2008 08:29:26  

Построил всех? :)
From: [info]_myx Date: 02/20/2008 23:11:34  

Получается, что так :-)
From: [info]ksch Date: 02/20/2008 15:47:05  

Молодец, приедешь - будет тебе пирожок с картошкой :-)
From: [info]vittt Date: 02/20/2008 18:45:23  

по ощущениям от прочитанного - полный бардак. Но, Влад, я в тебя верю!
From: [info]_myx Date: 02/20/2008 23:17:58  

Спасибо :-) Думаю, все получится. Еще две недели назад я сказал себе: "либо меня выгонят нафиг, либо я всех построю - третьего не дано". Пока вроде бы получается второе :-)
From: [info]aserofeev Date: 02/20/2008 20:21:51  

ужас-то какой...(((

ты меня прямо напугал... я теперь и не знаю чего от новой работы ждать...))

тут-то у меня весь Quality Control налажен уже по полной программе - и тебе багтрекинг полноценный (все всё везде заполняют - иначе ведь достану :)), и тебе письменные удоведомления о сборке билда и даже wiki проектная есть... программисты доступ к тестовым машинам вообще не имеют, кроме того, кто деплоит... и документация в соответствии со стандартами IEEE...

но мне и этого мало :))

блин, а как подумаешь, что всё заново надо будет начинать и до крови биться за каждую мелочь... так и уходить можно расхотеть :))
From: [info]_myx Date: 02/20/2008 23:16:26  

Самая распространенная ошибка: считать, что все плюсы старой работы сохранятся и на новой, а все минусы - останутся в старой :-)

А ты смотри на это с другой стороны: наладил, заработало - оставляй преемника и неси добро дальше.
From: [info]aserofeev Date: 02/21/2008 06:26:30  

Так и делаю... Больше всего меня в таких случаях challenge привлекает - смогу ли я донести добро в новый проект, и какого качества это добро будет ;-) Ибо когда все налажено, то скучно становится. "А он, мятежный, хочет бури..." и все такое ;-)
From: [info]tan_chick Date: 02/26/2008 14:32:44  

Дочитала "до была назначена встреча, посвященная обсуждению процесса." Чуть не разрыдалась, сдерживая приступ дежавю! :)
From: [info]_myx Date: 02/26/2008 14:54:17  

А ты его не сдерживай :-) Тем более, что, как мы все знаем по документальным фильмам, "дежавю - это сбой в Матрице" :-)

Комментарии