Чи новий Agile новий мікроуправління?


80

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

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

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

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

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

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

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


Це компанія в галузі охорони здоров'я, яка має офіси в США. Це, безумовно, відчуває, що стиль ковбоя спритний, що змушує мене взагалі не хотіти ходити на спритність, особливо в моїй компанії.

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

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

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


71
Я бачив більше зловживань в ім'я спритного, ніж мені цікаво коментувати. Багато разів "ми робимо спритність" означає "ми викидаємо всю подобу процесу і робимо те, що ми хочемо, є!" (для очевидної довідки про ковбоя). Тихе середовище, безумовно, допомагає, але ви повинні дозволити розробникам спілкуватися один з одним і забивати речі - без схвалення диктатора .
Берін Лорич

28
Ну, ти не робиш Agile ...
CaffGeek

13
Це справді мова. Не питання.
JohnFx

8
2 дні на сертифікованому майстер-курсі scrum не роблять менеджера майстра scrum, так само як 24 години з навчанням себе c ++ за 24 години не робить вас здібним програмістом c ++. Вони просто роблять неправильно.
Мет

9
потрібно читання: Half-Arsed Agile Manifesto «Ми чули про нові способи розробки програмного забезпечення, виплачуючи консультант і читати звіти Gartner ...»
комар

Відповіді:


89

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


7
Єдине, що я міг знайти, - це повідомлення "Joel on Software" про топ-12 речей, які кожна компанія повинна надати своїм програмістам. Один з 12 був тихим місцем для роботи. Я сумніваюся, що Джоел Спольський мав на увазі це.
Берін Лорич

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

5
@Kevin Cathcart, ми погоджуємося з цим питанням. Зараз я був у компанії, де було навпаки. У нас було ~ 40 людей у ​​бичці з відкритими столами та без кубиків. Єдина команда, яка могла щось зробити, - це та, яка зробила більшість шумів. Це тип середовища, від якого ви хочете захистити.
Берин Лорич

8
@Kevin - Мій відділ розвитку - це відкрита кухонна ферма, поруч із масивом із трьох дзвонів із написом "Продаж", "Велика розпродаж" та "Величезні розпродажі". Кілька разів на день продавці дзвонять цим і кричать "wooooo!". : - \
Дан Рей

2
@Dan У мене був ряд інтерв'ю кілька років тому, коли три стартапи сказали мені, що треба перенести хлопців з продажу від дияволів, тому що вони теж були! @ # $ Ing.
Ерік Reppen

46

Їм майстер Scrum не може розмовляти з іншими розробниками та не може приймати телефонні дзвінки в робочій зоні

Це насправді не є частиною Agile практики - і окремим питанням.

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


29
Це абсолютно проти самого першого принципу маніфесту "Agile": "Індивіди та взаємодія над процесами та інструментами". Див. Agilemanifesto.org для отримання додаткової інформації.
Берін Лорич

"Це абсолютно проти самого першого принципу <XXX> Маніфесту"; замініть що-небудь на XXX, і у вас буде культ вибору. ;-) Серйозно, це не змушує задуматися?
CesarGon

5
@ CesarGon, в цьому випадку ми говоримо про принципи того, що робить спритну роботу. Якщо ви не можете приписати основні принципи спритного, то, можливо, ви не хочете спритного. Досить просто. Я не кажу "навернись до віри", я кажу "роби те, що ти кажеш, що віриш". Серйозно, що не що роблять вам цікаво?
Berin Loritsch

1
@ CesarGon, те, що описано в ОП, стосується полярної протилежності наміру цього керівництва, як ви можете отримати. У який момент ви вважаєте свій середній тон досить близьким? Те, як ви говорите, звучить як 95% різниця між тонами досить близька. Давай І дайте мені трохи кредиту. Я працюю в реальному світі і визначаю процеси в корпораціях вже давно. Я добре розумію, що досить близько - і те, що описана ОП - це не так.
Берін Лорич

2
@Berin Loritsch: Я тобі дарую кредит; не було мого наміру з’являтися інакше. Насправді моє первісне зауваження щодо культів намагалося звучати частково жартома. Я намагаюся зробити те, що нам не потрібно кілька рядків у маніфесті, щоб захистити щось, що відверто проти здорового глузду. ОП описує ситуацію, через яку всі сигнали тривоги. Я сподіваюся, що ти це сприймаєш красиво; вибачте, якщо я був занадто суворий. :-)
CesarGon

31

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


24

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

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

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

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

