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

×


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

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


Сообщения - div

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 »
61
Соглашусь с Денисом, что было бы интереснее познакомиться с результатами оригинального самостоятельного исследования. Но, с другой стороны, самостоятельные исследования стоят денег и затрат, поэтому происходят редко, а указанная статья при разумной "стоимости" написания может оказаться хорошей отправной точкой для тех, кто ничего не знает о том,что старательность исполнителя обратно пропроциональна расстоянию до начальника.

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

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



62
а я слышал, что при демократии должно быть наоборот. Мол демократия должна защищать меньшество, а большинство и так себя защитит :)
Да, я тоже про это слышал. Но на практике почему-то всегда наборот :)))

63
Сейчас я использую SharePoint на своём проекте только как хранилище документов.
В SharePoint есть такая конструкция, как список, это типа таблицы записей с полями разных типов. В частности, поле может быть гиперссылкой, в которой можно хранить ссылку, например, на требование более высокого уровня, или на DOC файл с BRS или SRS, хранящийся в библиотеке документов того же Share Point.
В общем то, в списке SharePoint  можно реализовать многое из того, что можно реализовать в Work Item TFS, кроме сложного workflow и многостраничных форм с полями хитрых типов.

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

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

65
есть идея произвести реверс-инжиниринг требований и загнать их в СУТ (Sparx EA). Но пока не пойму - нужно это или нет, какие плюсы и минусы.
У нас была попытка все требования положить в одну общую систему. Пробовали на эту роль все системы, использующиеся разными проектными командами: Sparx EA, MS TFS, SharePoint. В результате пока отказались от такой унификации, т.к. для каждого проекта используемая в настоящее время система в определенномо смысле оказалась "оптимальной", и команды не сочли  проигрыш в удобстве и необходимости перехода в дургую систему стоящим выигрыша от унификации СУТ, хотя с наличием плюсов от такой унификации все согласились.

66
Коллеги, у меня когда-то давно возникал этот вопрос, и я разговаривал по этому поводу с одним из разработчиков 34 серии ГОСТ. Он сказал, что термин "объект автоматизации" в этой серии следует читать как "то, что подлежит автоматизации". Т.е. это просто местоимение, вместо которого нужно в каждом конкретном случае подставлять нужное понятие. Как правило, автоматизируется именно процесс, т.к. именно процесс может быть ручным, автоматизированным, или автоматическим. Поэтому практически всегда "объектом автоматизации" является "процесс".
Грубо говоря, некорректно говорить об автоматизированном банке, но можно говорить об автоматизированном процессе одобрения кредитов в банке. Мытье полов в этом банке при этом может осуществляться вручную.
Когда говорят об "автоматизированном цехе", имеют в виду, что в этом цехе автоматизирован основной производственный процесс . Служебные процессы (мытье полов, например, разгрузка заготовок, и даже начисление зарплаты) могут при этом не быть автоматизированы, и это не помешает цеху считаться автоматизированным.

67
А какого рода анализ данных предполагается?

68
Интересное наблюдение, только можно уточнить: весь этот год тестировался один и тот же билд одного и того же продукта?

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

70
4-5 багов на новое требование - это очень небольшое число. Должно быть больше. Возможно, не все баги учитываются.

71
______________________________
Systems analyst
From Wikipedia, the free encyclopedia
   A systems analyst researches problems, plans solutions, recommends software and systems, and coordinates development to meet business or other requirements.
______________________________
Business analyst
From Wikipedia, the free encyclopedia
   A Business Analyst (BA) is someone who analyzes the organization and design of businesses, government departments, and non-profit organizations; BAs also assess business models and their integration with technology.

72
Мы, наверное, о разном.
Я о больших проектах, у нас они под полмиллиона человеко-часов. Если ты там даже умрешь на работе, принципиального влияния на общий успех это не окажет. Гораздо лучше для общего дела просто сделать то, на что ты подписался, за то время, за которое ты подписался. Для этого, кстати, тоже требуется весьма напрячься :)
Зато потом можно рассказывать: "За последний месяц я провел в известном всему миру проекте 89.3 часа".

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

73
Никак нельзя это гарантировать. Поэтому Agile и рекомендуется к использованию только опытным и слаженным командам.

74
Не поверю (даже не убеждайте), что, например, аналитик, приходит и грит: я свои 16,7 часов, которые ты мне дал, отработал согласно плана/задания/итп - вот тебе что успел/сумел сваять, отвяжись...
Тем не менее, так и говорит, не так грубо, конечно. А что еще аналитик может сказать? Переработки не приветствуются, т.к. снижают качество и приводят к "выгоранию" людей.

Также сложно поверить, что все всегда получается в заданных рамках в соответствии с требованиями ТЗ, пусть не с первого раза, но в заданные сроки. 
"Не с первого раза", но в "заданные сроки" может получиться только если в плане было запланировано "не с первого раза". У нас time driven development, график выхода продуктов расписан на год вперед, поэтому даже на 1 день позже заданного срока закончить работу нельзя. Если не успеваем, то объем работ режется по мере приближения срока, сокращается функционал.

75
Они у Вас кирпичи что ли кладут, аналитики-то? как в свое время говаривал старина Брукс: время выполнения работы одним исполнителем может на порядок (или даже больше) отличаться от времени работы другого исполнителя.
Ну да, стараются ставить на задачи тех аналиков, которые делают задачи на порядок быстрее. В чем вопрос?

Я признаться не верю, что ПМу важно количество часов, отработанных аналитиком, а не результат конкретной работы с учетом его места в конечном продукте проекта.
Конечно, ПМу важен результат, а не количество часов. Но компания закупает у аналитиков не результат, а 40 часов в неделю (не контракторы мы, а на постоянке!), и ПМ распоряжается этим закупленным временем таким образом, чтобы получить максимальный результат. За это ПМу и платят, разве нет? Он же сам ничего не производит, просто следит, чтобы закупленное компанией рабочее время не утекло, а превратилось в полезный результат. А если компания закупает сразу результат, то и работа ПМа сводится к подписанию акта сдачи-приемки результата.

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