Как применять гибкие личные проекты?

Ответ 1

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

• Работайте над материалом, который добавляет ценность конечному продукту. Сделайте себе отставание от функций и расставьте приоритеты, как если бы вы были клиентом. Тогда дисциплинируйте себя, чтобы работать над функциями, основанными на их ценности для продукта, а не на том, что вы хотите сделать прямо сейчас. Это может сэкономить вам много ненужного, чрезмерно разработанного кода, который вы не будете использовать. Если у вас есть крайний срок, это еще более важно.

• Имейте эволюционный дизайн: начните с The Simplest Thing, которая может быть бесполезной работой и рефактором.

• Отложить решения до последнего ответственного момента.

• Внесите свой вклад в спринты или итерации (ОЧЕНЬ важно для университетских проектов).

• ...

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

При написании этого ответа, по крайней мере 3 других ответа подошли и избили меня. Я согласен со всеми из них.:)

Ответ 2

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

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

Ответ 3

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

Тем не менее, вы можете принять некоторые из методов:

• Часто выпускать
• Сосредоточьтесь на потребностях ваших пользователей.
• Не стесняйтесь отклоняться от основных планов версий - вы можете менять направление, когда захотите
• Потратьте меньше времени на создание основных фреймворков и получите что-то работающее как можно скорее. Затем вернитесь назад и рефакторинг, чтобы выполнить свои первоначальные потребности (если они все еще применяются).

Ответ 4

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

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

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

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

Как только разработанная карта будет выполнена, вы должны написать автоматические функциональные тесты. Вы можете использовать Quick Test Pro, FIT, Cucumber или другой любимый автоматический инструмент unit test. Я бы держался подальше от любых функций воспроизведения и записи, поскольку это может привести к переделке в будущем в качестве рефакторинга.

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

В конце итерации и до перехода вашего рабочего программного обеспечения на производство вы можете выполнить Тестирование приёма пользователей.

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

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

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

Ответ 5

Можно использовать Scrum для проектов одного человека.

• Создать резервную копию
• Оптимальное время для одного спринта - половина дня.

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

Ответ 6

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

Ответ 7

Несколько мыслей об этом:

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

Вполне возможно быть Agile в личном персональном проекте IMO.

Ответ 8

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

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

Я думаю, что диаграммы Big Visible и диаграммы Burndown/Burnup настолько полезны, что я написал программу Task Analytics, чтобы упростить эти графики, Он идеально подходит для проектов с небольшим или одним человеком.

Удачи.