Предложения по стилю работы - PullRequest
3 голосов
/ 21 января 2010

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

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

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

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

Извините, это было более длинное сообщение, чем я планировал.

Заранее спасибо.

Ответы [ 6 ]

2 голосов
/ 28 января 2010

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

  • Сделайте раннее вставание, чтобы все знали, что люди будут делать в этот день и что было сделано накануне
  • Иметь короткие циклы (например, 2 недели) с четкими и ощутимыми целями
  • Цель "поэтапной доставки"
  • Включите обратную связь с клиентом на ранней стадии процесса
  • Цель разработки, управляемой тестами, не писать без написания тестов

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

Когда вы будете расти органично, вы найдете некоторые вещи, которые работают, некоторые - нет, и т.д.

2 голосов
/ 28 января 2010

Чтение Оценка программного обеспечения Стивом Макконнеллом . Он многое расскажет о разнице между оценкой, целью и желанием. : Р

Серьезно.

2 голосов
/ 28 января 2010

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

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

Таким образом, FogBugz великолепен, я рекомендую хотя бы попробовать, так как он позволяет отслеживать как оценки, так и фактическое затраченное время. И я никак не связан с Джоэлом.

1 голос
/ 23 января 2010

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

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

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

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

Не волнуйтесь, усердная работа - верное решение стать лучше, терпение - ключ!

1 голос
/ 22 января 2010

Я думаю, вам следует изучить гибкую методологию (http://en.wikipedia.org/wiki/Agile_software_development), например, схватку. Ваше преимущество в том, что вы небольшая команда, в которой всего 4 человека, и поэтому вы знаете силу и способности друг друга, что также может быть очень полезным в полной мере. для любого типа управления проектами.
Исходя из личного опыта работы в небольшой команде, где большинство людей были новичками в разработке (опыт менее 1 года), у agile была очень малая кривая обучения, и мы использовали несколько различных гибких методологий, таких как scrum и xp, чтобы иметь способ работы Это значительно повышает эффективность нашей работы и помогает нам соблюдать сроки.
Отношения
Шивам

1 голос
/ 22 января 2010

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

http://en.wikipedia.org/wiki/Software_development_methodology

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

...