Місячні архіви: Лютий 2022

Скільки беклогів у вашому проекті?

В реальності може існувати декілька видів беклогу – паралельно жити своїм життям:

  • Беклог власника продукту – з чим прийшов до команди як замовник, на підставі чого планує product roadmap.
  • Беклог команди – що команда пропрацювала та що використовує при оперативному керування.
  • Беклог сподівань та очевидних речей – беклог замовника, я це не пишу, бо це і так очевидно (надалі перелік який змінюється час від часу)
  • Приватний таск-ліст розробника – окрема табличка з тасками яка може перетворитись в … Таємний беклог розробника – там з’являється технічний борг, ідеї щодо того що він хоче покращити або чим погратись з боку технологій. Кількість таких власних беклогів залежить від вподобань розробників та їх власного та незалежного бачення як правильно.
  • Беклог у коді – примітки щодо недороблених речей, відсутності обробки виключень, технічний борг, потенційні баги.
  • Беклог тестувальника – тест кейси та все що дізнався QA переглядаючи угоду, аналітичні документи, архітектури, всі інші вимоги тощо.

Наявність, кількість, ізольованість та різноманітність наведених вище беклогів у рамках проекту – це фундація конфліктів, низької ефективності, непередбачуваності та високого рівня незадоволеності всіх stakeholders проекту.

Вподобайка для low code / no code

Магічний вплив простих речей на замовника від https://www.facebook.com/Moshkovsky.art/

Рекламне гасло лідерів low-code / no-code: громадянин-бізнесмен може зробити свою програму. Чи це правда? Так. Це те що бажає бізнес? Мабуть, ні. Чому?

Читати далі

Що робить EM?

Чому їжачок Moshkovsky.art такий рішучий ви дізнаєтесь якщо дочитаєте до кінця

Серед ролей у IT є такий диво-коник: Engagement Manager (EM). Основна місія EM: знайте правильне рішення для правильного клієнта.

Давайте відразу визначимо що не є основною задачею – або ким не є EM:

  • EM не Сейл (AM) – бо не шукає правильних клієнтів, будує з ними відносини
  • EM не Адміністратор для підготовки контрактів або не помічних сейла – бо не займається підготовкою пакетів документів, не відстежує роботу тендерних майданчиків
  • EM не Маркетинг – бо не шукає потенційних клієнтів, не розвиває сайт та соціальні мережі, не виконує інформаційні розсилки, не організовує події
  • EM не керівник проектів (PM/DM) – тобто не керує виконанням проектів.
  • EM не бізнес-аналітик – тобто не займається повним виконанням бізнес аналізу, не створює аналітичні документи
  • EM не архітектор

… Але з іншого боку він або дуже пов’язаний у своїй взаємодії з ролями наведеними вище або навіть виконує їх частково. Зацікавлені?

Читати далі

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

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

Читати далі

YAGNI, нафіг

YAGNI — You ain’t gonna need it – вам це не потрібно. Все, що не передбачено технічним завданням проекту, не повинно бути в програмі. Або перестань вигадувати додаткові лісопеди та складнощі, не пиши чого-сь щоб-було тому що якщо-шо.

Читати далі

Матєрний disclaimer

Додаю до Hello world цього поважного сайту “Матєрний” disclaimer: “Всі матерні слова – це все крики душі манахєра софтвєрної розробки. Бо він людина культурна, він це оре всередині себе.”

PS Алгоритмічна схема нарисована архітектором доречного мату Moshkovsky_art

А якщо …

А якщо користувач буде працювати на телефоні без зв’язку – то давайте докрутимо підтримку offline? Або якщо користувач забажає змінити колір обов’язкових полів не формі, або якщо мусить … Надалі миттєво пропозиція цікавого технологічного рішення яке зробить добре уявному користувача у ситуації якщо що. А чи все добре коли ми частіше та частіше починаємо робити вправи “а якщо”?

Читати далі

TPM/BPM

Кожна позиція має свої особливості – project manager не є виключенням. На практиці існує купа умов щодо домену, технологій, платформ, конкретного бізнесу, культурного коду та міксу додаткових ролей які має виконувати Project Manager (а тут від бізнес-аналітика до фінансиста). Але головне це визначитись стратегічно: вам потрібен технічний керівник проектів або бізнесовий?

Читати далі

Невизначеність, припущеннями та всім зрозумілі речі

Кожен проект має свій рівень невизначеності, свої припущення та час від часу вимоги які мають бути реалізовані тому що це всім зрозумілі речі. Кожна з цих компонент створює у проекті хаос у межах – кожний раз випробуючи на міцність обсяг роботи, час та витрати проекту. Що ми можемо робити з цим? Керувати!

Читати далі

Оцінка всього беклогу as early as possible

Так, так – у Agile проекті потрібно робити якомога повну оцінку всього беклогу. Так – це буде не точна та не повна оцінка. Але це оцінка!

Попередня оцінка важлива. Потрібно розуміти не тільки чому та що поганого буде без неї, але й потрібно правильно її використовувати та знати про пастки швидкої оцінки проекту.

Читати далі

Корисні Issues

Завжди усміхнений менеджер проекту

Серед типів work item у Azure DevOps тип Issue використовується не дуже часто. Нажаль. А це дуже та дуже корисний тип work item. Чи варто вам приділяти більше уваги Issues? Безперечно!

Читати далі

Превентивна релокація як фіча хантерів

Цікава конкуренція за кадри між малими та великими компаніями – коли гіганти калькулюють та оптимізують витрати на реалокацію, кажуть та не роблять, маленькі кажуть та роблять – йди від цих жадібних корпорацій в наш комфортний офіс на Кіпрі!

Це доволі крутий приклад партизанського маркетингу на ринку праці! Тобто сьогодні якщо ти middle або seniour і під час співбесіди нема реалокаційного пакету – це вже не офер, а так, жлобство ?

Отакі часи, отакі зміни реальності ?

Timeless Laws of Software Development

Завжди круто почути історії досвідченого розробника, переглянути історію проблем та пошук рішень. Книгу “Timeless Laws of Software Developmen” написав досвідчений розробник – Jerry Fitzpatrick.

Читати далі

Свобода реалізації

За умов відсутності вимог можна зробити наступне – прийняте власне бачення реалізації як основне, повідомити про це замовника і виконати роботу на підставі цього.

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

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

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

Читати далі

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

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

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

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

Що таке UAT

Для команд розробки UAT (User Acceptance Testing) не дуже часто є частиною їх практики – він може проходити поза лаштунками первинного виробництва, його можуть проводити якось-такось. А ось коли замовник просить вас підготувати Стратегію тестування та визначити як ви будете проводити та готуватись до UAT – ви починаєте скажено гуглити what is faking UAT. Це нормально. Є кілька точок зору на UAT – пропоную варіант.

Зрозуміймо нащо проводити UAT. Замовник бажає визначитись чи дійсно замовлене програмне забезпечення. А як замовник це визначить? З точки зору замовника програмне забезпечення має забезпечувати роботу основних бізнес-сценаріїв від початку до кінця. Тобто ми маємо визначити всі наскрізні бізнес-сценарії, відокремити всі гілки прийняття рішень та таким чином отримаємо план тестування та виконати весь бізнес сценарій (процес) від початку до кінця.

Читати далі

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

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

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

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

Читати далі