Начинаю свой первый проект в роли лидера команды разработчиков. Команда небольшая, четыре человека включая меня. Все находимся в одном здании и имеем возможность собираться каждое утро чтоб обсудить что сделано и чем будем заниматься сегодня. Собственно к этому пока и сводится "управление" проектом. 10-го января мы впервые увидели друг друга, до этого работали в разных фирмах. Проект на C# + VisualStudio 2003.
Чую, что мне предстоит прочитать море литературы и набить немало шишек, но начну с самого главного.
1. Документация.
Документацию для разработчиков генерируем в NDoc, по возможности стараемся писать комментарии к классам и методам. Вопрос как и чем создавать обзорную документацию. Менеджер (он тоже программист) хочет иметь представление чем именно мы занимаемся, плюс на митингах хотелось бы иметь распечатку с наиболее важными классами и интерфейсами сгруппированными по сборкам, чтоб было проще распределять работу. Хочется иметь диаграмму отражающую структуру приложения (сборки, namespaces) плюс задокументировать классы находящиеся на границе между зонами ответсвенности разработчиков. В первую очередь интерфейсы и value objects.
Попробовали Visio — слабовато. Взяли пробную версию Rational Rose — похоже что это стрельба из пушки по воробьям. Генерация кода по модели нам не нужна, только документирование уже существующего кода. Что из софта посоветуете ?
2. Оценка прогресса
Хотелось бы иметь представление насколько мы близко к цели и что ещё предстоит сделать. Пусть субъективно и приблизительно, но всё-ж отслеживать насколько далеко продвинулась работа по проектам, сколько процентов уже выполнено. Увы, раньше мы подобными вопросами не задавались, так что не знаю даже по каким ключевым словам гуглить. К моменту релиза хотелось бы иметь журнал проделанных изменений для того чтоб знать что же мы реально успели сделать за это время, плюс не скрести мучительно затылок при написании секции what's new при последующих релизах.
3. Учёт труда
В данный момент это не слишком важно, но знание кто что и в какие сроки сделал поможет лучше распределять нагрузку между разработчиками.
Какой софт наиболее подходит для организации работы небольшой команды ?
Литература. Прототип приложения должен быть готов через пять недель, бета версия через два месяца. Впрочем, первая версия приложения должна быть совсем простой и эти сроки реальны, так что не отсылайте меня сразу читать Йордана . Реально за этот месяц успею прочитать одну книжку, в лучшем случае две (это если они доступны в электронном виде, бумажные с озона идут долго), поэтому спрошу что же читать в первую очередь ?.
Уточни пожалуйста всю структуру команды. Есть ли PM (Project manager)? Как я понял, в твои обязанности входит полное техническое сопровождение проекта, так? Тогда, как мне кажется, ты не с той стороны к этому подходишь. Не стоит вести проект на уровне классов. Это слишком мелкая детализация. Проще будет вести его на уровне бизнес-объектов. Пусть конкретная реализация классов будет личным делом исполнителя. Иначе за мелочами потеряешь главное. Нельзя объять необъятное.
Ведешь ли ты Project Plan, отмечают ли исполнители в нем прогресс каждый день? Расписаны ли у тебя mailstones? Ответь для себя на эти вопросы и многое прояснится.
Здравствуйте, Cazi, Вы писали:
C>Начинаю свой первый проект в роли лидера команды разработчиков. Команда небольшая, четыре человека включая меня. Все находимся в одном здании и имеем возможность собираться каждое утро чтоб обсудить что сделано и чем будем заниматься сегодня. Собственно к этому пока и сводится "управление" проектом. 10-го января мы впервые увидели друг друга, до этого работали в разных фирмах. Проект на C# + VisualStudio 2003.
Поздравляю
C>Чую, что мне предстоит прочитать море литературы и набить немало шишек, но начну с самого главного.
За одного битого трёх небитых дают.
Всё ниже сказанное мною, естесственно — ИМХО. C>1. Документация. C>Документацию для разработчиков генерируем в NDoc, по возможности стараемся писать комментарии к классам и методам. Вопрос как и чем создавать обзорную документацию.
По данному вопросу рекомендую "Гибкие технологии: экстремальные программирование и унифицированный процесс разработки". Скотт Амблер. Автор пишет о следующем: документируейте только действительно необходимые вещи, и если заказчик требует документацию на софт, беспокоясь за процесс разработки проекта — не проще ли ему показывать разрабатываемое в текущий момент ПО, а не тратить время на написании разного рода спецификаций, которые с вероятностью в 99 процентов изменятся в течении проекта.
Также пишет про то, что непосредственное общение и совместное(групповое) моделирование системы гораздо эффективнее, чем порождение кипы документации. Стремитесь к простоте кода.
Со своей стороны скажу — что один довольно немаленький проект (более 400 000 строк кода), как я сейчас понимаю — был успешно сделан именно в данном стиле.(кое-кто из участвующих в форумах RSDN приложил немало труда и, насколько я знаю — и сейчас прикладывает(ся) ),
C>Попробовали Visio — слабовато. Взяли пробную версию Rational Rose — похоже что это стрельба из пушки по воробьям. Генерация кода по модели нам не нужна, только документирование уже существующего кода. Что из софта посоветуете ?
Borland Together for VS.NET 2.0 — выдающийся по эффективности инструмент, поддерживающий прямой и обратный инженеринг кода.(Я линейку Together — тогда он ещё назывался Together Control Center — использую с 2000 года. А перепробовал и Visual Modeler, и Rational Rose, и Microsoft Visio). И как я уже писал выше — код должен себя документировать, а не документы. C>2. Оценка прогресса C>Хотелось бы иметь представление насколько мы близко к цели и что ещё предстоит сделать. Пусть субъективно и приблизительно, но всё-ж отслеживать насколько далеко продвинулась работа по проектам, сколько процентов уже выполнено. Увы, раньше мы подобными вопросами не задавались, так что не знаю даже по каким ключевым словам гуглить. К моменту релиза хотелось бы иметь журнал проделанных изменений для того чтоб знать что же мы реально успели сделать за это время, плюс не скрести мучительно затылок при написании секции what's new при последующих релизах.
Сделайте диаграмму Uses Cases + диаграммы деятельности — где и опишите в общих чертах выполняемые системой операции. А потом, постепенно реализуя — ставьте галочку: сделано. . И особенно на мелочах не заморачивайтесь — лучше вместе моделируйте разные аспекты системы, делитесь идеями и пишите код.
C>3. Учёт труда C>В данный момент это не слишком важно, но знание кто что и в какие сроки сделал поможет лучше распределять нагрузку между разработчиками.
Опять таки — на основе имеющейся диаграммы прецедентов (Uses Cases) составьте временной график их реализации в коде.
C>Какой софт наиболее подходит для организации работы небольшой команды ?
Контроль версий: замечательно работает CVS + Tortoise, студия у вас уже имеется, из CASE — Together, багтрекинг — Rational Clear Quest.
C>Литература. Прототип приложения должен быть готов через пять недель, бета версия через два месяца. Впрочем, первая версия приложения должна быть совсем простой и эти сроки реальны, так что не отсылайте меня сразу читать Йордана . Реально за этот месяц успею прочитать одну книжку, в лучшем случае две (это если они доступны в электронном виде, бумажные с озона идут долго), поэтому спрошу что же читать в первую очередь ?.
Эти три книги вы просто обязаны прочитать :
1. Гради Буч — объектно-ориентированный анализ и проектирование с примерами приложений на С++. Хоть и древняя (1994 год) — актуальности не потеряла и по сей день.
2. Гамма и сотоварищи. Паттерны проектирования.
3. Кент Бек. Экстремальное программирование: разработка через тестирование.
В сумме порядка 600 страниц текста. Если читать по 2 часа в день — за неделю осилить можно. Другое дело — что в голове не сразу уляжется — но потом всё устаканится .
В принципе — есть ещё пара десятков книг по теме, но на их чтение у вас действительно нет времени.
Здравствуйте, sigma, Вы писали:
S>Уточни пожалуйста всю структуру команды.
Наша команда:
Д — Дизайнер. Единственный незаменимый человек, потому как остальные художественными талантами не блещут. Знает Windows.Forms, программирует интерфейс.
С — студент. Окончил в прошлом году университет. Практический опыт сводится к приработкам во время учёбы, зато парень молод, оптимистичен, полон энергии. Иногда, в запале утверждает что сможет всё сделать до завтра и готов вечером дома сидеть перед монитором и работать из энтузиазма. В университете был обучен UML и прочей теории, по крайней мере так он говорит.
Б — спец по базам данных. Ну и всё остальное умеет понемногу. Знаком с трудами Гаммы и компании.
Л — лидер (я). Умею всё понемногу, читал кое-что из теории организации разработки ПО, Гамму, Бека, но с практикой слабовато. Раньше на фирме всё писалось "на коленке" и спасались лишь зверским трудолюбием и упорством шефа, который и тянул за собой всю команду. Собственно мой проект это первая попытка организовать работу руководствуясь не только собственными набитыми шишками, но и используя систематизированые знания из книг.
S> Есть ли PM (Project manager)?
К сожалению я с терминологией не знаком (потому и открыл топик, чтоб научиться). Каково определение PM ?
S> Как я понял, в твои обязанности входит полное техническое сопровождение проекта, так?
Ну и программирование, конечно. Просто Д С и Б работают у нас в фирме с 10-го января этого года, а я несколько лет. Потому мне и поручили направлять новеньких и организовывать их работу. При этом шеф хочет иметь представление чем же мы занимаемся, для него и нужна обзорная документация. Ну и мне на митинге проще ткнуть пальцем в диаграмму, чем произносить пространные речи (у нас четыре разработчика из четырёх разных стран с четырьмя различными родными языками).
S> Тогда, как мне кажется, ты не с той стороны к этому подходишь. Не стоит вести проект на уровне классов. Это слишком мелкая детализация. Проще будет вести его на уровне бизнес-объектов. Пусть конкретная реализация классов будет личным делом исполнителя.
Например Б. пишет слой доступа к БД который будет использоваться всей командой. Хотелось бы задокументировать интерфейсные классы, их методы, исключения. Внутреняя реализация классов остаётся на усмотрение исполнителя.
S>Ведешь ли ты Project Plan, отмечают ли исполнители в нем прогресс каждый день?
Пока это у нас в головах и обговаривается устно на митингах. Как и какими средствами посоветуешь вести этот план ?
Здравствуйте, Cazi, Вы писали:
C>Начинаю свой первый проект в роли лидера команды разработчиков. Команда небольшая, четыре человека включая меня.... C>.... C>...Прототип приложения должен быть готов через пять недель...
C>Литература. Прототип приложения должен быть готов через пять недель, бета версия через два месяца. Впрочем, первая версия приложения должна быть совсем простой и эти сроки реальны, так что не отсылайте меня сразу читать Йордана . Реально за этот месяц успею прочитать одну книжку, в лучшем случае две (это если они доступны в электронном виде, бумажные с озона идут долго), поэтому спрошу что же читать в первую очередь ?.
Можно посмотреть в сторону FDD, и книга на эту тему есть от создателей Together -- "Практическое руководство по функционально-ориентированной разработке ПО"
Здравствуйте, Cazi, Вы писали:
C>1. Документация. C>Документацию для разработчиков генерируем в NDoc, по возможности стараемся писать комментарии к классам и методам. Вопрос как и чем создавать обзорную документацию. Менеджер (он тоже программист) хочет иметь представление чем именно мы занимаемся, плюс на митингах хотелось бы иметь распечатку с наиболее важными классами и интерфейсами сгруппированными по сборкам, чтоб было проще распределять работу. Хочется иметь диаграмму отражающую структуру приложения (сборки, namespaces) плюс задокументировать классы находящиеся на границе между зонами ответсвенности разработчиков. В первую очередь интерфейсы и value objects.
Хочется — делайте обязательно. Кстати, для документирования функционала классов хорошо подходит формат CRC карт — это забивается в notes или комментарии. Гораздо информативнее списка методов.
C>Попробовали Visio — слабовато. Взяли пробную версию Rational Rose — похоже что это стрельба из пушки по воробьям. Генерация кода по модели нам не нужна, только документирование уже существующего кода. Что из софта посоветуете ?
Rational Rose . Делаете reverse engineering для вашего кода (автоматически построенные диаграммы выбрасываются), после чего любая диаграмма классов строится за несколько минут драг-энд-дропом из модели. Настолько просто, что даже нет смысла эти диаграммы хранить.
C>2. Оценка прогресса C>Хотелось бы иметь представление насколько мы близко к цели и что ещё предстоит сделать. Пусть субъективно и приблизительно, но всё-ж отслеживать насколько далеко продвинулась работа по проектам, сколько процентов уже выполнено. Увы, раньше мы подобными вопросами не задавались, так что не знаю даже по каким ключевым словам гуглить. К моменту релиза хотелось бы иметь журнал проделанных изменений для того чтоб знать что же мы реально успели сделать за это время, плюс не скрести мучительно затылок при написании секции what's new при последующих релизах.
Это делается посредством EV Plan. Тебе нужен календарный план по проекту в любой метрике (лучше в нескольких). Примеры метрик размера — кол-во классов, функций, строк кода... ну ты понял. Если вы не планируете и не считаете размер, то используйте в качестве метрики количество задач. График такой — количество закрытых задач по времени. Чертите его по календарному плану, а потом достраиваете фактический график — очень хорошо отслеживается выполнение плана.
C>3. Учёт труда C>В данный момент это не слишком важно, но знание кто что и в какие сроки сделал поможет лучше распределять нагрузку между разработчиками.
В идеале по каждой задаче сохраните статистику: кол-во дней(часов), кол-во добавленных + измененных строк кода, кол-во добавленных/измененных классов, кол. добавдленных/измененных функций.
C>Какой софт наиболее подходит для организации работы небольшой команды ?
Excel.
C>Литература. Прототип приложения должен быть готов через пять недель, бета версия через два месяца. Впрочем, первая версия приложения должна быть совсем простой и эти сроки реальны, так что не отсылайте меня сразу читать Йордана . Реально за этот месяц успею прочитать одну книжку, в лучшем случае две (это если они доступны в электронном виде, бумажные с озона идут долго), поэтому спрошу что же читать в первую очередь ?.
Учитывая ограниченность временем — "время-деньги" Салливана.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, Cazi, Вы писали:
G>Rational Rose . Делаете reverse engineering для вашего кода (автоматически построенные диаграммы выбрасываются), после чего любая диаграмма классов строится за несколько минут драг-энд-дропом из модели. Настолько просто, что даже нет смысла эти диаграммы хранить.
В Together вообще ничего не надо делать — динамическая синхронизация моделей делает успешно своё дело.
Здравствуйте, Cazi, Вы писали:
C>Начинаю свой первый проект в роли лидера команды разработчиков. Команда небольшая, четыре человека включая меня. Все находимся в одном здании и имеем возможность собираться каждое утро чтоб обсудить что сделано и чем будем заниматься сегодня. Собственно к этому пока и сводится "управление" проектом. 10-го января мы впервые увидели друг друга, до этого работали в разных фирмах. Проект на C# + VisualStudio 2003.
Перечисленные задачи — это в основнм круг ответсвенности PM.
Задача TL — 1) представлять себе архитектуру системы в любой удобной (суть эффективной) форме. На уровне блоков.
2) определить "физические" принципы, типа используем C# Java DB2 и т.д. и всегда быть способным объяснить почему именно так. 3) Осуществлять техническое руководство в стиле "в споре рождается истина".
Все собственно.
Требования к персоне:
Как минимум не отставать от команды по уровню знаний. Как мимнимум чуть превышать уровень команды по степени охвата разных веяний и направлений ("Философия программирования" is a right place for that )
Здравствуйте, Cazi, Вы писали:
C>Начинаю свой первый проект в роли лидера команды разработчиков. Команда небольшая, четыре человека включая меня. Все находимся в одном здании и имеем возможность собираться каждое утро чтоб обсудить что сделано и чем будем заниматься сегодня. Собственно к этому пока и сводится "управление" проектом. 10-го января мы впервые увидели друг друга, до этого работали в разных фирмах. Проект на C# + VisualStudio 2003.
C>Чую, что мне предстоит прочитать море литературы и набить немало шишек, но начну с самого главного.
C>1. Документация. C>Документацию для разработчиков генерируем в NDoc, по возможности стараемся писать комментарии к классам и методам. Вопрос как и чем создавать обзорную документацию. Менеджер (он тоже программист) хочет иметь представление чем именно мы занимаемся, плюс на митингах хотелось бы иметь распечатку с наиболее важными классами и интерфейсами сгруппированными по сборкам, чтоб было проще распределять работу. Хочется иметь диаграмму отражающую структуру приложения (сборки, namespaces) плюс задокументировать классы находящиеся на границе между зонами ответсвенности разработчиков. В первую очередь интерфейсы и value objects.
Я пользуюсь для генерации документации DOxyGen. Оправдывает себя по многим параметрам: — интегрится в VS 2003, позволяет вставлять коментарии по стандартным шаблонам (для классов и функций). Приучает к дисциплине и чёткому стилю. Документировать стоит для разработчиков 2 момента — особенности, отличные от стандартов и в шапке файла — подробные размышления (концепцию). Именно концепция. а не описание аргументов позволяет понять, что же вы делали через пол года и позже, а аргументы, если вы придерживаетесь стандартов именования, сами по себе говорят, что они есть.
C>Попробовали Visio — слабовато. Взяли пробную версию Rational Rose — похоже что это стрельба из пушки по воробьям. Генерация кода по модели нам не нужна, только документирование уже существующего кода. Что из софта посоветуете ?
Нет, Rational — в самый раз, а для интеграции с кодом используйте не Rational Rose, а Rational XDE+ (Это фишка аналог Rose, но ориентирована именно на разработчика, вы видете в VS Диаграмы классо в и все изменения в коде отражаются на ней. Следует помнить, что детализация должна быть ровно такой, чтобы разработчик однозначно мог понять, что от него требуется. Для того, чтобы вы не переделывали всё снова и снова, проектировать сразу и жестко стоит итерфейсы. Любые изменения, должны проходить только в бумажном виде с автографами и пояснениями причин, иначе у вас постоянно кто-то будет менять интерфейс, а другие переписывать свой код для стыковки, тратя своё время на чужую неорганизованность.
C>2. Оценка прогресса C>Хотелось бы иметь представление насколько мы близко к цели и что ещё предстоит сделать. Пусть субъективно и приблизительно, но всё-ж отслеживать насколько далеко продвинулась работа по проектам, сколько процентов уже выполнено. Увы, раньше мы подобными вопросами не задавались, так что не знаю даже по каким ключевым словам гуглить. К моменту релиза хотелось бы иметь журнал проделанных изменений для того чтоб знать что же мы реально успели сделать за это время, плюс не скрести мучительно затылок при написании секции what's new при последующих релизах.
C>3. Учёт труда C>В данный момент это не слишком важно, но знание кто что и в какие сроки сделал поможет лучше распределять нагрузку между разработчиками.
Для этой цели хорошо интегрить команду в Microsoft Project и четко рисовать планинг, отслеживая dead-line, наказывая виновных и поощряя вправившихся. Стоит также изначатьно привить народу мысль о том, что они команда и, если кто-то чувствует, что валит сроки — обязан оповестить немедленно остальных с указанием причин, чтобы тим-лид или PM смог перераспределить своевременно нагрузку и гарантировать своевременное выполнеие приоритетных задач.
C>Какой софт наиболее подходит для организации работы небольшой команды ?
Microsoft Project(планирование и интеграция) + Outlook (легко интегрится с MS Project) + Bugzilla — для регистрации глюков и поддержки управления качеством.
Здравствуйте, adr, Вы писали:
adr>Здравствуйте, Cazi, Вы писали:
C>>1. Документация.
adr>Документировать стоит для разработчиков 2 момента — особенности, отличные от стандартов и в шапке файла — подробные размышления (концепцию). Именно концепция. а не описание аргументов позволяет понять, что же вы делали через пол года и позже, а аргументы, если вы придерживаетесь стандартов именования, сами по себе говорят, что они есть.
. Реально за этот месяц успею прочитать одну книжку, в лучшем случае две (это если они доступны в электронном виде, бумажные с озона идут долго), поэтому спрошу что же читать в первую очередь ?.
), 
