Действительно ли Agile работал для вас как разработчика?

Ответ 1

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

Что пошло не так:

• Компания, с которой я работал, имела известную репутацию для найма разработчиков начального уровня за самую низкую оплату (25-27 тыс. долл. США в год была нормой), и часто мы проводили аутсорсинг работы самому низкому участнику тендера. Я слышал, что проворный просто не работает на неопытных разработчиков, и я думаю, что это проявилось в коде и нашей скорости оборота.

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

• Отвратительное тестирование: наши автоматизированные тесты были неоценимы, но тестирование QA и UAT было катастрофой. Поскольку у нас не было никакой официальной документации по требованиям, пользователи QA не знали, какую новую функциональность они тестировали, поэтому все QA состояло из более или менее случайного сквозного тестирования. Приемочные испытания пользователя были выполнены в производстве: мы установили продукт на наших серверах клиентов и сообщили об ошибках, произошедших в процессе производства.

• Развитие, основанное на кризисе: ошибки были обработаны с помощью "OMG МЫ ИМЕЕМ ИСПОЛЬЗОВАТЬ ЭТО И REDEPLOY PRONTO! СЕЙЧАС ТЕПЕРЬ ТЕПЕРЬ! НИКАКИЕ ВРЕМЯ ДЛЯ ИСПЫТАНИЙ ИСПЫТЫВАЮТ ЭТО!" методологии управления.

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

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

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

Ответ 2

В моей компании мы сделали оптовый переход на гибкие практики около 4 лет назад, когда вошел новый вице-президент. Этот VP в прошлом испытал успех с Agile и решил, что это то, что нам нужно.

Как оказалось, он был прав. В то время я был разработчиком (хотя и несколько младшим), и мне нравились эти практики. Паровое программирование действительно помогло передаче знаний и предотвратило формирование бункеров знаний. Единичное тестирование, разработка, основанная на тестах, и акцентирование тестов в целом сделаны для более надежного кода, который не был слишком переработан. No Big Design Up Front означало, что вместо того, чтобы 6 месяцев писать документы требований (к тому времени рынок прошел мимо нас), мы были прототипом и своевременно предоставляли реальную ценность клиентам. Работая в тесном контакте с суррогатом клиента (в нашем случае, техническим менеджером продукта), значительно сократилось время обратной связи по циклу, что помогло нам доставить то, что действительно хотел клиент.

В нашей организации было немало талантливых разработчиков, но мы были очень склонны к ковбойскому кодированию. Некоторым разработчикам не нравились новые методы ( "Что вы имеете в виду, пишите тесты? Я разработчик!" ), Но в целом все любили изменения. Дефекты снизились, уровень удовлетворенности клиентов повысился, и наш офис стал очень хорошо рассматриваться в нашей компании.

Примерно год назад я стал менеджером, и я активно использую Agile-практики, включая некоторые Lean-принципы (анализ потока ценности, удаление отходов, kanban). Затягивание циклов выпуска продолжается, и моя команда теперь выпускает как можно чаще (с качеством!) - часто каждые две недели. В прошлом году у моей команды не было выявленных недостатков моей команды, и люди продаж и управление продуктами любят более короткие циклы выпуска.

Как разработчик, Agile действительно увеличила мою уверенность в работе с различными областями кода (теперь я чувствую нервность всякий раз, когда я что-то меняю в пакете, который НЕ имеет 100% unit test охвата!), научил меня быть более продуманным программистом (думая о пробных последствиях, бизнес-эффектах и ​​т.д.) и помог мне написать простой, самодокументирующий код. Как менеджер, Agile и kanban дают мне предсказуемость, более низкое время выполнения, более низкие коэффициенты дефектов и уполномоченную команду. Это не теория, не спекуляция или размахивание рук - моральный дух нашей команды, уровень ошибок, удовлетворенность клиентов и баланс не доказали, что Agile может делать замечательные вещи для организации.

Ответ 3

Прокомментировать Принципы Agile Manifesto из моего опыта на сайте, который его попробовал.

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

Это был обоюдоострый меч для моего последнего сайта - ценным было принято считать 100% совершенным и без ошибок.

