?

Log in

No account? Create an account
November 2016   01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
cartoon

Полностью распределенная разработка - что в основе

Posted on 2010.02.12 at 02:05

Comments:


NaN
guamoka at 2010-02-12 09:41 (UTC) (Link)
Вообще удивительно, до чего много таких разработчиков, стоящих на ключевых позициях в проекте, у которых напрочь осутствует чутье на "узловые точки", иерархию и координацию. В результате на каждого члена команды сваливается задача с кучей открытых горизонтальных и- того хуже- вертикальных связей. На одной из работ все же довелось наблюдать разработку по принципу "команда главного хирурга", правда всего лишь в масштабе подсистемы. Но разницу можно было почувствовать сразу, когда один ключевой разработчик занимался формулированием требований, делегированием обязанностей и интеграцией полученных компонент. Чаще же работа вырождается в то, что для разработки прикуривателя или, там, бардочка, каждый разработчик должен иметь и поддерживать целый автомобиль. Уныло.
nuald at 2010-02-12 14:35 (UTC) (Link)
Когда ключевой разработчик занимается всем сразу, это, конечно, плохо, и вообще это нонсенс - при любом косяке (например, этот разработчик заболевает) проект скатывается в бездну. Ну может кто-то так и делает, могу только посочувствовать.

А вот насчет того, что каждый разработчик не "должен иметь и поддерживать целый автомобиль" я все-таки буду немного несогласен. Я не особо люблю очень узкопрофильных специалистов, т.к. они:
- бесполезны вне своего профиля (как дотнетчики, которые теряются когда им нужно через interop прикрутить какую-нить dll-ку, хотя по идее это их обязанность);
- при каких-то форсмажорных обстоятельствах (опять-таки кто-то заболел) не смогут никого заменить.

Специализацию конечно, хорошо иметь, и развиваться в данном направлении, но не стоит забывать и про другие векторы развития - жизнь не стоит на месте, и надо постоянно учиться, особенно в нашей динамично изменяющейся отрасли.
Gaperton
gaperton at 2010-02-12 14:48 (UTC) (Link)
+1 везде.

ИМХО, самый сильный минус "технологической" специализации - крайняя ограниченность возможностей по перебалансировке нагрузки по ходу проекта, в случае, когда вскрываются неожиданные обстоятельства.

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

Гораздо лучше "функциональная" специализация - по предметной области. Она рулит.
NaN
guamoka at 2010-02-13 18:16 (UTC) (Link)
В общем-то, я имел в виду не совсем то.


Когда ключевой разработчик занимается всем сразу, это, конечно, плохо


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


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


Во-вторых, речь не идет об узкой специализации. Существует определенный стек знаний, которым должен обладать разработчик, скажем, разработчик JEE приложенией, и этот набор знаний не ограничевается Java, либо какой-то частью JEE спецификации, а влючает в себя и базы данных, и интернет технологий, и администрирования App серверов, причем от различных вендоров, и проч. Речь шла о грамотном распределении обязанностей в команде на проекте и зон отвественности. На практике же, очень часто встреченной мной, получается так, что отсутствие менеджмента на этом уровне выливается в разработку "Фигаро здесь, Фигаро там, Фигаро опять здесь, Фигаро и здесь и там, пока другой Фигаро занят еще более срочным делом". И все это- отсутствие грамотного управления разработкой- оправдывается тем, что якобы разработчи а) не желают учиться б) не хотят работать.
Previous Entry  Next Entry