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

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

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


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

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

23.08.2012 12:01, pik пишет:

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

23.08.2012 12:24, . пишет:

> Не верю. clearcase не может нормально работать. У него архитектурные
> проблемы, скорость работы от того же git будет отличаться на порядки.
Когда-то применяли. Вполне себе хорошо работал.

> Их много, очень много. Думаю по всех исходникам порядка тысяч. Не знаю
> насколько это всё используется, может просто мёртвый код расплодился.
Я ж пишу — рефакторить.

> V>коммит некомпилируемого наказывать. И т.д.
> Организовать запуск билда на компе дева непросто.
Билда чего? Всегда можно выделить часть, которую можно скомпилить и
убедиться, что она и в системе скомпилится.
Если же у вас так называемый спагетти-код, то единственное, что вас
спамет — это рефакторинг (вплоть до переписывания с нуля различных частей)

> Тестирование в зачаточном состоянии...
По мне — это святое в разработке софта. Без тестирования получается
обычно гора мусора, которую проще выкинуть, чем использовать и
поддерживать. Организовывай тестирование.

> Главный вопрос — что конкретно внедрять-то?
Ничего. Сначала пофиксите баги организации. А затем для типичных
автоматических операций ищете инструменты (часто бывает лучше написать
свои или общеизвестные заточить под себя).

Введите документ-регламент разработки и наказывайте за его игнор.
Имейте достаточно четкий и понятный всем набор требований к продукту.
Внедрите тестирование.
Проведите рефакторинг кода и инструментов сборки.
Введите юнит-тестирование.

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

On 23.08.2012 14:58, . wrote:

> H>А вы там кто и есть ли вообще деньги/время на то, чтобы что-то внедрять?
> H>От этого зависят ответы.

> Допустим есть и время, и деньги. Я, конечно, тут далеко не хозяин, но
> думаю вполне могу высказать своё мнение и внести какие-то предложения
> чтобы кто-то что-то начал делать. Вот и хочется вначале быть хотя бы
> уверенным: куда идти, что делать и как потом проверить, что это хоть
> как-то сработало и оказалось больше полезным, чем вредным.

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

Если есть время — я бы начал с ревизии: а что собственно есть, что с чем
и как связано, зачем оно вообще нужно, когда последний раз обновлялось и
т.п. и попытки это как-то осознать/документировать. Вполне возможно, что
по итогам разбирательства окажется что из этих 1000 скриптов сборки
реально используется 50, а из 100 проектов за последний год были коммиты
в 7.

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

1. Если есть деньги — надо искать средство миграции с ClearCase хотя бы
на SVN (как наиболее распространённую VCS, с неё если что можно и дальше
на git и т.п.). Возможно есть конторы где "всё работает", но по-моему
ClearCase — одно из мощнейших средств для того, чтобы тормознуть работу
большого проекта. Боюсь что бесплатных средств тут либо нет, либо они
будут глючить.

2. Про тестирование — совершенно согласен со Vzhyk, его не может не
быть. Может не быть юнит-тестов, интеграционных тестов или ручного
тестирования — это зависит от того, что за софт вы разрабатываете.
Но когда нет ничего из вышеперечисленного — это беда, добавлять фазу
тестирования (выделяя на это ресурсы и время) всё равно придётся.

--
WBR,
Serge.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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 тул допилят.

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

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

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

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

pik>здесь я это так понял что тул вообще не важен.
pik>я не отрицаю что если самый лучший тул обезяне дать то конечно ничего не получится.
pik>разум + хорошие тулы = залог успеха

Тул не важен. Тул это производный элемент от процесса.
Если нет процесса — тулы не помогут.
Если процесс есть — либо можно найти готовый тул под него либо сделать свой (возможно на основе существующих).

А подход — поставьте TFS и будет вам счастье — это чисто маркетинговый подход.
В компании работающей на Java вполне может не быть ни одной машины под Windows и TFS можно поставить на сервер только в виде коробочки.

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

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

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

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

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

Здравствуйте, 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>Здравствуйте, bkat, Вы писали:

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

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

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

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

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

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

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


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

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

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

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


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

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

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

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

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

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

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


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

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

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

V>Нет.
в вашем стиле:
Да

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

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

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

.>Почитываю иногда Continuous delivery, посоветуйте ещё что-нибудь по этой же теме или поделитесь своим опытом.
Если коммуникация затруденан и проект слишком большой, то смотри в сторону RUP. И да, документации придётся писать много. Большой упор надо сделать на интеграцию разных компаонентов междуд собой, вплоть до выделения специального человека в качестве интегратора. Ну и за версионностью следить надо. Никаких API/ABI break без предворительного предупреждения.

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

