Методология проекта для небольших команд [закрыто]

Question

Обычно в каждом проекте в моей фирме работают от 1 до 4 разработчиков/арт-директоров/копирайтеров. Какую методологию вы бы порекомендовали использовать?Гибкий?ХР?Скрам?Что-то другое?(Я знаю, что это все вариации одной и той же концепции, да)

Answer 1

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

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

Answer 2

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

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

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

Answer 3

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

Answer 4

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

Answer 5

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

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

Answer 6

Ответ, как известно, зависит от...

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

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

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

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