Agile для Solo Developer

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

• Выполняя тестовую разработку
• Развиваясь в небольших спринтах
• Имея много контактов с клиентом

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

В дополнение к ответу от klez (все хорошие предложения) я бы предложил следующее:

• Ведение
  журнала невыполненных работ по продукту В основе списка невыполненных работ по продукту лежит список всех элементов, которые вы собираетесь завершить на этом этапе для этого продукта.
• Поддержание спринт-спада и спада продукта
  . Спринт-спуск начинается со списка всех задач, которые вы решили выполнить в этом спринте (подмножество ваших продуктов, которые должны быть выполнены в течение определенного периода времени - например, 2 недели) вместе с оценка работы требуется. Когда вы отмечаете вещи, вы отмечаете их как выполненные; тем самым уменьшая (или сжигая) оставшуюся работу для этого спринта.
  Аналогичным образом, сокращение объема продаж продукта отслеживает оставшуюся работу для всей очереди продуктов.
• Принятие концепций относительной оценки и скорости
  Относительная оценка - это метод оценки, который использует другие задачи (или истории) в качестве руководства. Например, если вы знаете, что задача A проще, чем задача B, и примерно вдвое сложнее задачи C, вы должны убедиться, что «точки» для задачи A были правильными относительно этих ожиданий.
  Акцент делается не на правильном угадывании объема требуемой работы, а на поддержании согласованности оценок друг с другом.
  Скорость - это мера того, сколько «очков» вы заработали в спринте. Если ваша относительная оценка обеспечивает согласованность, эту скорость можно использовать для оценки того, какие задачи вы, скорее всего, будете выполнять в предстоящих спринтах. Обратите внимание, что эта скорость должна постоянно пересматриваться.

• Ограничение незавершенного производства (помимо тайм-бокса). Даже если вы используете итерационный метод (в отличие от Канбана), допустим, ваша скорость составляет 8 баллов за итерацию. Не начинайте работать на всех 8 сразу. Ограничение WIP количеством историй или баллов - это хорошо.
• Автоматические приемочные тесты для всех ваших пользовательских историй. Автоматизируйте как можно больше в целом.
• Ошибка в создании слишком маленьких пользовательских историй. Как правило, составьте соотношение самой большой и самой маленькой истории 3: 1 . Если вы недооцениваете историю в Scrum, и она оказывается слишком большой, несколько разработчиков могут использовать ее, чтобы вернуть ее в нужное русло. Но тебе не хватает людей.
• Если в командном контексте обычного размера вы не решитесь, стоит ли разделить всплеск пользовательской истории - в одиночном или небольшом коллективе, сделайте всплеск без колебаний. Это помогает сделать истории меньше и более предсказуемыми.
• Ретроспективы важны в Agile в целом, поэтому Kanban (это будет Personal Kanban) набирает здесь дополнительные очки, потому что его ретроспективный процесс в большей степени основан на данных. Трудно играть в Triple Nickels, когда людей не хватает.

Эти вещи, вероятно, применимы как к одиночной, так и к небольшой команде (2 или 3 разработчика).

ДОБАВЛЕНО: через некоторое время после того, как я написал этот ответ, я нашел этот доклад на конференции и был очень впечатлен: Личный Канбан: Оптимизация Индивидуального Кодера

• Либо работайте над четко определенными спринтами, либо сознательно выбирайте подход Канбана. Не случайно попал в Канбан
• Сначала ошибки, потом вторые.
• Все еще сосредотачивайтесь на ценности против раздувания функций. (ЯГНИ над позолотой)
• Ретроспективы так же ценны. И, что не менее важно, вносите изменения в процесс небольшими порциями. Не думайте, что сегодня вы начнете использовать TDD, Mock и IoC одним выстрелом, если у вас действительно нет внешних функций для доставки банкоматов. Приносите по одному за раз.

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

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

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

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

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