Отже, щоб відповісти на ваше запитання безпосередньо: Agile не повинен бути новим мікроуправлінням. Йдеться про надання можливості людям, які роблять фактичну роботу, щоб виконати лайно. Але у вашому випадку Agile звучить як остання брехня, яку вони вам говорять, поки вони потурають своїм поганим інстинктам. За що мені справді шкода.


4
+1. Agile / scrum / xp або будь-що інше - це лише терміни "mumbo jumbo" для ІТ-магазинів, які не є власне програмними компаніями. Як ви вже сказали, ніхто не вносив кардинальних змін, закопуючи голову в пісок за допомогою цих практик. Потрібно прочитати лише цей чудовий розробник програмного забезпечення Lean Software: Agile Toolkit і поставити всі BS позаду. Ці практики не для ІТ-магазинів - це мій висновок.
Сміт Джеймс

23

Це не спритно.

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

Гаразд, скандал розігнався!

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

Я відчуваю, що має бути по-третє. Немає.


-1, я не згоден. Швидкий розвиток також означає, що ви очищаєте та полегшуєте процеси, а також здатність адаптуватися до змін. Що, як буває, саме те, про що йдеться у Scrum. Розмова також стосується вимог та планування, інакше.
Сокіл

6
Так, давай, це 2012 рік. Цитуйте Кент Бек публічне написання або залиште його. Не має значення, чи він метушився на вашому дивані.
nes1983

6
@ nes1983: Я писав, що в 2011 році. Тоді було інакше.
Том Андерсон

3
Я ніколи не чув терміну "технічна заборгованість", поки на моєму радарі не вискочила скрута. Я був на тренінгу. Легко продається зміїна олія означала звернутися до менеджменту за рахунок довгострокових міркувань щодо якості продукції. 100% фігня. Хоча я б цілком проковтнув це, якби Scrum Masters отримав меч у стилі Конана людям, що загрожують цілісності процесу.
Ерік Реппен

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

16

Скрум - уродлива дитина Agile. Це найпопулярніший з усіх спритних методологій, і саме тому його найпопулярніший серед менеджерів.

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

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

Кращий приклад цього дан Алістер Кокберн (один з творців моторного маніфесту):

“Помістіть 4-6 людей у ​​кімнату з робочими станціями та дошками та доступом до користувачів. Дозвольте їм доставляти користувачеві перевірене програмне забезпечення кожні один-два місяці, а в іншому випадку залишайте їх у спокої.

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

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


Чи пропонують вони доставляти користувачеві перевірене програмне забезпечення кожні 2/3 тижні?
користувач272671

2
@ user272671 НІ. Нехай вони регулярно доставляють користувачеві перевірене програмне забезпечення. Не за тупо довільним графіком, як 2 або 3 тижні. Якщо користувачі або складність програмного забезпечення такі, що цикл працює 6 тижнів, то робіть 6 тижнів. Якщо це можна зробити на "коли завершено", тоді зробіть це. Не обмежуйте себе штучними обмеженнями. Такий не спритний.
gbjbaanb

11

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

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

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

У будь-якому випадку, якщо розробники відмовляться від цього, не застосовуйте його ! Або це буде катастрофа, яку ви описуєте.


9

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

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

Вони, звичайно, часто знаходяться в прямому протиріччі і можуть статися в одному проекті.


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

1
всякий раз, коли я стикався з scrum, його вводили, тому що менеджер (як правило, вище за керівника проекту) чув про це як про "річ".
jwenting

7

Щоб відповісти на ваше первісне питання, чи є новий Agile новим мікроуправлінням, я б сказав, що ні.

По-перше, прочитайте це (маніфест Agile), і ви помітите, що не спілкуватися зі своїми співавторами не вказано.

Насправді "Особи та взаємодія" - це якраз навпаки, якщо не спілкуватися з вашими співавторами.


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

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

2

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

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

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

Живий маніфест Agile

"Ми розкриваємо кращі шляхи розробки програмного забезпечення, роблячи це та допомагаючи іншим робити це".

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

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


1

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

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


1
Розвивайте трудові відносини після роботи, ми повинні розвивати наших часто нехтуючих відносин з друзями та родинами після роботи. Вважаючи, що Співробітники рідко дружать і користуються більшою кількістю можливостей допомогти собі за рахунок інших коштів. Компанія так, чоловіки, корони та інструменти просто не усвідомлюють цього, оскільки можливості нечасті. XP може мати деяку цінність, я не маю досвіду сказати інше. Scrum став іншою версією мікроменеджменту, принаймні, у 3-х компаніях, про яких я знав. .... Я знаю що, я дуже ненавиджу корпоративну Америку, щоб бути навіть трохи об'єктивною.
Дж. М. Бекер

