Вызывает ли Agile разработчиков больше времени на работу?


25

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

Особенно:

1) Парное программирование - самый большой трудовой фактор, просто потому что неудобно делать все эти проволочки, когда двое из вас сидят вместе.

2) Короткие истории - когда у вас ОГРОМНЫЙ кусок работы, который должен быть выполнен, например, за месяц, довольно часто расслабляться в течение первых трех недель и переключаться в режим OMG DEADLINE для последней.

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

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

4) Тестирование и обратная связь - опять же, это мешает вам держать задачи «готовыми на 99%» (когда на самом деле это около 20%), пока не наступит крайний срок.

Считаете ли вы, что в Agile вы работаете больше, чем в «обычных» методологиях? Это давление компенсируется более комфортной обстановкой и ощущением того, что все быстро делается правильно?



3
Я думаю, что Agile делает программистов более эффективными, делая их более счастливыми. Конечно, это преодолевает промедление, потому что два программиста видят друг друга, и чувство обмена идеями кодов гораздо более полезно, чем чтение блогов или ответы на вопросы на SE.com
такт

1
Кажется, Agile-программирование - это EPIC WIN, я прав?
Адам Арольд

2
Слышали о «эффекте срока»? Эффективность почти вдвое приближается к крайнему сроку - Agile поддерживает двухнедельные итерации, чтобы сбалансировать скуку (простой) с беспокойством, удерживая вас на пороге продуктивности!
кандидат наук

Agile просто заставляет вас работать с собственностью! Если это ВАШЕ, вы потратите на это больше времени, чем кофе, серфинг, блоги. И поскольку это ВАШЕ, у вас будет положительная причина, чтобы признать это и закончить это - так же, как и другие. Отсюда и больше шансов у «команды» достичь цели! :)
PhD

Ответы:


38

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

Как вы заметили, парное программирование гарантирует, что вы остаетесь сфокусированным (среди других преимуществ, таких как улучшение распространения навыков / знаний, улучшение кода, меньше ошибок, унифицированный дизайн и т. Д.).

Я обнаружил, что дисциплина это всегда борьба за меня. Если я подружусь с кем-то, есть вероятность, что один из нас сегодня хочет поработать, а другой тянет за собой. Таким образом, «работа в течение месяца» часто превращается в «совместную работу в течение одной недели», удивляясь тому, как огромный объем работы решается в конце, потратить день или около того на восстановление (рефакторинг, исправление TODO в коде, добавление пару тестов, сёрфинг с чистой совестью) а потом перехват на следующий месяц работы.

Итоговый результат: я гораздо более расслаблен (больше, чем несмотря на постоянный контроль), сплоченность команды намного лучше, работа выполняется быстрее, люди не бредут вокруг какой-то незначительной проблемы часами или даже днями (потому что кто-то другой может заметить проблему гораздо быстрее).

Когда вы говорите: «Может, вам действительно стыдно», разве это не хорошо? Это означает, что вы чувствуете, что сделали неправильно, и вам следует. Вам не платят, чтобы ничего не сделать. Если вы ничего не делаете, вы чувствуете себя беспомощным, несчастным, недостойным, несчастным. Вместо того, чтобы стыдиться, отступите и подумайте: «Почему я ничего не сделал сегодня?» Тебе нужна помощь? Есть что-то, чего ты не понимаешь? Является ли текущая задача слишком сложной? Тебе это не нравится? Может быть, вы можете переключить задачу с кем-то еще. Может быть, кто-то еще может помочь вам пройти. Agile означает: взять на себя ответственность вместо того, чтобы быть микроуправляемым, как марионетка на струнах. Вам нужен инструмент? Иди к своему боссу и попроси его. Учись спорить. Учитесь вставать и кричать, когда вам нужно.

Что касается тестов, то есть приятное место, когда ваш код внезапно падает от «хорошего» до «идеального». Это тот момент, когда вы замечаете, что вам нужно реализовать функцию X, и вы подумали, что это станет кошмаром, и вдруг поймете, что код почти готов. Просто небольшой рефакторинг тут и там. Новый класс и готово. Четыре недели работы внезапно стали днем. Победа! Triumph!


20

Я согласен.

Парное программирование

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

Короткие истории

Командное общение и сплоченность

Тестирование и обратная связь

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

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

  • Для разработчика невозможно просто сделать минимум. Голый миниум теперь командный средний!

  • Это делает невозможным для руководства не сотрудничать должным образом.

Вот почему я сказал (в других моих ответах на подобные вопросы), что Agile не для каждой организации (и для всех).

Например, государственный сектор действительно не подходит для Agile.

Agile используется в качестве инструмента давления? Конечно, я видел это много раз. Это только делает вещи намного хуже.


7
Re: утомительно. Мы занимаемся парным программированием в моем офисе. Это 8 часов супер интенсивного материала ... и тогда вы можете просто пойти домой. 40 часов рабочих недель в сердце Силиконовой долины. (Помогает предотвратить выгорание).

