Что делать если вы всю свою сознательную жизнь были программистом, причём 99% времени работали один, и вас неожиданно повысили?
Следовательно, вам неизвестны принципы работы в команде. Вам надо начинать довольно объёмный проект.
Один вы не справитесь, значит надо набирать команду. Ваша задача на данный момент — за кратчайшие сроки узнать, как можно больше о том, как организовать работу над проектом. В этой статье я попытаюсь ответить, как это можно сделать. Попытаемся ответить на следующие вопросы:
1. С чего вообще начать делать проект? Например, что идёт первым — набор людей, а потом составление некоего плана проекта или наоборот?
2. Как правильно планировать проект? Какие инструменты применять?
3. Каким образом организовать работу? Как распределять задания? Как потом собирать воедино то, что написали программисты, и как описать программисту, что от него конкретно надо?
4. Нужны ли метадологии разработки программного обеспечения, такие как RUP, XP, Agile, AgileUP etc. Если да, то как выбрать то, что надо?
5. Как оценить, сколько и каких ресурсов надо?
Рассмотрим каждый вопрос отдельно:
1)Если проект кратковременный и в будущем вы можете распрощаться с людьми, то можно искать людей именно для проекта — некоторое время можно поработать даже с тем, кем душа не лежит общаться. Но если проект длительный или вы желаете набрать команду, с которой будете работать в будущем — ищите людей, с которыми сможете работать длительное время. Тех, с кем не будет проблем при общении (крупных проблем, т.к. мелкие точно встретятся). Тех, кто имеет достаточный уровень опыта (с вашей точки зрения). И тех, кто согласен работать под вашим руководством (зачастую бывает, что человек всем хорош, но постоянно будет тянуть одеяло на себя, что явно не будет способствовать успешной работе команды).
2) Начинать планирование стоит с определения и документирования требований. Потом постепенно начинаете описывать, из чего оно должно состоять (отдельные модули проекта) и в итоге детализируете до той степени, на которой задача будет ясна хотя бы вашим подчинённым. Если эту проектную документацию будете показывать заказчику, надо позаботиться, чтобы и ему она была понятна. Постарайтесь сначала всё описать и только потом раздавать задачи для кодирования. Опыт показывает, что начало написания до завершения проектировки приводит в конечном итоге к несогласованности модулей и увеличению сроков и нервного напряжения. Чтобы понять, как правильно планировать объект и какие инструменты использовать, полезно почитать заметки Джоэла Спольски на эту тему, его вариант не самый лучший, но для начала то, что нужно, т.к. не надо разбираться с различными специализированными программами. Уже потом, если захочется, можете посмотреть различные программы и выбрать, что тебе удобнее и полезнее. Если вы хорошо владеете UML, можете использовать его при проектировании и описании, но если нет, то не стоит, в этом случае лучше спроектировать все на бумаге. Заметки Спольски можно найти на его сайте www.joelonsoftware.com (там же неподалёку есть и локализованная русская версия, но заметки в ней не все).
3)Для начала надо разбить проект на подзадачи. Выделить обособленные части (которые можно разрабатывать параллельно. А затем раздавайте задачи либо тем, кто лучше и быстрее сделает, либо тем, кого желаете подтянуть в данной области.
Сборку воедино практически всегда можно сделать полуавтоматической. Нужно сделать костяк проекта, к которому будут присоединяться модули (куски кода) и положить этот скелет на VCS/SVN/иже_с_ними. Каждый программист будет выкладывать туда свой модуль (рабочий вариант, даже если вместо функций заглушки — всё равно проект должен компилироваться), а когда надо будет собрать проект воедино, кто-то будет либо вручную, либо автоматически (например, Ant'ом) собирать его.
Чтобы не было конфликтов, надо описывать в проектной документации интерфейсы модулей. Тогда и разночтений по поводу имён функций и возвращаемых типов не будет в принципе. Кстати, модуль не обязательно должен быть представлен классом. Это может быть и просто набор функций, например.
4)Лучше не заострять внимания на этом, пока вы не знакомы с подобными методологиями. Маловероятно, что хотя бы одна из этих метод является панацеей. Отдельные элементы полезны во многих случаях, но в целом методу каждый раз применять не выйдет. Сначала стоит наладить работу команды, а отом же можно экспериментировать с различными методами.
5) Поначалу можно определять примерно, а позже уже начнете чувствовать. Кстати, у того же Джоэла на эту тему тоже есть немного умных мыслей.
Следовательно, вам неизвестны принципы работы в команде. Вам надо начинать довольно объёмный проект.
Один вы не справитесь, значит надо набирать команду. Ваша задача на данный момент — за кратчайшие сроки узнать, как можно больше о том, как организовать работу над проектом. В этой статье я попытаюсь ответить, как это можно сделать. Попытаемся ответить на следующие вопросы:
1. С чего вообще начать делать проект? Например, что идёт первым — набор людей, а потом составление некоего плана проекта или наоборот?
2. Как правильно планировать проект? Какие инструменты применять?
3. Каким образом организовать работу? Как распределять задания? Как потом собирать воедино то, что написали программисты, и как описать программисту, что от него конкретно надо?
4. Нужны ли метадологии разработки программного обеспечения, такие как RUP, XP, Agile, AgileUP etc. Если да, то как выбрать то, что надо?
5. Как оценить, сколько и каких ресурсов надо?
Рассмотрим каждый вопрос отдельно:
1)Если проект кратковременный и в будущем вы можете распрощаться с людьми, то можно искать людей именно для проекта — некоторое время можно поработать даже с тем, кем душа не лежит общаться. Но если проект длительный или вы желаете набрать команду, с которой будете работать в будущем — ищите людей, с которыми сможете работать длительное время. Тех, с кем не будет проблем при общении (крупных проблем, т.к. мелкие точно встретятся). Тех, кто имеет достаточный уровень опыта (с вашей точки зрения). И тех, кто согласен работать под вашим руководством (зачастую бывает, что человек всем хорош, но постоянно будет тянуть одеяло на себя, что явно не будет способствовать успешной работе команды).
2) Начинать планирование стоит с определения и документирования требований. Потом постепенно начинаете описывать, из чего оно должно состоять (отдельные модули проекта) и в итоге детализируете до той степени, на которой задача будет ясна хотя бы вашим подчинённым. Если эту проектную документацию будете показывать заказчику, надо позаботиться, чтобы и ему она была понятна. Постарайтесь сначала всё описать и только потом раздавать задачи для кодирования. Опыт показывает, что начало написания до завершения проектировки приводит в конечном итоге к несогласованности модулей и увеличению сроков и нервного напряжения. Чтобы понять, как правильно планировать объект и какие инструменты использовать, полезно почитать заметки Джоэла Спольски на эту тему, его вариант не самый лучший, но для начала то, что нужно, т.к. не надо разбираться с различными специализированными программами. Уже потом, если захочется, можете посмотреть различные программы и выбрать, что тебе удобнее и полезнее. Если вы хорошо владеете UML, можете использовать его при проектировании и описании, но если нет, то не стоит, в этом случае лучше спроектировать все на бумаге. Заметки Спольски можно найти на его сайте www.joelonsoftware.com (там же неподалёку есть и локализованная русская версия, но заметки в ней не все).
3)Для начала надо разбить проект на подзадачи. Выделить обособленные части (которые можно разрабатывать параллельно. А затем раздавайте задачи либо тем, кто лучше и быстрее сделает, либо тем, кого желаете подтянуть в данной области.
Сборку воедино практически всегда можно сделать полуавтоматической. Нужно сделать костяк проекта, к которому будут присоединяться модули (куски кода) и положить этот скелет на VCS/SVN/иже_с_ними. Каждый программист будет выкладывать туда свой модуль (рабочий вариант, даже если вместо функций заглушки — всё равно проект должен компилироваться), а когда надо будет собрать проект воедино, кто-то будет либо вручную, либо автоматически (например, Ant'ом) собирать его.
Чтобы не было конфликтов, надо описывать в проектной документации интерфейсы модулей. Тогда и разночтений по поводу имён функций и возвращаемых типов не будет в принципе. Кстати, модуль не обязательно должен быть представлен классом. Это может быть и просто набор функций, например.
4)Лучше не заострять внимания на этом, пока вы не знакомы с подобными методологиями. Маловероятно, что хотя бы одна из этих метод является панацеей. Отдельные элементы полезны во многих случаях, но в целом методу каждый раз применять не выйдет. Сначала стоит наладить работу команды, а отом же можно экспериментировать с различными методами.
5) Поначалу можно определять примерно, а позже уже начнете чувствовать. Кстати, у того же Джоэла на эту тему тоже есть немного умных мыслей.