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

[gaperton]

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

Comments

Небольшое уточнение

[nuald]

Раз уж вы приводите в пример нашу компанию, то внесу пару уточнений:
- Chief Programmer - это обычно наш Project Manager (только он не всегда пишет код). Да, это не особо удачно и не особо эффективно, поэтому мы активно работаем над оптимизацией внутренней логистики, чтобы снизить на PM-а нагрузку. И из этого следствие - PM-ами у нас становятся только бывшие разработчики, которые хорошо разбираются в теме.
- Вместо доски с маркерами мы активно используем вики. Стараемся все по максимуму документировать, чтобы инфа была не в головах, а была известна всем заинтересованным сторонам.

Re: Небольшое уточнение

[kpy3]

Доска + мыльница-из-телефона + wiki тоже хороший вариант. Дружно нарисовали, обсудили, сфоткали, картинку вставили в wiki, добавили комментариев.

Re: Небольшое уточнение

[shalayev]

Доска и мыльница легко заменяются whiteboardmeeting (приблуда такая к скайпу)

Re: Небольшое уточнение

[kpy3]

О! Спасибо за наводку. =)

[guamoka]

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

[nuald]

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

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

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

[gaperton]

+1 везде.

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

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

Гораздо лучше "функциональная" специализация - по предметной области. Она рулит.

[guamoka]

В общем-то, я имел в виду не совсем то.

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

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

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

[i_love_python]

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

[gaperton]

Это радует. Это подтверждает, что истина где-то рядом.