Наверное есть какая-то литература, рекомендации, success story и т.п. как управлять разработкой ПО в большой организации (десятки проектов, сотни разработчиков раскиданных по Глобусу).
Преимущественно java.
Вроде понятно, что можно завести какой-нибудь git, maven/artifactory, jenkins и т.п. Но общей картины как это всё интегрировать у меня нет — как вести зависимости между модулями, как организовывать взаимодействие команд, версии артефактов, интеграция, авто-тесты, деплоймент, настройка окружения, гайдлайны и обучение, делать модернизацию (например java 1.5 -> 1.7), и т.п.

Почитываю иногда Continuous delivery, посоветуйте ещё что-нибудь по этой же теме или поделитесь своим опытом.

Здравствуйте, ., Вы писали:

.>Наверное есть какая-то литература, рекомендации, success story и т.п. как управлять разработкой ПО в большой организации (десятки проектов, сотни разработчиков раскиданных по Глобусу).

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

Опиши свою ситуацию, тебе будут ответы.

P.S. У меня в блоге рассматриваются периодически большие организации с точки зрения SCM — возможно, на часть вопросов найдёшь там нужное.

Здравствуйте, Aquary, Вы писали:

A>Опиши свою ситуацию, тебе будут ответы.
Ситуацию описывать неинтересно, обычное г мамонта — ibm-чудовища, clearcase, ant, java5, eclipse.
Я пока думаю о другом подходе — вообразить себе в голове идеал и поискать пути его достижения, наиболее безболезненные.

За блог — спасибо.

Здравствуйте, ., Вы писали:

.>Я пока думаю о другом подходе — вообразить себе в голове идеал и поискать пути его достижения, наиболее безболезненные.

Совершенно бесполезная трата времени.

Здравствуйте, ., Вы писали:

.>Наверное есть какая-то литература, рекомендации, success story и т.п. как управлять разработкой ПО в большой организации (десятки проектов, сотни разработчиков раскиданных по Глобусу).


оченъ мощным инструментом в данном случае будет Team Foundation Server (TFS) в VS2012,
был ма МС-конференции, хотъ и ползала в конце докладом недоволъна была(я в том числе)
но это потому что ожидания разработчка ещё болъше были, для менеджера или началъника болъшого отдела
это выглядело совсем по другому — они остались оченъ доволъны, стоит конечно денег

Здравствуйте, pik, Вы писали:

pik>Здравствуйте, ., Вы писали:

.>>Наверное есть какая-то литература, рекомендации, success story и т.п. как управлять разработкой ПО в большой организации (десятки проектов, сотни разработчиков раскиданных по Глобусу).


pik>оченъ мощным инструментом в данном случае будет Team Foundation Server (TFS) в VS2012,
pik>был ма МС-конференции, хотъ и ползала в конце докладом недоволъна была(я в том числе)
pik>но это потому что ожидания разработчка ещё болъше были, для менеджера или началъника болъшого отдела
pik>это выглядело совсем по другому — они остались оченъ доволъны, стоит конечно денег

Типичное заблуждение, что тулы решают проблемы.
Никакой тул сам по себе, а TFS тем более, ни на каплю не приблизят успех.
С любым, даже самым крутым тулом справедлив принцип "shit in, shit out".

Здравствуйте, bkat, Вы писали:

B>Типичное заблуждение, что тулы решают проблемы.
B>Никакой тул сам по себе, а TFS тем более, ни на каплю не приблизят успех.
B>С любым, даже самым крутым тулом справедлив принцип "shit in, shit out".

типичное заблуждение с огромными задачами справится "вручную".
может вы и совсем без компъютера обойдётесъ

21.08.2012 22:51, . пишет:

> Вроде понятно, что можно завести какой-нибудь git, maven/artifactory,
> jenkins и т.п. Но общей картины как это всё интегрировать у меня нет —
> как вести зависимости между модулями, как организовывать взаимодействие
> команд, версии артефактов, интеграция, авто-тесты, деплоймент, настройка
> окружения, гайдлайны и обучение, делать модернизацию (например java 1.5
> -> 1.7), и т.п.

