Здравствуйте, AlexNek, Вы писали:

AN>>>По крайней мере, один человек должен четко "видеть" все программу, он же должен четко определять "путь разработки", любое отклонение от пути должно обязательно с ним согласовываться и обсуждаться. Он же пишет "скелет", на который команда добавляет "мясо".
A>>А вот это для такой маленькой команды не обязательно. Люди, скорее всего, будут сидеть в одной комнате и всегда смогут договориться. А раз проект маленький, то и косяки любо достаточно просто исправить или достаточно быстро обнаружить.
AN>Мне кажется, это заблуждение. Не всегда все просто исправить и быстро обнаружить, особенно если нет "системы тестирования", а в малой команде ее часто нет. Пару лет назад мы вот тоже втроем немного работали: один отвечал за базу, второй все остальное, третий только тестировал. Одну часть пришлось переписать, после недели борьбы. Одну ошибку нашли случайно решив подшутить над коллегой.
Я говорю исходя из своего опыта. Всегда удавалось договориться. Косяки удавалось увидеть в течении недели (чаще 1-2 дня). Крупных косяков дошедшик до заказчика, тьффу-тьфу, не было. Мелкие да, были. Крупных нет.

СУВ, Aikin

Здравствуйте, itarchitect.ru, Вы писали:

IR>Здравствуйте, AlexNek, Вы писали:

AN>>Здравствуйте, itarchitect.ru, Вы писали:

IR>>>С учетом, того что это форум по управлению проектами.
IR>>>Главное, что нужно сделать до написания кода это согласовать требования и архитектуру системы с заказчиком.
IR>>>Избавляет от кучи лишней работы.
AN>>помогает в основном при "качании прав" и "отмазок".
AN>>Обычно получается так
AN>>Еще не видел ни одного помещения разработчиков без подобной картинки

IR>Согласование помогает заставить людей прочитать документацию проекта. Затем они выдадут свои замечания к вашему решению. Это именно то, что вам нужно.
IR>Есть система, которая существует в голове разработчиков, а есть система, которая существуют в голове заказчика. Если нормально организовать согласование документов, то возникает диалог между разработчиками и заказчиками, который позволяет сблизить их понимание.
Позволяет, но вот на сколько процентов я не возьмусь оценить.

IR>Ещё очень помогает показ работающих прототипов заказчику.
IR>В методологии внедрения Oracle есть демонстрация минимум двух прототипов заказчику до начала первого тестирования.
IR>Сначала показывают вертикальное решение для данного типа Заказчика. Собирают обратную связь.
IR>Затем показывают докрученное решение и опять собирают обратную связь.
Это уже гораздо теплее, во многих случаях очень здорово помогает.

IR>Согласование документов и показ прототипов дает очень хороший результат.
Но к сожалению бывают и исключения. Вот еще свежий пример: все согласовали, все показали, все утвердили. Уже осталось только вылизать приложение, как вдруг тестер получает несколько наборов параметров которые все правильные в наборе, но эти наборы не должны существовать вместе. То есть подход который хотелось иметь оказался неправильным в принципе. Хотя вообще то это пока первая и единственная встретившаяся ситуация.

Здравствуйте, Aikin, Вы писали:

A>Здравствуйте, AlexNek, Вы писали:

AN>>>>По крайней мере, один человек должен четко "видеть" все программу, он же должен четко определять "путь разработки", любое отклонение от пути должно обязательно с ним согласовываться и обсуждаться. Он же пишет "скелет", на который команда добавляет "мясо".
A>>>А вот это для такой маленькой команды не обязательно. Люди, скорее всего, будут сидеть в одной комнате и всегда смогут договориться. А раз проект маленький, то и косяки любо достаточно просто исправить или достаточно быстро обнаружить.
AN>>Мне кажется, это заблуждение. Не всегда все просто исправить и быстро обнаружить, особенно если нет "системы тестирования", а в малой команде ее часто нет. Пару лет назад мы вот тоже втроем немного работали: один отвечал за базу, второй все остальное, третий только тестировал. Одну часть пришлось переписать, после недели борьбы. Одну ошибку нашли случайно решив подшутить над коллегой.
A>Я говорю исходя из своего опыта. Всегда удавалось договориться. Косяки удавалось увидеть в течении недели (чаще 1-2 дня). Крупных косяков дошедшик до заказчика, тьффу-тьфу, не было. Мелкие да, были. Крупных нет.
Все бывает, если приходить на море всегда днем, там полно людей и вода достаточно теплая. Но стоит прийти ночью и ситуация немного меняется. Бывает берешь уже отлаженный и протестированный кусок в абсолютно другой проект и тут может таакое открытся. Еще могут подлянку подкинуть мелкие баги найденные в конце тестирования. После их исправления часто все не проверяется по новому.

Здравствуйте, AlexNek, Вы писали:

IR>>Согласование документов и показ прототипов дает очень хороший результат.
AN>Но к сожалению бывают и исключения. Вот еще свежий пример: все согласовали, все показали, все утвердили. Уже осталось только вылизать приложение, как вдруг тестер получает несколько наборов параметров которые все правильные в наборе, но эти наборы не должны существовать вместе. То есть подход который хотелось иметь оказался неправильным в принципе. Хотя вообще то это пока первая и единственная встретившаяся ситуация.

Абсолютно нормальная ситуация.
Есть такая штука как управление изменениями в проекте. Никто и никогда не сможет создать информационную систему, удовлетворяющую всем требованиям, в рамках одного проекта.

Почему?

Потому, что требования всегда меняются, аппетит приходит во время еды. Основная задача руководителя проекта — управлять содержанием проекта. Все остальное производные от содержания проекта.
"Мы ведь оба понимаем, что это изменение скоупа проекта. Мы подготовим ТКП в течение недели"
"Надо не забыть включить это в следующую версию системы. Мы как раз готовим ТКП"

Наболело
---------------------------
Андрей
www.itarchitect.ru