Хтось ще відчуває, що Scrum не спритний?

41

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

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

Керівники проектів це люблять

Керівники проектів, які за своєю природою одержимі строками, начебто люблять Scrum. На мій досвід вони, здається, використовують Sprint Backlog як засіб для відстеження вимог часу та ведення запису про те, скільки часу було витрачено на певне завдання. Замість того, щоб використовувати дошку, всі вони використовують аркуш "excel", який кожен розробник повинен заповнити релігійно.

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

Стійні зустрічі

Зустрічі зі штандарами на попередньому місці, де я працював, були кошмаром. Щодня нам доводилося пояснювати, що ми зробили вчора і що ми збиралися зробити в цей день. Якщо ми переглянемо своє "завдання" для завдання, керівник проекту спричинив би смерд, і посилався на "Блог за спринтами" як на спосіб показу некомпетентного, що ви не дотримуєтеся часової шкали.

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

Висновок

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

Думає хто?

agile scrum

— винарама
джерело

6

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

— superM

7

Так. Навіть один із "батьків" Agile не погоджується, що Scrum справді спритний: youtube.com/watch?v=hG4LH6P8Syk

— Euphoric

18

Отже, що ви говорите, це те, що ви не робите Scrum, і вам це відомо, але потім ви здивовані, що Notscrum також є Notagile?

— pdr

2

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

— Роб

11

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

— Берислав Лопак

25

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

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

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

— Стефан Більяет
джерело

16

Чим щоденні зміни відрізняються від мікроуправління?

— Джорджіо

10

Стандарти команди повинні організувати свій час так, щоб вони не переходили один одному. Абсолютно недоречно говорити про кошториси, час, що минув на минулі завдання тощо. - Дійсно, керівник проекту (на відміну від майстра розробки), мабуть, не повинен взагалі відвідувати.

— Джулія Хейвард

10

@Georgio: залежить від того, що ви розумієте під мікроменеджментом. Завдання щоденного резерву в SCRUM - інформувати всіх про те, що роблять усі, а не надавати можливість керівнику проектів карати людей за те, що вони не відповідають оцінкам. Насправді в SCRUM немає керівника проектів, відстеження та коригування кошторисів - це завдання команди, і якщо їх не виконати, питання задати: «що це спричинило і як ми можемо цього уникнути чи допустити в майбутньому? ", а не" чия це вина і як погано ми можемо змусити його почуватись? "

— Майкл Боргвардт

3

@ErikReppen, як і з майже будь-чим, у вас є невелика група людей, які придумали корисне вдосконалення, і тоді ви отримаєте набагато більшу групу, яка хоче її монетизувати і взагалі повністю перекручує: - я вірю в Scrum, але я повністю віддаляюся від Альянсу Scrum та його сертифікаційного бізнесу.

— Стефан Більяет

8

@jessehouwing: Так, але нав'язувати зустрічі зрілій команді - це як підходити до того, хто може ідеально ходити, і говорити їм: дивіться, у вас проблема, ви не можете ходити, я навчу вас правильно ходити. Ці люди дивляться на вас і запитують себе: Гей, чого хоче цей хлопець від мене? Звичайно, я можу ходити. Тож нав'язування щоденних зустрічей зрілому, самоорганізуючому колективу лише порушує їх робочий потік: це просто марнотратство. Таке рішення можна пояснити некомпетентним керівництвом або бажанням спостерігати / контролювати, як працює команда.

— Джорджіо

20

Так. Навіть один із "батьків" Agile не погоджується, що Scrum справді спритний: youtube.com/watch?v=hG4LH6P8Syk - Euphoric

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

— винарама
джерело

2

Це (те, що ви написали, а не те, що сказав дядько Боб) - це не послідовник. Тільки тому, що щось є процесом управління, це не робить його по суті неприступним.

— Дейв Хілліє

9

Можна мати коричневих котів та коричневих собак, але бурий кіт ніколи не може бути коричневою собакою. Це не тому, що воно не коричневе, це тому, що це не собака. Аналогічно, процес управління Agile не може бути процесом розробки програмного забезпечення Agile, не тому, що він не спритний, а тому, що це не процес розробки програмного забезпечення, про що ми говоримо.

— winarama

1

Тоді ви, можливо, захочете оновити своє запитання під назвою "Хтось ще відчуває, що Scrum не спритний?"

— Дейв Хілліє

Дякуємо, що поділилися відео. Я вважав це справді освічуючим.

— MickJ

Що ж, менеджери, як спритні, навіть зловживають цим. Тож вони можуть звинувачувати розробників. Тож використання спритного будь-якого підробленого чи ні - це питання політичної коректності.

— Кохання

13

Ви описуєте те, що ми, Професійні тренери з Scrum, бачимо багато в організаціях, які «впровадили Scrum». Часто вони також "роблять XP в команді розробників", це означає, що десь кілька тестів Unit працює на сервері збірки. Це не біда .

Так, менеджери проектів можуть використовувати відставання продукту, особливо оцифрованого, для зловживання пекло метрик таких систем. Але Команда з розвитку та Майстер Scrum не повинні його пускати. Що тут все-таки робить менеджер проектів? Чи не повинен це бути власником продукту ?!

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

— джиссеупінг
джерело

12

Ви, напевно, очікували цього, але те, що деякі (багато?) Люди неправильно використовують Scrum, не означає, що Scrum не спритний.

Керівник проекту : такої ролі в команді Scrum немає. Майстер Scrum не несе відповідальності за бюджет або дотримання термінів. Він несе відповідальність за допомогу команді та усунення будь-яких перешкод, які стоять на шляху до поставленої мети. З того, що ви описуєте, здається, що ваш прем'єр-міністр викрав Scrum, щоб взяти для себе прерогативи, які зазвичай переходять до команди та власника продукту, продовжуючи попередні звички командування та контролю.

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

З посібника з Scrum :

Моніторинг ходу спринту

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

— guillaume31
джерело

Неминуче стати культу, орієнтованої на вину, навіть Scrum є теоретично 100% політично правильним.

— Любов

2

scrum - методологія управління проектами

agile - це методологія розробки програмного забезпечення (-ish)

scrum + agile працює дуже добре

скупіться без спритного ... не так вже й багато

— Стівен А. Лоу
джерело

3

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

— winarama

2

Я думаю, що це неминуче. У розробників просто не так багато почуття власності в процесі (не хочу цього). Нещодавно у спринтерському огляді я поставив під сумнів ціль команди: написати програмне забезпечення або зробити гарний графік вибуху добре. Я висловив свою думку, але тоді всі прем’єр-міністри в кімнаті повинні були зробити все можливе, щоб підкреслити важливість бла-бла-бла. Лол!

— Роб

2

@ T-Pane: Ще цікавіше, що Scrum спочатку був запропонований як методологія розробки нового продукту - hbr.org/1986/01/the-new-new-product-development-game/ar/1

— Стівен А. Лоу

2

@ StevenA.Lowe Ah Scrum, він подорожує самопізнанням.

— winarama

1

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

— Venture2099