Вообще-то оное не раз уже обсуждалось здесь. Почитай форум.
Пока что тебе сложно что-то советовать, ибо выше какая-то каша.
Выглядит,так, что тебе на голову свалился большой проект, а что делать
ты вообще не представляешь — но в этом случае непонятно как тебе дать
какой-то совет.
Ну попробую. Разберись сначала с RUP, пойми в чем отличие от "водопада".
Затем почитай XP, Agile. После у тебя сформируется некое видение и
начнешь организовывать процесс разработки. А инструменты для этого
выбираются в последнюю очередь.

З.Ы. Возможно, имеет смысл тебе сейчас этим вообще не заниматься, а
передать проект кому другому, у кого есть соответствующий опыт, а самому
учиться у того.

Здравствуйте, pik, Вы писали:

pik>Здравствуйте, bkat, Вы писали:

B>>Типичное заблуждение, что тулы решают проблемы.
B>>Никакой тул сам по себе, а TFS тем более, ни на каплю не приблизят успех.
B>>С любым, даже самым крутым тулом справедлив принцип "shit in, shit out".

pik>типичное заблуждение с огромными задачами справится "вручную".
pik>может вы и совсем без компъютера обойдётесъ

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

Ну а конкретно к продуктам от MS для управления проектами я лично отношусь весьма скептически.
Пусть хотя бы нормальный UML тул допилят.

Здравствуйте, pik, Вы писали:

pik>оченъ мощным инструментом в данном случае будет Team Foundation Server (TFS) в VS2012,
pik>был ма МС-конференции, хотъ и ползала в конце докладом недоволъна была(я в том числе)
pik>но это потому что ожидания разработчка ещё болъше были, для менеджера или началъника болъшого отдела
pik>это выглядело совсем по другому — они остались оченъ доволъны, стоит конечно денег
TFS уж очень microsoft-only, всё гвоздями прибито к платформе, Rational Team Concert (RTS) имхо на порядок лучше, тем более для java-мира.
Хотя я сам с tfs не знаком, но пишут и такое. Может для начальника отдела оно и красивые графики рисует, но для разработчиков — ад.

Здравствуйте, Vzhyk, Вы писали:

V>Вообще-то оное не раз уже обсуждалось здесь. Почитай форум.
V>Пока что тебе сложно что-то советовать, ибо выше какая-то каша.
V>Выглядит,так, что тебе на голову свалился большой проект, а что делать
V>ты вообще не представляешь — но в этом случае непонятно как тебе дать
V>какой-то совет.
V>Ну попробую. Разберись сначала с RUP, пойми в чем отличие от "водопада".
V>Затем почитай XP, Agile. После у тебя сформируется некое видение и
V>начнешь организовывать процесс разработки. А инструменты для этого
V>выбираются в последнюю очередь.
Насчёт инструментов — не согласен. Сейчас у нас ant, вроде типа система сборки, "зачем платить больше?", нафиг всякие maven наизобретали? Но сейчас сборка осуществляется километровыми ant-скриптами, в них разбираются только вечно занятые пара человек и что-то поменять (скажем даже тривиальную вещь — добавить запуск unit-тестов) очень сложно. И в команде разработчиков билд запускается только изредка и далеко не всеми, нередко коммитят даже некомпилируемый код.
Создание view (то бишь тупо взятие кода из репозитория) процесс который может легко занимать недели, особенно для нового сотрудника. Тормознутость clearcase (типичные операции требуют нескольких минут, а то и часов) сильно влияет на это самое "некое видение".

V>З.Ы. Возможно, имеет смысл тебе сейчас этим вообще не заниматься, а
V>передать проект кому другому, у кого есть соответствующий опыт, а самому
V>учиться у того.
На самом деле это не на меня одного свалилось, а просто у меня есть возможность как-то влиять на весь этот бардак. Дух Agile и т.п. вроде уже гуляет, хочется ещё каких-то новых идей и больше уверенности, что идём в правильном направлении, а не меняем шило на мыло.

