Сообщений в теме: 20

[baranceva]

Автор: Наталья Руколь

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


Роль требований в процессе разработки
Требования похожи на единорогов. Такие же прекрасные мифические создания, несущие людям счастье  В ~99% проектов, с которыми я сталкивалась, требования:

• Были неполным
• Были некорректным
• Отсутствовали

Выбирайте любые пункты из трёх, а иногда и все вместе.

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

Как всегда, у нас есть выбор. Вариант #1 – подождать: а вдруг появятся? Чтобы ожидание не было скучным, можно разбавлять его регулярными жалобами на нехватку требований и байками из серии «а вот в нормальных компаниях…».

И есть вариант #2 – построить процесс таким образом, что у вас появятся требования. Именно об этом варианте мы и поговорим в статье.



Читать дальше

[Фрося]

уф... да... без требований плохо!

Вопрос появился.
А по какому принципу требования делились на функциональные и не функциональные?

Например, ограничения на размер картинок почему вдруг попали в нефункциональные требования?

Честно говоря, всеми возможностями форума не пользуюсь.
Что опрос - это принадлежность темы - мне понятно.
А вот что картинка - принадлежность темы, честно говоря не думала. Это интересно! Надо порыться и попробовать темы создавать с картинкой по теме! К этой теме например пририсовать картинку с параллельными/непараллельными прямыми!
Полагала, что картинка это принадлежность ответа(поста).

[LeshaL]

Вопрос появился.
А по какому принципу требования делились на функциональные и не функциональные?

Например, ограничения на размер картинок почему вдруг попали в нефункциональные требования?

Возник тот же самый вопрос. Дочитал до этого места и решил отложить до прояснения вопроса. Хотел спросить, но был опережен.

[Фрося]

уф... еще вопросы появились.

"В ~99% проектов, с которыми я сталкивалась, требования:
Были неполным
•Были некорректным
•Отсутствовали
"

1. Где-то дальше в статье предлагается зафиксировать требования и начать обсуждать с аналитиком.
Т.е. что? Аналитик работал плохо (раз требований нету или они плохие), а тут рррраз -- и осознал, что вот требования надо обсуждать и анализировать?
2. По поводу инструментов. Ежели предполагается некий коллектив запирать в комнате, чтоб требования обсудить и согласовать; то вот бутылку мартини ставлю -- не будут они ни в вики лазить, ни еще куда. Максимум -- крестики поставят на листе бумаги или почеркают этот лист. Или -- вообще просто будут о чем -то рассуждать.
Так что инструмент для сбора требований должен позволять легко печатать эти листы бумаги. Причем -- шрифтом удобном и в простецком виде. Word великолепно подходит!
И БЛОКНОТ!!! Банальный бумажный блокнот для записи потока рассуждений участников!

[Natalya Rukol]

Вопрос появился.
А по какому принципу требования делились на функциональные и не функциональные?

Например, ограничения на размер картинок почему вдруг попали в нефункциональные требования?

Фунциональные требования отвечают на вопрос "что делать?":
- загружать картинку на сервер
- отображать в форме
- вставлять её в текст сообщения
и т.д.

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

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

Почему так? Проверено - удобно!

Можно ли по-другому? Наверное, можно, но в моей практике получилась каша, когда мы делали вложенные требования к "загрузке картинок": "jpg", "png" и т.д. В итоге мы переделывали по схеме, описанной в статье.

[Natalya Rukol]

уф... еще вопросы появились.

"В ~99% проектов, с которыми я сталкивалась, требования:
Были неполным
•Были некорректным
•Отсутствовали
"

1. Где-то дальше в статье предлагается зафиксировать требования и начать обсуждать с аналитиком.
Т.е. что? Аналитик работал плохо (раз требований нету или они плохие), а тут рррраз -- и осознал, что вот требования надо обсуждать и анализировать?

Угу. Очень силён человеческий фактор.
1) аналитик уверен, что написать все требования - это долго и нудно, а тут ему показывают, насколько просто начать.
2) вместо нытиков "нам нужно вот это" он сталкивается с людьми, которые готовы что-то сами делать, и просят только помощь и поддержку, а не "сделайте всё за меня".
3) в тайм-менеджменте есть приём "съесть слона". "Написать требования к продукту" - это слон, которого скушать нереально. А тут мы режем его на кусочки, и просим объяснить вот эти 4, самые непонятные из 300, требования. Это - запросто, потому что можно сделать быстро!
4) слоник порезан, части сделаны. В моей практике сразу всплывает куча косяков, заводятся баги, что-то меняется к лучшему. Аналитик видит: "ого! потратил час - и столько пользы", и к следующей просьбе "растолкуй вот эти 6 требований" относится с позитивом!
5) если перейти на следующий уровень развития, и помимо требований начать вести измеримые риски качества, можно ввести простую статистику. "Вот здесь, после адекватного выяснения 10 требований, мы нашли 16 багов. Следовательно, невыясненные 290 требований - 464 ненайденные баги. Вы к этому готовы?"

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

