Как организовать работу группы программистов

Короче у нас тут такая ситуация... Есть 3 человека. Нам надо втроем работать над одним проектом...

Так вот у кого есть опыт работы в команде над крупным проектом?

В каком виде друг другу передавать куски кода, как организовать взаимодействие между классами....

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

Поделитесь опытом командной работы, короче...

0

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

1

Хм, проект на 3 человека я бы не назвал крупным....

Тебе приходилось раньше заниматься управлением проектами? Как организована разработка сейчас? Чего ты хочешь добиться, организовав "работу команды"?

Добавлено через 1 час 33 минуты
PS: совсем забыл самое главное уточнить - а какова твоя-то роль (должность, положение...) во всей этой петрушке?

0

система контроля версий нужна, система контроля багов, хотя проект видимо невелик
а так наверняка нужно составить функциональную спецификацию, тз

0

система контроля багов

Имеется ввиду баг-трекер?

0

insideone, ага, ну для трех человек это слишком продвинуто =)

0

Сообщение от CheshireCat Хм, проект на 3 человека я бы не назвал крупным.... Тебе приходилось раньше заниматься управлением проектами? Как организована разработка сейчас? Чего ты хочешь добиться, организовав "работу команды"? Добавлено через 1 час 33 минуты PS: совсем забыл самое главное уточнить - а какова твоя-то роль (должность, положение...) во всей этой петрушке?

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

Моя роль - инженер-программист. Занимаюсь БД, получением снимка, логированием, обработкой изображения фильтрами + надо реализовать поддержку DICOM принтера и сервера. У нас часто функции пересекаются...

Проблема в том, что сложно сводить всё в кучу. Я предполагаю, и предлагаю вариант черного ящика: Т.е. мы разделили функции, которые будем реализовывать, и друг другу сказали: "Мне нужно от тебя получить то-то в таком-то виде... тебе даю такие-то входные данные"... Т.е. я не обязан в его код вдаваться, чтобы написать свой кусок... Я правильно понимаю?.. Мне бы хотелось послушать организацию такой работы на конкретном небольшом примере.

Добавлено через 1 минуту

Сообщение от alex_x_x а так наверняка нужно составить функциональную спецификацию, тз

Можно взглянуть на пример, как должны выглядеть эти документы? Если есть такой, конечно...

0

Сообщение от davian Моя роль - инженер-программист. Занимаюсь БД, получением снимка, логированием, обработкой изображения фильтрами + надо реализовать поддержку DICOM принтера и сервера.

Ага. Понятно. Тебе уже дали тут несколько полезных советов, и наверняка дадут еще не один.

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

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

0

CheshireCat, истину глаголишь, я всякие SVN так вообще сисадмин должен ставить и настраивать )

Кстати а кто пишет ТЗ? Программист?

0

ТЗ ? Программист? Да ни в коем случае! (при этом мы сразу исключаем из рассмотрения фирмы, где единственный "программист"-универсал - он и швец, и жнец, и на дуде игрец, и сеть протягивает, и бумагу в принтер секретарше заправляет....)

ТЗ обычно пишется Аналитиком (причем, часто есть разделение: Бизнес-аналитик занимается анализом бизнес-области и формализует бизнес-процессы в этой области (в данном случае это работа врача-рентгенолога), Системный же аналитик отвечает за перевод бизнес-требований, вытекающих из бизнес-процесса, в конкретные функциональные требования к разрабатываемому ПО), но также в этом процессе активное участие принимают Руководитель проекта, ответственное лицо от Заказчика продукта (вот здесь очень важно, чтобы это лицо было заинтересовано в успехе проекта) и Технический писатель (он главным образом оформляет ТЗ согласно требованиям ГОСТа). Но уж никак не Программист - не его это сфера ответственности.

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

1

Сообщение от CheshireCat Но, например, совмещение ролей Руководителя проекта, Программиста (Разработчика) и Тестировщика - крайне не рекомендуется, хотя оно сплошь и рядом встречается в сверхмаленьких командах.)

Встречается, встречается... А сверхмаленькая команда это сколько? Вот допустим штат в 17 человек на какой уровень тянет?

Тогда уж ещё вопрос встает - это все на опыте как-нибудь приходит иль специализрованная литература какая существует? Не в общем плане, а именно в сфере создания ПО...

0

Сверхмаленькая команда - это 1-2-3 человека. Тут, как правило, совмещение ролей просто неизбежно. Хорошо, когда хотя бы один из участников понимает, какие вообще роли существуют в разработке, каковы сферы ответственности, как их разделить и т.п. Плохо, когда разработка ведется хаотично; ну или по принципу "лебедь, рак да щука", что и понятно.....
17 человек, если все они работают над одним проектом - это, пожалуй, средний уровень..... тут структурирование их работы просто неизбежно.

Что же касается второй части вопроса, то существует аж целая дисциплина - Управление проектами. И литература на эту тему существует, и учебные центры (ажник выдающие соответствующие сертификаты) и т.п. Но, конечно, опыт - вещь нисколько не менее важная, а порой незаменимая.
Вот некоторый список литературы по управлению проектами (все существует в электронном виде, гугл в помощь) - не исчерпывающий, конечно... :
PMBoK 2004 rus.pdf
Анализ требований и создание архитектуры решений на основе Microsoft .NET..pdf
Архипенков Руководство командой разработчиков ПО.pdf
Архипенков Управление проектами.pdf
Берлинский Константин Набор серебряных пуль.pdf
Брукс Фредерик Мифический человеко-месяц.pdf
Вигерс Карл Разработка требований к программному обеспечению.pdf
ДеМарко Том Deadline.pdf
ДеМарко Том Вальсируя с медведями.pdf
ДеМарко Том Человеческий фактор.pdf
Йордон Эдвард Смертельный марш.pdf
Орлов Технологии разработки ПО.pdf
Панкаж Джалота - Управление программным проектом на практике.djvu
Рейнвотер Как пасти котов.djvu
Ройс Уолтер Управление проектами по созданию ПО.pdf
Салливэн Эд Время - деньги.pdf
Фатрелл Управление программными проектами.djvu

Наиболее важные (удачные?) с моей точки зрения книги выделены.

2

0

Сообщение от CheshireCat Плохо, когда разработка ведется хаотично; ну или по принципу "лебедь, рак да щука"

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

Описанные тобою функции - это прерогатива руководителя проекта (Менеджера проекта), но никак не инженера-программиста.

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

0

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

Рядовой программист не несет ответственности за "у нас тендер на конец декабря, к этому сроку надо сдать софт". Будет ли сдан софт, не будет ли, да и будет ли вообще написан какой-либо софт - вообще не его головная боль. Равно как рядовой программист не занимается ни проектированием количества и взаимодействия этих модулей, согласованностью их интерфейсов, и прочими подробностями (а занимается этим - Архитектор или Тим-лидер).

Как в армии - рядовой получил четкий приказ и должен его выполнить. Все. Успех фронтовой операции в целом - вне его ответственности.

1

Сообщение от davian Короче у нас тут такая ситуация... Есть 3 человека. Нам надо втроем работать над одним проектом... Так вот у кого есть опыт работы в команде над крупным проектом? В каком виде друг другу передавать куски кода, как организовать взаимодействие между классами.... Скажем, можно так: сделать некое ядро, отладить его, и потом передавать во все классы через конструктор указатель на этот некий ядровый класс... Поделитесь опытом командной работы, короче...

на сервер установить redmine, программисты подключаются к redmine (это как сайт, на php написан), смотрят задания и делают.

0