2
+1 за "Agile не для каждой организации".
Райан Хейс

Хороший ответ. У вас также есть источник для этого "(1 разработчик на 5 уходит из компании)". Было бы интересно прочитать всю историю.
Jan_V

@Jan_V: сам Кен Швабер (в 2008 году). К сожалению, это не было записано.

+1: очень хороший ответ. Agile позволяет гораздо точнее следить за развитием, но не обязательно повышает производительность. Многим программистам не нужно парное программирование для мотивации: интересной проблемы может быть достаточно, чтобы они работали 10 часов подряд. В определенных ситуациях SCRUM может снизить производительность на 50% и более. Но все эти истории всегда объясняются словами: «Вы делаете это неправильно».
Джорджио

8

Считаете ли вы, что в Agile вы работаете больше, чем в «обычных» методологиях? Это давление компенсируется более комфортной обстановкой и ощущением того, что все быстро делается правильно?

Это заставляет меня работать больше, но, прежде всего, это заставляет меня работать над правильным делом. В любой момент я знаю, что я должен делать .

Это своего рода положительное давление. Это сильно отличается от некоторых внешних «вы уже отстали от графика, работайте больше, работайте сверхурочно!» вид давления.


7

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

Agile, все, что я создаю, это несколько результатов.


4

В нашей компании

Парное программирование - когда что-то действительно сложное и требует широкого анализа, даже мы бы собрали вместе двух отличных людей и выполнили бы задание в БЫСТРОЕ время. Здесь сложность задачи решает необходимость парного программирования.

Короткие истории - Затем расслабьтесь на 3 недели (примерно 5-6 часов в день) и в последний момент (примерно 12-14 часов в день) как разработчик. Мне не нравится колебаться в моей рабочей нагрузке. Работайте около 8 часов в день и сохраняйте свой график стабильным, и это всегда выглядит ОХЛАДИТЕЛЬНО.

Командное общение и сплоченность - На встрече Scrum мы не только разделяем статус задачи, но и препятствия. Здесь, когда кто-то действительно нуждается в помощи, другие участники действительно предложили бы свои идеи, чтобы помочь ему. Но, конечно, вам нужна отличная команда для этого, и мы :)

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

Поэтому, как разработчик, я очень доволен тем, что я беру на себя, и, черт возьми, могу сказать, что никогда не чувствовал НАСТОЯЩЕГО давления в срок.


4

Считаете ли вы, что в Agile вы работаете больше, чем в «обычных» методологиях?

  • Если вы имеете в виду, чувствую ли я себя более продуктивным в Agile, я бы сказал, что это зависит .
     
    Я обычно думаю об этом с точки зрения Ferrari (как обычный) против Landrover (как Scrum). При езде по шоссе Ferrari чертовски бьет Ландровера.
     
    Это бездорожье, когда нужен джип, а не спортивная машина - я имею в виду, если ваши требования нерегулярны и / или если командная работа и опыт управления не так хороши, вам придется выбирать Scrum - просто потому, что попытка перейти на обычную дорогу даст Вы застряли - как Ferrari застрянет на бездорожье.

Что касается «работать больше» , то я думаю, что подобные вещи, вероятно, недооценивают IQ программиста и его способность адаптироваться к различным формам управленческого слабоумия .

До сих пор я участвовал в двух командах Scrum, которые делали совершенно разные проекты в разных компаниях. В обеих командах я не заметил каких-либо изменений в моих привычках по сравнению, например, с водопадом / итеративным.

Я бы с гордостью заявлял, что это потому, что я такой особенный и непобедимый, но, честно говоря, я видел, что привычки всех других парней в команде тоже непобедимы.


«Что касается« работать больше », то я думаю, что такие ожидаемые вещи, вероятно, недооценивают IQ программиста и его способность адаптироваться к различным формам управленческого слабоумия». Что ж, могут быть команды, которым действительно нужно внимательно следить, чтобы сосредоточиться на своих задачах. ИМО это особенно актуально для неопытных разработчиков и плохих планировщиков. Конечно, для более опытных программистов эти практики выглядят как слабоумие в управлении , то есть они могут извлечь из них очень мало пользы или вообще не получить ее.
Джорджио

@ Джорджио, да, я имел в виду нечто подобное, когда заявлял, что "если работа в команде ... не так уж хороша", может быть хорошей причиной, чтобы предпочесть гибкую. Я только хочу отметить, что даже тогда ожидание, что agile заставит их «работать больше», является своего рода утопией ... или, точнее, слишком простой, чтобы работать хорошо. Я видел, как это успешно использовалось, чтобы научить неопытных разработчиков и плохих планировщиков работать и планировать лучше / больше
комнат

2
Вдобавок к этому, для опытных программистов все ритуалы SCRUM могут просто помешать выполнению мысли. Чтобы продолжить с вашей метафорой: если вы едете на Ferrari по прямой дороге, необходимость останавливаться каждые 2 км или около того, чтобы проверить, едете ли вы в правильном направлении, только замедлит вас. Но да, это поможет (плохим) менеджерам почувствовать контроль.
Джорджио

