?

Log in

No account? Create an account

psilonsk


Блог об управлении проектами


Previous Entry Share Next Entry
Вопрос из зала: плохо формализованные задачи в ИТ-проекте
psilonsk


Одна милая барышня прислала письмо с проектным вопросом. Предлагаю помочь барышне добрым экспертным советом.

Примечания: место действия - Берлин, спринт - это двухнедельная итерация разработки ПО, орфография автора письма сохранена почти нетронутой.

Работаю тестировщиком сейчас в одном проекте, пишем десктоп-приложение. Создаются задачи на 2 недели, пока разработчики разрабатывают, я пишу тест-кейсы. Когда спринт закончен, они отправляют его на тестирование, и тестирование делает другой человек по моим тест-кейсам. Для меня схема слегка странновата, но у них так уж сложилось и как-то работает.
Проблема в следующем: задача содержит фразы типа "надо разработать загрузку фото", и там указывается, где это фото должно быть. Как это должно выглядеть не описано, устно говорят: "У нас везде такие загрузки используются". Но по мне загрузка, скажем,
PDF и загрузка фото - разные вещи. Ну и плюс в задаче было много информации, которая, как опять же оказалось при личном общении, будет сделана в другом спринте, просто забыли обновить.
На мое предложение описывать как должно быть, ПМ ответил: "у меня нет времени, ты всегда можешь все спросить". Получается, не спросила - сама виновата, что не поняла. Но! Что-то может измениться уже после того как задача в спринте и мы ее обсудили...

Чего мне делать?
1. Продолжать давить на ПМ каждый раз, но сегодня я уже получила: "твои замечания не имеют смысла, у меня нет времени" - испорчу отношения.
2. Идти к начальнику и говорить о проблеме с описанием задачи - не знаю о возможных последствиях.
3. Продолжать писать тест кейсы и дождаться чтобы разницу увидел человек, который проверяет - я буду виновата, что не спрашивала.
4. Ходить по каждому вопросу или собирать все в один и тратить один или два дня ПМ, пока он мне не объяснит требования к каждой задаче и ждать, пока ему надоест, - мне надоест первее :(

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




Ждем ваших умных комментариев и советов.)


promo psilonsk february 12, 2015 18:07 17
Buy for 100 tokens
Ранее в сериале: История первая: договор Ариадны История вторая: лыжи, смоктульки и чаевые История третья: мертвец и розетка ​*** — Послушай, Леша, послушай меня, милый мой друг. Ты же менеджер проектов, так? Ты же не дебил, правильно? Я тебе на пальцах объясняю, а ты понять не можешь.…

  • 1
Надо сесть рядом с разработчиком и писать тест-кейзы конкретно к тому, что он разрабатывает.

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

Ну, прочитали, например, в проектной документации "надо разработать загрузку фото", а как это должно выглядеть, не написано. Тогда идете к тому разработчику, который ее разрабатывает, и спрашиваете: как будет выглядеть твоя загрузка фото? И документируете, что он наобъясняет. Если такие загрузки действительно у них используются везде, то он даже сможет показать пример в работающем состоянии.

ну это то конечно. Это вполне укладывается в вышеописанную картину. Только надо всё записывать и держать улики в почте. Кстати, не всегда разработчик может показать работающий модуль. Кейсы могут писаться заранее.
Хотя в моей личной практике был случай, когда я именно сидела рядом с разработчиком и писала ПИМИ(ну те же кейсы, только страшнее), на основании его слов.
У девушки с опытом всё придёт.

Вот, я прямо как знал!

А если разработчик делает так как понял от ПМ, который в свою очередь понял от заказчика. Тест кейсы пройдут конечно, но смысл в них?

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

  • 1