Приветствуем меняющиеся требования, даже в конце развития. Гибкие процессы изменение жгута проводов для конкурентное преимущество.

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

Предоставляйте частое ПО, от пары недель до пары месяцев, с предпочтением более короткая шкала времени.

Норма в течение многих лет в основном строилась и развертывалась ежедневно, ежечасно, почти в режиме реального времени...

Деловые люди и разработчики должны ежедневно работать на протяжении всей проект.

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

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

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

Самый эффективный и эффективный метод передачи информации в и в рамках команды разработчиков беседа лицом к лицу.

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

Рабочее программное обеспечение является основным меру прогресса.

Без сомнения, здесь.

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

Я согласен с этим 100%; проблема с прошлой командой, с которой я работал, заключалась в ожидании 30-часовых дней, 10-дневных недель и 400-дневных лет не было темпа, с которым я согласился.

Постоянное внимание к техническим превосходство и хороший дизайн маневренности.

Именно здесь необходим моральный дух и образование разработчиков.

Простота - искусство максимизации количество выполненной работы - не необходимо.

Мне это нравится, и это была одна из моих целей. Тем не менее, было "если вы не печатаете, вы не работаете", которое было трудно преодолеть.

Лучшие архитектуры, требования, и конструкции возникают из самоорганизующиеся команды.

Я согласен с этим около 90% - мое единственное предостережение в том, что они должны быть хорошо образованными и хорошо информированными командами.

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

Мы просто потерпели неудачу, и это, вероятно, вызвало массу других проблем, которые у нас были. Деловая сторона действительно хорошо говорила: "Вам нужно делать то, что мы говорим, должно быть сделано".

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

Ответ 4

Agile отлично зарекомендовал себя как разработчик в моей нынешней среде. Вот несколько практик и почему это работает так хорошо:

• Программирование пар - это не позволяет кому-либо почувствовать индивидуальное владение кодом. Пары разработчиков, как правило, делают лучший код, чем один "сумасшедший научный" код, который, кажется, происходит, если один человек пишет кучу кода в изоляции. Это также позволяет кому-то быть привлеченным, если кто-то уходит, и эта функция или усовершенствование должны быть сделаны, пока человек уезжает. Иногда один разработчик может подумать, что что-то будет здорово, но если кто-то еще не сможет понять код, бесполезно иметь, если он не является совершенным и надежным в будущем, что маловероятно.

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

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

• YAGNI - принцип "вам не нужен", который действительно может быть тяжелым, если вы были проницательным программистом, который обычно ставит 101 вещи как "ну, мне может понадобиться это когда-нибудь..." mindset. Другой способ поставить это идея "Keep It Simple, Stupid".

• Спринты. Идея здесь, похоже, не позволяет почувствовать себя подавленным, поскольку мы просто работаем в течение 2 недель по тому или иному вопросу и не смотрим слишком далеко вперед, так как это может измениться.

• Демонстрации. Показывая, что мы сделали, получить обратную связь о том, что хорошо, а что нет, имеет решающее значение для улучшения качества и наличия мышления, которое мы хотим "непрерывного улучшения" в проекте и что хорошего достаточно сегодня, завтра будет не достаточно хорошо и лучше поработать над тем, что мы делаем.

• IPM, ретроспективы. Возможность взглянуть на то, что было сделано в ретроспективе, полезна для устранения разочарований, празднования того, что хорошо работает, и поиска путей решения проблем с болью. IPM - это то место, где мы определяем наше будущее для следующего спринта с точки зрения того, какими будут цели, и как долго мы будем думать, что будут делаться разные вещи, используя несколько различных инструментов оценки, один для точек на "эпиках", как мы их называем, и другой в течение нескольких часов на отдельной задаче или карточке, которая является частью истории, которая является чем-то между эпическим и небольшим произведением.

• Истории Storywall и пользователей - теперь это низкотехнологичный инструмент, поскольку это всего лишь несколько досок, с разделителями и столбцами, которые обеспечивают некоторую структуру. У нас есть полосы для каждого из эпосов и различных столбцов для состояний работы: отставание, в разработке, на dev или в тесте. Есть также места для отставания задачи, заблокированных карточек, вопросов, стандартов и практик и несколько других вещей, которые могут быть полезны для менеджеров, чтобы увидеть, чтобы получить обзор текущего состояния, если они хотят получить более большую картину, чем то, что они будут получить при standup.

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

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

