Может ли фрилансер использовать гибкую разработку?

Я хочу улучшить способ разработки программного обеспечения. Я хочу разрабатывать быстрее и отличный код! Сегодня я использую метод водопада в качестве фрилансера, пишу веб-материалы (сайты, системы и т. Д.). Есть ли способ использовать гибкую разработку (XP, SCRUM и т. Д.), Работающий таким образом? Я ничего не знаю о гибкой разработке, с чего мне начать? Большое спасибо.

... Конечно, кроме парного программирования. ;-)

Серьезно, я тоже фрилансер и использую гибкие техники, насколько могу. Это работает для меня очень хорошо. Я широко использую TDD,

Никто нигде не использует 100% XP или Scrum, но каждый использует его части, пытаясь принять столько, сколько работает для них. По моему мнению, чем больше вы принимаете, тем лучше для вас.

Больше всего мне не хватает парного программирования. То, как вы преодолеваете это

1. Перейти на множество групповых встреч пользователей.
2. Найдите пару людей, которых вы уважаете как разработчиков.
3. Попросите их встретиться с вами за чашкой кофе или что-нибудь написать код. Периодически отдавайте им часть вашей почасовой заработной платы, если вы чувствуете, что это необходимо, или просто отвечаете натурой на работу над их кодом.
4. Посетите или создайте Hack Club, как этот: http://www.DallasHackClub.org .

Вот некоторые ресурсы, которые я использую:

• Экстремальное программирование - быстрое онлайн-руководство по XP.
• Отличный обзор Scrum .
• Фантастическая и короткая книга . Идеально для вас!

Поэтому я бы сказал, что использование Agile в качестве фрилансера состоит из трех основных «замечательных моментов»:

1. Для крупных клиентов, Работа / счет в итерациях. В конце итерации заказчик может продолжить работу над проектом или завершить проект (то есть: он достиг своей цели). Я знаю (из опыта), что я не могу оценить хорошо больше, чем несколько недель, и оплата за итерацию также поддерживает поступление денежных средств. Неинтересно быть на шестом месяце трехмесячного проекта и ждать чтобы завершить проект, чтобы вы могли ...

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

3. Хорошие инструменты для совместной работы с клиентами. Моя стандартная оценка (для чего-то меньшего, чем стоимость работы итерации) на самом деле представляет собой серию шагов по поведенческому развитию, основанных на ожиданиях клиента. Я отправляю это клиенту и говорю: «Это правильно?». Это гарантирует, что все находятся на одной странице.

4. Самая простая вещь, которая могла бы работать. Об этом следует помнить во время работы: не бойтесь вернуться к клиенту и сказать: «Это было бы намного проще (или более мощным, или чем-то еще), если бы мы сделали это таким образом ...» "

5. Скрам это важно. Мне нравится отправлять своим клиентам электронные письма каждый день, когда я работаю над их проектом. Это как моя схватка с ними: «над чем я работал сегодня», «что / когда я собираюсь работать над их проектом дальше?», «Есть ли что-то на моем пути?» И «В целом, как продвигается прогресс ?»

6. Разработка, управляемая тестами, действительно полезна даже для одного программиста. Мои "оценки с историями BDD в них" помогают мне подпитывать этот процесс.

Отличный способ начать путешествие Agile - настроить рабочий процесс с помощью системы KANBAN.

У нас просто есть 3 дорожки:

1. Наши задачи или отставание
2. Над чем мы работаем или в процессе
3. Вещи, которые мы завершаем или СДЕЛАНО.

Этот простой Agile рабочий процесс - отличный способ начать.

С точки зрения кодирования, я бы рекомендовал использовать разработку через тестирование (TDD). Мы включили много замечательных ссылок, описывающих TDD, в нашу статью, но перепишем их здесь:

Для получения дополнительной информации проверьте следующие ресурсы:

• AgileData.org - отличный ресурс для разработки через тестирование.
• JamesShore.com - Еще одна отличная поломка для TDD
• Net Tuts - забавное введение в TDD, которое мне нравится!
• Артима - Интервью с Мартином Фаулером
• Игры изнутри - хороший пример TDD
• DaniWeb - Введение в TDD для разработчиков
• Марк Левисон - Статья о TDD

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

Поскольку вы пытаетесь найти свой собственный путь, чтобы улучшить свою общую эффективность, вот несколько советов, которые могут помочь вам, по крайней мере, не совершать те же ошибки, что и я:

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

Тот факт, что они больше подходят для облегчения совместной работы команды, не имеет значения. Удержаться от соблазна. Вы не кладете себя в том, чтобы что- то делать, а затем надеетесь, что принятие этого сработает к лучшему. Это не так, это просто расстраивает вас. Сначала вы находите свой способ ведения дел, а затем ищите подходящее программное решение. Я закончил с использованием досок (начался с одной, но теперь у меня в комнате две) для отслеживания / разработки историй и техники Pomodoro | Список дел « Сегодня», чтобы отслеживать мои задачи по разработке, и это чертовски 2011 год. Придерживайтесь основ, пока мы не получим некоторые интерфейсы, такие как интерфейсы Iron Man 2 или летающие машины.

Отражение, отражение, отражение

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

Заботьтесь о сроках, сосредоточьтесь на том, как быстро вы справляетесь

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

Отклоняться соответственно

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

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

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

Конечно, принятие методологии проектирования, отличной от Waterfall, может быть очень полезным для эффективного управления жизненным циклом проектов в зависимости от требований вашего бизнеса. Для быстрой разработки существует огромное количество ресурсов онлайн. Я хотел бы взглянуть на AUP (Agile Unified Process), который включает в себя TDD (Test Driven Development). Это может быть чрезвычайно полезно при создании / управлении большими масштабируемыми системами.

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

Например, вы часто не соблюдаете сроки? Новые функции вводят большое количество ошибок? Вызывают ли новые требования серьезную перепланировку? Требует ли бизнес регулярных рабочих систем для представления? Проверьте: Agile , Iterative и Agile Intro .