Ответ 1

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

Во-первых, вы могли бы работать с другими, возможно, в проекте с открытым исходным кодом? Это была бы хорошая возможность опробовать гибкие методы с другими, у которых может быть больше опыта.

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

Ответ 2

Да

Проверьте PXP или личное программирование.

http://portal.acm.org/citation.cfm?id=1593127

Резюме из статьи:

Личностное экстремальное программирование (PXP) процесс разработки программного обеспечения для одиночный человек команда. Он основан на значения Extreme Programming (XP) то есть простота, связь, обратной связи и мужества. Он работает сохраняя важные аспекты XP и уточнение значений так, чтобы они может поместиться в одиночного программиста ситуация. PXP все еще может быть усовершенствован и улучшилось. Это в традиции из XP практиков, чтобы варьировать XP до охватывать все, что работает. Мы надеемся что PXP наследует эти прагматические корни, также. Отказ от принципов XP как программирование пары не обязательно трагедия. Мы все еще считают, что после XP строго более эффективный способ преследовать многопользовательские проекты. Но мы также убежден, что многие из XP методы и методы могут быть применены к индивидуальной работе. PXP подход пытается сбалансировать "слишком тяжелый" и "слишком легкий", методологии. PXP будет вводить правильное количество строгости для ситуации, не перегружая команда с ненужной бюрократией.

Ответ 3

Да - можно сделать много гибких практик как индивидуума.

Если вы уже знаете, как это сделать, вы можете сделать это как единственный разработчик:

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

Вещи, которые вы не можете сделать самостоятельно:

• парное программирование
• Семинары CRC/RRC (... вам нужно было бы поговорить с собой довольно много)

Ответ 4

Некоторые аспекты могут быть сделаны в одиночку: запуск продукта и использование панели задач приходят на ум. Посмотрите, что делает secretGeek.

Конечно, некоторые не могут: парное программирование, схватки и т.д.

Ответ 5

Программирование пар будет сложным:)

Позвольте проверить Agile Principles:

• Лица и взаимодействия над процессами и инструментами
• Рабочее программное обеспечение по полной документации
• Сотрудничество с клиентами по контракту
• Ответ на изменение в соответствии с планом

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

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

Ответ 6

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

• Ваша логика работы с программным обеспечением всегда должна отражать реальный мир. Вы ловите рыбу с удочкой, а не бейсбольной битой; поэтому забудьте об этом.
  
• Всегда начинайте строить из элемента проекта, к которому относятся все остальные элементы. Это имеет смысл, если вы думаете, что, как функция в программном проекте, который называется не более. Это может быть моделирование базы данных. Было бы бесполезно, если вы сначала моделируете уровень доступа к данным, прежде чем моделировать базу данных.
  
• Не обращайте внимания на изменение имен переменных. Это самая письменная запись в дневнике программиста; поэтому не нужно стыдиться.
  
• Методология изменяет мир. Сделать это стоит. Сделайте каждый логический процесс с помощью функции или процедуры. Когда проект станет огромным, вы поймете, что это лучший способ.
  
• Если вы не разрабатываете компилятор языка в сборке, не стесняйтесь использовать огромные цепочки вызовов процедур, в которых один вызывает другой, а другой - и т.д. Используйте методы повсюду, почти напоминающие каждый объект с классами и являющийся модульным.
  
• Модульность - это все. Установите модульность вашей основной цели. Я сказал, что все это время?
  
• Последнее слово для начала проекта. Если вы строите квартиру, вы, наконец, устанавливаете главный вход. Но при использовании вы входите в здание со входа. Знайте.
  

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

Ответ 7

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

Ответ 8

Definately. Agile очень гибкая с точки зрения количества людей. Некоторые методологии, такие как Scrum, сосредоточены главным образом на том, чтобы делать как можно больше в ограниченное время, например две недели (спринты). Это включает в себя все, что вы хотите. Если ваша команда требует QA, то это часть ее. Как одиночка, вы решаете, что хотите включить.

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

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

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

Ответ 9

Да

XP/TDD масштабируется от одной до одной тысячи. Программирование пар не является обязательным.

Ответ 10

ДА.

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

• Преимущества Scrum/Agile над водопадом
• Как вы можете создавать лучшие "продукты" с помощью Scrum/Agile
• Какие типы проектов лучше подходят для Scrum
• Плюсы и минусы Scrum
• Scrum Rituals и почему они необходимы (какое преимущество они делают принести)
• Различные роли в схватках и их обязанностях (Scrum Master, Владелец продукта и команда разработчиков)

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

Пример:

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

Мастер Scrum: Продолжайте проверять, следуете ли вы всем ритуалам схватки в правильном смысле и духе, и можете ли вы извлечь из этого выгоду.

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