Чи Scrum перетворює активних розробників в пасивних розробників?

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

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

Існує велика різниця між тим, як ти вирішуєш, що робити , або тобі сказали, що робити .

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

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

1. Я схильний шукати менше, щоб знайти краще рішення, підхід чи техніку
2. Я не прокидаюся вранці, очікуючи потрапити на приємну роботу. Швидше, я відчуваю, що змушений працювати, щоб жити
3. У мене більше голоду працювати після власних хобі-проектів після роботи
4. Я більше не підштовхуватиму команду до вищих технологічних рівнів
5. Я більше часу витрачаю на вечерю, або чаю, і маю менше ентузіазму повертатися до роботи
6. Зараз я готовий більше, щоб робота закінчилася швидше, щоб я міг повернутися додому

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

Однак зараз я відчуваю, що мені завжди говорять щось робити, а не вирішувати щось робити.

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

Ви робите "scrum but"? Тобто, часткова роздратування, частина чогось іншого. (тобто: "Ми робимо scrum, але всі наші історії повинні надходити від нашого PMO, а не власника продукту.") Багато шалених лайнів називається Scrum в наші дні.

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

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

Ваша проблема - це не Scrum (і як згадував Джаррод Роберсон у коментарях, це не Scrum, що ви описуєте) - це мікроменеджмент Власника продукту та ваша (та Команда) відсутність впевненості .

"Однак, завдяки методології scrum, зараз багато рішень просто походять від власника продукту. Він визначає пріоритетність PBI, він аналізує, як програмне забезпечення повинно працювати, навіть іноді як користувальницький інтерфейс та функціональність.

Ви помиляєтесь. Тільки з короткого огляду сторінки Вікіпедії для Scrum видно, що: "Команда, крос-функціональна група, яка робить фактичний аналіз, проектування, впровадження, тестування тощо". Побачити? Власник продукту говорить вам, що робити, але вирішити, як це зробити, вирішуватиме команда .

Ви відповідальна за впровадження, тому вам слід вирішити, як програма буде реалізована. Прислухайтеся до думки власника продукту, але остаточне рішення вирішувати саме ви (або Команда).

ДО РЕЧІ мікрорівні робить свою чергу активних розробників в пасивні розробник.

Те, що ви описуєте, НЕ СКРУМ

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

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

SCRUM - це співпраця, саме для цього проводяться зустрічі планування Sprint, щоб сприяти співпраці між усіма зацікавленими сторонами; власник продукту, розробники та тестування.

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

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

СКРУМ полягає в тому, щоб зробити процес легкої ваги, який може бути передбачуваним і повторюваним в рамках маніфесту спритності.

Мені сумно чути історії про те, що дуже хороші речі так перекручені.

Я здогадуюсь перед Scrum, всі просто робили те, що хотіли: yippee ki-yay mf'er . Ваші користувачі - ваші благодійники, і вони керують історією та сплачують рахунки. Власник продукту переконує, що історія закінчиться. Ось як, ваша група дійшла висновку, що Власник продукту повинен розповідати, як програмувати.

Ви хочете написати код або зробити акуратні маленькі програми, які, на вашу думку, класні? "Я хочу створити функцію A першою, а не B, щоб я міг підтримувати свою свободу вибору". Знайдіть іншого благодійника, а не нову методологію розробки.

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

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

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

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

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

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

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

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

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

З маніфесту Agile:

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

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

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

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

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

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

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

І у нас іноді є мікроуправління, але це інша проблема.

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

Питання: Методика прописує х, але х не працює добре. Що нам робити?

A: Уточнити вашу реалізацію x. Можливо, перестаньте це робити взагалі. Методологія - це не ваш начальник!

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

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

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

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

Я мав такий самий досвід роботи з Scrum і люблю називати це «тиранією історії».

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

Єдиний вихід, який я знайшов поки що, - це або відкинути Scrum - часто це не можливо і / або доцільно, оскільки, зрештою, у нього є переваги - або запровадити щось на кшталт 20% часу Google, щоб розробити розробників творчим відділенням, крім "ти" Ви можете вибрати спосіб реалізації сторінки для входу ", оскільки насправді ви не такі, як ваша реалізація обмежена наявним кодом та архітектурою системи - тобто, якщо не враховувати свободу вибору між циклом" a і a time "a свобода.

Існує велика різниця між тим, як ти вирішуєш, що робити , або тобі сказали, що робити .

На мій досвід, існує досить довгий шлях від того, щоб сказати, що робити, і вирішити, що робити.

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

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

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

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