2. По поводу инструментов. Ежели предполагается некий коллектив запирать в комнате, чтоб требования обсудить и согласовать; то вот бутылку мартини ставлю -- не будут они ни в вики лазить, ни еще куда. Максимум -- крестики поставят на листе бумаги или почеркают этот лист. Или -- вообще просто будут о чем -то рассуждать.
Так что инструмент для сбора требований должен позволять легко печатать эти листы бумаги. Причем -- шрифтом удобном и в простецком виде. Word великолепно подходит!
И БЛОКНОТ!!! Банальный бумажный блокнот для записи потока рассуждений участников!

В блоконте нет иерархии, структуры, статусов. В общем, давай розовый мартини - когда мы запирались на 2 недели, мы сидели с ноутбуками в шарпоинте.


А вообще, вижу в ответе недоверие "так не получится, аналитика за один день не изменить, требования в системе прорабатывать не получится и т.д."
Без паники! Всё проверено, всё работает :) Не веришь - проверь, только не с целью доказать, что не получится (как говорил Генри Форд: "неважно, что вы доказываете, что можете что-то или что не можете, у вас в любом случае это получится").

[Фрося]

Вопрос появился.
А по какому принципу требования делились на функциональные и не функциональные?

Например, ограничения на размер картинок почему вдруг попали в нефункциональные требования?

Фунциональные требования отвечают на вопрос "что делать?":
- загружать картинку на сервер
- отображать в форме
- вставлять её в текст сообщения
и т.д.

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

(пожимая плечами).
Автор в любой своей статье вправе вводить любые свои собственные определения.
Только тогда:
1. Это определение надо формулировать в статье. Желательно в начале статьи.
2. Желательно доказать непротиворечивость системы определений автора и продемонстрировать, что так лучше.

[elfische]

А я вот не поняла, как связано название с содержанием. Могу, конечно, придумать объяснение, которое меня даже устроит, но сам факт непонимания есть.

[Фрося]

А вообще, вижу в ответе недоверие "так не получится, аналитика за один день не изменить, требования в системе прорабатывать не получится и т.д."
Без паники! Всё проверено, всё работает :) Не веришь - проверь, только не с целью доказать, что не получится (как говорил Генри Форд: "неважно, что вы доказываете, что можете что-то или что не можете, у вас в любом случае это получится").

Недоверие?
К поеданию слона по кусочкам? Нисколько - работает (ну... это ж такая распространная фишка!).

Обсуждать статью, я думаю, интересней.

Наташа!
Вот прямо здесь, на форуме, попробуй создать тему с картинкой.

Требование:
Создание тем.
Вставка картинок.

есть же в твоей статье? Так?

Т.е. чтоб была тема, а где-нибудь рядом с опросом к теме -- и картинка.

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

Ну вот если создашь -- тогда есть смысл статью обсуждать.
Если не удастся -- смысла нету обсуждать статью-то.

Вообще сбор, анализ, и фиксирование требований -- сильно объемная тема. Взгляд тестировщика.
На мой вкус -- очень такая темка подходящая для бурного обсуждения на SQA 10!

[Фрося]

Вот!

[elfische]

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

[Natalya Rukol]

Автор в любой своей статье вправе вводить любые свои собственные определения.
Только тогда:
1. Это определение надо формулировать в статье. Желательно в начале статьи.
2. Желательно доказать непротиворечивость системы определений автора и продемонстрировать, что так лучше.

Я не ввожу определений! Анализ (любой, при проектировании продуктов или при проектировании тестов) - это искусство, а не ремесло. Если собрать в одной комнате 5 супер-пупер аналитиков, а в другой 5 супер-пупер тест-дизайнеров, и выдать в каждой комнате одинаковые задачи, каждый участник сделает результат по-своему. Нет "единственно правильного" решения, и я его не навязываю - это то же самое, что объяснять художнику как "правильно" рисовать. Хочется сделать по-другому? Welcome, это может получиться даже лучше.

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

[Natalya Rukol]

картинка  1.png   4,35К   5 Количество загрузок:

[Natalya Rukol]

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

