Вкратце история возникновения этого самого вопроса. Работаю не в софтверной компании, а скажем так, в IT отделе большой компании занимающейся продажами. Как это и положено начинали с малого до развивались до того, что отделе сейчас порядка 15 человек, которые в среднем группами по 3-5 чел разбросаны по уголкам России. Основная наша задача автоматизация производства и продаж, с нею мы с горем пополам справляемся, но вот свою деятельность автоматизировать пока не можем. Сейчас перехожу к самому вопросу. Что я хочу видеть. Это некоторую централизацию управления нашей работы. Т.е. должно быть общее хранилище исподников кода, этот код должен быть хоть как-то спроектирован, а не написан сразу после требования Марьи Ивановны о получении не существующего пока квартального отчета. Должен быть центральный репозиторий требований к проектам, что мы ведем. Хотелось бы проекты оформить в какие-то итеративно подобные жизненные циклы, а не в стихийные штурмы по требованию начальства. Вообщем приблизиться хотя бы ко второму уровню СММ. Кроме этого, работа наша во многом стала дублироваться, т.е. один нарисовал библиотеку для одного отчета, другой, не зная о том что все это уже создано, благополучно рисует такую же, за что оба получают не плохие деньги от руководства, и благодарности пользователей.
И все бы можно было сделать, если бы не два но, первое это катострафически быстрое изменение требований. Мысли руководства примерно такие: программеры мол свои, они за работу деньги получают, сегодня решили одно, пусть автоматизируют, завтра совершенно противоположное, пусть опять автоматизируют. Понятно, что ни о каком документировании кода, его проектировании, описании серьезном тестировании здесь речь не ведется. И второе, “но” вытекает из первого, ребята и сами не прочь разложить то, что они делают по полкам, но если требования меняются так быстро, что задачу то понять не всегда успеваешь, а не то что ее задокументировать и закодировать. Если их заставить, перед тем как взяться за кодирование, 50% времени посетить проектированию и всяческим там вещам по составлению артефактов, то я думаю, что все это увязнет в болоте. Здесь можно принять волевое решение, типа того, что делаем так и ни как по-другому, если бы была уверенность в том, что это пойдет на пользу, а не затормозит процесс и вызовет недовольство в команде.
Если у кого есть соображения и опыт по управлению ситуациями схожими с моей, то пожалуйста поделитесь, буду весьма благодарен.
Здравствуйте Forrest, Вы писали:
F>Коллеги, прошу у вас совета по одному вопросу.
F>Вкратце история возникновения этого самого вопроса. Работаю не в софтверной компании, а скажем так, в IT отделе большой компании F>занимающейся продажами. Как это и положено начинали с малого до развивались до того, что отделе сейчас порядка 15 человек, которые F>в среднем группами по 3-5 чел разбросаны по уголкам России. Основная наша задача автоматизация производства и продаж, с нею мы с F>горем пополам справляемся, но вот свою деятельность автоматизировать пока не можем. Сейчас перехожу к самому вопросу. Что я хочу F>видеть. Это некоторую централизацию управления нашей работы. Т.е. должно быть общее хранилище исподников кода,
Т.е. вы не используете контроллеры версий?
Почему?
Гляньте в сторону CVS-сервер + WinCVS + AraxisMerge
платное только последнее, но без него можно обойтись или найти фришны-диф.
F>этот код должен быть хоть как-то спроектирован, а не написан сразу после требования Марьи Ивановны о получении не существующего F> пока квартального отчета. F>Должен быть центральный репозиторий требований к проектам, что мы ведем. Хотелось бы проекты оформить в какие-то итеративно F>подобные жизненные циклы, а не в стихийные штурмы по требованию начальства. Вообщем приблизиться хотя бы ко второму уровню СММ. F>Кроме этого, работа наша во многом стала дублироваться, т.е. один нарисовал библиотеку для одного отчета, другой, не зная о том что F>все это уже создано, благополучно рисует такую же, за что оба получают не плохие деньги от руководства, и благодарности F>пользователей.
Нужен человек, который следт за коммитами в общий репозиторий, и координировал действия программистов.
И вовремя стучит им по голове )
Да и программистам нужно следить за внешними изменениями общего кода.
(как правило они этого не хотят делать.)
Работает правило: легче самому написать, чем разбираться во внешнем коде.
на выходе: каждый клепает свое(и как правило кривое.)
F> И все бы можно было сделать, если бы не два но, первое это катострафически быстрое изменение требований.
Побольше обобщайте. все что встретилось более ожного раза — суйте в либу.
Последующие задачи будут решаться быстрее...
F>Мысли руководства примерно такие: программеры мол свои, они за работу деньги получают, сегодня решили одно, пусть автоматизируют, F>завтра совершенно противоположное, пусть опять автоматизируют. Понятно, что ни о каком документировании кода, его проектировании, F>описании серьезном тестировании здесь речь не ведется.
А на чем ведется разработка?
Если С++, то поставьте DoxyGen — она генерит *.chm файлик, с индексом по исходному коду.
Это и есть дока для разработчика.
Ничего и писать не нужно...
F>И второе, “но” вытекает из первого, ребята и сами не прочь разложить то, что они делают по полкам,
Еслиб хотели, давно разложили. )
F>но если требования меняются так быстро, что задачу то понять не всегда успеваешь,
Конкретный пример можешь привести.
Чтот не верится что начальство так скачет, или Вы сегодня автоматизируете продажу конфеток,
а через недельку разрабатываете CAD?
F>а не то что ее задокументировать и закодировать. F>Если их заставить, перед тем как взяться за кодирование, 50% времени посетить проектированию и всяческим там вещам по составлению F>артефактов, то я думаю, что все это увязнет в болоте. Здесь можно принять волевое решение, типа того, что делаем так и ни как по- F>другому, если бы была уверенность в том, что это пойдет на пользу,
Это имхо необходимо...,но сложно.
Ты командуешь всем этим?
F>а не затормозит процесс и вызовет недовольство в команде.
Если платят хорошо... то никуда они не денутся )
F>Если у кого есть соображения и опыт по управлению ситуациями схожими с моей, то пожалуйста поделитесь, буду весьма благодарен.
Здравствуйте Forrest, Вы писали:
F>Коллеги, прошу у вас совета по одному вопросу.
F>Вкратце история возникновения этого самого вопроса. Работаю не в софтверной компании, а скажем так, в IT отделе большой компании занимающейся продажами. Как это и положено начинали с малого до развивались до того, что отделе сейчас порядка 15 человек, которые в среднем группами по 3-5 чел разбросаны по уголкам России. Основная наша задача автоматизация производства и продаж, с нею мы с горем пополам справляемся, но вот свою деятельность автоматизировать пока не можем. Сейчас перехожу к самому вопросу. Что я хочу видеть. Это некоторую централизацию управления нашей работы. Т.е. должно быть общее хранилище исподников кода, этот код должен быть хоть как-то спроектирован, а не написан сразу после требования Марьи Ивановны о получении не существующего пока квартального отчета. Должен быть центральный репозиторий требований к проектам, что мы ведем. Хотелось бы проекты оформить в какие-то итеративно подобные жизненные циклы, а не в стихийные штурмы по требованию начальства. Вообщем приблизиться хотя бы ко второму уровню СММ. Кроме этого, работа наша во многом стала дублироваться, т.е. один нарисовал библиотеку для одного отчета, другой, не зная о том что все это уже создано, благополучно рисует такую же, за что оба получают не плохие деньги от руководства, и благодарности пользователей. F> И все бы можно было сделать, если бы не два но, первое это катострафически быстрое изменение требований. Мысли руководства примерно такие: программеры мол свои, они за работу деньги получают, сегодня решили одно, пусть автоматизируют, завтра совершенно противоположное, пусть опять автоматизируют. Понятно, что ни о каком документировании кода, его проектировании, описании серьезном тестировании здесь речь не ведется. И второе, “но” вытекает из первого, ребята и сами не прочь разложить то, что они делают по полкам, но если требования меняются так быстро, что задачу то понять не всегда успеваешь, а не то что ее задокументировать и закодировать. Если их заставить, перед тем как взяться за кодирование, 50% времени посетить проектированию и всяческим там вещам по составлению артефактов, то я думаю, что все это увязнет в болоте. Здесь можно принять волевое решение, типа того, что делаем так и ни как по-другому, если бы была уверенность в том, что это пойдет на пользу, а не затормозит процесс и вызовет недовольство в команде. F> Если у кого есть соображения и опыт по управлению ситуациями схожими с моей, то пожалуйста поделитесь, буду весьма благодарен.
Как я понял корни ваших проблем:
1. Географическая разрозненность колектива
2. Частое изменение требований
Возможные решения
по п. 1:
— увеличить комуникационные возможности, email, icq, video-chat (сейчас это уже совсем не фантастика).
— регулярные, (можно короткие) чаты, а лучше video-чаты с участием всех членов фирмы,
что то типа планерок.
— поощрение общения (например отдых работников в одном месте за счет фирмы)
по п.2
— уделить большее внимание анализу требований (есть масса хорошей литературы на эту тему)
— сделать итерации максимально короткими (уж ни как не более недели)
Здравствуйте Forrest, Вы писали:
F>Коллеги, прошу у вас совета по одному вопросу.
[skip]
Посмотри в сторону XP (extreme programming): extreme programming in Russian
и еще поищи по форуму на эту тему.