Здравствуйте, bkat, Вы писали:

B>Не обойдусь конечно.
B>Но когда для решения проблем (какой кстати?) тут же предлагают тул, то работать это гарантированно не будет.

B>Ну а конкретно к продуктам от MS для управления проектами я лично отношусь весьма скептически.
B>Пусть хотя бы нормальный UML тул допилят.

во первых я не предлагал для решения всех проблем один тул. скорее всего для сложного менеджмента надо болъше чем один тул. во вторых я совсем не фанат МС-та и долгое время работал с борландом, в третъих у нас болъшой коллектив и тоже есть части удалённые(США, япония) и мы хоть и на С++/дотнет в VS работаем но МС-ский TFS не юзаем, полъзуемся борландовким тулом и целым рядом своих. Почему вдруг TFS? потому что был на МС-ской конференции и там персоналъно
руководителъ тима разработки TFSа нам новую версию для 2012 перезентировал. Шеф был доволен , я не очень, коллега разработчик тоже доволен. НО в принципе и я скажу: хорошая и нужная штука. Не смотря на денъги мы будет всёж её юзать.

Здравствуйте, ., Вы писали:

.>Хотя я сам с tfs не знаком, но пишут и такое. Может для начальника отдела оно и красивые графики рисует, но для разработчиков — ад.

Не совсем верно, да это типичный МС-продукт со всеми его недостатками но я речъ вёл именно о TFS2012 который ещё мало кто видел а это поверъте мне не толъко картинки и не сколъко а очень мощный инструмéнт именно для координирования болъших проектов причём полезный как для разработчиков так и для координаторов/менеджеров проектов. это не реклама, я не работаю в МС-е

Здравствуйте, pik, Вы писали:

pik>Не совсем верно, да это типичный МС-продукт со всеми его недостатками но я речъ вёл именно о TFS2012 который ещё мало кто видел а это поверъте мне не толъко картинки и не сколъко а очень мощный инструмéнт именно для координирования болъших проектов причём полезный как для разработчиков так и для координаторов/менеджеров проектов. это не реклама, я не работаю в МС-е
Какая там система контроля версий? Если там всё ещё с блокировками, и другая вменяемая система не интегрируется по человечески, то сразу в топку.

Здравствуйте, pik, Вы писали:

pik>Здравствуйте, bkat, Вы писали:

B>>Не обойдусь конечно.
B>>Но когда для решения проблем (какой кстати?) тут же предлагают тул, то работать это гарантированно не будет.

B>>Ну а конкретно к продуктам от MS для управления проектами я лично отношусь весьма скептически.
B>>Пусть хотя бы нормальный UML тул допилят.

pik>во первых я не предлагал для решения всех проблем один тул. скорее всего для сложного менеджмента надо болъше чем один тул. во вторых я совсем не фанат МС-та и долгое время работал с борландом, в третъих у нас болъшой коллектив и тоже есть части удалённые(США, япония) и мы хоть и на С++/дотнет в VS работаем но МС-ский TFS не юзаем, полъзуемся борландовким тулом и целым рядом своих. Почему вдруг TFS? потому что был на МС-ской конференции и там персоналъно
pik>руководителъ тима разработки TFSа нам новую версию для 2012 перезентировал. Шеф был доволен , я не очень, коллега разработчик тоже доволен. НО в принципе и я скажу: хорошая и нужная штука. Не смотря на денъги мы будет всёж её юзать.

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

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

Короче все не просто, и роль тулов в успехе проектов очень и очень небольшая.

Здравствуйте, bkat, Вы писали:


B>Короче все не просто, и роль тулов в успехе проектов очень и очень небольшая.