Ответ 5

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

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

Ответ 6

Я одновременно разработчик и менеджер, поэтому у меня либо есть особое понимание, либо мое мнение совершенно недействительно.;)

Я скажу, что Agile означает много чего. На данный момент это целая группа методологий и руководств.

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

Мне удалось медленно реализовать кучу вещей из Scrum без (надеюсь), как инструмент. Сжигание отчетов, стендовых встреч и карточек с рассказами на доске действительно помогло нам в доставке программного обеспечения. Например, по любым проектам задачи постоянно выполняются досрочно или поздно. В действительно большом проекте очень сложно сказать, что это делает с датой вашего корабля. С отчетами о сжигании я могу сказать, что делает проскальзывание на дату нашего корабля, и если нам нужно просто начать резку функций, чтобы соответствовать сроку.

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

Но это не просто управленческий материал. В Agile существует тонко о лучших методах управления версиями, модульном тестировании и т.д. Просто хорошие надежные методы. Как индустрия, мы довольно ужасно относимся к наставничеству, так что хорошо, что эта информация там.

Ответ 7

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

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

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

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

Ответ 8

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

Возьмите TDD в качестве примера: Код теста, красная полоса, код функциональности, зеленая панель, рефакторинг, красная полоса, исправление, зеленая полоса.

С точки зрения менеджеров также справедлив более быстрый цикл обратной связи: ежедневная встреча, зеленый статус, ежедневная встреча двух, статус желтый, контрмеры/повторное назначение ресурсов, ежедневная встреча три, статус зеленый.

Непосредственная обратная связь и знание того, куда вы направляетесь, создают ощущение безопасности.

Ответ 9

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

Ответ 10

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

Но с организационной точки зрения, если он дает результаты, кого это волнует.

Ответ 11

Я думаю, что делает "гибкий" проект гибким, это методология: "Дизайн на сегодня не на завтра".

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

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

Теперь, эта техника "работает"? Да! При правильном применении технология способствует тому, что программный продукт будет готов к отправке в любое время, чтобы реагировать на конкуренцию.

С другой стороны, поскольку программисты чувствуют, что они кодируют больше, они, как правило, более счастливы. И они менее раздражены написанием спецификаций, потому что эта фаза по своей природе всегда мала.

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

Ответ 12

Практически все менеджеры знают о "Agile": теперь эта вещь, вы знаете? В одиночку по вашему первоначальному вопросу я бы предположил, что что-то действительно не так. Я действительно рекомендую вам читать книгу, например Практики гибкого разработчика (как говорится в названии - о том, что для вас).

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

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

Взгляните на отслеживание времени (и оценку времени) - есть некоторые менеджеры, которые думают об измерении того, сколько работы вы выполняете: Эй, у вас есть контракт на 40 часов, но инструмент отслеживания времени говорит, что вы работаете только 38h на этой неделе! Это не то, как это предназначалось для использования.

Единственное, что вы можете сделать по этому поводу: вам нужно узнать, какие гибкие методы существуют. Посредственные менеджеры выбирают те, которые они находят интересными. Хорошие менеджеры поймут, почему и не только выбирают методы для их непосредственной выгоды, но также и те, которые сделают команду более счастливой/эффективной/командной (Team vs Workgroup).

P.S. Что-то, что вам действительно нужно позаботиться: в подвижном месте нет места для бездельников. Каждый должен делать вещи самостоятельно. Вы должны поставить личный интерес в успех продукта. Если вы ничего не делаете самостоятельно, кто-то скажет вам, что делать (а затем микроменеджмент).

Ответ 13

Действительно ли работает Agile?   " Да."

До того, как появилось "Agile Programming", существовали эквивалентные в значительной степени непризнанные методологии. Я думал, что они называются инкрементными прототипами, но, по-видимому, это было разделено на это и эволюционное прототипирование.

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

Это просто тот Водопад и другие разрушенные методы управления, которые получили всю прессу.

Я говорю "Проворные работы". Я говорю это единственное, что когда-либо работало.