Agile для Solo Developer

133

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

kelleystar
источник
77
Я просто пытался принять парное программирование в качестве индивидуального разработчика, и это улучшило качество моей работы!
Wizard79

Ответы:

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

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

Федерико Клез Каллока
источник
18
Я бы категорически не согласился с утверждением, что разработка «Ковбоя» является гибкой, даже для индивидуального разработчика
Трэвис Кристиан,
4
@TravisChristian - это больше одинокий рейнджер.
JeffO
9
Вот ссылка на тезис , который @ a.brookshollar пытался оставить в качестве правки.
Скотт Уитлок
6
Держу пари, что ни Тревис, ни 11 человек, которые проголосовали за его комментарий, не читали этот тезис. Полное название: «Ковбой: методология гибкого программирования для индивидуального программиста», и хотя оно немного устарело, его стоит прочитать.
Брайен Мэлоун
2
Ссылка на тезис
устарела
39

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

  • Ведение
    журнала невыполненных работ по продукту В основе списка невыполненных работ по продукту лежит список всех элементов, которые вы собираетесь завершить на этом этапе для этого продукта.
  • Поддержание спринт-спада и спада продукта
    . Спринт-спуск начинается со списка всех задач, которые вы решили выполнить в этом спринте (подмножество ваших продуктов, которые должны быть выполнены в течение определенного периода времени - например, 2 недели) вместе с оценка работы требуется. Когда вы отмечаете вещи, вы отмечаете их как выполненные; тем самым уменьшая (или сжигая) оставшуюся работу для этого спринта.
    Аналогичным образом, сокращение объема продаж продукта отслеживает оставшуюся работу для всей очереди продуктов.
  • Принятие концепций относительной оценки и скорости
    Относительная оценка - это метод оценки, который использует другие задачи (или истории) в качестве руководства. Например, если вы знаете, что задача A проще, чем задача B, и примерно вдвое сложнее задачи C, вы должны убедиться, что «точки» для задачи A были правильными относительно этих ожиданий.
    Акцент делается не на правильном угадывании объема требуемой работы, а на поддержании согласованности оценок друг с другом.
    Скорость - это мера того, сколько «очков» вы заработали в спринте. Если ваша относительная оценка обеспечивает согласованность, эту скорость можно использовать для оценки того, какие задачи вы, скорее всего, будете выполнять в предстоящих спринтах. Обратите внимание, что эта скорость должна постоянно пересматриваться.
Damovisa
источник
Отставание продукта, выгрузка, относительная оценка (сюжетные точки) и скорость - все это важные гибкие методы. Ни один из них не является специфическим для ситуации одиночного практикующего.
ажеглов
4
... как и TDD, спринты и контакты с клиентами ...
Дамовиза,
5
было бы хорошо, если бы вы также сказали, что означает весь этот жаргон. Я так же невежественен, как и до того, как прочитал этот ответ ..
Нажмите Upvote
2
@Damovisa: Мне не нужны ваши описания или поиск в Интернете, большое спасибо. Вы довольно точно описываете некоторые распространенные практики Scrum. Это именно отправная точка вопроса ОП. Да, эти практики существуют, но они ориентированы на команду, как я могу применить их на микроуровне? В ваших описаниях нет ничего специфичного для микромасштаба.
ажеглов
4
@azheglov Ого, не нужно обижаться. Я подчеркнул, какие части Scrum, на мой взгляд, наиболее полезны в сценарии соло-разработки, а не как их применять. Ни один из этих методов не должен измениться вообще для сольной команды, поэтому они будут применяться точно так же. Чтобы отразить ваши слова - в этих методах нет ничего, что было бы характерно для микромасштаба.
Дамовиза
21
  • Ограничение незавершенного производства (помимо тайм-бокса). Даже если вы используете итерационный метод (в отличие от Канбана), допустим, ваша скорость составляет 8 баллов за итерацию. Не начинайте работать на всех 8 сразу. Ограничение WIP количеством историй или баллов - это хорошо.
  • Автоматические приемочные тесты для всех ваших пользовательских историй. Автоматизируйте как можно больше в целом.
  • Ошибка в создании слишком маленьких пользовательских историй. Как правило, составьте соотношение самой большой и самой маленькой истории 3: 1 . Если вы недооцениваете историю в Scrum, и она оказывается слишком большой, несколько разработчиков могут использовать ее, чтобы вернуть ее в нужное русло. Но тебе не хватает людей.
  • Если в командном контексте обычного размера вы не решитесь, стоит ли разделить всплеск пользовательской истории - в одиночном или небольшом коллективе, сделайте всплеск без колебаний. Это помогает сделать истории меньше и более предсказуемыми.
  • Ретроспективы важны в Agile в целом, поэтому Kanban (это будет Personal Kanban) набирает здесь дополнительные очки, потому что его ретроспективный процесс в большей степени основан на данных. Трудно играть в Triple Nickels, когда людей не хватает.

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

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

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

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

MIA
источник
3

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

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

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

S.Robins
источник
0

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

codeyoung
источник
8
Это БОЛЬШЕ из значения, которое я получаю откуда-то вроде stackoverflow. Я не могу сказать вам, сколько вопросов я набрал, а затем не нажал "Отправить".
Дэн Рэй
5
Связанный: c2.com/cgi/wiki?RubberDucking
Джо Лисс
2
Резиновая утка - отличная концепция (обсуждается в соответствующих вопросах здесь), но как это отвечает на заданный вопрос? «Как бы кто-то реализовал концепции процессов Agile в качестве индивидуального разработчика?»
комнат