не могу согласится, чем болъше "машина(любая)" даёт поддержки тем лучше резулътат.
именно робот даёт в промаышленности, когда конечно он человеком полностю и хорошо отлажен, наиболее еффективный, предсказуемый и точный резулътат. то что вы описываете можно немного и как хаос, неуправляемость
означить. Моё мнение(подтвеждённое опытом) именно хорошие тулы приводят к предсказуемым успехам и хорошей управляемости проектами. В нашем коллективе я не могу себе пердставить на сег. денъ работу без наших 3 тулов управления процессов, кроме того у нас есть целая куча документов/регламентов которыемы обязаны выполнять.
без всего этого да был бы хаос и бардак и как минимум 100% болъшая затрата времени на управление проектом.
потому что МС наконец ососзнал особенную важностъ еффективного управления проектами и сделал из игрушки наконец более-менее хороший инструмент мы после первых перезентаций TFS2012 планируем переход на этот тул.

22.08.2012 22:00, . пишет:

> Насчёт инструментов — не согласен. Сейчас у нас ant, вроде типа система
> сборки, "зачем платить больше?", нафиг всякие maven наизобретали? Но
> сейчас сборка осуществляется километровыми ant-скриптами, в них
> разбираются только вечно занятые пара человек и что-то поменять (скажем
> даже тривиальную вещь — добавить запуск unit-тестов) очень сложно. И в
> команде разработчиков билд запускается только изредка и далеко не всеми,
> нередко коммитят даже некомпилируемый код.
> Создание view (то бишь тупо взятие кода из репозитория) процесс который
> может легко занимать недели, особенно для нового сотрудника.
> Тормознутость clearcase (типичные операции требуют нескольких минут, а
> то и часов) сильно влияет на это самое "некое видение".
То что ты здесь описал, это проблемы никак не инструментов — это
проблемы организации. Все эти инструменты прекрасно работают в других
местах.
Я бы на твоем месте начал с починки багов, что ты описал. Дал одному
програмеру задачу разобраться с ant скриптами и отрефакторить их. За
коммит некомпилируемого наказывать. И т.д.
Ты не слова ни написал о тестировании, мне почему-то кажется, что у вас
там ситуация не лучше — просто пофиксте баги организации, что уже видите
сами для начала.

> На самом деле это не на меня одного свалилось, а просто у меня есть
> возможность как-то влиять на весь этот бардак. Дух Agile и т.п. вроде
> уже гуляет, хочется ещё каких-то новых идей и больше уверенности, что
> идём в правильном направлении, а не меняем шило на мыло.
При описанном бардаке Агиль его только добавит. Сначала пофиксите баги
выше, а затем можете внедрять что-то новое.

Здравствуйте, pik, Вы писали:

pik>Здравствуйте, bkat, Вы писали:


B>>Короче все не просто, и роль тулов в успехе проектов очень и очень небольшая.

pik>не могу согласится, чем болъше "машина(любая)" даёт поддержки тем лучше резулътат.
pik>именно робот даёт в промаышленности, когда конечно он человеком полностю и хорошо отлажен, наиболее еффективный, предсказуемый и точный резулътат. то что вы описываете можно немного и как хаос, неуправляемость
pik>означить. Моё мнение(подтвеждённое опытом) именно хорошие тулы приводят к предсказуемым успехам и хорошей управляемости проектами. В нашем коллективе я не могу себе пердставить на сег. денъ работу без наших 3 тулов управления процессов, кроме того у нас есть целая куча документов/регламентов которыемы обязаны выполнять.
pik>без всего этого да был бы хаос и бардак и как минимум 100% болъшая затрата времени на управление проектом.
pik>потому что МС наконец ососзнал особенную важностъ еффективного управления проектами и сделал из игрушки наконец более-менее хороший инструмент мы после первых перезентаций TFS2012 планируем переход на этот тул.

Осталось только понять, как же народ успешно делал проекты без TFS2012

23.08.2012 11:26, pik пишет:

> не могу согласится, чем болъше "машина(любая)" даёт поддержки тем лучше
> резулътат.
Нет.

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

Здравствуйте, bkat, Вы писали:


B>Осталось только понять, как же народ успешно делал проекты без TFS2012

а я что претендовал на то что это единственный или лучший тул?
мы дискутируем о том что лучше: совсем без тулов или всёж с ними