Agile для разработчика-одиночки

• За счет разработки на основе тестирования
• За счет разработки в небольших спринтах
• Имея много контактов с клиентом

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

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

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

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

Эти вещи применять возможно как соло, так и небольших команд (2 или 3 разработчиков) ситуациях.

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

• Либо работать хорошо определенными спринты, или сознательно выбрать подход канбан. Дон'т случайно попадают в канбан
• Ошибки во-первых, особенности второй.
• Все-таки удержать внимание на значение и особенность раздуваться. (YAGNI за золото плакировкой)
• Ретроспективы не менее ценны. И что не менее важно, внести изменения в процесс небольшие куски. Дон't решить, что сегодня вы'ре собираюсь начать ходить ТДД МОК и МОК в один выстрел, если вы действительно не имеют внешних признаков поставке банкоматов. Принесите один за раз.

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

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

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

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

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