Имеет Гибкий, действительно работал на Вас как Разработчик? [закрытый]

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

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

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

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

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

Часто доставляйте работающее программное обеспечение, от пары недель до пары месяцев, с предпочтением более короткие сроки.

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

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

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

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

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

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

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

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

Здесь нет сомнений.

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

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

совершенство и хороший дизайн улучшают ловкость.

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

Простота - искусство максимизировать объем незавершенной работы - это необходимо.

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

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

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

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

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

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

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

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

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

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

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

а продавцы и менеджеры продукта любят более короткие циклы выпуска.

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

а продавцы и менеджеры продукта любят более короткие циклы выпуска.

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

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

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

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

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

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

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

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

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

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

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

• ЯГНИ - Принцип «Тебе это не понадобится», который может быть действительно сложным, если вы были проницательным программистом, который обычно вставляет 101 вещь как «Ну, мне может понадобиться это когда-нибудь ...». Другой способ выразить это - идея «Держи это просто, глупо».

• Спринты - Эта идея, кажется, предотвращает чувство подавленности, поскольку мы просто работаем в течение 2 недель над тем или этим, и не делаем этого. Не заглядываю слишком далеко вперед, так как это вполне может измениться.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Просто Waterfall и другие неработающие методы управления привлекли внимание прессы.

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

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

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

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

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

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

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

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