Чи добре, що в команді Scrum є люди з кількома ролями?

Я оцінюю деякі методології Agile-стилю для можливого ознайомлення зі своєю командою. З Scrum, чи дозволяється одній і тій же особі виконувати кілька ролей? У нас є невелика команда з чотирьох розробників та веб-дизайнера; у нас насправді немає керівництва (я виконую цю роль), тестувальників якості та бізнес-аналітиків, і всі наші завдання з розвитку виходять із CIO. Автоматичне тестування розглядається як загальна витрата часу, і все зосереджено на швидкості, а не на якості.

Що трапиться, це те, що CIO винайде завдання з розробки (будь то функція чи помилка) і передасть його розробнику (а не всій команді, окремому користувачеві, часто приватному чи неприйнятому), який тоді очікується, що це завершиться. CIO не збирає вимог, що перевищують початкову ідею (і це нас покусало раніше, тому що ми реалізуємо щось лише для того, щоб з’ясувати, що ніхто з кінцевих користувачів не може використовувати цю функцію, оскільки з ними не зверталися і навіть не інформували про це перш ніж ми розробили її, і в паніці нам скажуть змінити зміну), але вимагає сказати / затвердити все, що ми робимо.

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

По-друге, якщо це може спрацювати, чи нерозумно для когось, скажімо самого себе, виступати як ScrumMaster, так і розробником? Або, щоб розробник був також власником продукту (хоча ймовірно, це буде CIO, який не є розробником)? Я розумію, що Майстер Scrum та власник продукту мають бути різними людьми, але в той же час я не думаю, що у нас є хтось, хто має якості власника продукту (швидше за все, це перетвориться на "мені потрібні всі ці історії, я не байдуже, як, але зробити це "тип угоди та / або будь-яка заморозка буде розморожена за примху".

Мені здається, що мені може знадобитися вибирати шматки Scrum / XP / Lean, щоб компенсувати, як це робиться в даний час, оскільки це малоймовірно, що менталітет можна змінити; наприклад, парне програмування ніколи не пролетить (сприймається як марно, ви отримуєте половину завдань, якщо вам потрібні дві людини на все), TDD буде важко продати, але короткі цикли будуть вітатися.

Scrum, Kanban або будь-яка інша методологія Agile - це насамперед методологія, орієнтована на проекти з розробки програмного забезпечення . Іншими словами, це практика управління проектами за своєю суттю.

Наскільки ви відчайдушно хочете, щоб ви та ваша команда займалися проектами, ви зрозумієте, що Agile просто не працюватиме у вашій організації через те, що ви насправді не займаєтесь «проектною» роботою або віддаєте себе як команда "зобов'язання проекту".

Ви можете організувати міні-проект навколо складної функції, але насправді у вас немає зв’язку з бізнес-аналітиками або кінцевими користувачами, тож як можна перевірити, що ви постачаєте в Історіях користувачів, коли ви не можете реально знати, що це за користувач хоче?

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

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

Він не повинен працювати так

Спринт є зобов'язанням по всій команді , щоб доставити підмножина користувальницьких історій до певної дати. Після запуску спринт повинен пройти до завершення, перш ніж відбуватимуться репріорітизація чи зміни. Як слід керувати проектом, коли він працює в таких хаотичних спеціальних умовах?

Ви не працюєте в середовищі, що сприяє методам Agile управління проектами. Ви навіть не працюєте в середовищі, що сприяє методології водоспаду. Ви працюєте в монархії, і ви просто пешки-королі, які проводять його торги та гасять пожежі.

Це не є командою проекту з розробки програмного забезпечення.

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

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

При цьому, у вас виникнуть серйозні проблеми з Agile, якщо у вас не буде реальної покупки як у вашого директора, так і у клієнтів. Чи готовий ваш CIO дотримуватися того факту, що він не може додати робочий предмет до середини спринту, але доведеться почекати до наступного? Чи готовий він розставити пріоритети для розроблених питань? З того, що ви написали, здається, що він володіє тим, що ви робите, і, таким чином, повинен бути власником продукту. Якщо він не бажає, ви більше не будете досягати успіху, ніж зараз.

Scrum може бути хорошим рішенням для вашої проблеми щодо CIO, що призначає роботу розробнику ad hoc, але лише в тому випадку, якщо CIO закупляється на цьому процесі. Я підозрюю, що вашому керівництву ЦІ не буде подобатися, що він приймає пряме завдання. Але якщо ви можете змусити CIO придбати ідею написання ним історій користувачів, а потім визначити їх пріоритетними, він може знайти це дуже ефективним способом управління. Але це розпочнеться з того, що ви переконаєте свого керівника директора дотримуватися цього процесу.

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

Власник продукту повинен знаходитися за межами команди розробників, оскільки в противному випадку тут може виникнути поганий конфлікт інтересів. Scrum Master може бути розробником, хоча в цьому випадку конфлікту не так вже й погано.