V>То что ты здесь описал, это проблемы никак не инструментов — это
V>проблемы организации. Все эти инструменты прекрасно работают в других
V>местах.
Не верю. clearcase не может нормально работать. У него архитектурные проблемы, скорость работы от того же git будет отличаться на порядки.
Может СС и хорош для хранения больших объёмов данных, наверное идеален при разработке видеоигр с кучей cut-scenes или подобного, но для типичной разработки — совсем не катит, хранить бинарики .jar — жуткий антипаттерн.

V>Я бы на твоем месте начал с починки багов, что ты описал. Дал одному
V>програмеру задачу разобраться с ant скриптами и отрефакторить их. За
Их много, очень много. Думаю по всех исходникам порядка тысяч. Не знаю насколько это всё используется, может просто мёртвый код расплодился.

V>коммит некомпилируемого наказывать. И т.д.
Организовать запуск билда на компе дева непросто.

V>Ты не слова ни написал о тестировании, мне почему-то кажется, что у вас
V>там ситуация не лучше — просто пофиксте баги организации, что уже видите
V>сами для начала.
Тестирование в зачаточном состоянии...

V>При описанном бардаке Агиль его только добавит. Сначала пофиксите баги
V>выше, а затем можете внедрять что-то новое.
Главный вопрос — что конкретно внедрять-то?

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

pik>потому что МС наконец ососзнал особенную важностъ еффективного управления проектами и сделал из игрушки наконец более-менее хороший инструмент мы после первых перезентаций TFS2012 планируем переход на этот тул.
А с какими тулзами сравнивали-то? Делать выбор тулза просто после эффектной презентации, да ещё и за столько $€£, несколько опрометчиво.

On 23.08.2012 13:24, . wrote:

> V>То что ты здесь описал, это проблемы никак не инструментов — это
> V>проблемы организации. Все эти инструменты прекрасно работают в других
> V>местах.
> Не верю. clearcase не может нормально работать.

+1

> V>коммит некомпилируемого наказывать. И т.д.
> Организовать запуск билда на компе дева непросто.

Keywords: continuous integration, hudson/jenkins — билд по кажому
коммиту. Собирается на отдельной машине (не у разработчика). Должно
помочь, хотя с интеграцией с СС возможно придётся повозиться.

> V>При описанном бардаке Агиль его только добавит. Сначала пофиксите баги
> V>выше, а затем можете внедрять что-то новое.
> Главный вопрос — что конкретно внедрять-то?

А вы там кто и есть ли вообще деньги/время на то, чтобы что-то внедрять?
От этого зависят ответы.

--
WBR,
Serge.

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

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


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

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

С тулами или без тулов, я лично не спорю. Конечно с тулами.
Но фокус должен быть не на тулах. Проблемы не в них вообще.

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

pik>вы сами писали в другой ветке о выской производизтелъности и еффективности труда в европе, как думаете за счёт чего это происходит?

Роль тулов точно будет невелика.
Я видел отличные спеки написаные в обычном MS Word.
И я видел полнейший хаос в DOORs.

Видел понятный product backlog в екселе и полнейшую кашу в product backlog в TFS.
Правда видел и вменяемые product backlog и в TFS.
Роль TFS в получении вменяемого product backlog вообще никакая.

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

>> V>коммит некомпилируемого наказывать. И т.д.
>> Организовать запуск билда на компе дева непросто.
H>Keywords: continuous integration, hudson/jenkins — билд по кажому
H>коммиту. Собирается на отдельной машине (не у разработчика). Должно
H>помочь, хотя с интеграцией с СС возможно придётся повозиться.
Уже внедряем Jenkins, даже иногда работает: через раз какие-то глюки во время апдейта исходников из CC и билд проваливается.

>> Главный вопрос — что конкретно внедрять-то?
H>А вы там кто и есть ли вообще деньги/время на то, чтобы что-то внедрять?
H>От этого зависят ответы.
Допустим есть и время, и деньги. Я, конечно, тут далеко не хозяин, но думаю вполне могу высказать своё мнение и внести какие-то предложения чтобы кто-то что-то начал делать. Вот и хочется вначале быть хотя бы уверенным: куда идти, что делать и как потом проверить, что это хоть как-то сработало и оказалось больше полезным, чем вредным.

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

B>С тулами или без тулов, я лично не спорю. Конечно с тулами.
B>Но фокус должен быть не на тулах. Проблемы не в них вообще.

вот тут согласен, вы к сожалению так с начала не имели ввиду:

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

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

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

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