@ Джорджио согласен. Насколько я могу судить, вы правильно поняли мою метафору :)
Комнат

2

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


2
Нужна цитата. Это смелое утверждение; Я видел много занятой работы в "гибкой" среде.

2

неудобно делать все эти проволочки, когда двое из вас сидят вместе.

Я не согласен. Я работал с группой курильщиков, и им всем удавалось отдыхать вместе, потому что «все это делали».

обычно расслабляться в первые три недели

Это признак плохого управления независимо от методологии. Даже если через месяц будет огромный кусок, я ожидаю увидеть что-то в конце первой недели.

вам нечего сказать, вам может быть действительно стыдно.

Если вы готовы подрочить на три недели, подумайте о чушь, чтобы сказать.

4) Тестирование и обратная связь - опять же, это мешает вам держать задачи «готовыми на 99%» (когда на самом деле это около 20%), пока не наступит крайний срок.

Проекты водопада могут иметь тестирование и ежедневные сборки.

Лично я не хотел бы писать код и ничего не делать с ним в течение месяца. Я предпочитаю цикл с более короткой обратной связью в моем коде, независимо от того, является ли он закодированным обзором или подписью пользователя. Когда другие одобряют мою работу, это полезно. Это похоже на то, как кот бросает мышь на вашем пороге, чтобы вы знали, что она делает свою работу.


1

Agile не заставляет разработчиков работать больше , а работает более эффективно


1
и более продуктивным, что семантически более важно.

Это правда?
Кейси

0

Формулировка вопроса «заставлять разработчиков работать больше» наталкивается на небольшой минус, но, безусловно, будет позитивно, если мы действительно сделаем больше и откладываем меньше?

Тем не менее, это хороший момент. Я чувствовал себя немного измученным в этом году, но это огромное неписанное преимущество, которое я не признавал.

Я бы согласился, что Agile может привести к тому, что разработчики будут более продуктивными. Ваше мнение о видимости, ответственности и склонности к медлительности - все это очень верно.

Но гибкость может и должна привести к тому, что разработчики будут усерднее работать по позитивным причинам - кнут и пряник. Если все сделано хорошо, Agile даст разработчикам больше взаимодействия с пользователями, меньше проявлений надругательства, больше контроля над их работой, и все это может привести к получению большего от вашей команды.


1
вы правы, Agile - не в том, чтобы работать усерднее, а в том, чтобы более эффективно работать над самыми ценными вещами . По моему многолетнему опыту, это заставляет разработчиков фактически работать не так усердно, потому что у них более реалистичные сроки и результаты; будучи гораздо более продуктивным за такое же время, это приводит к * эффективности *

Никакая гибкая задача - это не повышение эффективности работы (и это не так, учитывая все встречи, обзоры спринтов и т. Д.), А более предсказуемое : вы не устанавливаете крайний срок, а затем эффективно работаете, чтобы его выполнить, а, наоборот, вы контролируете процесс так, чтобы установленные вами сроки стали более разумными. Так что речь идет не о производительности, а о предсказуемости .
Джорджио

0

дальнейшая работа по-прежнему не является семантически правильной или не имеет отношения к Agile, цель - повысить продуктивность . Особое внимание уделяется тому, чтобы меньше работать не над чем-то, а больше работать нормально над правильным ; что не означает работать больше , просто более продуктивно .

Побочным эффектом является то, что он очень быстро выставляет бездельников и тех, кто неэффективен или некомпетентен. Что больше похоже на то, что вы получаете.

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


-2

«Оружие не убивает людей. Люди убивают людей!» То же самое с Agile. Agile не заставляет людей работать больше, менеджеры заставляют людей работать больше.


2
Менеджеры не заставляют людей работать больше. Четкая видимость и быстрая обратная связь заставляют людей больше работать, и они делают.
Шон Макмиллан

Да, но до какой точки? В одном спринте вы выбираете 10 историй, следующий спринт: 15, следующий спринт: 20, следующий спринт: 25. Сколько времени до того, как команда достигнет своего человеческого предела, и не очень ловкий менеджер решит поднять его. Может быть, вы не сталкивались с такой ситуацией. В по-настоящему проворном проекте вы узнаете скорость своих команд по мере продвижения спринтов. В лучшем случае вы сможете работать с 10% маржи. Больше ничего.
DPD

2
На успешных гибких проектах, которые я сделал, мы используем «вчерашнюю погоду», чтобы планировать наши итерации. Сколько бы точек мы ни выполнили на прошлой итерации, мы планируем эту итерацию. Менеджер может уговаривать / кричать все, что он хочет, но команда решает, что им удобно, и это то, что запланировано. (Конечно, у нас был бай-ин на уровне директора, что означает, что если менеджер попытается форсировать команду, у него будут проблемы.)
Шон Макмиллан

@Sean McMillan - Может быть, менеджер не так уж важен, когда режиссер полностью покупает Agile, но это случается редко.
JeffO
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.