Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - kirillss

Страницы: « 1 2 3 4 5 6 7 8 9 10 »
46
Народ, сдается мне что это некоторая схоластика.
Что изменится от того что то или иное требование мы определим как функциональное, а на самом деле он нефункциональное?

47
Можно и нужно, иначе мы дойдем до включения требований безопасности информации в функциональные

Вот где конец света то будет)))))))))))

48
2cintyao
Можно конечно обсуждать все написанные метрики дополнять их и т.д., только в общем случае все перечисленное относится именно к процессу анализа. В котором участвует как команда (причем местами не только аналитик) так и заказчик

То есть это не качество/эффективность Аналитика

49
Некоторые выводы:
1 Существуют способы оценки конкретного аналитика. Но без ручного привода они не обходятся. Ручной привод неприятен возможностью использовать его как способ наказать неугодных (вариант для руководства) или формального подстраивания под него низов (дело при этом может и пострадать)
2 Обьективных вариантов оценки в жизни видимо всетаки никто (по крайней мере из тех кто участвовал в обсуждении) не использует, по разным причинам.. Такие оценки неизвестны или трудоемки в реализации

Вывод получается что оценивать все таки надо не аналитиков, а целиком команду или решение/продукт полученный этой командой

Согласны?

50
А чем он многострадален!?

51
Григорий, а запись докладов С.Нужненко и В.Григораш есть? Ждать?

52
Был.
Григорий насколько я понимаю писал. Интересно было посмотреть некоторые доклады, так как интересные пересекались по времени.

53
kirillss
3.  Не совсем понимаю что значит 'Для такой методы оценки должна быть хорошо отлажена трассируемость требования-фича-релиз-баг'. Поясните плиз. :)

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

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

55
а можно попроще пересказать смысл вышеупомянутой статьи!!!
В чем революция то?

56
Заезжайте в Москву будет третий))))

57
2LastLegion86

Ага процесс становится понятнее....
Некоторые замечание/мысли
1 Какова средняя трудоемкость доработки (если не секрет конечно) в человеко-месяцах например.
2 Оценка колва запросов на изменение по Вашей методологии будет скорее характеризовать тройку (персонал автоматизируемого подразделения,аналитик,автоматизируемый бизнес). Кстати а аналитики могут участвовать в автоматизации разных бизнес подразделений или в основном "сидят" в "своем" бизнесе?
3 Для такой методы оценки должна быть хорошо отлажена трассируемость требования-фича-релиз-баг. Ну то есть если у вас эта прослеживаемость есть то большой комплимент вашему IT!!
4 Какие последствия (финансовые,организационные) у Вашей оценки аналитика?

58
2LastLegion86
даже в Вашем упрощенном примере (нет заказа товара) не совсем очевидно что это вина аналитика! По крайней мере есть доводы и за и против. Что уж говорить о сложностях в оценке аналитика в "боевых" задачах. Основная проблема (риск аналитика, если хотите) - нечеткость правил и неоднозначность их толкования

59
Не забывайте что работа аналитика - не только и не столько сбор требований. Основная работа - на мой взгляд - построение МОДЕЛИ проектируемой системы. А все что до сих пор пришлось услышать касалось ИСКЛЮЧИТЕЛЬНО сбора требований.

60
.. параметр "количество запросов на изменение" ..бесполезен для отслеживания эффективности работы аналитика..

+100

Страницы: « 1 2 3 4 5 6 7 8 9 10 »