Глядя на обычные практики Agile, мне кажется, что они (преднамеренно или непреднамеренно?) Заставляют разработчиков тратить больше времени на работу, а не на чтение блогов / статей, общение в чате, перерывы на кофе и просто медлительность.
Особенно:
1) Парное программирование - самый большой трудовой фактор, просто потому что неудобно делать все эти проволочки, когда двое из вас сидят вместе.
2) Короткие истории - когда у вас ОГРОМНЫЙ кусок работы, который должен быть выполнен, например, за месяц, довольно часто расслабляться в течение первых трех недель и переключаться в режим OMG DEADLINE для последней.
А с небольшими кусочками (которые должны быть сделаны за день или меньше) все обстоит с точностью до наоборот - вы чувствуете, что время ограничено, нет места для маневрирования, и вы скоро будете нести ответственность за выполнение задачи, поэтому вы начинаете работает сразу.
3) Командное общение и сплоченность - когда вы проигрываете в медленной, удаленной и тихой обстановке, это может показаться нормальным, но когда в конце дня на собрании Scrum все хвастаются тем, чего они достигли, и вам нечего сказать, что вы действительно можете почувствовать стыдно.
4) Тестирование и обратная связь - опять же, это мешает вам держать задачи «готовыми на 99%» (когда на самом деле это около 20%), пока не наступит крайний срок.
Считаете ли вы, что в Agile вы работаете больше, чем в «обычных» методологиях? Это давление компенсируется более комфортной обстановкой и ощущением того, что все быстро делается правильно?
Ответы:
Основная идея гибких методов - помочь вам быть продуктивным - в позитивном смысле. Никого не волнует, если вы проводите час в серфинге каждый день, если уложитесь в срок. Все злятся, если ты каждый день полчаса занимаешься серфингом, но упускаешь срок. Решение: упростить соблюдение сроков.
Как вы заметили, парное программирование гарантирует, что вы остаетесь сфокусированным (среди других преимуществ, таких как улучшение распространения навыков / знаний, улучшение кода, меньше ошибок, унифицированный дизайн и т. Д.).
Я обнаружил, что дисциплина это всегда борьба за меня. Если я подружусь с кем-то, есть вероятность, что один из нас сегодня хочет поработать, а другой тянет за собой. Таким образом, «работа в течение месяца» часто превращается в «совместную работу в течение одной недели», удивляясь тому, как огромный объем работы решается в конце, потратить день или около того на восстановление (рефакторинг, исправление TODO в коде, добавление пару тестов, сёрфинг с чистой совестью) а потом перехват на следующий месяц работы.
Итоговый результат: я гораздо более расслаблен (больше, чем несмотря на постоянный контроль), сплоченность команды намного лучше, работа выполняется быстрее, люди не бредут вокруг какой-то незначительной проблемы часами или даже днями (потому что кто-то другой может заметить проблему гораздо быстрее).
Когда вы говорите: «Может, вам действительно стыдно», разве это не хорошо? Это означает, что вы чувствуете, что сделали неправильно, и вам следует. Вам не платят, чтобы ничего не сделать. Если вы ничего не делаете, вы чувствуете себя беспомощным, несчастным, недостойным, несчастным. Вместо того, чтобы стыдиться, отступите и подумайте: «Почему я ничего не сделал сегодня?» Тебе нужна помощь? Есть что-то, чего ты не понимаешь? Является ли текущая задача слишком сложной? Тебе это не нравится? Может быть, вы можете переключить задачу с кем-то еще. Может быть, кто-то еще может помочь вам пройти. Agile означает: взять на себя ответственность вместо того, чтобы быть микроуправляемым, как марионетка на струнах. Вам нужен инструмент? Иди к своему боссу и попроси его. Учись спорить. Учитесь вставать и кричать, когда вам нужно.
Что касается тестов, то есть приятное место, когда ваш код внезапно падает от «хорошего» до «идеального». Это тот момент, когда вы замечаете, что вам нужно реализовать функцию X, и вы подумали, что это станет кошмаром, и вдруг поймете, что код почти готов. Просто небольшой рефакторинг тут и там. Новый класс и готово. Четыре недели работы внезапно стали днем. Победа! Triumph!
источник
Я согласен.
Это очень интенсивный и исчерпывающий способ работы, и я никогда не применяю его, если у меня нет одних разработчиков, которых должны тренировать другие (например, новичков)
Да, Agile и, в частности, Scrum - это мощный инструмент повышения производительности. При правильном применении оборот может составлять до 20% (1 разработчик на 5 покидает компанию).
Причина проста: Scrum не обеспечивает большей производительности
it provides the whole company with much more visibility on what's going on(в том числе в управлении, конечно).Для разработчика невозможно просто сделать минимум. Голый миниум теперь командный средний!
Это делает невозможным для руководства не сотрудничать должным образом.
Вот почему я сказал (в других моих ответах на подобные вопросы), что Agile не для каждой организации (и для всех).
Например, государственный сектор действительно не подходит для Agile.
Agile используется в качестве инструмента давления? Конечно, я видел это много раз. Это только делает вещи намного хуже.
источник
Это заставляет меня работать больше, но, прежде всего, это заставляет меня работать над правильным делом. В любой момент я знаю, что я должен делать .
Это своего рода положительное давление. Это сильно отличается от некоторых внешних «вы уже отстали от графика, работайте больше, работайте сверхурочно!» вид давления.
источник
На самом деле, я гораздо продуктивнее, когда использую традиционные методы. С помощью обычного метода я создаю, например, подробный анализ требований, технико-экономическое обоснование, функциональную спецификацию, техническую спецификацию и множество протоколов встреч, и все это в течение нескольких месяцев! Я мог бы даже создать несколько строк кода, как только анализ воздействия будет сделан!
Agile, все, что я создаю, это несколько результатов.
источник
В нашей компании
Парное программирование - когда что-то действительно сложное и требует широкого анализа, даже мы бы собрали вместе двух отличных людей и выполнили бы задание в БЫСТРОЕ время. Здесь сложность задачи решает необходимость парного программирования.
Короткие истории - Затем расслабьтесь на 3 недели (примерно 5-6 часов в день) и в последний момент (примерно 12-14 часов в день) как разработчик. Мне не нравится колебаться в моей рабочей нагрузке. Работайте около 8 часов в день и сохраняйте свой график стабильным, и это всегда выглядит ОХЛАДИТЕЛЬНО.
Командное общение и сплоченность - На встрече Scrum мы не только разделяем статус задачи, но и препятствия. Здесь, когда кто-то действительно нуждается в помощи, другие участники действительно предложили бы свои идеи, чтобы помочь ему. Но, конечно, вам нужна отличная команда для этого, и мы :)
Тестирование и обратная связь - Конечно, как разработчик, я не хочу, чтобы я был обременен ошибками, наконец, в следующий момент после того, как вы обнаружите ошибку, это исправить ее, и снова, это позволит мне иметь хороший прогноз того, что следует / можно сделать следующее и перенести срок (при необходимости) соответственно.
Поэтому, как разработчик, я очень доволен тем, что я беру на себя, и, черт возьми, могу сказать, что никогда не чувствовал НАСТОЯЩЕГО давления в срок.
источник
Я обычно думаю об этом с точки зрения Ferrari (как обычный) против Landrover (как Scrum). При езде по шоссе Ferrari чертовски бьет Ландровера.
Это бездорожье, когда нужен джип, а не спортивная машина - я имею в виду, если ваши требования нерегулярны и / или если командная работа и опыт управления не так хороши, вам придется выбирать Scrum - просто потому, что попытка перейти на обычную дорогу даст Вы застряли - как Ferrari застрянет на бездорожье.
Что касается «работать больше» , то я думаю, что подобные вещи, вероятно, недооценивают IQ программиста и его способность адаптироваться к различным формам управленческого слабоумия .
До сих пор я участвовал в двух командах Scrum, которые делали совершенно разные проекты в разных компаниях. В обеих командах я не заметил каких-либо изменений в моих привычках по сравнению, например, с водопадом / итеративным.
источник
Agile заставляет программистов выполнять более полезную работу, потому что различные методы гибкой разработки отсеивают занятую работу и работу, которая просто не нужна.
источник
Я не согласен. Я работал с группой курильщиков, и им всем удавалось отдыхать вместе, потому что «все это делали».
Это признак плохого управления независимо от методологии. Даже если через месяц будет огромный кусок, я ожидаю увидеть что-то в конце первой недели.
Если вы готовы подрочить на три недели, подумайте о чушь, чтобы сказать.
Проекты водопада могут иметь тестирование и ежедневные сборки.
Лично я не хотел бы писать код и ничего не делать с ним в течение месяца. Я предпочитаю цикл с более короткой обратной связью в моем коде, независимо от того, является ли он закодированным обзором или подписью пользователя. Когда другие одобряют мою работу, это полезно. Это похоже на то, как кот бросает мышь на вашем пороге, чтобы вы знали, что она делает свою работу.
источник
Agile не заставляет разработчиков работать больше , а работает более эффективно
источник
Формулировка вопроса «заставлять разработчиков работать больше» наталкивается на небольшой минус, но, безусловно, будет позитивно, если мы действительно сделаем больше и откладываем меньше?
Тем не менее, это хороший момент. Я чувствовал себя немного измученным в этом году, но это огромное неписанное преимущество, которое я не признавал.
Я бы согласился, что Agile может привести к тому, что разработчики будут более продуктивными. Ваше мнение о видимости, ответственности и склонности к медлительности - все это очень верно.
Но гибкость может и должна привести к тому, что разработчики будут усерднее работать по позитивным причинам - кнут и пряник. Если все сделано хорошо, Agile даст разработчикам больше взаимодействия с пользователями, меньше проявлений надругательства, больше контроля над их работой, и все это может привести к получению большего от вашей команды.
источник
дальнейшая работа по-прежнему не является семантически правильной или не имеет отношения к Agile, цель - повысить продуктивность . Особое внимание уделяется тому, чтобы меньше работать не над чем-то, а больше работать нормально над правильным ; что не означает работать больше , просто более продуктивно .
Побочным эффектом является то, что он очень быстро выставляет бездельников и тех, кто неэффективен или некомпетентен. Что больше похоже на то, что вы получаете.
Методика не имеет значения , от того , или нет , разработчик не работает . Процесс заключается в том, что даже в водопаде обзоры руководства и обзоры кода также могут выявить эти проблемы, но не так прозрачно, как в большинстве Agile-методологий.
источник
«Оружие не убивает людей. Люди убивают людей!» То же самое с Agile. Agile не заставляет людей работать больше, менеджеры заставляют людей работать больше.
источник