Архіви категорій: BA

Улюблені фічі

З початком проєкт після першого Project Kick-off починається велика політична гра власних інтересів членів команди щодо фіч рішення. Чи буде це зроблено навмисно? Мабуть, ні. Але чому так станеться? Тому що навіть розробники – люди (чи не всі?).

Читати далі

Системна робота над вимогами та Agile

Для системної роботи над вимогами та архітектурою рішення рекомендується створювати окрему Agile команду. Дуже швидко робота над вимогами та архітектурою на майбутнє починає конфліктувати з основним процесом розробки.

Читати далі

Вимоги: шматочками ітераційно VS цілісно та уточнення

ПлюсиМінуси
Шматочки+ Легко для Product Owner
+ Гнучкість
+ Гарно для продуктів з великою кількістю неперевірених продуктів
+ Найбільш швидка реакція на зміни у продукті – вимоги змінюються у рамках ітерації
– Відсутніть повної картини, стресс для команди
– Мінливість архітектури
– Переробки у розробників
– Конфлікти у вимогах
– Втрата контролю над змінами та залежностями
– Невизначеність у тестувальників
– Вимагає від експертів реагувати на часті запитання
Цілісно+ Повна картина для всіх інших ролей
+ Надійна архітектура
+ Менше переробок у всіх інших ролей
+ Гарно для процесів та рішень із зрозумілою мотивацією та стабільністю вимог
+ Економія часу експертів
+ Підвищення автономності команди
– Напруга для Product Onwer
– Висока вартість інвестицій
– Додаткові затрати на оновлення
– Більше часу на підготовку
– Пізніше старт проекту
– Погано коли дуже багато ймовірних гіпотез на старті

Форма вимог: Use Case vs User Story

Use Case – це повна та гарно деталізована форма вимог. User Story – це антистресова компромісна форма вимог для спрощеного підключення вимог у Agile проєкті. За умов гарного пропрацювання куца форма User Story плавно перетворюється у Use Case.

Розуміння в цілому

Проєкт потрібно починати з розуміння в цілому – що ми робимо, нащо ми це робимо, де та як воно буде використовуватись.

” – А! Це ж питання до бізнес-аналітиків – нащо інженерам знати це? Нехай BA ібуцця з бізнесом, не заважайте інженерам! ” – отаке можна почути від пересічного софтбудівника.

Отаке … але ніт.

Читати далі

Обирайте ступінь деталізації вимог та необхідні причандали

Для аналітика у проекті важливо не потрапити у аналітичний параліч. Причина паралічу – непомірна кількість питань кожне з яких аналізується досконало – деталізація, всі типи причандалів (схеми, моделі, прототипи, матриці залежностей). Як врятувати себе від паралічу? Правило 20-80 можна застосувати до вимог – 20% вимог мають мати високий рівень деталізації. Це може вам суттєво допомогти в оптимізації своєї роботи.

Читати далі

БА як кінь

Бізнес аналітик як кінь

Класична відповідь на співбесідах з більшості бізнес-аналітиков щодо роботи – я пишу вимоги. Звідти все про що розповідає БА це функціональні та іноді нефункціональні вимоги, діаграми процесів, схеми даних. Вам потрібен аналітик саме для цього? Все ж гарно?

Якщо вам потрібен БА який пише диктант вимог, писар при його величні продакт-овнер та дивиться метр-вправо, метр-вліво то ок – такий собі кінь із шорами який професійно працює на рівні функціональних вимог. Звісно це жорсткий перегиб і сам тут БА починають лютувати, бити себе копитом у груді та розказувати скільки всього вони роблять, і що без них все це наібнеться. А того хто їм сказав про коня пошиють в козли, дурні та мудаки. Отже, увагу ми отримали 🙂

Читати далі