Бизнес-аналитика подавай?

[singalen]

Вот почему программисты считают, что требования должен писать кто-то другой?

Ну, то есть, я знаю, почему. Потому что мы хотим колбасить код и больше ничего.

Требования вырабатывают ВМЕСТЕ.
А то сваливаем их на нетехнического специалиста, у которого есть ещё и совсем другие обязанности, а потом сами же на них косим стрелки - мол, неполны, противоречивы и реализуются через место, не именуемое головой.

Бывает, что лучше всех написать требования можешь именно ты.

Если вы, ребята, профессионалы, то сотрудничайте с людями, с которыми работаете.

Comments

[profuel.livejournal.com]

>более того, обычно они даже начнут возражать, что мол зачем нужно с
>ними обсуждать очевидные казалось бы вещи. "вот здесь же нужен
>месседжбокс, а вот тут эдит". надеюсь вы не в такой ситуации.
Увы, ситуация хуже :(
50% - "зачем спрашивать очевидное" Сюда входят и вещи "когда-то с кем-то оговоренные", и вещи "так ведь очевидно, что при удалении надо спросить - "уверены?"
50% - вы не учли всех пожеланий заказчика, о которых мы забыли вам рассказать. А хочет, обычно, наш заказчик - чего-то сверхъестественного.

Последнюю книгу не видел, взял на заметку.

[klizardin.livejournal.com]

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

[singalen]

А если на пальцах - что именно он предлагает? :)

[klizardin.livejournal.com]

1. предлагает достаточно хороший формат для написания вариантов использования.
2. рассматривает этот формат формулируя наилучшие подходы к формированию вариантов использования.

фактически, четко очерчивает нужные и не нужные, хорошие и плохие подходы в написании варантов использования, или описании поведенческой части требований.

в том числе формулирует достаточно важное замечание

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

Формулирует правила/техники хорошего описания/написания вариантов использования.

Например.

Полный список основных действующих лиц дает еще три преимущества:
* Он фокусирует наши мысли на людях, которые будут использовать систему. В документе, содержащем требования, мы фиксируем, Koro предполаrаем в качестве основных действующих лиц, описание их работы, их типичную подrотовку и навыки.

Мы делаем это, чтобы разработчики системы и интерфейса пользователя моrли обеспечить соответствие системы этим характеристикам.

* Он определяет структуру списка Действующее лицо/Цель, которая будет использована для расстановки приоритетов и распределения работы.

* Он нужен для разбиения orpoмнoгo множества вариантов использования на пакеты, которые можно распределить между различными rруппами разработчиков.

или

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

цели Обобщенного уровеня -- выше уровня моря, белый вариант использования.

цели уровня подфункций -- это цели, достижение которых требуется для реализации целей пользователей.

[klizardin.livejournal.com]

книга дает этакий базис самого подхода к разработке требований. чем и полезна.

или еще выписанные фрагменты

[klizardin.livejournal.com]

Выявление правильной цели пользователя -- труднейшая вещь в вариантах использования. Сосредоточьтесь на следующих правилах:
* Выявите цель пользователя.
* Используйте от трех до 10 шагов на вариант использования. (т.е. не пишите очень длинных/детальных сценариев)


--Выявление цели пользователя--
Спросите себя, является ли это тем, чего действительно сейчас Хочет от системы основное действующее лицо?

Очень часто начинающие набрасывают подводные варианты использования, думая, что те находятся на уровне моря. Чтобы обнаружить цель более выcoкoго уровня, задайте себе любой из этих вопросов:
* Чеro на самом деле хочет действующее лицо?
* Почему действующее лицо это делает?

[klizardin.livejournal.com]

ну и также этот базис близок разработчику.

[singalen]

Ага, спасибо. Я такие инсайты от Лармана получал, помнится.

[singalen]

А по-моему, это мискомьюникейшн. Они не хотят понять вас, а вы их, если огрублять.

[profuel.livejournal.com]

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

[singalen]

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

Попробуй вызвать заказчика на разговор "по душам" - типа, я для вас всё хочу сделать, но сейчас мы закрыты друг для друга и общаемся с напрягами.

Для нас, например, работает подход, когда мы лично ездим к заказчику и получаем от него скоуп на три месяца вперёд :D

[profuel.livejournal.com]

увы, местным менеджерам это не понятно. Им кажется, что проект с оценкой 1 мес делается 3 мес, потому что через неделю появляется еще один срочный проект, потом еще один..... прямо крик души :)

Ваш подход мне нравится, попробуем.

[singalen]

Ну так объясни им :)