Чи змушує Agile розробників витрачати більше часу, фактично працюючи?

Дивлячись на загальні методи Agile, мені здається, що вони (навмисно чи ненавмисно?) Змушують розробників витрачати більше часу, фактично працюючи на відміну від читання блогів / статей, спілкування в чаті, перерв на каву та просто зволікання.

Зокрема:

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

2) Короткі історії - коли у вас є ВЕЛИЧИЙ шматок роботи, яку потрібно виконати, наприклад, за місяць, досить часто звичаюватись протягом перших трьох тижнів і перейти в режим OMG DEADLINE для останнього.

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

3) Командна комунікація та згуртованість - коли у вас низька ефективність у повільному, віддаленому та тихому середовищі, це може відчувати себе нормально, але коли наприкінці дня на зустрічі Scrum усі можуть похвалитися тим, що вони досягли, і ви нічого не можете сказати, що можете насправді відчути соромно.

4) Тестування та зворотній зв'язок - знову ж таки, це заважає вам тримати завдання "99% готовими" (коли насправді це близько 20%), поки термін несподівано не відбудеться.

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

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

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

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

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

Коли ви говорите: "Ви насправді можете соромитися", хіба це не добре? Це означає, що ви відчуваєте, що зробили не так і повинні. Вам нічого не платять, щоб нічого не зробити. Якщо нічого не зробити, змушує себе почувати себе безпорадним, нещасним, недостойним, нещасним. Замість того, щоб соромитися, відступіться і подумайте: "Чому я нічого не зробив сьогодні?" Тобі потрібна допомога? Чи є щось, чого ти не розумієш? Поточне завдання занадто важке? Вам це не подобається? Можливо, ви можете переключити завдання з кимось іншим. Можливо, хтось ще може допомогти вам пройти. Agile означає: візьміть на себе відповідальність, а не мікроконтролюйте, як маріонетку на струнах. Вам потрібен інструмент? Ідіть до свого начальника і попросіть його. Навчіться сперечатися. Навчіться вставати і кричати, коли треба.

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

Я згоден.

Парне програмування

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

Розповіді

Командна комунікація та згуртованість

Тестування та відгуки

Так Agile, а саме Scrum - це величезний приріст продуктивності. При правильному застосуванні перевернення може становити до 20% (1 розробник на 5 залишає компанію).

Причина проста: Scrum не забезпечує більшої продуктивності it provides the whole company with much more visibility on what's going on(в тому числі в управлінні, звичайно).

• Неможливо для розробника просто робити мінімум. Голий мініум - це тепер середня команда!

• Це робить неможливим, щоб керівництво не співпрацювало належним чином.

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

Наприклад, державний сектор дійсно не підходить для Agile.

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

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

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

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

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

Agile, все, що я створюю, - це кілька результатів.

У нашій компанії

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

Короткі історії - Тоді збиваючись на 3 тижні (приблизно 5-6 годин на день) і поспішаючи в останній момент (приблизно 12-14 годин на день) як розробник, мені не подобається коливатися в моєму трудовому тягарі. Працюйте близько 8 годин на день і зберігайте свій графік стабільним, і це завжди виглядає COOL.

Комунікація в команді та згуртованість - На зустрічі з неприємностями ми не лише ділимось завданням, але й перешкодами. Тут, коли комусь справді потрібна допомога, інші члени насправді придумують свої ідеї, щоб допомогти йому. Але, безумовно, для цього вам потрібна чудова команда, і ми :)

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

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

Чи відчуваєте ви, що в Agile ви працюєте більше, ніж за "звичайними" методологіями?

• Якщо ви маєте на увазі, чи відчуваю я себе більш продуктивним під Agile, я б сказав, що це залежить .
   
  _{Я зазвичай думаю про це з погляду Ferrari (як звичайного) проти Landrover (як Scrum). Під час руху по трасі Ferrari б'є пекло з Landrover.
   
  Це позашляховик, коли потрібен джип, а не спортивний автомобіль - я маю на увазі, якщо ваші вимоги нерегулярні та / або якщо командна робота та досвід управління не такі гарні, вам доведеться вибирати Scrum - просто тому, що, якщо спробувати звичайний, ви отримаєте ти застряг - як Ferrari застрягне бездоріжжя.}

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

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

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

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

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

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

властиво відшаровуватися протягом перших трьох тижнів

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

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

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

4) Тестування та зворотній зв'язок - знову ж таки, це заважає вам тримати завдання "99% готовими" (коли насправді це близько 20%), поки термін несподівано не відбудеться.

Проекти водоспаду можуть мати тестування та щоденні побудови.

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

Agile не змушує розробників працювати більше , але працювати ефективніше

Фразування питання "змушувати розробників працювати більше" стикається з невеликим негативом, але, безумовно, це позитивно, якщо ми насправді більше робимо і менше відкладаємо?

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

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

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

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

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

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

"Гармати не вбивають людей. Люди вбивають людей!" Так само і з Agile. Agile не змушує людей працювати більше, менеджери змушують людей працювати більше.