Методология проекта для небольших групп

Ответ 1

Я не думаю, что для этого существует общий ответ, вопрос слишком широк, и вы не можете просто "принять методологию", как если бы это был продукт, который вы вынимаете из коробки, это то, что вы развиваться со временем... но в любом случае я настоятельно рекомендую вам получить копию этой книги: Head First Software Development

Затем вы адаптируете идеи, которые вам нравятся в вашем проекте. Не беспокойтесь о именах и словах, они все будут "passé" в следующем году. Сначала попробуйте, примите идеи, которые имеют больше смысла и дают наибольшую выгоду для доллара, и не пытайтесь решать проблемы, которые еще не существуют. Это будет очень хорошее начало.

Ответ 2

Для парного программирования, по крайней мере, лучше всего иметь четное число программистов...; P

Одна из хороших вещей о небольших командах заключается в том, что вам не нужно много систем поддержки, чтобы общаться внутри (багтрекер становится более или менее списком задач для себя, но это так хорошо). Если встреча со всей командой просто включает в себя поворот вокруг вашего чарира и сказать "Эй, Боб и Карл, взгляните на это!", Вам все равно не нужны все формальные правила методологии. Но гибкие методы в целом хорошо подходят для небольших и средних команд, но для них требуются самомотивированные члены команды.

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

Ответ 3

Для таких небольших команд я определенно посмотрю на подход Agile к разработке программного обеспечения. Лично я бы, наверное, использовал смесь XP, Scrum и Lean, потому что я знаю этих лучших. Особенно, если вы новичок в Agile, XP обеспечивает хорошую отправную точку, из которой вы можете найти свою адаптацию к проекту. Я настоятельно рекомендую книгу "Искусство гибкого развития".

Ответ 4

Моя группа разработчиков 3 просто использует Kanban + непрерывное развертывание, и это заставляет нас двигаться быстро. Я посмотрел на Scrum и других, и там слишком много накладных расходов для нашей небольшой команды.

Ответ 5

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

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

Ответ 6

Ответ на этот вопрос, по-видимому, зависит...

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

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

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

Естественно, я также разработал CM-процессы и методы тестирования в соответствии с требованиями проекта и команды.