ZoRROmbiнужно написать три приложения по одной теме, есть три программиста.Возник такой вопрос: разделить приложения каждому по одной штуке и писать их от начала и до конца или разрабатывать поочередно вместе (втроем) каждое приложение?Хотелось бы конечно вместе, т.к. легче выявлять ошибки. Можно советоваться, можно использовать единый стиль проектирования, использовать наработки, родившиеся в одном приложении, в других приложениях, но тут проблема как осуществить эту одновременную разработку? Но мы никогда не занимались коллективной разработкой.
Какие у кого мысли по этому поводу?

1) Если нет опыта в руководстве коллективной разработкой - то моё имхо, это будет всё в корзину...
2) С другой стороны - коллективный разум это ВСЕГДА больше и полезней чем одиночки. Или по другому - если коллектив как единый разум - это оптимум...


Как - да хрен его знает. Есть различные подходы. Мне кажеться дело больше привычки чем чего то другого. Могу предложить общие мысли - как ориентиры. Это следующие весчи...
а) Если Вы взяли на себя роль рукамиводителя(организатора) - старайтесь ОРГАНИЗОВЫВАТЬ а не решать, что лучше а что хуже опираясь на свой опыт. Или по другому - старайтесь почаще задавать себе вопрос - а почему именно Ваше предложение должно быть взято как решение ?
б) Задавайте постоянно себе и другим вопрос - ЭТО относиться к теме обсуждения либо спам ?
в) Постоянно контролируйте границу обсуждения. Обязательно подводите черту и резюме. Помните - до этого было ОБСУЖДЕНИЕ. После этого - это уже РЕШЕНИЕ. И последнее нужно ОБЯЗАТЕЛЬНО ВЫПОЛНЯТЬ !
г) Старайтесь принимать решение - когда ситуация спорная (тут кто то должен отвечать за принятие решения, ставить точку если хотите - обязательно). Во всех остальных случаях - либо умейте изложить свои мысли и доказать право на жизнь кочки зрения либо подчиняйтесь (именно подчиняться как СПЕЦИАЛИСТ, как организатор - организовывайте..).
д) Постарайтесь сделать обсуждения ОБЩИМИ и ИНТЕНСИВНЫМИ (сорьки, тут уже у каждого свои методы). Больше 1-2 часа в день - моё имхо, не стоит...
е) Исходите по времени из следующих прикидок... первые 1-2 месяца - учение СЛЫШАТЬ опонента. Результат в ввиде кода будет НЕ РАНЬШЕ. У заказчика результат даст НЕ РАНЬШЕ 4-6 месяцев... но это того будет стоить - поверьте уж дураку...
ж) старайтесь ориентировать людей на ИНТЕРЕС познания нового (покатят бизнес игры - так же сорьки, дальше не могу конкретизировать). Не стоит фиксировать код-человек (в тихом омуте черти топяться(С)). Но и сумбурности не стоить вносить. Помните - программист должен программировать (С) ! А не писать отчёты, либо гадать о будущих затратах (это всё уже устарело. есть методы более эффективные - сорьки, это уже свои наработки). Если надо писать отчёты - моё имхо, это удел рукамиводителя....



на самом деле тема интересная и достаточно обширная...
на мой взгляд, очень мало толковых менагеров ХОТЯЩИХ и ИМЕЮЩИХ ВОЗМОЖНОСТИ, что то делать реально для организации ПРОИЗВОДСТВА СОФТА и повышения КПД программеров... Просче бабло получать и отчёты собирать - такова жизнь...

удачи Вам
(круглый)

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

для начала нуна определиться, что имеем под понятием "коллективной разработки".

с уважением
(круглый)
ЗЫ
Всегда встаёт проблема в подобных случаях. Как слепому рассказать, что такое солнце ? всё равно получиться светлый жёлто-белый кружочек на голубом фоне...