0

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

Мої думки на тему "Деви не розмовляють ні з ким, а з майстром scrum":

Я працював там, де раніше це було правилом. ЗАРАЗ, правило було більше пов'язане з проханням людей виконувати завдання. Наприклад, я не можу випадковим чином підійти до тестера розробників і попросити їх зробити тестування для мене протягом наступних кількох годин. Мені потрібно поговорити з майстром scrum, щоб вони могли обговорити зі своїм членом команди, як ця робота впишеться у спринт, якщо це надзвичайна ситуація (або якщо її потрібно підштовхнути до відставання для майбутнього спринту).

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

В іншому випадку, чорти повинні БУДЬ розмовляти між собою. Завжди. Це допомагає вам швидше працювати над проблемами, стати ближчим як команда та швидше реалізовувати.

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

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


-1

Автор оригіналу Сміт Джейнс, можливо, мав досвід. Але це типові проблеми, які я знайшов у проекті Agile.

  1. Більшість організацій, розробників, як передбачається, працюють над декількома проектами, в Agile / scrum. Спринти ніколи не вважаються цим фактом. ваш Scrum Master передбачає, що вам слід закінчити свої історії в кінці спринту. Ваш майстер Scrum може бути присвячений лише одному проекту, але не розробникам. або дозволити телефонний дзвінок.
  2. Я бачив Agile проекти, де Sprint планується, Stories включені в Sprint, не збиваючись .. на півдорозі або в середині спринтів. є одним із зловживань у найбільш спритних проектах.
  3. Тестування: TTD .. так, це дуже добре .. але я бачив, що більшість Agile проектів повністю покладаються на TTD ... не передбачено жодного обсягу чи часу для функціонального або людського тестування ... Ще одне зловживання ... Також багато майстрів Scrum не знають і не розуміють важливості функціонального тестування. Ваш фрагмент коду може працювати ідеально, якщо він не задовольняє потреби бізнесу .. він не приносить користі. Це трапляється, коли бізнес не бере участь заздалегідь .. або участь там є ... але не відображає прийняття бізнес-рішень. Зрештою, розробники звинувачують, що ви не доставили функціонал .. або це закінчиться зміною в останню хвилину ... зайві довгі години, оскільки ваш майстер Scrum не хоче брати на себе вину за не завершену історію.

Зловживайте тут ... або низька участь бізнесу або учасника, не повністю обізнаного, або ділова людина, що випадає в середині спринту.

  1. Не всі проекти підходять для Agile ... Більшість менеджерів або майстрів scrum не знають цього .. Проекти технічного обслуговування .. Дефект, який може бути спочатку припущений, може бути зроблений за 8 годин, прийнятий у спринті. Витративши 4 години, виявив, що це Java / інший продукт ... (я нещодавно зіткнувся з дефектом, пов'язаним із Quartz Scheduler .. в межах нашого проекту), і цей дефект може призвести до оновлення продукту / пакета. фінансування, нова версія або оновлення повинні бути затверджені внутрішньою інженерією і т. д. 5. Ретроспекція: цей крок виконує лише декілька Agile проектів. Якщо це взагалі зроблено .. Управління, Scrum Master ніколи не брав на себе відповідальності за невдалі історії ..
  2. Створення пари .. Багато розробників розглядає парування як місце зловживання колег .. критикує інший дизайн, практику кодування .. поводження з рейтингом як командна робота. Вчіться один у одного ... Ще один спосіб зловживання Agile / Scrum.

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


дивіться це посилання .. Чому Agile проекти провалюються .. brighthubpm.com/agile/55778-why-do-agile-projects-fail
mukunda

Я, мабуть, згоден з інформацією, представленою в цій статті, і там. Я розумію, що є такі, хто вважає Agile непогрішним, але реальність Agile залишає мало місця для введення нових і більш ефективних ідей. is..brighthubpm.com / agile / 55778-why-do-agile-projects-fail
користувач272671

-3

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


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

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

1
Я згоден з @Geo. На сьогоднішній день у мене таке враження від того, що таке "Agile" у реальному світі. Якщо у вас є така установка на заводській підлозі - це просто форма мікроуправління. Тепер Маніфест намагається сказати нам, що це не так. Але проект за проектом, я змушений ще більше вірити, що це просто інша назва "Micromanagement". І це вбиває творчість.
користувач272671
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.