View Full Version : Есть тут программисты?
redgorilla
07-23-2006, 01:15 PM
Мне вот интересно как правильно организовать процесс разработки программного обеспечения. Дело вот в чем, решил я наконец организовать пару веб-программистов для приема проектов из –за далекой заграницы. У меня вобще-то есть опыт написание простых и средних проектов, но все делал я сам и опыта написание сложных проектов нету. Поэтому хотел спросить советов людей которые нормальный софт пишут…. Как правильно организовать процесс, какая иерархия, какие проги нужны для разработки и поддержи крупных проектов.
Вобщем интересует:
1. Какие должны быть специалисты для работы на в команде (до 10 человек)… ну там project – manager и т.д…. и кто за что отвечает.
2. Что из ПО можно использовать для поддержки и развития кода (Языки будут ПХП и АСП… но я думаю это не сильно влияет)
3. Какие методы разрабоки можно использовать для веб проектов….
4. Какие стандарты следует установить для всей команды и для каждого проекта (ну там.... code guidline и т.д.)
Заранее благодарен
Начни с конца.Что хочешь получить на выходе. Далее - бей все на этапы.
Последний с конца- сдача и/или поддержка. Чел, который способен продать сухой песок бедуинам в Сахаре и объяснить юзеру, что неработающая прога - мираж! А на самом деле все давно уже сделалось и просто "услвно не показано".
Предпоследний -- тестирование. Нужна програма тестирования.Типа ввожу а, на выходе вижу а, б, с.. Если не вижу - "обратитесь к разработчикам"
Перед ним - сборка. Вот есть такая папочка, где готовые наработки, а есть - где исходники. Каждый писарь кроме исходников сдает файл - журнал, чего сделал по функционалу или инструменту. Сборщик находит кусочки кода и пытается сваять нетленку...
С программерами - все понятно.Дали ему кусок задачи, он его реализовывает. Если речь о WEB, где до чертиков графики, для всех изначально, выбираем стиль: фон, кнопочки, пупочки, банерочки, шрифтики... Размеры таблиц, фон в таблицах,и т.д.
А перед ним сидит постановщик задачи, который расписывает алгоритм (схему) чего хочет клиент и как это монтируется, исходя из инструмеальных возможностей.
Сбоку от всего этого сидит задумчивая личность, под названием технический писатель.Этот создает документацию по проекту.Если она требуется.Пишет хелп. И на этом основании, мешает всем работать - ходит, спрашивает : а это что, а это - как?
Ну, а во главе сидит инженер - конструктор проекта. Он рисует блок-схему всего проекта, как раз и придумывает стиль, если работаем для www, она же - "щетка".
Но начинать надо с получения технического задания.Что б эта сволочь - заказчик все там прописал и ре придумывал по ходу новые трудности.
Это так, общая схема. На самом деле наш "Новый проект" в блок- схеме , занимал примерно 5 х 1 метр. Со стрелочками, ответвлениями и приклееными листиками поздних приработок. Была прога (не помню, кей -ком, что ли) где вся документация либо хранилась, либо содержала ссылку к файлам на другом компе. Ораганайзер такой, по темам.
(В Вебе шаришь, придумаешь запроссто)
Гамбринус
07-24-2006, 08:09 AM
А вот как это у нас делается:
http://stylusinc.com/Common/Concerns/SoftwareDevtPhilosophy.php
http://www.augustana.ab.ca/~mohrj/courses/2000.winter/csc220/papers/rup_best_practices/rup_bestpractices.pdf
Ну и таких общих пару слов (там есть ссылки на то что почитать):
http://www.ics.uci.edu/~wscacchi/Papers/SE-Encyc/Process-Models-SE-Encyc.pdf
http://www.sei.cmu.edu/pub/documents/90.reports/pdf/tr24.90.pdf
redgorilla
07-24-2006, 08:11 AM
Начни с конца.Что хочешь получить на выходе. Далее - бей все на этапы.
.......
Но начинать надо с получения технического задания.Что б эта сволочь - заказчик все там прописал и ре придумывал по ходу новые трудности.
Это так, общая схема. На самом деле наш "Новый проект" в блок- схеме , занимал примерно 5 х 1 метр. Со стрелочками, ответвлениями и приклееными листиками поздних приработок. Была прога (не помню, кей -ком, что ли) где вся документация либо хранилась, либо содержала ссылку к файлам на другом компе. Ораганайзер такой, по темам.
(В Вебе шаришь, придумаешь запроссто)
Спасибо за исчерпывающий ответ... раставили все по местам.... кто, где, чего делает...
Вот еще небольшой вопрос можно ли доверять программистам в оценке времени на выполенние задач или врем лучше определять исходя из мнеия как ПМ так и кодеров?
redgorilla
07-24-2006, 08:35 AM
А вот как это у нас делается:
http://stylusinc.com/Common/Concerns/SoftwareDevtPhilosophy.php
http://www.augustana.ab.ca/~mohrj/courses/2000.winter/csc220/papers/rup_best_practices/rup_bestpractices.pdf
Ну и таких общих пару слов (там есть ссылки на то что почитать):
http://www.ics.uci.edu/~wscacchi/Papers/SE-Encyc/Process-Models-SE-Encyc.pdf
http://www.sei.cmu.edu/pub/documents/90.reports/pdf/tr24.90.pdf
Пасибо за документы, пошел читать.... эт, я как понял, RUP цветет и процветат в США? XP для романтиков одиночек и необльших груп?
Sixteen
07-24-2006, 08:38 AM
Спасибо за исчерпывающий ответ... раставили все по местам.... кто, где, чего делает...
Вот еще небольшой вопрос можно ли доверять программистам в оценке времени на выполенние задач или врем лучше определять исходя из мнеия как ПМ так и кодеров?
доверять по вопросам времени ваапще никому нельзя. план
нужно просто постоянно корректировать, потому что все оценки крайне приблизительны.
два принципа жылезных принципа -
1. чем меньше задача, тем легче ее точно оценить
во времени.
2. чем меньше задач одновременно ставится перед одним программистом -тем быстрее он может их выполнить.
Гамбринус
07-24-2006, 09:01 AM
...два принципа жылезных принципа -
1. чем меньше задача, тем легче ее точно оценить
во времени.
2. чем меньше задач одновременно ставится перед одним программистом -тем быстрее он может их выполнить.
Хотел еще из собственных наблюдений добавить -- чем больше программеров трудятся над проэктом, тем хуже качество софта во всех отношениях. По сему надо вовлекать как можно меньше девелоперов, даже если КАЖЕТСЯ что они не уложатся в сроки. IMHO
Sixteen
07-24-2006, 09:27 AM
Хотел еще из собственных наблюдений добавить -- чем больше программеров трудятся над проэктом, тем хуже качество софта во всех отношениях. По сему надо вовлекать как можно меньше девелоперов, даже если КАЖЕТСЯ что они не уложатся в сроки. IMHO
совершенно верно! чем их больше, тем больше требуется затрат на координацию.
при чем координационные затраты растут быстрее чем то ускорение
которое можно получить от добавления дополнительных программеров.
поэтому если пять программистов будут делать проэкт год, то двадцать
вообще никогда не закончат.
Спасибо за исчерпывающий ответ... раставили все по местам.... кто, где, чего делает...
Вот еще небольшой вопрос можно ли доверять программистам в оценке времени на выполенние задач или врем лучше определять исходя из мнеия как ПМ так и кодеров?
Ну, это даже не анекдот, а суровая реальность: задача, которую один программист может решить за один день, два программиста сделают..за три!
У нас даже самый умный Гуру пишет так: трудоемкость 1.7*2 дня. Вот как хочешь так и понимай!
1.7 - это его работа, потом - сдача сборщику, сборка, тестирование, исправления явных багов.
А уж этот зубр пишет тексты лет двадцать. Тему вопроса знает:lol:
mick_by
08-02-2006, 07:12 AM
У меня вобще-то есть опыт написание простых и средних проектов, но все делал я сам и опыта написание сложных проектов нету.
1. На самом деле - разница если так можно сказать не большая. Большой/Сложный проект - это набор простых и средних проектов. Главное - изначально все правильно запланировать.
Как правильно организовать процесс, какая иерархия
Принцип абсолютно тот же, что и в любом бизнесе. Руководитель, замы, рядовые сотрудники.
.... какие проги нужны для разработки
Все зависит от проектов, которыми вы хотите занятся. Под так называемый LAMP (Linux, Apache, MySQL, Perl/php) вообще и Linux/Unix web and software development - очень много freeware opensource инструментов - и выбор конкретного зависит от задач, или от желания программистов. Главное что бы делали все быстро и грамотно. Что касается Windows - то по опыту лучше использовать родные мелкомякгие IDE & tools.
.... и поддержи крупных проектов.
Это вопрос отдельны и касается приципов поддержки проекта - иногда хватает одного dedicated девелопера, иногда нужен call-center. Зависит от того что вы делаете.
Какие должны быть специалисты для работы на в команде (до 10 человек)… ну там project – manager и т.д…. и кто за что отвечает.
Я говорю минимум - реально можно раздуть больше:
Project manager, Lead developer, developers, QA.
Project manager - тут понятно общеe управления + project plan creation & update , project resource management. Specification, Documentation & Prototype development.
Lead Developer - при всем при том, что project manager IMHO должен обладать познаниями в development (MBA без знаний в software development я даже не рассматриваю - это отстой), в проекте должен быть ведущий программист, который решает (помогает решать) текущие технические/алгоритмические вопросы, отвечает за структуру классов (если ООП) и БД. Помагает project managerу оценивать время на разработку.
Developers - понятно вроде как.
QA - он же специалист по тестирование, нужен будет с самого начала проекта (а не как некоторые думают). Составляет project testing plan и собственно осуществляет его непосредственное выполнение. Помагает project managerу оценивать время на тестирование.
Что из ПО можно использовать для поддержки и развития кода (Языки будут ПХП и АСП… но я думаю это не сильно влияет)
Лучше ASP.NET, ASP просто больше проблем создаст в дальшейнем. А вообще - выбор языка больше зависит от 2 вещей: задача которую нужно сделать, и если есть - желание клиента.
Какие методы разрабоки можно использовать для веб проектов….
Большой вопрос для ответа здесь :) а какие вы знаете?
При все уважении к YUMу описание процесса может смешное - но приведет в случае такого построения и отношения - к краху проекта.
Какие стандарты следует установить для всей команды и для каждого проекта (ну там.... code guidline и т.д.)
ISO 9001 :) на самом деле зависит от компании. тоже вопрос большой и требует дополнительного обсуждения.
Вот еще небольшой вопрос можно ли доверять программистам в оценке времени на выполенние задач или врем лучше определять исходя из мнеия как ПМ так и кодеров?
Все зависиь от их квалификации. 100% нельзя доверять никому. поэтому оценку делает PM - ему помогают уточнять Lead DEv & QA, к этому времени тоже надо накинуть немного будет на всякие риски - и получится конечная сумма. Если надо - оценку (принцип оценки) могу рассписать от и до.
два принципа жылезных принципа -
1. чем меньше задача, тем легче ее точно оценить
во времени.
2. чем меньше задач одновременно ставится перед одним программистом -тем быстрее он может их выполнить
Это правильно в том плане - что:
1. Любой проект надо дифференцировать на маленькие задачи - так легче итого подсчитать.
2. #2 - спорно - надо давать дозированно. а не все сразу, и таски должны выполняться в определенной последовательности.
Хотел еще из собственных наблюдений добавить -- чем больше программеров трудятся над проэктом, тем хуже качество софта во всех отношениях. По сему надо вовлекать как можно меньше девелоперов, даже если КАЖЕТСЯ что они не уложатся в сроки.
IMHO - все зависит от project managerа. Если он баран - то проект прогарит при любых условиях.
совершенно верно! чем их больше, тем больше требуется затрат на координацию. при чем координационные затраты растут быстрее чем то ускорение которое можно получить от добавления дополнительных программеров.поэтому если пять программистов будут делать проэкт год, то двадцать вообще никогда не закончат.
Абсолютно неверно!!!
1. Project manager отвечает за внутрипроектную коммуникацию и координацию - поэтому если что-то не выходит - его вина. ЕСЛИ все с самого начало спланированно правильно, совместная работа грамотно организовано, то двадцать программистов напишут и сделают все на порядок лучше и быстрее 5ти. Опять же - все упирается в опыт и умение/навыки Project Managerа
нас даже самый умный Гуру пишет так: трудоемкость 1.7*2 дня. Вот как хочешь так и понимай! 1.7 - это его работа, потом - сдача сборщику, сборка, тестирование, исправления явных багов.
Для себя я создал алгоритм оценки программистов, поэтому у каждого своего программера как и в это примере - я знаю коэффициент, который учитываю при оценке проекта.
Sixteen
08-02-2006, 07:52 AM
Абсолютно неверно!!!
1. Project manager отвечает за внутрипроектную коммуникацию и координацию - поэтому если что-то не выходит - его вина. ЕСЛИ все с самого начало спланированно правильно, совместная работа грамотно организовано, то двадцать программистов напишут и сделают все на порядок лучше и быстрее 5ти. Опять же - все упирается в опыт и умение/навыки Project Managerа
это так - в теории координация зависит от ПМ, и эффективность
тоже зависит от ПМ. Практика же показывает, что
вероятность того что ваш ПМ компетентен (а не идиот)
стемится к нулю. я могу долго и много обсуждать почему
и от чего это так, но это так. в этих постоянно встречающихся
ситуациях проекты выполняются не за счет ПМов, а за счет того что есть работающие горизонтальные связи между командами, в которых ПМы вообще не участвуют, и все происходит скорее вопреки ПМам.
cosmopolit
08-02-2006, 08:11 AM
это так - в теории координация зависит от ПМ, и эффективность
тоже зависит от ПМ. .....
Прочитала три раза, долго думала...:rolleyes:
ПМ это ПМС укороченное что-ли? И эффективность тогда напрямую зависит...:cool:
Sixteen
08-02-2006, 11:52 AM
Прочитала три раза, долго думала...:rolleyes:
ПМ это ПМС укороченное что-ли? И эффективность тогда напрямую зависит...:cool:
ПМ - проект-менеджер, или project manager.
mick_by
08-02-2006, 12:41 PM
это так - в теории координация зависит от ПМ, и эффективность
тоже зависит от ПМ. Практика же показывает, что
вероятность того что ваш ПМ компетентен (а не идиот)
стемится к нулю.
Честно говоря - странная практика.
Я прошел весь путь кодер->дев->лид.дев->PM->Head of Project Office - и ни разу у меня небыло сбоя в проектах. На самом деле качество ПМа зависит от того, чего придерживаются в компании. Если раздолбайский подход: "типа мы крутая фирма и делаем большие проекты" -> то да - это контора не проживет, а если же жесткие правила, постоянно отслеживается качество на всех участках - то тогда все ок.
По поводу неэффективности ПМ - если брать тех ПМов что я видел - которые никогда (типа MBA) или минимум программили - и слабо представляют процесс разработки или были слабыми девелоперами =- то у них - да - коммуникация никакая, управление никакое и проч.
Sixteen
08-02-2006, 12:50 PM
Честно говоря - странная практика.
Я прошел весь путь кодер->дев->лид.дев->PM->Head of Project Office - и ни разу у меня небыло сбоя в проектах. На самом деле качество ПМа зависит от того, чего придерживаются в компании. Если раздолбайский подход: "типа мы крутая фирма и делаем большие проекты" -> то да - это контора не проживет, а если же жесткие правила, постоянно отслеживается качество на всех участках - то тогда все ок.
По поводу неэффективности ПМ - если брать тех ПМов что я видел - которые никогда (типа MBA) или минимум программили - и слабо представляют процесс разработки или были слабыми девелоперами =- то у них - да - коммуникация никакая, управление никакое и проч.
принцип Питера, уважаемый Мик, принцип Питера.
ничего странного в практике нету. если в фирме не понимают
принципа Питера, то никакие жесткие правила не помогут.
mick_by
08-02-2006, 01:02 PM
На самом деле - никаких принципов Питера :) должен быть сплошой PMI + ISO9001 :)
Sixteen
08-02-2006, 01:28 PM
На самом деле - никаких принципов Питера :) должен быть сплошой PMI + ISO9001 :)
в отличие от ISO принцип питера является законом природы ...
вот это то чем занимаются проджект менеджеры - они все время говорят от том что должно быть,
вместо того чтобы говорить о том что реально может быть :D
mick_by
08-02-2006, 04:12 PM
в отличие от ISO принцип питера является законом природы ...
вот это то чем занимаются проджект менеджеры - они все время говорят от том что должно быть,
вместо того чтобы говорить о том что реально может быть :D
Чисто девелоперский ответ :evillaugh
http://www.ashmanov.com/pap/obspro.phtml
Sixteen
08-02-2006, 05:35 PM
Чисто девелоперский ответ :evillaugh
http://www.ashmanov.com/pap/obspro.phtml
нет, ну это просто ликбез для народа совсем от сохи.
Гамбринус
08-05-2006, 11:27 PM
...IMHO - все зависит от project managerа. Если он баран - то проект прогарит при любых условиях. ...
От праджект мэнаджэра требуется только вовремя вычислять и выгонять баранов из команды... И оберегать команду от баранов из высшего командного состава. Всё остальное зависит от того кто софт ручками пишет... а праджект мэнаджер может быть бараном в своё удовольствие при указаных выше условиях!