B>Роль тулов точно будет невелика.
B>Я видел отличные спеки написаные в обычном MS Word.
B>И я видел полнейший хаос в DOORs.

B>Видел понятный product backlog в екселе и полнейшую кашу в product backlog в TFS.
B>Правда видел и вменяемые product backlog и в TFS.
B>Роль TFS в получении вменяемого product backlog вообще никакая.

ну дак кто это отрицает что без разума самый лучший тул не сработает?
я с самого начал имел ввиду разум + хороший тул >>> разум + без тула,
т.е. в одинаковых условиях с тулом резулътат будет намного лучше и продуктивней.
это не оспоримо и доказано практикой

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


.>А с какими тулзами сравнивали-то? Делать выбор тулза просто после эффектной презентации, да ещё и за столько $€£, несколько опрометчиво.


дело в том что мы сидим полностю на МС-кой "игле" у нас МСДН-ий абонемент по которому у нас всё новейшее поступает сразу. TFS не полъзовались так как он действителъно плох был, посему брали годами проверенный борландовский продукт + свои причиндалы к нему. МС действиетелъно TFS очень силъно подтянул и человек который там
АЛМ занимается(Кристиан Биндер) делал нам презентацию и интенсивно отвечал на вопросы и это было всёж для нас с нашим опытом очень убедителъно:

http://en.wikipedia.org/wiki/Application_lifecycle_management

почему TFS? есть много причин, но решение ещё не окончателъно, мы будем далъше щупать

23.08.2012 15:53, hrensgory пишет:

> После получения какого-то результата надо сесть и подумать — а чего мы
> вообще хотим достичь-то? Какова цель преобразований, что не так — не
> вовремя выпускаются версии (чего именно), много багов (где именно),
> неудобно вносить изменения (куда именно)? Исходя из этого действовать
> дальше. Но несколько вещей я бы не откладывал:
>
> 1. Если есть деньги — надо искать средство миграции
Не надо. Для начала нужно ответить на вопросы выше, хотя бы. А после
этого уже смотреть тратить ли деньги или что другое делать.

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

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

B>>Роль тулов точно будет невелика.
B>>Я видел отличные спеки написаные в обычном MS Word.
B>>И я видел полнейший хаос в DOORs.

B>>Видел понятный product backlog в екселе и полнейшую кашу в product backlog в TFS.
B>>Правда видел и вменяемые product backlog и в TFS.
B>>Роль TFS в получении вменяемого product backlog вообще никакая.

pik>ну дак кто это отрицает что без разума самый лучший тул не сработает?
pik>я с самого начал имел ввиду разум + хороший тул >>> разум + без тула,
pik>т.е. в одинаковых условиях с тулом резулътат будет намного лучше и продуктивней.
pik>это не оспоримо и доказано практикой

Опять же. Сначала нужно понять что надо, а потом прикидывать как это автоматизировать.
А то давайте я вам SAP порекомендую.
Вы ведь там разумные и наверняка сможете с ним что-нибудь наавтоматизировать

On 23.08.2012 17:18, Vzhyk wrote:

>> После получения какого-то результата надо сесть и подумать — а чего мы
>> вообще хотим достичь-то? Какова цель преобразований, что не так — не
>> вовремя выпускаются версии (чего именно), много багов (где именно),
>> неудобно вносить изменения (куда именно)? Исходя из этого действовать
>> дальше. Но несколько вещей я бы не откладывал:
>>
>> 1. Если есть деньги — надо искать средство миграции
> Не надо. Для начала нужно ответить на вопросы выше, хотя бы. А после
> этого уже смотреть тратить ли деньги или что другое делать.

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

--
WBR,
Serge.

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

С помощью багзиллы, SVN, Excel, Hudson и такой-то матери.

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

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

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

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

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

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

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

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

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

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


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

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

Советую почитать басню Крылова "Квартет". Особенно последнюю фразу из нее.

pik>а я что претендовал на то что это единственный или лучший тул?

Ну, выглядит именно так. Ну и, честно говоря, по презентации (причем откровенно маркетинговой) судить о продукте — как минимум несерьезно.
Все-таки процессы в каждой организации свои, так что и инструменты нужны свои и настраивать их нужно индивидуально.

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

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

Могу порекомендовать тулзы, которые точно работают в таких ситуациях:

1. Perforce
   
2. Code Collaborator
   
3. Dev Track
   
4. Dev Test
   
5. Hansoft
   
6. Confluence
   
7. Excel
   
8. Word
   
9. Visio

Может, что-то ещё забыл.