Ситауция такова.
Небольшой город, хочется расти над собой, но нужен опыт работы над проектом.
Задача\проект придуманы. 3 человека собраны
Хотелось бы этот проект (даже если он и провалится) сделать красиво и по уму. То есть ТЗ, контроль ошибок, времени...
Чтобы посоветовали по этому поводу?
Типа пример ТЗ, как 3 человекам контролировать процесс разработки...
В общем поклоняюсь гуру.
Здравствуйте, McSpace, Вы писали:
MS>Ты слышал умные слова типа RUP, Экстримального программирования (XP), MSF и .т.п. ?
MS>Вот тебе удобный случай изучить и на практике применить одну из методологий...
Слышал
Про ХР немного знаю, но в этой ситуации не подойдет. Так как у нас удаленная разработка...
А вот про остальное в свете своей задачи очень хотелось бы услышать...
Здравствуйте, ironwit, Вы писали:
I>Здравствуйте, McSpace, Вы писали:
MS>>Ты слышал умные слова типа RUP, Экстримального программирования (XP), MSF и .т.п. ?
MS>>Вот тебе удобный случай изучить и на практике применить одну из методологий... I>Слышал I>Про ХР немного знаю, но в этой ситуации не подойдет. Так как у нас удаленная разработка... I>А вот про остальное в свете своей задачи очень хотелось бы услышать...
RUP — итерационный процесс управляемый требованиями (рисками)=> вопрос имеешь ли ты постоянный доступ к заказчику и конечному пользователю (личные встречи, телефон, на худой конец инет, хотя без реального общения будет тяжело), если нет, то мммм даже не знаю... все зависит от проекта конечно...
Здравствуйте, McSpace, Вы писали:
MS>Ты слышал умные слова типа RUP, Экстримального программирования (XP), MSF и .т.п. ? MS>Вот тебе удобный случай изучить и на практике применить одну из методологий...
Разве первый и третий команде из трёх человек подойдёт?
Здравствуйте, ironwit, Вы писали:
I>Хотелось бы этот проект (даже если он и провалится) сделать красиво и по уму. То есть ТЗ, контроль ошибок, времени... I>Чтобы посоветовали по этому поводу?
{не гуру} рекомендую раздобыть литературу по UML, (в MSDN есть книжонка) разобраться мне кажется многие вопросы начнут прояснятся.
L>RUP — итерационный процесс управляемый требованиями (рисками)=> вопрос имеешь ли ты постоянный доступ к заказчику и конечному пользователю (личные встречи, телефон, на худой конец инет, хотя без реального общения будет тяжело), если нет, то мммм даже не знаю... все зависит от проекта конечно...
Мы сами себе заказчики... Так как проект хоть и реален, но выбран просто для набора опыта...
Проект требуется кое каким интернет знакомым (большому кол-ву), поэтому баг-репортов будет много и разного качества, как от профессиональных программистов до продвинутых юзеров (очень редко от чайников). Это ответ?
Здравствуйте, <Аноним>, Вы писали:
А>Здравствуйте, ironwit, Вы писали:
I>>Хотелось бы этот проект (даже если он и провалится) сделать красиво и по уму. То есть ТЗ, контроль ошибок, времени... I>>Чтобы посоветовали по этому поводу?
А>{не гуру} рекомендую раздобыть литературу по UML, (в MSDN есть книжонка) разобраться мне кажется многие вопросы начнут прояснятся.
Буча (или бутча) читал... Также кое что на эту тему читал. Но так толком и не понял как планировать время, как писать нормальное ТЗ, как увидеть все ньюансы будущего проекта
Здравствуйте, McSpace, Вы писали:
MS>Ты слышал умные слова типа RUP, Экстримального программирования (XP), MSF и .т.п. ?
Советую использовать RUP — очень настраиваемая вещь, есть хорошие книги, которые помогут понять и настроить процесс для конкретной работы. Главное не зарыться в бумажной работе, а чувствовать грань между анархией и рутиной. Наличие документации по проекту значительно облегчает разработку больших проектов, их дальнейшее сопровождение, способствует хорошей устойчивости к потерям в команде.
ХР мне лично не нравится большой свободой членов команды и трудностью соблюдения принципов ХР. В результате через некоторое время команда постепенно начинает переходить к анархии. На небольшой команде может очень сильно чувствоваться потеря одного из игроков команды.
Из MSF можно взять некоторые идеи (и приложить их к RUP ), но, на мой взгляд, его нельзя применять в разработке, т.к. этота методология недалеко ушла от водопадного метода разработки.
Здравствуйте, Слава Шевцов, Вы писали:
СШ>Здравствуйте, McSpace, Вы писали:
MS>>Ты слышал умные слова типа RUP, Экстримального программирования (XP), MSF и .т.п. ? MS>>Вот тебе удобный случай изучить и на практике применить одну из методологий...
СШ>Разве первый и третий команде из трёх человек подойдёт?
Первый вполне подойдет, т.к. один человек может совмещать несколько ролей в своей работе.
Здравствуйте, McSpace, Вы писали:
А>>{не гуру} рекомендую раздобыть литературу по UML, (в MSDN есть книжонка) разобраться мне кажется многие вопросы начнут прояснятся.
MS>Я точно не Гуру, но к управлению проектом UML, по-моему, никак не относится.
Да, это всего-лишь язык графических описаний, используемый при анализе и проектировании. Его с успехом можно заменить на другие аналоги или придумать свой язык описания, но с таким распространенным стандартом значительно легче передавать свои мысли другим.
MS>>Я точно не Гуру, но к управлению проектом UML, по-моему, никак не относится.
S>Да, это всего-лишь язык графических описаний, используемый при анализе и проектировании. Его с успехом можно заменить на другие аналоги или придумать свой язык описания, но с таким распространенным стандартом значительно легче передавать свои мысли другим.
Спасибо за поддержку. А то я уж подумал, что в UML кем-то включено графическое представление упраления проектами и рисками...
While (!Life.EOF){
You.Money ++;
You.Girls.Add(new Girl(90,60,90));
BeHappy();
}
Здравствуйте, stasukas, Вы писали:
MS>>>Ты слышал умные слова типа RUP, Экстримального программирования (XP), MSF и .т.п. ? MS>>>Вот тебе удобный случай изучить и на практике применить одну из методологий...
СШ>>Разве первый и третий команде из трёх человек подойдёт?
S>Первый вполне подойдет, т.к. один человек может совмещать несколько ролей в своей работе.
Не тяжеловат ли он? ИМХО, там очень много бумаги, которая необходима для управления большими командами, но вредны для мелких. Или я что-то не увидел?
Здравствуйте, Слава Шевцов, Вы писали:
СШ>Здравствуйте, stasukas, Вы писали:
MS>>>>Ты слышал умные слова типа RUP, Экстримального программирования (XP), MSF и .т.п. ? MS>>>>Вот тебе удобный случай изучить и на практике применить одну из методологий...
СШ>>>Разве первый и третий команде из трёх человек подойдёт?
S>>Первый вполне подойдет, т.к. один человек может совмещать несколько ролей в своей работе.
СШ>Не тяжеловат ли он? ИМХО, там очень много бумаги, которая необходима для управления большими командами, но вредны для мелких. Или я что-то не увидел?
Еще раз скажу, что это настраиваемый процесс. Всегда можно определить уровень необходимой документации (у нового человека не должна пухнуть голова от избытка информации и вопросов быть не должно). Не обязательно описывать каждый завиток, достаточно дать правильное направление.
Практика показала, что для небольшой команды RUP вполне хорошо подходит, а подобный опыт очень важен на больших проектах.
Здравствуйте, ironwit, Вы писали:
I>Ситауция такова. I>Небольшой город, хочется расти над собой, но нужен опыт работы над проектом. I>Задача\проект придуманы. 3 человека собраны I>Хотелось бы этот проект (даже если он и провалится) сделать красиво и по уму. То есть ТЗ, контроль ошибок, времени... I>Чтобы посоветовали по этому поводу? I>Типа пример ТЗ, как 3 человекам контролировать процесс разработки... I>В общем поклоняюсь гуру.
Ой, не надо за ТЗ ничего говорить . Попробуйте для начала просто сформулировать ТРЕБОВАНИЯ к вашей системе. Просто хотябы в виде списка "Система должна ...", нарисвать картинку "Ваша система и те с кем/чем она взаимодействует", и это будет более информативно, чем ТЗ . Да, создание ТЗ не относиться к управлению проектом по-большому счету.
Здравствуйте, Слава, Вы писали:
S>>Первый вполне подойдет, т.к. один человек может совмещать несколько S>>ролей в своей работе. СШ> Не тяжеловат ли он? ИМХО, там очень много бумаги, которая необходима СШ> для управления большими командами, но вредны для мелких. Или я СШ> что-то не увидел?
Я тут парой месяцев раньше рекомендовал очень полезную книжку: Ф. Крачтен, П. Крол, «Rational Unified Process — это легко. Руководство по RUP для практиков» (на «Озоне» она пока ещё есть в наличии
). Так вот, там описан RUP для проектной команды из одного человека.
Насчёт того, что в RUP много бумаги — это, собственно, либо заблуждение, либо следствие ошибок, допущенных при разработке и внедрении процесса. Есть основополагающие принципы, без которых RUP — не RUP. Но к этим принципам не относится, например, требование «документируйте каждый ваш чих».
Здравствуйте, stasukas, Вы писали:
S>Здравствуйте, McSpace, Вы писали:
MS>>Ты слышал умные слова типа RUP, Экстримального программирования (XP), MSF и .т.п. ?
S>Советую использовать RUP — очень настраиваемая вещь, есть хорошие книги, которые помогут понять и настроить процесс для конкретной работы. Главное не зарыться в бумажной работе, а чувствовать грань между анархией и рутиной. Наличие документации по проекту значительно облегчает разработку больших проектов, их дальнейшее сопровождение, способствует хорошей устойчивости к потерям в команде.
Насчет хороших книг по RUP -- не так уж их и много .
S>ХР мне лично не нравится большой свободой членов команды и трудностью соблюдения принципов ХР. В результате через некоторое время команда постепенно начинает переходить к анархии. На небольшой команде может очень сильно чувствоваться потеря одного из игроков команды.
XP декларирует в т.ч. коллективное владение кодом ... и если использовать парное программирование, то потеря одного не должна приводить к катастрофам.
Здравствуйте, ironwit, Вы писали:
I>Здравствуйте, <Аноним>, Вы писали:
А>>Здравствуйте, ironwit, Вы писали:
I>>>Хотелось бы этот проект (даже если он и провалится) сделать красиво и по уму. То есть ТЗ, контроль ошибок, времени... I>>>Чтобы посоветовали по этому поводу?
А>>{не гуру} рекомендую раздобыть литературу по UML, (в MSDN есть книжонка) разобраться мне кажется многие вопросы начнут прояснятся.
I>Буча (или бутча) читал... Также кое что на эту тему читал. Но так толком и не понял как планировать время, как писать нормальное ТЗ, как увидеть все ньюансы будущего проекта
Нигде не пишут о том, как писать ТЗ. Про требования -- можно найти несколько книг на русскм. Это книга К. Вигерса, Д. Лефингвелла и А. Коберна ... Все ньюансы -- не увидишь ... все ньюансы -- это в модели дизайна или в исходном коде .
Re[6]: управление проектом начинающими :)
От:
Аноним
Дата:
08.02.05 14:35
Оценка:
Здравствуйте, speedballer, Вы писали:
S>Здравствуйте, Слава, Вы писали:
S>Насчёт того, что в RUP много бумаги — это, собственно, либо заблуждение, либо следствие ошибок, допущенных при разработке и внедрении процесса. Есть основополагающие принципы, без которых RUP — не RUP. Но к этим принципам не относится, например, требование «документируйте каждый ваш чих».
О, раз пошли вопросы по RUP ... вот если на основе RUP делается свой процесс и он не use-case driven ... можно ли говорить что это RUP ?
), но, на мой взгляд, его нельзя применять в разработке, т.к. этота методология недалеко ушла от водопадного метода разработки.
Автор(ы): Пер Кролл, Филипп Крачтен
?
