Просмотр сообщений
В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
Плохо, что у тебя в блоге нельзя прокомментировать не зарегистрировавшись в wordpress.Плохо. Думаю над этим.
Мне кажется, ты делаешь определенную ошибку, делая акцент на требования к ПО. Там не требования к ПО, а требования к системе. Все-таки это несколько разные вещи. Отсюда и диссонанс в восприятии ГОСТа.Э-э-э... Ровно это я и написал. Что это требования к системе.
ИМХО проблема выбора реквестов решается проще:Гуру от менеджмента говорят, что без глубинных знаний это не работает...
1. Собирать раз в неделю/две/месяц по одному представителю от каждой единицы бизнеса и дать им самим выставить приоритеты, потом эти приоритеты соблюдать и только с разрешения ген дира что-то туда вкрячивать до след совещания (итерации).
или
2. Предложить метрики, с кот должны приходить реквесты, бизнес их заполняет и все само выстраивается, при конфликтах завете нужных представителей от бизнеса.
Я почитал руководство. Это инструмент разработан под ТОС. Я согласен, что это вынос мозга. Об этом читать приятно в цели 2, но чтобы использовать! Если ты пользуешься и легко, то тебе уже пора в Санта-Барбаре местечко иметьДа, инструмент разработан под ТОС.
То, что на сайте выглядит весьма привлекательно, но не очень убедительно. Ты бы мог какие-то примеры привести?На шкафу лежат несколько диаграмм с реальных проектов. Будешь у нас - заходи, покажу.
Миф 5. Если исправление багов откладывать на финальную стадию проекта, то невозможно автоматизировать тестирование, так как тесты бесты будут постоянно разломаны.
Всё прекрасно автоматизируется. Главное, чтобы фичу можно было пройти, и основной flow работал бы так, как запланировано. Как я уже писал, такие баги фиксятся в первую очередь. Без их фикса фича не принимается.
Миф 4. Чем больше времени проходит между внесением дефекта и его исправлением, тем дороже исправлениеТак и есть. Это вовсе не миф. Хорошее время между внесением бага в код и донесением информации о нем до программиста - от секунд до четверти часа. Хорошее время между внесением бага в код и его исправлением - в пределах рабочего дня.
Denis Beskov, greesha, спасибо большое за ответы! Но тут у меня возник еще вопрос по этому поводу. Дело в том, что прежде чем понять, что нужно бизнес-аналитику, нужно уяснить, а точно ли ты БА. У меня на этот счет закрались сомнения. Прочтение статей на тему разницы между БА и СА результатов особых не дали, только внесли в мою голову еще больше путаницы. Дело в том, что моя должность называется именно БА, однако, возможно, начальство просто не улавливает разницы.С терминологией у нас караул! В дальнейшем я исхожу из того, что БА дают рекомендации по изменению работы организации. При этом АСУ может быть как бесполезной, так и вредной.
Об этом лучше спросить у профессионалов по бизнес-анализу, но в моём понимании это:Последнюю неделю перечитывал Генги Нива, поэтому дам советы, как написано у Деминга.
Теория ограничений (TOC)
Методика Balanced Score Cards (BSC)
ARIS (Как методология, а не нотация)
BABOK
С точки зрения взаимодействия с разработкой полезно познакомиться с ГОСТ 34 и Scrum.
Ну и в целом полезно познакомиться с методикам системного анализа и решения проблем за рамками ИТ — Оптнер, ТРИЗ, Дизайн-мышление.
+ отраслевые методики, типа eTOM.
