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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Здравствуйте, 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? есть много причин, но решение ещё не окончателъно, мы будем далъше щупать

On 23.08.2012 14:58, . wrote:

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

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

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

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

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

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

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

--
WBR,
Serge.

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, т.к. там будут описаны грабли которые расколотили менеджменту лоб.
Не знаю, по-моему всё-таки есть плохие тулзы, а есть хорошие. С плохими тулзами хороший процесс делать гораздо сложнее.

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