Здравствуйте, gbs, Вы писали:
gbs>По поводу написания сопутствующей проекту документации — логичнее использовать RUP. gbs>Но RUP никакого отношения не имеет к управлению проектами. gbs>Чтобы составить план трудозатрат проекта, оценить риски и спланировать бюджет существуют gbs>специальные дисциплины и стандарты — например PMI. gbs>Рекомендую к прочтению книгу:
gbs>Управление проектами: стандарты, методы, опыт. gbs>2-е изд. gbs>Авторы: Товб А. С., Ципес Г. Л. gbs>М.: ЗАО «Олимп—Бизнес», 2005. — 240 с.: ил. ISBN 5-9693-0039-1
gbs>тут: здесь
Ох книги... Как много в этом слове... К сожалению у меня тут такую книгу не найдешь, а ждать пока она доедет
Будем расти по статьям и общению со специалистами...
Здравствуйте, ironwit, Вы писали:
I>Про ХР немного знаю, но в этой ситуации не подойдет. Так как у нас удаленная разработка... I>А вот про остальное в свете своей задачи очень хотелось бы услышать...
На самом деле, применение XP в распределенной разработке вполне возможно.
Без парного программирования, конечно, но это не ключевая практика XP.
Что критично — это наладить связь между разработчиками: почта, ICQ, IRC, Wiki....
В принципе, все практики XP (даже ПП, в некот. степени) нормально переносятся
на распределенную разработку.
I>>Хотелось бы этот проект (даже если он и провалится) сделать красиво и по уму. То есть ТЗ, контроль ошибок, времени... I>>Чтобы посоветовали по этому поводу? А>{не гуру} рекомендую раздобыть литературу по UML, (в MSDN есть книжонка) разобраться мне кажется многие вопросы начнут прояснятся.
Ага. Я вот теперь и думаю пойти в книжный купить 5 книг по UML. Нанять 5 программистов и стать миллионером ибо из ваших слов вытекает, что эта команда мне горы свернет.
I>А вот с управлением проектом... Тут хуже, все сразу расплылись вилами по воде И я стал отставать... I>Можно ли проще?
Ты особо не заморачивайся на методологии. Знать и представлять о чем они конечно желательно. Но в твоем случае с 3-мя человеками надо действовать проще. Мой совет:
0. Заведите какую либо CVS + Bugtracking. Определите стандарты кодирования и правила оформления документации (например, используйте doxygen). Если есть желание то еще можно подключить unit-тестирование.
1. Определите цель. Создайте тексовый файл и в нем список, что должно быть в конечно проекте, что вы хотите получить.
2. Набросайте на бумажке архитектуру. Посидите подумайте над ней. Разойдитесь и подумайте в отдельности, соберитесь снова и еще раз обсудите. Старайтесь делать все как можно проще и не отклонятся от намеченой цели. Если вы распределены географически — используйт wiki.
3. Исходя из Цели, Набора тредуемой функциональности и получившейся архитектуры составте План ваших действий. Это может быть не только план написания кода, но и написание документации и тестирование. Пункты плана распределите между участниками. Если есть временые ограничения, то их желательно просчитать тоже на этом этапе.
4. Приступайте к разработке. Не важно как вы будете разрабатывать, но всегда следите за тем куда идете и как выполняется план. План можно менять в процессе, но меняя его всегда анализируйте к чему это приведет. Помните — ваша задача достигнуть цели.
А если сейчас попытаетесь влезть по уши в какую-либо методологию, то высока вероятность что цели своей не достигнете.
Здравствуйте, serg_mo, Вы писали:
_>Здравствуйте, ironwit, Вы писали:
I>>Про ХР немного знаю, но в этой ситуации не подойдет. Так как у нас удаленная разработка... I>>А вот про остальное в свете своей задачи очень хотелось бы услышать...
_>На самом деле, применение XP в распределенной разработке вполне возможно. _>Без парного программирования, конечно, но это не ключевая практика XP.
_>Что критично — это наладить связь между разработчиками: почта, ICQ, IRC, Wiki.... _>В принципе, все практики XP (даже ПП, в некот. степени) нормально переносятся _>на распределенную разработку.
Да у нас в общем то общение налажено, аська плюс, редко, личные встречи за
... << RSDN@Home 1.1.4 beta 4 Раз пусто, значит скорее всего пишу с работы. Там колонок нет
Здравствуйте, Ed.Nixon, Вы писали:
I>>>Хотелось бы этот проект (даже если он и провалится) сделать красиво и по уму. То есть ТЗ, контроль ошибок, времени... I>>>Чтобы посоветовали по этому поводу? А>>{не гуру} рекомендую раздобыть литературу по UML, (в MSDN есть книжонка) разобраться мне кажется многие вопросы начнут прояснятся.
EN>Ага. Я вот теперь и думаю пойти в книжный купить 5 книг по UML. Нанять 5 программистов и стать миллионером ибо из ваших слов вытекает, что эта команда мне горы свернет.
Странная у вас логика... Я такого из этого поста не вынес... Вот ведь разница между опытом и начинающими
... << RSDN@Home 1.1.4 beta 4 Раз пусто, значит скорее всего пишу с работы. Там колонок нет
Здравствуйте, serg_mo, Вы писали:
sm> На самом деле, применение XP в распределенной разработке вполне sm> возможно. sm> Без парного программирования, конечно, но это не ключевая практика sm> XP.
Это, мягко говоря, чертовски далеко от истины. Потому что парное программирование — именно ключевая практика XP. Помимо этого, в условиях георафически распределённой команды разработчиков под большим вопросом находятся и все остальные ключевые практики XP.
Здравствуйте, speedballer, Вы писали:
S>Это, мягко говоря, чертовски далеко от истины. Потому что парное программирование — именно ключевая практика XP. Помимо этого, в условиях георафически распределённой команды разработчиков под большим вопросом находятся и все остальные ключевые практики XP.
Давай попробуем разобраться. Особенность географически распределенной команды состоит в затрудненности общения между членами команды. Но, на мой взгляд, современные технические средства позволяют наладить уровень общения, приемлемый для применения XP. Для непосредственного общения разработчиков могу предложить IRC (его преимущество в обеспечении возможности группового общения в real-time), а для ведения журналов разработки, оформления требований и т. д. — Wiki, как электронную замену карточек.
Естественно, такой способ общения менее эффективен, чем непосредственное общение разработчиков, сидящих в одной комнате, но, тем не менее, вполне достаточен для эффективной разработки.
В идеале команде, конечно, нужен комп, постоянно выставленный в Инет, чтобы можно было на нем организовать Wiki-сервер, репозиторий исходников, настроить постоянную интеграцию и т. д. Но, думаю, реально обойтись и имеющимися средствами .
Кстати, на XProgramming.ru была предпринята попытка реализовать проект средствами дистанционной команды. Была успешно пройдена стадия формулирования требований и планирование первого релиза. Потом, проект, правда, заглох, ввиду угасания интереса у участников.
Мой товарищ использовал Wiki для общения с заказчиком, т. к. их команде не удалось получить его в постоянное пользование.
Кроме того, в одном из выпусков журнала "Программист" была статья, в которой автор делился практическим опытом применения XP в распределенной команде. Не могу, правда, никак этот выпуск найти
Относительно парного программирования. Я имею в виду, что эта практика не ключевая, т. к. от нее, если на то есть объективные причины, можно отказаться, не нарушая духа XP. Мы внедряли XP в команде из 3 человек, где, по понятным причинам, кому-то приходилось работать в одиночку. Работа одиночки была, в общем случае, менее эффективна, чем работа пары, но мы справлялись .
Кроме того, парное программирование невозможно, если работаешь над проектом один. Тем не менее, XP в одиночном проекте вполне применимо.
Здравствуйте, serg_mo, Вы писали:
_>Здравствуйте, ironwit, Вы писали:
I>>Да у нас в общем то общение налажено, аська плюс, редко, личные встречи за
_>Еще, как минимум, нужен Wiki.
Зачем? Какова ее целесообразность?
... << RSDN@Home 1.1.4 beta 4 Раз пусто, значит скорее всего пишу с работы. Там колонок нет
Здравствуйте, ironwit, Вы писали:
_>>Еще, как минимум, нужен Wiki. I>Зачем? Какова ее целесообразность?
У разговоров по Аське (и у разговоров вообще) есть такая особенность — поговорили и забыли. Кроме того, другие члены команды не в курсе, о чем был разговор. Wiki — это аналог доски в комнате. Фиксируются важные объявления, замечания, просто заметки на общее рассмотрение. Каждый может читать и изменять содержимое. Разработчики могут помещать на Wiki всяческие tips'n'tricks, полезные ссылки и т. п. В общем, такую информацию, которая циркулирует в устном виде в команде, когда все сидят в одной комнате.
В XP Wiki удобно применять для размещения User Stories, их обсуждений, оценок.
Ценное свойство Wiki, по сравнению с доской, в том, что можно структурировать информацию, разбивать по страничкам.
Здравствуйте, serg_mo, Вы писали:
_>Здравствуйте, ironwit, Вы писали:
I>>Да у нас в общем то общение налажено, аська плюс, редко, личные встречи за
_>Еще, как минимум, нужен Wiki.
А где его(это) взять?
Шурыгин Сергей
"Не следует преумножать сущности сверх необходимости" (с) Оккам
Здравствуйте, serg_mo, Вы писали:
_>Здравствуйте, speedballer, Вы писали:
S>>Это, мягко говоря, чертовски далеко от истины. Потому что парное программирование — именно ключевая практика XP. Помимо этого, в условиях георафически распределённой команды разработчиков под большим вопросом находятся и все остальные ключевые практики XP.
[SKIPPED] _>Относительно парного программирования. Я имею в виду, что эта практика не ключевая, т. к. от нее, если на то есть объективные причины, можно отказаться, не нарушая духа XP. Мы внедряли XP в команде из 3 человек, где, по понятным причинам, кому-то приходилось работать в одиночку. Работа одиночки была, в общем случае, менее эффективна, чем работа пары, но мы справлялись .
_>Кроме того, парное программирование невозможно, если работаешь над проектом один. Тем не менее, XP в одиночном проекте вполне применимо.
Как нас учит литература, есть разные "модели жизненного цикла разработки ПО". XP — одна из них. В XP парное программирование — это не только, когда два человека активно общаются между собой. Не менее важно, что один при этом не бьёт по клавишам, а контролирует второго (бьющего) и паралллельно работает головой. При этом осуществляется достаточно жёсткий контроль разработчиков друг над другом, что в совокупности даёт прирост производительности и качества.
Другие аспекты XP вроде итерационности, хитрости построения модели тестирования и т.п. присутствуют и в других моделях.
Можете рассмотреть спиральную или инкрементальную модели... Если требуется всё делать быстро и уровень владения инструментами достаточно высок, то можно использовать RAD модель. Если заказчик беспокойный и хочет как можно быстрее видеть, что будет в результате — можно использовать модель прототипирования.
ИМХО вам точно не подойдёт каскадная или V-образная модель, поскольку они несколько устарели и использоваться могут в основном в очень "консервативных" проектах.
Ещё одно. Выбор конкретной модели должен быть в первую очередь продиктован различными условиями, в которых будет выполняться проект (например, есть ли тесная связь с заказчиком, уровень технологической сложности проекта, компетентность команды, сроки и стоимость и т.п.).
На самом деле ничего сложного в выборе модели после того, как вы подумаете об условиях, в которых придётся делать проект, нет. Как правило берётся наиболее подходящая под ваши условия и адаптируется под ваш конкретный проект (лишнее, но не ключевое, убирается, что-то добавляется...). Ключевые параметры модели только убирать нельзя — модель перестаёт поддаваться управлению (анализу сроков и т.п.). Так что брать XP и убирать парное программирование — не советую.
Здравствуйте, Spidola, Вы писали:
S>Здравствуйте, serg_mo, Вы писали:
S>В XP парное программирование — это не только, когда два человека активно общаются между собой. Не менее важно, что один при этом не бьёт по клавишам, а контролирует второго (бьющего) и паралллельно работает головой. При этом осуществляется достаточно жёсткий контроль разработчиков друг над другом, что в совокупности даёт прирост производительности и качества.
Безусловно. Чтобы как-то приблизиться к эффекту парного программирования, я при разработке в одиночку периодически меняю кепку "драйвера" на "навигатора". Конечно, вторая голова была бы лучше, не спорю, но если его нет, приходится работать за двоих.
S>Ещё одно. Выбор конкретной модели должен быть в первую очередь продиктован различными условиями, в которых будет выполняться проект (например, есть ли тесная связь с заказчиком, уровень технологической сложности проекта, компетентность команды, сроки и стоимость и т.п.).
Здравая мысль. Я просто защищаю "распределенный XP"
S>Ключевые параметры модели только убирать нельзя — модель перестаёт поддаваться управлению (анализу сроков и т.п.). Так что брать XP и убирать парное программирование — не советую.
Еще раз повторю — парное программирование не является ключевым параметром. Да, оно позволяет повысить эффективность работы. Но ключевым параметром — нет.
Здравствуйте, serg_mo, Вы писали:
_>Здравствуйте, Spidola, Вы писали:
S>>Здравствуйте, serg_mo, Вы писали:
S>>В XP парное программирование — это не только, когда два человека активно общаются между собой. Не менее важно, что один при этом не бьёт по клавишам, а контролирует второго (бьющего) и паралллельно работает головой. При этом осуществляется достаточно жёсткий контроль разработчиков друг над другом, что в совокупности даёт прирост производительности и качества.
_>Безусловно. Чтобы как-то приблизиться к эффекту парного программирования, я при разработке в одиночку периодически меняю кепку "драйвера" на "навигатора". Конечно, вторая голова была бы лучше, не спорю, но если его нет, приходится работать за двоих.
Вы отдаляетесь от него. Фактически, вы пытаетесь инкапсулировать в индивидууме несколько ролей и последовательно выступаете в этих ролях. Парное программирование подразумевает размазывание роли по нескольким индивидуумам (конкретно по двум).
S>>Ключевые параметры модели только убирать нельзя — модель перестаёт поддаваться управлению (анализу сроков и т.п.). Так что брать XP и убирать парное программирование — не советую.
_>Еще раз повторю — парное программирование не является ключевым параметром. Да, оно позволяет повысить эффективность работы. Но ключевым параметром — нет.
Я, конечно, не адепт XP, но насколько я читал — парное программирование суть одно из "основных правил XP"... Вот тут, например, даже схемка есть, где парное программирование визуально в центре модели изображено.
Здравствуйте, ironwit, Вы писали:
I>Ситауция такова. I>Небольшой город, хочется расти над собой, но нужен опыт работы над проектом. I>Задача\проект придуманы. 3 человека собраны I>Хотелось бы этот проект (даже если он и провалится) сделать красиво и по уму. То есть ТЗ, контроль ошибок, времени... I>Чтобы посоветовали по этому поводу? I>Типа пример ТЗ, как 3 человекам контролировать процесс разработки...
Здравствуйте, serg_mo, Вы писали:
_>Здравствуйте, ironwit, Вы писали:
_>>>Еще, как минимум, нужен Wiki. I>>Зачем? Какова ее целесообразность?
_>В XP Wiki удобно применять для размещения User Stories, их обсуждений, оценок.
Ок, примерно понял...
Теперь еще надо все это настроить для того чтобы работать на работу (с подкл. к инету) и дома (без инета...)
... << RSDN@Home 1.1.4 beta 4 Раз пусто, значит скорее всего пишу с работы. Там колонок нет
Издательство: 