| Девицы-красавицы! ( @ 2009-05-01 10:50:00 |
Ещё рабочее.
Люди, программисты и тестеры, в каком виде вы получаете документацию от бизнеса? Кто-нибудь работал с Use Case Modeling with UML? Чем это лучше, хуже других методов для вас?
У меня дилема. На прошлой работе мы были в одной команде с BA и программистами. Всё можно было утрясти, проконтролировать, отследить и в любой момент обговорить. Сейчас я в группе, которая отвечает за стратегическое направление, в ней нет ни BA ни программеров. Для карьеры хорошо, для выполнения конкретных задач плохо. Во-первых, эти люди далеко, а, во-вторых, они не бесплатные. Чтобы не выйти из бюджета, мы должны поставить им задачу и сидеть ждать результата. Они к нам обращаются только в крайнем случае, в основном интерпретируют наши Business Requirements Docs на свое усмотрение. Я тут новая метла, которая привыкла, чтобы её дизайны не интерпретировались, а в точности воплощались, согласно прототипу и что все мои требования четко задокументированы аналитиком, а если нет, то всегда можно подкорректировать по ходу. У нас тут так делать не привыкли, по вышеописанным причинам. То есть, либо сама документируй, либо предложи подучить менеджеров, которые сейчас это делают, но в общих чертах.
На старой работе использовали UML & Rational Unified Process. Меня устраивало, других вроде тоже. Имеет смысл его на новой работе пропагандировать или есть ещё лучше способы?
Люди, программисты и тестеры, в каком виде вы получаете документацию от бизнеса? Кто-нибудь работал с Use Case Modeling with UML? Чем это лучше, хуже других методов для вас?
У меня дилема. На прошлой работе мы были в одной команде с BA и программистами. Всё можно было утрясти, проконтролировать, отследить и в любой момент обговорить. Сейчас я в группе, которая отвечает за стратегическое направление, в ней нет ни BA ни программеров. Для карьеры хорошо, для выполнения конкретных задач плохо. Во-первых, эти люди далеко, а, во-вторых, они не бесплатные. Чтобы не выйти из бюджета, мы должны поставить им задачу и сидеть ждать результата. Они к нам обращаются только в крайнем случае, в основном интерпретируют наши Business Requirements Docs на свое усмотрение. Я тут новая метла, которая привыкла, чтобы её дизайны не интерпретировались, а в точности воплощались, согласно прототипу и что все мои требования четко задокументированы аналитиком, а если нет, то всегда можно подкорректировать по ходу. У нас тут так делать не привыкли, по вышеописанным причинам. То есть, либо сама документируй, либо предложи подучить менеджеров, которые сейчас это делают, но в общих чертах.
На старой работе использовали UML & Rational Unified Process. Меня устраивало, других вроде тоже. Имеет смысл его на новой работе пропагандировать или есть ещё лучше способы?