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

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

D>>>>ИМХО, все зависит от проекта. Но диаграмма классов еще никому не помешала А архитектура чем подробней сначала тем лучше. Другое дело, что в реальной жизни приходится параллелить процессы выяснения требований, создания архитектуры и первого прототипа.

S>>>И что, получается параллельно?
S>>>У нас было в планах один сервис и exe. теперь 2 сервиса и 5 exe-шников. И требования при этом не менялись. Такие решения были в ходе разработки архитекруты.
D>>Получается не всегда так красиво, как хотелось бы. Вы о каком проекте говорите про изменение количества сервисов и exe? Про текущий который планируете? Если так, то изменение количества модулей в процессе проработки архитектуры (а не разработки) это нормально.

S>Да, в том, о котором я спрашивал. Хотя я уже не там . Поэтому сейчас мне просто интересно.
S>Мы не начинали делать проект до утверждения диаграммы бинарных компонентов. Все было на уровне тестовых проектиков для тестирования RPC и т.п.

S>>>Насчет диаграммы классов — имеется ввиду все классы внутри программы или только интерфейсные?
D>>Укрупненно сделать все, а в детали вдаваться по мере необходимости (возникновения сложностей понимания задачи у разработчиков).

S>Укрупненно, это:
S>класс А — для отправки запросов в интернет.
S>Или класс А имеет такие публичные методы: ...
S>такие приватные методы: ...
S>и т.п.

S>?

То что Вы описали нужно делать все и итеративно. Т.е. сначала граф классов с их названиями и описанием в максимум 10 слов. Затем уже объявить у них методы.

S>К тому же в процессе появляется куча мелких классов. Ну там.. класс-хелпер, который, к примеру, возвращает текущую директорию для временных файлов и т.п.

Так в этом то и смысл проектирования, чтобы итеративно продумать все до мельчайших подробностей. Но чтобы не потерять общией смысл проекта/продукта нужно стараться не перескакивать через промежуточные шаги, типа диаграмм модулей и классов.

S>Лично я, когда сам писал проекты, так никогда не пробовал. т.е. перед написанием кода были абстрактные компоненты без интерфейсов, которые что-то конкретное будут делать.
S>Потом это детализировалось по мере написания. Но это когда один разработчик..

Когда один разработчик, или даже 2, это простительно. Но когда людей становится больше, а еще и ротация происходит, то без документации никак.

D>>Можно четко спланировать первый спринт, Вам что-то мешает это сделать?

S>Сейчас уже не актуально, спасибо за то, что отозвались..
S>Изначалоно вопрос состоял именно в стратегии. Перед планированием спринта, я себе представляю, нужно иметь представления о процессе + некоторые сроки и т.п. подробности.

Все зависит от того, что от Вас требуют заказчик. Как строго Вы зажаты сроками и/или бюджетами. От этого зависит то как четко Вам нужно осознавать то или иное перед началом спринта и насколько простительны Вам будут промахи в оценках/планах/сроках.

S>т.е. иметь первое приближение и возможность ответить на вопрос — нужна ли диаграмма классов и т.п.