[Devel] Репозитории проектов по АСУ

[Evgeny Sinelnikov]

23 июля 2009 г. 1:06 пользователь Vitaly Lipatov (lav на altlinux.ru) написал:
> On 22 июля 2009, Evgeny Sinelnikov wrote:
> ...
>> Будем считать, что работают от 3 до 5 человек.
>>
>> Любой проект делится на части... Кто-то придумывает
>> архитектуру, и ставит задачи... По мере реализации сводит всё
> У нас не так.

Это плохо. Архитектура есть у любого проекта. Если она складывается
спонтанно, ничего хорошего в этом нет.

>> воедино, у него все забирают изменения... Ему отчитываются, с
> Такого человека нет. Каждый работает над своей частью.

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

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

Это означает, что задачи разбиты неудачно.

>> Для трёх человек здесь всё вроде тривиально, для пяти...
>> Вопрос в том как их организовать... Заставить их сваливать все
>> исходники в одну кучу без проверки что же сделано и как это
>> работает - это значит закрыть глаза на эту проблему.
>> Коллективную безответственность за конечный результат стоит
>> избегать, поэтому сливать стоит всё через ответственных за
>> задачи, обычно, при таком числе людей,  пересечений уже стоит
>> избегать.
>>
>> Вообще задача управление большой командой - это вопрос
>> отдельный. Не думаю, что git здесь должен сильно помешать.
>> Скорее наоборот.
>>
>> Предполагается, что
>> а) все знают, кто принимает конечный результат и отдают свои
>> результаты ему;
> Это всё красиво звучит, но если ты должен добавить функцию в
> класс, которой я собираюсь воспользоваться через полчаса, потому
> что иначе я не смогу сегодня продемонстрировать сохранение на
> флэш?
>

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

На практике же бывает всё, и если уж так вышло... И тебе срочно что-то
нужно. Ты знаешь кто это реализует и что он уже завершил нужную тебе
часть. Делаешь git pull из его репозитория и не пытаешься на этом
этапе "распрямить" историю через централизованный репозиторий.


>> б) все роли в команде при тесной работе друг
>> другу известны и вопрос "кто главный" не возникает;
>> в) для ёмких задач появляется свой "главный", с которым
>> взаимодействует "основной главный".
> Это пример некой централизованной разработки, с "выделенным
> сервером". Представь, что главных нет, все равнозначны.

Представил. У кого узнать что мы пишем? Кто определяет техническую
часть: как пишем, с помощью каких средств, в каком порядке? Порядок
определяется из видения архитектуры. Чем более ясно представлено
разделение на компоненты и заданы интерфейсы, тем проще их разделить
работу на задачи.

Когда же "главных нет, все равнозначны", но поставленные вопросы
кто-то всё-таки решает, получаем "главных нет, но есть те, кто
главнее". Не стоит путать взаимопонимание в команде с равенством. Если
кто-то задаёт сроки, указывает на ограничения и прослеживает
соответствие результата плану, равенства добиться сложно...

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

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

> Вспомним Раймонда: Собор или Базар? :)

Я взглянул... Ну, это не совсем то... Базар, в полной мере,
предполагает несколько условных допущений:
0) Тестирование проводится бесплатно силами сообщества
1) Сроки реализации не фиксированы
2) Число разработчиков потенциально безгранично, а стоимость их работы
стремится к нулю
3) Результат заранее не определён
4) Ответственность за то, что же получилось, ни на ком не лежит

Это всё, конечно, утрированно... Но на практике так и получается...
Этот механизм не подходит для маленьких закрытых задач под заказ.

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

Здесь есть более проработанные схемы, чем я способен описать в паре
предложений. Как минимум, стоит обратить внимание на модель зрелости
процесса разработки ПО (CMM - Capability Maturity Model):
http://ru.wikipedia.org/wiki/CMMI
http://www.microsoft.com/rus/business/Vision/Strategy/Levels.mspx
http://www.microsoft.com/rus/midsizebusiness/solutions/itinfrastructure/stages/default.mspx

-- 
Sin (Sinelnikov Evgeny)