alex_mq0 ([info]alex_mq0) wrote in [info]ru_pm,
@ 2007-02-03 13:57:00
Previous Entry  Add to memories!  Tell a Friend!  Next Entry
Как делить проект
Недавно обсуждал со своем начальником следующий вопрос: Как лучше разделять задания для выполнения по проекту. Есть два мнения: необходимо делить проект на мелкие части и выдавать части любому свободному программисту, размер части не более 8 часов - одного рабочего дня - так думаю я и программисты в моей команде. Мнение начальника - выделять в проекте большие блоки и назначать ответственных за каждый блок, что бы он постоянно отвечал за него и в случае наличия проблемы решал ее. Хотелось бы услышать ваше мнение по этому вопросу.
crosspost ru_managemet,ru_java.

(Post a new comment)


[info]t_gra
2007-02-07 10:15 pm UTC (link)
С одной стороны, мелкие части - хорошо, т.к. это не создаёт больших изолированных кусков, в которых разбирается один человек и которые будут тяжёлым наследием для кого-то, если человек заболеет или уволится. Кроме того, каждый человек в случае "больших кусков" меньше имеет разнообразия и в результате меньше развивается.

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

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

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

Так что общий ответ - выбор этого аспекта методологии зависит от конкретного проекта/проектов, конкретной команды с её людьми, и конкретной организации с её культурой. Интересно услышать подробности :)

Хорошая, на мой взгляд, реализация (и безусловно не "единственно правильная") - в eXtreme Programming - работа над заданиями осуществляется парами программистов в различных сочетаниях. В результате между людьми перетекают как явные и неявные знания технологий, так и явные и неявные знания о проекте. Одно плохо - супер-мега-архитектору, который хочет спроектировать "общую модель всего и навсегда", при этом трудно развернуться :)

(Reply to this) (Thread)

[info]lazy_frog
2007-02-07 10:41 pm UTC (link)
Лично мне было бы тяжело делить проект на кусочки по 8 часов, т.к. при кол-ве участников более 3х я бы занимался только делением.

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

Критическими факторами при выборе размера (и тяжести) куска были: расстояние до программиста (мог быть рядом, а мог быть в другом городе) и уровень доверия (опыт общения, квалификация и т.д.). Был человек, которому можно было отдать требования заказчика и раз в пару недель корректировать приоритеты.

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

(Reply to this) (Parent)(Thread)

[info]t_gra
2007-02-08 09:15 pm UTC (link)
Да, гибкость в размере разбиения полезна.

(Reply to this) (Parent)

[info]alf_kadett
2007-02-07 11:08 pm UTC (link)
Что-то мне подсказывает, что такой вопрос тут уже был, буквально пару дней назад.

(Reply to this) (Thread)

[info]alex_mq0
2007-02-08 10:05 am UTC (link)
Не здесь, а в других сообществах ;) здесь кроспост

(Reply to this) (Parent)

[info]ad_null
2007-02-08 08:16 am UTC (link)
1) У вас должен быть человек, который даже при делении на мелкие куски будет знать целостную картину.
2) Деление на мелкие куски все равно произойдет, иначе как вы узнаете, сколько времени займет исполнение большого блока? Угадаете? Тем более, что если не формализовать кусочки, то делить на куски придется программеру/ответственному лицу и не факт, что он качественно подойдет к управлению своим временем и не станет хвататься то за одно, то за другое.
3) Задачи должны распределяться не кому попало, а учитывая уровень задачи и степень доверия к разработчику (относительно данной задачи).
4) короткие задачи удобны, если есть человек, который отслеживает их выполнение и осуществляет планирование. По опыту могу сказать - как только управленец начинает заниматься исполнительской деятельностью - проект уходит у него из под контроля.
5) Методики планирования позволяют избежать простоя разработчиков и организовать эффективность их работы даже при делении и на меньшие кусочки.

(Reply to this) (Thread)

[info]t_gra
2007-02-08 08:04 pm UTC (link)
    4) короткие задачи удобны, если есть человек, который отслеживает их выполнение и осуществляет планирование. По опыту могу сказать - как только управленец начинает заниматься исполнительской деятельностью - проект уходит у него из под контроля.

100%, программистское состояние ума - довольно безответственное. Нужно или воздерживаться от этого или уметь быстро переключаться.

(Reply to this) (Parent)

[info]zibsun
2007-02-08 08:30 am UTC (link)
1) Можно выдавать большие задания (ну порядка недели-двух) и время от времени ротировать людей между кусками функциональности. Это позволит получить взгляд со тороны на код и заменит обязательные (вообще то) code reviews.

То есть замедлит разработку в краткосроной перспективе и ускорит в долгосрочной. Ротации хороши, если у менеджмента аллергия на парное программирование :-)

2) Можно содавать feature teams как в Feature Driven Development. Берешь адекватного разработчика и даешь ему большой кусок. У него 1-2 помощника. Они его дробят кусок на части (до 16 часов на человека) и делают совместно. И так все крупные куски распределяешь на несольких лидеров. Задача менеджера - помогать всем координироваться.

(Reply to this)


[info]johndegree
2007-02-08 10:03 am UTC (link)
поздравляю со вступлением в ряды игроков в корпоративный волейбол. Вы описывете типичнейшую ситуацию когда ни исполнитель ни менеджер не хочет принять на себя полную ответственность за продукт. На самом деле, не иможет быть "или так или так", всегда есть "и так и так и еще по другому". Не занимайтесь глупостями - идите от задачи.

(Reply to this) (Thread)

[info]alex_mq0
2007-02-08 10:04 am UTC (link)
Супер, определение мне нравится )

(Reply to this) (Parent)
Мои 5 копеек...
(Anonymous)
2007-02-09 09:14 pm UTC (link)
Первый вариант абсолютно нежизнеспособен. Представьте себя на месте программиста, который узнает свою следующую задачу только когда закончит предыдущую...

Подробнее здесь: http://alexlebedev.com/blog/walking-on-the-rake-1/

(Reply to this) (Thread)
Re: Мои 5 копеек...
[info]alex_mq0
2007-02-10 09:13 am UTC (link)
Ну не все так грустно, я вас уверяю ) Предложене раздавать задачи по мере освобождения программистов просто абсурдно . Речь идет именно о детализации задач, следить за статусом выполнения большой задачи без реперных точек практически не возможно, мое мнение и опыт заключается в следующем: если задача выполняется больше 4 дней - то отследить реально, насколько продвинулось решение проблемы не возможно... можно только ждать у моря погоды - когда там будет все сделано... х3, как говорится...
Именно из-за этого задачу нужно делать на маленькие участки и выдавая блоки участков на разработку одному человеку контролировать, как он делает работу именно по прохождению реперных точек. Участком может быть какая то фича в ПО, как пример ;)

(Reply to this) (Parent)

Create an Account
Forgot your login?
Login w/ OpenID
English • Español • Deutsch • Русский…