I>А вот с управлением проектом... Тут хуже, все сразу расплылись вилами по воде И я стал отставать... I>Можно ли проще?
Ты особо не заморачивайся на методологии. Знать и представлять о чем они конечно желательно. Но в твоем случае с 3-мя человеками надо действовать проще. Мой совет:
0. Заведите какую либо CVS + Bugtracking. Определите стандарты кодирования и правила оформления документации (например, используйте doxygen). Если есть желание то еще можно подключить unit-тестирование.
1. Определите цель. Создайте тексовый файл и в нем список, что должно быть в конечно проекте, что вы хотите получить.
2. Набросайте на бумажке архитектуру. Посидите подумайте над ней. Разойдитесь и подумайте в отдельности, соберитесь снова и еще раз обсудите. Старайтесь делать все как можно проще и не отклонятся от намеченой цели. Если вы распределены географически — используйт wiki.
3. Исходя из Цели, Набора тредуемой функциональности и получившейся архитектуры составте План ваших действий. Это может быть не только план написания кода, но и написание документации и тестирование. Пункты плана распределите между участниками. Если есть временые ограничения, то их желательно просчитать тоже на этом этапе.
4. Приступайте к разработке. Не важно как вы будете разрабатывать, но всегда следите за тем куда идете и как выполняется план. План можно менять в процессе, но меняя его всегда анализируйте к чему это приведет. Помните — ваша задача достигнуть цели.
А если сейчас попытаетесь влезть по уши в какую-либо методологию, то высока вероятность что цели своей не достигнете.
Здравствуйте, ironwit, Вы писали:
I>Ситауция такова. I>Небольшой город, хочется расти над собой, но нужен опыт работы над проектом. I>Задача\проект придуманы. 3 человека собраны I>Хотелось бы этот проект (даже если он и провалится) сделать красиво и по уму. То есть ТЗ, контроль ошибок, времени... I>Чтобы посоветовали по этому поводу? I>Типа пример ТЗ, как 3 человекам контролировать процесс разработки... I>В общем поклоняюсь гуру.
Ой, не надо за ТЗ ничего говорить . Попробуйте для начала просто сформулировать ТРЕБОВАНИЯ к вашей системе. Просто хотябы в виде списка "Система должна ...", нарисвать картинку "Ваша система и те с кем/чем она взаимодействует", и это будет более информативно, чем ТЗ . Да, создание ТЗ не относиться к управлению проектом по-большому счету.
. Может чего сгодится... I>Неплохо... Там есть упоминание о том, что не стоит выдавать на гора бумажки о том, "Что я сделал за сегодня". Почему?
Потому что такие мумажки требуются в нескольких случаях:
— когда в команде много народу и требуется общий формат контроля (и формальный процесс контроля по бумажкам уже простроен);
— когда эти "бумажки" имеют фактический вес при распределении благ (например, по ним выплачивается зарплата);
— когда нет возможности переговорить с каждым сотрудником;
— когда нет электронных средств контроля и т.п.
В общем я считаю, что такие бумажки вообще не нужны. Если нужен контроль, то желательно делать это какими-то автоматизированными средствами (например, анализом реализованных Requirements). Да и раздражают эти бумажки людей основательно. А уж в команде, где 3 человека можно всё решить словами или усилиями одного секретаря (читай — роль "администратор проекта").
Здравствуйте, ironwit, Вы писали:
I>Ситауция такова. I>Небольшой город, хочется расти над собой, но нужен опыт работы над проектом. I>Задача\проект придуманы. 3 человека собраны I>Хотелось бы этот проект (даже если он и провалится) сделать красиво и по уму. То есть ТЗ, контроль ошибок, времени... I>Чтобы посоветовали по этому поводу? I>Типа пример ТЗ, как 3 человекам контролировать процесс разработки... I>В общем поклоняюсь гуру.
Если вы начинаете новый проект или поддерживаете уже существующий, статья содержит практические советы о том, как сделать ваш проект узнаваемым, как мотивировать остальных присоединиться к вашему проекту, и как сделать так, чтобы ваш проект оставался долгожителем и активным на долгое время. Распланируйте свой opensource проект.
Ситауция такова.
Небольшой город, хочется расти над собой, но нужен опыт работы над проектом.
Задача\проект придуманы. 3 человека собраны
Хотелось бы этот проект (даже если он и провалится) сделать красиво и по уму. То есть ТЗ, контроль ошибок, времени...
Чтобы посоветовали по этому поводу?
Типа пример ТЗ, как 3 человекам контролировать процесс разработки...
В общем поклоняюсь гуру.
Здравствуйте, byur, Вы писали:
I>>Буча (или бутча) читал... Также кое что на эту тему читал. Но так толком и не понял как планировать время, как писать нормальное ТЗ, как увидеть все ньюансы будущего проекта
B>Нигде не пишут о том, как писать ТЗ. Про требования -- можно найти несколько книг на русскм. Это книга К. Вигерса, Д. Лефингвелла и А. Коберна ... Все ньюансы -- не увидишь ... все ньюансы -- это в модели дизайна или в исходном коде .
Здравствуйте, serg_mo, Вы писали:
_>Здравствуйте, speedballer, Вы писали:
S>>Это, мягко говоря, чертовски далеко от истины. Потому что парное программирование — именно ключевая практика XP. Помимо этого, в условиях георафически распределённой команды разработчиков под большим вопросом находятся и все остальные ключевые практики XP.
[SKIPPED] _>Относительно парного программирования. Я имею в виду, что эта практика не ключевая, т. к. от нее, если на то есть объективные причины, можно отказаться, не нарушая духа XP. Мы внедряли XP в команде из 3 человек, где, по понятным причинам, кому-то приходилось работать в одиночку. Работа одиночки была, в общем случае, менее эффективна, чем работа пары, но мы справлялись .
_>Кроме того, парное программирование невозможно, если работаешь над проектом один. Тем не менее, XP в одиночном проекте вполне применимо.
Как нас учит литература, есть разные "модели жизненного цикла разработки ПО". XP — одна из них. В XP парное программирование — это не только, когда два человека активно общаются между собой. Не менее важно, что один при этом не бьёт по клавишам, а контролирует второго (бьющего) и паралллельно работает головой. При этом осуществляется достаточно жёсткий контроль разработчиков друг над другом, что в совокупности даёт прирост производительности и качества.
Другие аспекты XP вроде итерационности, хитрости построения модели тестирования и т.п. присутствуют и в других моделях.
Можете рассмотреть спиральную или инкрементальную модели... Если требуется всё делать быстро и уровень владения инструментами достаточно высок, то можно использовать RAD модель. Если заказчик беспокойный и хочет как можно быстрее видеть, что будет в результате — можно использовать модель прототипирования.
ИМХО вам точно не подойдёт каскадная или V-образная модель, поскольку они несколько устарели и использоваться могут в основном в очень "консервативных" проектах.
Ещё одно. Выбор конкретной модели должен быть в первую очередь продиктован различными условиями, в которых будет выполняться проект (например, есть ли тесная связь с заказчиком, уровень технологической сложности проекта, компетентность команды, сроки и стоимость и т.п.).
На самом деле ничего сложного в выборе модели после того, как вы подумаете об условиях, в которых придётся делать проект, нет. Как правило берётся наиболее подходящая под ваши условия и адаптируется под ваш конкретный проект (лишнее, но не ключевое, убирается, что-то добавляется...). Ключевые параметры модели только убирать нельзя — модель перестаёт поддаваться управлению (анализу сроков и т.п.). Так что брать XP и убирать парное программирование — не советую.
Здравствуйте, Spidola, Вы писали:
S>Здравствуйте, Dog, Вы писали:
I>>>>Типа пример ТЗ, как 3 человекам контролировать процесс разработки... S>>>Позволю себе себя процитировать здесь
Здравствуйте, 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 вполне хорошо подходит, а подобный опыт очень важен на больших проектах.
Здравствуйте, Слава, Вы писали:
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 ?
спасибо всем выступившим... НАсчет ТЗ разобрался, буду и правда рисовать листик с пожеланиями
А вот с управлением проектом... Тут хуже, все сразу расплылись вилами по воде И я стал отставать...
Можно ли проще?
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, speedballer, Вы писали:
S>>Здравствуйте, Слава, Вы писали:
S>>Насчёт того, что в RUP много бумаги — это, собственно, либо заблуждение, либо следствие ошибок, допущенных при разработке и внедрении процесса. Есть основополагающие принципы, без которых RUP — не RUP. Но к этим принципам не относится, например, требование «документируйте каждый ваш чих».
А>О, раз пошли вопросы по RUP ... вот если на основе RUP делается свой процесс и он не use-case driven ... можно ли говорить что это RUP ?
Думаю, что нет, т.к. среди шести (кажется) принципов РУП есть:
— управление требованиями,
— моделирование на UML.
Отсюда, видимо, и UC автоматически вылазят.
Здравствуйте, ironwit, Вы писали:
I>Здравствуйте, ironwit, Вы писали:
I>спасибо всем выступившим... НАсчет ТЗ разобрался, буду и правда рисовать листик с пожеланиями I>А вот с управлением проектом... Тут хуже, все сразу расплылись вилами по воде И я стал отставать... I>Можно ли проще?
Если попытаться изучить RUP по официальной документации, то начинающему ИМХО расхочется разрабатывать IT-системы. Посоветовал бы купить книжку (тут выше что-то рекомендовали), в которой изначально проводится мысль, что всегда следует работать в рамках некоторого подмножества РУП (т.е. некоторого упрощенного варианта), но при этом следуя базовым принципам,декларируемым РУП. Все принципы не берусь точно воспроизвести, тем не менее, это: итерационность, управление на основе требований, модульная архитектура системы, использование моделирования (UML), сквозное тестирование, [забыл].
I>Чтобы посоветовали по этому поводу?
Имхо Лармана посмотреть стоит — весьма неплохо и компактно описывает rup-ообразный процесс. С управлением требованиями и прочим и прочим.
Здравствуйте, аноним, Вы писали:
> О, раз пошли вопросы по RUP ... вот если на основе RUP делается свой > процесс и он не use-case driven ... можно ли говорить что это RUP > ?
Это гипотетический вопрос, или вы считаете, что вам удалось разработать на основе RUP свой процесс, и этот процесс не use-case driven (и чем он тогда, с позволения сказать, driven)?
Теоретически, нигде не декларируется, что use case является основополагающим для RUP. Вот, например, цитата из RUP (имеется в виду продукт):
Our recommended (выделено мной — s.) method for organizing your functional requirements is using use cases.
С другой стороны:
The RUP employs a "use-case driven approach", which means that use cases defined for a system are the basis for the entire development process.
Там же приводится довольно длинный список тех ролей, которые играют юз-кейсы в различных дисциплинах и видах деятельности, подразумеваемых RUP как процессом. Из этого можно сделать вывод, что вряд ли удастся адаптировать RUP настолько, чтобы исключить из процесса use-case как таковые.
McSpace -> Re[4]: управление проектом начинающими
M> Спасибо за поддержку. А то я уж подумал, что в UML кем-то включено M> графическое представление упраления проектами и рисками...
:
При больщом желании там таки можно план-график построить
<!-- Yury Kopyl aka hrg | Только взял боец гитару, сразу — видно
гармонист -->
byur -> Re: управление проектом начинающими
b> Ой, не надо за ТЗ ничего говорить . Попробуйте для начала просто b> сформулировать ТРЕБОВАНИЯ к вашей системе. Просто хотябы в виде b> списка "Система должна ...", нарисвать картинку "Ваша система и те с b> кем/чем она взаимодействует", и это будет более информативно, чем ТЗ b> . Да, создание ТЗ не относиться к управлению проектом по-большому b> счету.
Еще проще взять шаблон Vision из RUP и писать по нему
Здравствуйте, speedballer, Вы писали:
S>Здравствуйте, аноним, Вы писали:
>> О, раз пошли вопросы по RUP ... вот если на основе RUP делается свой >> процесс и он не use-case driven ... можно ли говорить что это RUP >> ?
S>Это гипотетический вопрос, или вы считаете, что вам удалось разработать на основе RUP свой процесс, и этот процесс не use-case driven (и чем он тогда, с позволения сказать, driven)?
можно утверждать, что существует класс систем, для которых разработка UC не очень эффективна. Это например разработка фреймворков, где упор на дизайн в большей степени. В этом случае требования описываются, например, в виде иерархических списков. Каркас процесса может быть взят из RUP (роли, работы,артефакты ..). Этими требованиями и будет этот процесс driven . Why not?
S>Теоретически, нигде не декларируется, что use case является основополагающим для RUP. Вот, например, цитата из RUP (имеется в виду продукт):
S>
S>Our recommended (выделено мной — s.) method for organizing your functional requirements is using use cases.
Кстати это появилось в нем недавно ... а до этого, кажись у Кратчена мелькало про spirit of RUP .. и use-case driven
Здравствуйте, hrg, Вы писали:
hrg>byur -> Re: управление проектом начинающими
b>> Ой, не надо за ТЗ ничего говорить . Попробуйте для начала просто b>> сформулировать ТРЕБОВАНИЯ к вашей системе. Просто хотябы в виде b>> списка "Система должна ...", нарисвать картинку "Ваша система и те с b>> кем/чем она взаимодействует", и это будет более информативно, чем ТЗ b>> . Да, создание ТЗ не относиться к управлению проектом по-большому b>> счету.
hrg>Еще проще взять шаблон Vision из RUP и писать по нему
Vision, это только часть ТЗ. ТЗ это Vision + UC spec./SRS + Supplementary Spec + Test Plan (Как методика испытаний ). Например в Vision пишутся features, а это еще не требования.
Здравствуйте, byur, Вы писали:
b> можно утверждать, что существует класс систем, для которых разработка b> UC не очень эффективна. Это например разработка фреймворков, где упор b> на дизайн в большей степени. В этом случае требования описываются, b> например, в виде иерархических списков. Каркас процесса может быть b> взят из RUP (роли, работы,артефакты ..). Этими требованиями и будет b> этот процесс driven . Why not?
У меня нет совершенно никакого опыта разработки framework'ов, поэтому ни соглашаться, ни возражать не стану.
S>>
S>>Our recommended (выделено мной — s.) method for
S>>organizing your functional requirements is using use cases.
b> Кстати это появилось в нем недавно ... а до этого, кажись у b> Кратчена мелькало про spirit of RUP .. и use-case driven
Кстати, это было ещё в самом первом RUP — 1998-го года издания.
Здравствуйте, byur, Вы писали:
hrg>>Еще проще взять шаблон Vision из RUP и писать по нему
b> Vision, это только часть ТЗ. ТЗ это Vision + UC spec./SRS + b> Supplementary Spec + Test Plan (Как методика испытаний ). Например b> в Vision пишутся features, а это еще не требования.
Давайте избегать термина ТЗ, говоря о RUP, — по той простой причине, что RUP не имеет ни малейшего понятия о том, что такое ТЗ, а ГОСТ 34.602-89 не имеет ни малейшего понятия о том, что такое RUP.
Здравствуйте, speedballer, Вы писали:
b>> Кстати это появилось в нем недавно ... а до этого, кажись у b>> Кратчена мелькало про spirit of RUP .. и use-case driven
S>Кстати, это было ещё в самом первом RUP — 1998-го года издания.
Под "это", я подразумевал изменение тона с категоричного "use-case driven", на дипломатичное "recommended" ... это они вроде как после торжества XP ввели.
Здравствуйте, speedballer, Вы писали:
S>Здравствуйте, byur, Вы писали:
hrg>>>Еще проще взять шаблон Vision из RUP и писать по нему
b>> Vision, это только часть ТЗ. ТЗ это Vision + UC spec./SRS + b>> Supplementary Spec + Test Plan (Как методика испытаний ). Например b>> в Vision пишутся features, а это еще не требования.
S>Давайте избегать термина ТЗ, говоря о RUP, — по той простой причине, что RUP не имеет ни малейшего понятия о том, что такое ТЗ, а ГОСТ 34.602-89 не имеет ни малейшего понятия о том, что такое RUP.
Оно то конечно да, но ... в наших условиях они живут бок о бок, и AFAIU именно об этом хотел сказать автор, говоря о Vision ... пример: http://www.cmcons.com/gost_34_19.htm.
Вздорная статейка. Никогда, ни при каких условиях RUP не может соответствовать требованиям ГОСТ 34.601-90, и не может быть никакого соответствия между фазами RUP и стадиями указанного ГОСТ (разве только в воспалённом воображении авторов указанной статьи, по всей видимости, слышавших о RUP от знакомых в курилке) — по той простой причине, что первый подразумевает итеративный процесс, а второй — каскадный.
Здравствуйте, speedballer, Вы писали:
S>Здравствуйте, byur, Вы писали:
b>> пример: http://www.cmcons.com/gost_34_19.htm.
S>Вздорная статейка. Никогда, ни при каких условиях RUP не может соответствовать требованиям ГОСТ 34.601-90, и не может быть никакого соответствия между фазами RUP и стадиями указанного ГОСТ (разве только в воспалённом воображении авторов указанной статьи, по всей видимости, слышавших о RUP от знакомых в курилке) — по той простой причине, что первый подразумевает итеративный процесс, а второй — каскадный.
Я спрашивал об этом г. Позина, он согласился с тем, что сравнивать ПРОЦЕССЫ, которые регламентированы RUP и ГОСТ абсурд из-за их разной природы... и сказал, что они как раз ориентировались на то, что у некой конторы был процесс на базе RUP, итеративный, как они утверждают. Но заказчик требует ТЗ по ГОСТ ... отсюда и родилась эта статья. На почему они стали показывать переделанную картинку RUP о фазах и впихнули названия о стадиях -- я не понимаю ...
Здравствуйте, byur, Вы писали:
S>>Советую использовать RUP — очень настраиваемая вещь, есть хорошие книги, которые помогут понять и настроить процесс для конкретной работы. Главное не зарыться в бумажной работе, а чувствовать грань между анархией и рутиной. Наличие документации по проекту значительно облегчает разработку больших проектов, их дальнейшее сопровождение, способствует хорошей устойчивости к потерям в команде.
B>Насчет хороших книг по RUP -- не так уж их и много .
Да, их не много, но их качество (первоисточника, перевод иногда совсем убитый) очень высоко для тех, кто только начинает свое движение в этом направлении.
S>>ХР мне лично не нравится большой свободой членов команды и трудностью соблюдения принципов ХР. В результате через некоторое время команда постепенно начинает переходить к анархии. На небольшой команде может очень сильно чувствоваться потеря одного из игроков команды.
B>XP декларирует в т.ч. коллективное владение кодом ... и если использовать парное программирование, то потеря одного не должна приводить к катастрофам.
Такую схему я описывал в применении к RUP и считаю ее лучше, чем использование ХР.
... << RSDN@Home 1.1.4 beta 4 rev. 309>>
Re[8]: управление проектом начинающими :)
От:
Аноним
Дата:
10.02.05 15:48
Оценка:
B>Я спрашивал об этом г. Позина, он согласился с тем, что сравнивать ПРОЦЕССЫ, которые регламентированы RUP и ГОСТ абсурд из-за их разной природы... и сказал, что они как раз ориентировались на то, что у некой конторы был процесс на базе RUP, итеративный, как они утверждают. Но заказчик требует ТЗ по ГОСТ ... отсюда и родилась эта статья. На почему они стали показывать переделанную картинку RUP о фазах и впихнули названия о стадиях -- я не понимаю ...
У меня такое ощущение, что вы неправильно поняли ответ Позина
Жизненный цикл по РУП и по ГОСТ — это РАЗНЫЕ жизненные циклы
В статье и в ответе было сказано лишь про то, что работать можно по РУП, а ДОКУМЕНТАЦИЮ ВЫПУСКАТЬ В ФОРМАТЕ ГОСТ...
Оцените разницу!!!
Заказчику по барабану как мы работаем, он хочет видеть результат, а план работ и описание в привычном формате — формате гост.
Здравствуйте, ironwit, Вы писали:
I>Ситауция такова. I>Небольшой город, хочется расти над собой, но нужен опыт работы над проектом. I>Задача\проект придуманы. 3 человека собраны I>Хотелось бы этот проект (даже если он и провалится) сделать красиво и по уму. То есть ТЗ, контроль ошибок, времени... I>Чтобы посоветовали по этому поводу? I>Типа пример ТЗ, как 3 человекам контролировать процесс разработки... I>В общем поклоняюсь гуру.
По поводу написания сопутствующей проекту документации — логичнее использовать RUP.
Но RUP никакого отношения не имеет к управлению проектами.
Чтобы составить план трудозатрат проекта, оценить риски и спланировать бюджет существуют
специальные дисциплины и стандарты — например PMI.
Рекомендую к прочтению книгу:
Управление проектами: стандарты, методы, опыт.
2-е изд.
Авторы: Товб А. С., Ципес Г. Л.
М.: ЗАО «Олимп—Бизнес», 2005. — 240 с.: ил. ISBN 5-9693-0039-1
Здравствуйте, 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 программистов и стать миллионером ибо из ваших слов вытекает, что эта команда мне горы свернет.
Здравствуйте, 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.
А где его(это) взять?
Шурыгин Сергей
"Не следует преумножать сущности сверх необходимости" (с) Оккам
Здравствуйте, 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 Раз пусто, значит скорее всего пишу с работы. Там колонок нет
Здравствуйте, serg_mo, Вы писали:
>Особенность географически распределенной команды состоит в затрудненности общения между членами команды. Но, на мой взгляд, современные технические средства позволяют наладить уровень общения, приемлемый для применения XP. Для непосредственного общения разработчиков могу предложить IRC (его преимущество в обеспечении возможности группового общения в real-time), а для ведения журналов разработки, оформления требований и т. д. — Wiki, как электронную замену карточек.
По-моему, не правильно смешивать XP и распределенную команду. Это понятия как бы из разных опер. Можно в рамках любой методологии работать распределенно.
И позволю себе ложку дегтя в сторону Wiki. В целом Wiki вещь интересная и полезная. Но только причем здесь управление проектом? Wiki предназначена для структурирования информации вообще. А для управления проектами существуют специализированные средства, и все они, видимо, клиент-серверные. Поэтому при использовании правильных средств управления проектом и так называемая распределенная разработка ничем не будет отличается от разработки в офисе. Просто локальная сеть заменяется глобальной интернетовской.
Мы сейчас так и работаем (правда по выделенке unlimited "Стрим" в Москве): в офисе несколько серверов (программных), реализующих функции упправления требованиями, контроля версий, СУБД. И разницы никакой — что дома мы сидим, что в офисе. И соответственно методология процесса разработки произвольная может быть. У нас как бы RUP. Хотя что такое RUP? У каждого он свой.
Здравствуйте, Spidola, Вы писали:
S> Вы отдаляетесь от него. Фактически, вы пытаетесь инкапсулировать в индивидууме несколько ролей и последовательно выступаете в этих ролях. Парное программирование подразумевает размазывание роли по нескольким индивидуумам (конкретно по двум).
Да, именно так я и поступаю — выступаю последовательно в 2 ролях. И это не парное программирование. Я, фактически, не просто отдаляюсь от парного программирования, я подменяю его суррогатом, в некотором роде. А что делать, если в команде нечетное количество человек? Кто-то вынужден работать в одиночку.
И наиболее эффективный способ, до которого мы дошли, был именно в последовательном переключении ролей. Когда программист, находясь в кепке драйвера, чувствовал, что заходит в ступор, он немедленно одевал кепку навигатора. Если и в кепке навигатора он не мог из этого ступора выйти, он кричал "хелп" и вторая пара на время отвлекалась от своей задачи и бросалась к нему на помощь. Как только выход из ступора нахоодился, все продолжали работу.
Еще раз повторюсь — это _не_ парное программирование. И по эффективности такой подход, конечно, уступает парному программированию. Он требует от разработчика большей самодисциплины и внимательности. Но это — тот способ, который позволил нам минимизировать негативное влияние отсутствия полноценного парного программирования.
Не поймите меня неправильно — я не считаю парное программирование несущественной практикой. Наоборот, эта практика очень важна, поскольку она, во-первых, позволяет повысить скорость и качество работы команды, а во-вторых, обеспечивает постоянный обмен знаниями между членами команды и вообще создает благоприятный климат для коммуникации.
Почему тогда я не считаю эту практику ключевой? Большинство практик являются для XP жизненно необходимыми. Уберите планирование — разработка уйдет в хаос. Уберите рефакторинг — забудьте о простом дизайне — забудьте о коротких релизах — забудьте об обратной связи с заказчиком. Но есть ряд практик, невозможность которых можно компенсировать другими средствами. Например , заказчик в команде — если не удается получить реального заказчика себе в команду, его можно "изобрести". Аналогично, на мой взгляд, и с парным программированием. Но, естественно, отсутствие парного программирования придется компенсировать другими средствами. Альтернатива, наверное, будет менее эффективна, но все же возможно будет поддерживать постоянный прогнозируемый темп разработки и сохранить быструю реакцию на изменения требований.
В принципе, опытная сработавшаяся команда ХР может достаточно вольно обращаться с практиками.
Написал последнее предложение и надолго задумался. Результатом раздумий было то, что я изменил свое мнение относительно целесообразности применения ХР в данном конкретном случае. Несмотря на то, что я все же считаю, что распределенная команда — не помеха для использования ХР, в данном случае, думаю, что попытка его применения не пройдет. Именно потому, что потребуется адаптация "чистого ХР". Новичкам в этой методологии я бы не рекомендовал заниматься этим — очень много шансов наделать ошибок из-за осутствия опыта.
В данной ситуации, думаю, подойдет методология, уже готовая для распределенной команды.
Да и вообще, Spidola прав — выбирать процесс надо исходя из требований реальной ситуации. Это я тут бросился защищать ХР из-за заявления, что в распределенной среде ХР не применимо. Сорри, погорячился
S>>>Ключевые параметры модели только убирать нельзя — модель перестаёт поддаваться управлению (анализу сроков и т.п.). Так что брать XP и убирать парное программирование — не советую.
S>Я, конечно, не адепт XP, но насколько я читал — парное программирование суть одно из "основных правил XP"... Вот тут, например, даже схемка есть, где парное программирование визуально в центре модели изображено.
Парное программирование называют основным правилом ХР, потому что в ХР это — основной способ рабочего общения программистов. Но если вы его уберете и грамотно заполните образовавшийся пробел, модель все же останется управляемой и дух ХР не пострадает.
Кстати, приведенная картинка группирует практики по другому принципу. Внеший слой составляют практики, относящиеся к общению с заказчиком, средний — к отношениям между разработчиками в команде, и внутренний — к собственно процессу кодирования. Она не отражает взаимного влияния практик. Такая картинка приведена в книге Бека "XP Explained".
Здравствуйте, segeyros, Вы писали:
S>По-моему, не правильно смешивать XP и распределенную команду. Это понятия как бы из разных опер. Можно в рамках любой методологии работать распределенно.
Ну, все-таки ХР в своем "каноническом" виде малопригодно для распределенной разработки — упор делается на постоянную и очень тесную коммуникацию разработчиков.
S>И позволю себе ложку дегтя в сторону Wiki. В целом Wiki вещь интересная и полезная. Но только причем здесь управление проектом? Wiki предназначена для структурирования информации вообще. А для управления проектами существуют специализированные средства, и все они, видимо, клиент-серверные.
Я исходил из принципа "The simplest thing possible". Мой коллега в своей команде применял Wiki для координации разработчиков и заказчика, и я имел аналогичный опыт. И мне, и ему Wiki хватало за глаза, работать с ней было просто и удобно. Да и обмен информацией получался менее формальный.
S>Мы сейчас так и работаем (правда по выделенке unlimited "Стрим" в Москве): в офисе несколько серверов (программных), реализующих функции упправления требованиями, контроля версий, СУБД. И разницы никакой — что дома мы сидим, что в офисе. И соответственно методология процесса разработки произвольная может быть. У нас как бы RUP. Хотя что такое RUP? У каждого он свой.
Тогда посоветуй ребятам (см. начальный пост). Возможно, это то, что им нужно.
. Может чего сгодится... I>>Неплохо... Там есть упоминание о том, что не стоит выдавать на гора бумажки о том, "Что я сделал за сегодня". Почему?
S>В общем я считаю, что такие бумажки вообще не нужны. Если нужен контроль, то желательно делать это какими-то автоматизированными средствами (например, анализом реализованных Requirements). Да и раздражают эти бумажки людей основательно. А уж в команде, где 3 человека можно всё решить словами или усилиями одного секретаря (читай — роль "администратор проекта").
Ясно, спасибо. В этом полностью с тобой согласен
... << RSDN@Home 1.1.4 beta 4 Раз пусто, значит скорее всего пишу с работы. Там колонок нет
Тут хуже, все сразу расплылись вилами по воде 
Автор(ы): Алистер Коберн
Издательство: 
Автор(ы): Пер Кролл, Филипп Крачтен