Вернуться к аналитику и сказать, что разработчики делать не хотят :) Предложить вместе обсудить, выяснить как всё-таки правильно сделать, формализовать/описать договорённость. После этого уже идти к разработчикам. Повторить цикл N раз пока результат не будет достигнут :)

[Фрося]

картинка  1.png   4,35К   5 Количество загрузок:

Ага.
Я так в пост (сообщение) тоже могу вставить.

А вот темку создать с картинкой не вышло!!
И картинка дивная к параллельным прямым!

Прикрепленные файлы

•  IMG_2920.jpg   3,88МБ   11 Количество загрузок:

[elfische]

Вернуться к аналитику и сказать, что разработчики делать не хотят :) Предложить вместе обсудить, выяснить как всё-таки правильно сделать, формализовать/описать договорённость. После этого уже идти к разработчикам. Повторить цикл N раз пока результат не будет достигнут :)

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

[Natalya Rukol]

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

Давайте разбирать конкретнее:
- Чем чревато "неразбирательство" по вопросу, который Вы поднимаете? Если произойдёт бяка, которой Вы опасаетесь - во сколько $, или часов, или ещё чего-нибудь она встанет компании?
- Какова вероятность того, что эта бяка произойдёт? Сколько %, навскидку?
- Чтобы не допустить эту проблему, какое-то время придётся потратить Вам, аналитику, разработчику, протестировать результат. Оцените эти затраты в $ или времени, в той же единице что и первый пункт.

А теперь - немножко магии :) Умножьте первые два значения и сравните с третьим. Если третье больше - не парьтесь и не мешайте людям работать. Если перемножение первых двух пунктов существенно больше - покажите свои выкладки РМу и объясните, что вы экономите для проекта кучу денег.

[ch_ip]

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

Давайте разбирать конкретнее:
- Чем чревато "неразбирательство" по вопросу, который Вы поднимаете? Если произойдёт бяка, которой Вы опасаетесь - во сколько $, или часов, или ещё чего-нибудь она встанет компании?

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

[Natalya Rukol]

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

Таки да, далеко не любой крутости и далеко не любого уровня знаний по проекту, но автор написал:

Наталья, вот такая ситуация.
Тестировщик видит некое стечение обстоятельств, которые сами по себе проблемой на текущий момент не является, но в будущем если и возникнет что-то, то сразу тяжёлое.

Надеюсь что я правильно понимаю "что-то сразу тяжёлое".

[elfische]

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

Таки да, далеко не любой крутости и далеко не любого уровня знаний по проекту, но автор написал:

Наталья, вот такая ситуация.
Тестировщик видит некое стечение обстоятельств, которые сами по себе проблемой на текущий момент не является, но в будущем если и возникнет что-то, то сразу тяжёлое.

Надеюсь что я правильно понимаю "что-то сразу тяжёлое".

Как я вовремя вернулась: один мой вопрос уже задали, и ответ уже есть (-: Потому перейду к "сразу тяжёлому".
Наверно, лучше сразу описать ситуацию, чем говорить общими словами. Приложение состоит из нескольких модулей. Есть служебный со всякими настройками, правами и пр. В нём также имеется раздел справочники. Справочник -- хранилище данных, из которого в нужном месте подтягиваются значения в поле типа "выпадающий список". Значения из справочников могут использоваться в других справочниках. Для сложных модулей уровень вложенности ещё здесь уже 2-3, плюс вставка в сам модуль. А сверху на это накладывается невидимая логика: зависимости между полями в самом модуле. Все справочники всех модулей хранятся в общей куче, невозможно узнать, как они связаны между собой и модулями.
Итак, имеем область, которая используется редко со стороны разработки и никогда со стороны пользователей. В последнее время у меня лично стало возникать много мелких проблем, связанных со справочниками: то при переходе на другую базу потерялось 70% содержимого, то внешне кажется, что не работает невидимая логика. В итоге за последние две недели 4 дня (а ведь время могло бы исчисляться в минутах) потратила на работу с этими справочниками, попутно выловив баги, пустые справочники и неудобства. Если баги я ещё могу занести в джиру и их поправят, то с предложениями по улучшению в последнее время всё намного хуже. От них просто отмахиваются. Соответственно, мне нужно превратить предложение в баг. А для этого нужно сформировать требования и заручиться поддержкой со стороны аналитики или хотя бы внедрения (последних волнуют справочники только тогда, когда с ними проблемы).

И в догонку к предыдущему вопросу. Как узнать, 4 дня моей работы это дорого для фирмы или нет?