Поделитесь пожалуйста, что вы делаете в период между тем, когда закончились все исследования, сформированы требования, нарисован дизайн и собственно написанием кода.
Диаграммы классов, компонентов, прецедентов и т.п. К чему вы приходите перед тем, как все сядут за написание кода? Какова подробность архитектуры на этот момент?
Команда из 3-х человек. Проект — небольшой десктоп с#/c++.
Здравствуйте, sidorov18, Вы писали:
S>Поделитесь пожалуйста, что вы делаете в период между тем, когда закончились все исследования, сформированы требования, нарисован дизайн и собственно написанием кода.
Вы почему-то предполагаете, что такой момент в принципе есть.
На самом деле, это существует только в случае "чистой" модели "водопада" (waterfall), что сейчас почти нереально.
(Сейчас Вам вывалят целую кучу ссылок о том, что такое agile development, почему оно такое, чем хорошо, какие варианты его есть и почему.)
В более современных подходах уже до "завершения всех исследований" обычно есть какая-то часть кода с прототипами, пусть даже на других языках и средствах, и уже представления о том, что надо будет переделать после первой рабочей версии.
S>Диаграммы классов, компонентов, прецедентов и т.п. К чему вы приходите перед тем, как все сядут за написание кода? Какова подробность архитектуры на этот момент?
Иногда её вообще нет, иногда выписана до мелких деталей. Каждый раз по-разному.
The God is real, unless declared integer.
Re[2]: Что нужно для проекта перед написанием кода
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, sidorov18, Вы писали:
S>>Поделитесь пожалуйста, что вы делаете в период между тем, когда закончились все исследования, сформированы требования, нарисован дизайн и собственно написанием кода.
N>Вы почему-то предполагаете, что такой момент в принципе есть.
Выражусь яснее.
Есть несколько программистов и им нужно сесть за один модуль(исполняемый файл) и начать его писать.
Стоит ли создавать интерфейсы, диаграмму классов заранее, или это разруливается по ходу. У меня нет опыта развертывания проекта в таких условиях.
N>На самом деле, это существует только в случае "чистой" модели "водопада" (waterfall), что сейчас почти нереально. N>(Сейчас Вам вывалят целую кучу ссылок о том, что такое agile development, почему оно такое, чем хорошо, какие варианты его есть и почему.)
Со Scrum/Agile знаком, но в "первом приближении".
т.е. сам участвовал, как разработчик, в паре проектов, где использовался Scrum. Хотя у каждого руководителя был немного "авторский" подход.
Кто-то не делал daily meeting, кто-то позволял добавлять тикеты в середиту спринта и т.п.
Сам сейчас что-то подобное использую. В целом — на этапе устаканивания и ознакомления с ролью ПМ.
Если хорошие ссылки есть(которых нет в первых результатах гугла) — кидайте.
N>В более современных подходах уже до "завершения всех исследований" обычно есть какая-то часть кода с прототипами, пусть даже на других языках и средствах, и уже представления о том, что надо будет переделать после первой рабочей версии.
Код есть только в тестовых проектах, нацеленных протестировать конкретный функционал ОС. Из разряда "Можно ли перехватывать диалоговые окна Windows Installer во время установки".
N>Иногда её вообще нет, иногда выписана до мелких деталей. Каждый раз по-разному.
А развернутей напишите пожалуйста. Ну пару примеров — случай, где использовали, а где нет.
Здравствуйте, sidorov18, Вы писали:
S>Поделитесь пожалуйста, что вы делаете в период между тем, когда закончились все исследования, сформированы требования, нарисован дизайн и собственно написанием кода.
S>Диаграммы классов, компонентов, прецедентов и т.п. К чему вы приходите перед тем, как все сядут за написание кода? Какова подробность архитектуры на этот момент?
S>Команда из 3-х человек. Проект — небольшой десктоп с#/c++.
ИМХО, все зависит от проекта. Но диаграмма классов еще никому не помешала А архитектура чем подробней сначала тем лучше. Другое дело, что в реальной жизни приходится параллелить процессы выяснения требований, создания архитектуры и первого прототипа.
А вообще, если сформированы все требования, то я бы предложил Вам засесть за
1. декомпозицию задач (чем мельче задача, тем лучше, но не короче 4х часов)
2. оценку этих задач
3. составление четкого плана с вехами, майлстоунами и дедлайнами.
во время работы над пунктом 1 станет ясно где какие диаграммы нужны и глубину проработки архитектуры.
Re[2]: Что нужно для проекта перед написанием кода
Здравствуйте, dertotejunge, Вы писали:
D>Здравствуйте, sidorov18, Вы писали:
S>>Поделитесь пожалуйста, что вы делаете в период между тем, когда закончились все исследования, сформированы требования, нарисован дизайн и собственно написанием кода.
S>>Диаграммы классов, компонентов, прецедентов и т.п. К чему вы приходите перед тем, как все сядут за написание кода? Какова подробность архитектуры на этот момент?
S>>Команда из 3-х человек. Проект — небольшой десктоп с#/c++.
D>ИМХО, все зависит от проекта. Но диаграмма классов еще никому не помешала А архитектура чем подробней сначала тем лучше. Другое дело, что в реальной жизни приходится параллелить процессы выяснения требований, создания архитектуры и первого прототипа.
И что, получается параллельно?
У нас было в планах один сервис и exe. теперь 2 сервиса и 5 exe-шников. И требования при этом не менялись. Такие решения были в ходе разработки архитекруты.
Насчет диаграммы классов — имеется ввиду все классы внутри программы или только интерфейсные?
D>А вообще, если сформированы все требования, то я бы предложил Вам засесть за D>1. декомпозицию задач (чем мельче задача, тем лучше, но не короче 4х часов)
Это же, фактически, планирование спринта, так?
Обычно это делается перед спринтом.
Или вы предлагаете сначала сделать вот такое планирование, а потом уже планировать вехи?
D>2. оценку этих задач D>3. составление четкого плана с вехами, майлстоунами и дедлайнами.
D>во время работы над пунктом 1 станет ясно где какие диаграммы нужны и глубину проработки архитектуры.
Здравствуйте, sidorov18, Вы писали:
S>Поделитесь пожалуйста, что вы делаете в период между тем, когда закончились все исследования, сформированы требования, нарисован дизайн и собственно написанием кода.
S>Диаграммы классов, компонентов, прецедентов и т.п. К чему вы приходите перед тем, как все сядут за написание кода? Какова подробность архитектуры на этот момент?
S>Команда из 3-х человек. Проект — небольшой десктоп с#/c++.
Для начала Вам нужно:
1. Декомпозиция задач
2. Оценки задач
3. План работ.
Re[3]: Что нужно для проекта перед написанием кода
Здравствуйте, sidorov18, Вы писали:
S>Здравствуйте, dertotejunge, Вы писали:
D>>Здравствуйте, sidorov18, Вы писали:
S>>>Поделитесь пожалуйста, что вы делаете в период между тем, когда закончились все исследования, сформированы требования, нарисован дизайн и собственно написанием кода.
S>>>Диаграммы классов, компонентов, прецедентов и т.п. К чему вы приходите перед тем, как все сядут за написание кода? Какова подробность архитектуры на этот момент?
S>>>Команда из 3-х человек. Проект — небольшой десктоп с#/c++.
D>>ИМХО, все зависит от проекта. Но диаграмма классов еще никому не помешала А архитектура чем подробней сначала тем лучше. Другое дело, что в реальной жизни приходится параллелить процессы выяснения требований, создания архитектуры и первого прототипа.
S>И что, получается параллельно? S>У нас было в планах один сервис и exe. теперь 2 сервиса и 5 exe-шников. И требования при этом не менялись. Такие решения были в ходе разработки архитекруты.
Получается не всегда так красиво, как хотелось бы. Вы о каком проекте говорите про изменение количества сервисов и exe? Про текущий который планируете? Если так, то изменение количества модулей в процессе проработки архитектуры (а не разработки) это нормально.
S>Насчет диаграммы классов — имеется ввиду все классы внутри программы или только интерфейсные?
Укрупненно сделать все, а в детали вдаваться по мере необходимости (возникновения сложностей понимания задачи у разработчиков).
D>>А вообще, если сформированы все требования, то я бы предложил Вам засесть за D>>1. декомпозицию задач (чем мельче задача, тем лучше, но не короче 4х часов)
S>Это же, фактически, планирование спринта, так? S>Обычно это делается перед спринтом. S>Или вы предлагаете сначала сделать вот такое планирование, а потом уже планировать вехи?
D>>2. оценку этих задач D>>3. составление четкого плана с вехами, майлстоунами и дедлайнами.
D>>во время работы над пунктом 1 станет ясно где какие диаграммы нужны и глубину проработки архитектуры.
Можно четко спланировать первый спринт, Вам что-то мешает это сделать?
Так же можно долгосрочные планы составить, на некоторое обозримое будущее.
И еще можно задуматься о рисках, например Об этом конечно больше говорят, чем делают. Но как показывает практика, если их все-таки осознать, определить и заранее донести до руководства/инвесторов, то потом в случае их возникновения будет не так тяжело доказать "что ты не верблюд".
Re[4]: Что нужно для проекта перед написанием кода
Здравствуйте, dertotejunge, Вы писали:
D>>>ИМХО, все зависит от проекта. Но диаграмма классов еще никому не помешала А архитектура чем подробней сначала тем лучше. Другое дело, что в реальной жизни приходится параллелить процессы выяснения требований, создания архитектуры и первого прототипа.
S>>И что, получается параллельно? S>>У нас было в планах один сервис и exe. теперь 2 сервиса и 5 exe-шников. И требования при этом не менялись. Такие решения были в ходе разработки архитекруты. D>Получается не всегда так красиво, как хотелось бы. Вы о каком проекте говорите про изменение количества сервисов и exe? Про текущий который планируете? Если так, то изменение количества модулей в процессе проработки архитектуры (а не разработки) это нормально.
Да, в том, о котором я спрашивал. Хотя я уже не там . Поэтому сейчас мне просто интересно.
Мы не начинали делать проект до утверждения диаграммы бинарных компонентов. Все было на уровне тестовых проектиков для тестирования RPC и т.п.
S>>Насчет диаграммы классов — имеется ввиду все классы внутри программы или только интерфейсные? D>Укрупненно сделать все, а в детали вдаваться по мере необходимости (возникновения сложностей понимания задачи у разработчиков).
Укрупненно, это:
класс А — для отправки запросов в интернет.
Или класс А имеет такие публичные методы: ...
такие приватные методы: ...
и т.п.
?
К тому же в процессе появляется куча мелких классов. Ну там.. класс-хелпер, который, к примеру, возвращает текущую директорию для временных файлов и т.п.
Лично я, когда сам писал проекты, так никогда не пробовал. т.е. перед написанием кода были абстрактные компоненты без интерфейсов, которые что-то конкретное будут делать.
Потом это детализировалось по мере написания. Но это когда один разработчик..
D>Можно четко спланировать первый спринт, Вам что-то мешает это сделать?
Сейчас уже не актуально, спасибо за то, что отозвались..
Изначалоно вопрос состоял именно в стратегии. Перед планированием спринта, я себе представляю, нужно иметь представления о процессе + некоторые сроки и т.п. подробности.
т.е. иметь первое приближение и возможность ответить на вопрос — нужна ли диаграмма классов и т.п.
Здравствуйте, sidorov18, Вы писали:
S>Поделитесь пожалуйста, что вы делаете в период между тем, когда закончились все исследования, сформированы требования, нарисован дизайн и собственно написанием кода.
Беру требования и прореживаю их, чтобы получить так называемую "минимально работающую программу" (когда многих фич нету, но юзеры уже могут извлекать пользу из проги)-- кошу все требования без которых можно обойтись.
Делаю эту версию. Показываю заказчику. Принимаю замечания, переделываю.
Когда сделана минимальная версия у меня и у заказчика уже есть понимания что же конкретно нужно ему (в принципе ради этого и делается минимальная версия)
Далее наращиваем функционал фича за фичей.
Где-то так.
СУВ, Aikin
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[5]: Что нужно для проекта перед написанием кода
Здравствуйте, 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>т.е. иметь первое приближение и возможность ответить на вопрос — нужна ли диаграмма классов и т.п.
Здравствуйте, sidorov18, Вы писали:
S>Поделитесь пожалуйста, что вы делаете в период между тем, когда закончились все исследования,
может мы вкладываем разные понятия, но у нас исследования всегда идут паралельно, если релиз не горит. S>сформированы требования, нарисован дизайн и собственно написанием кода.
требования как и дизайн имеют обыкновения менятся, причем требования практически всегда "в худшую сторону". S>Диаграммы классов, компонентов, прецедентов и т.п. К чему вы приходите перед тем, как все сядут за написание кода? Какова подробность архитектуры на этот момент?
Самое интересное, что в текущем проекте удалось пронаблюдать различные способы разработки.
Кратко — было два лагеря "теоретиков" и "практиков".
Первые, хотели все вначале разработать и описать на бумаге. Вторые пропагандировали так называемое "спиральное нисходящее программирование". (технология структурного программирования) То бишь когда движемся от простого к сложному и на каждом витке спирали имеется "рабочая" программа. Все перепитии "борьбы" описывать не имеет смысла. Важен результат.
Первые обклеили все шкафы и стенки диаграммами и графиками, но не имели ничего готового. Вторые имели пару листиков с диаграммами (и то, сделали их чисто для объяснения первой группе) и программу которая что то делала. Через какое то время деятельность первой группы была официально запрещена и в работу пошла версия второй группы.
S>Команда из 3-х человек. Проект — небольшой десктоп с#/c++.
Несколько маловато людей. Но вначале нужен разработчик архитектуры и желательно оппонент. По крайней мере, один человек должен четко "видеть" все программу, он же должен четко определять "путь разработки", любое отклонение от пути должно обязательно с ним согласовываться и обсуждаться. Он же пишет "скелет", на который команда добавляет "мясо".
Полностью поддерживаю ваших "практиков". Именно так и нужно делать, ИМО.
S>>Команда из 3-х человек. Проект — небольшой десктоп с#/c++. AN>Несколько маловато людей.
Это не людей маловато, а проект небольшой. Судя по всему меншьше чем те с которыми ты привык работать.
AN>Но вначале нужен разработчик архитектуры и желательно оппонент.
Нужны. Набросок архитектуры тоже нужен. AN>По крайней мере, один человек должен четко "видеть" все программу, он же должен четко определять "путь разработки", любое отклонение от пути должно обязательно с ним согласовываться и обсуждаться. Он же пишет "скелет", на который команда добавляет "мясо".
А вот это для такой маленькой команды не обязательно. Люди, скорее всего, будут сидеть в одной комнате и всегда смогут договориться. А раз проект маленький, то и косяки любо достаточно просто исправить или достаточно быстро обнаружить.
ЗЫ Если чё, то именно на таких небольших проектах (2-4 человека) я последние 2-3 года и работаю.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[6]: Что нужно для проекта перед написанием кода
Здравствуйте, dertotejunge, Вы писали:
S>>Укрупненно, это: S>>класс А — для отправки запросов в интернет. S>>Или класс А имеет такие публичные методы: ... S>>такие приватные методы: ... S>>и т.п.
S>>?
D>То что Вы описали нужно делать все и итеративно. Т.е. сначала граф классов с их названиями и описанием в максимум 10 слов. Затем уже объявить у них методы.
Ну а сама разработка начинается уже во время этого приближения? Или вы имеете ввиду сначала построить все диаграммы в мелочах, а потом садится за имплементацию?
Re[7]: Что нужно для проекта перед написанием кода
Здравствуйте, sidorov18, Вы писали:
S>Здравствуйте, dertotejunge, Вы писали:
S>>>Укрупненно, это: S>>>класс А — для отправки запросов в интернет. S>>>Или класс А имеет такие публичные методы: ... S>>>такие приватные методы: ... S>>>и т.п.
S>>>?
D>>То что Вы описали нужно делать все и итеративно. Т.е. сначала граф классов с их названиями и описанием в максимум 10 слов. Затем уже объявить у них методы.
S>Ну а сама разработка начинается уже во время этого приближения? Или вы имеете ввиду сначала построить все диаграммы в мелочах, а потом садится за имплементацию?
В идеале, то потом. В реале обычно это параллелится. На самом деле, насколько доверяете разработчикам. Опытным можно дать классы без интерфейсов, они сами договорятся. Если новички, то чем детальнее будет все проработано вплоть до типов полей в БД, тем лучше.
Re[2]: Что нужно для проекта перед написанием кода
С учетом, того что это форум по управлению проектами.
Главное, что нужно сделать до написания кода это согласовать требования и архитектуру системы с заказчиком.
Избавляет от кучи лишней работы.
Re[3]: Что нужно для проекта перед написанием кода
Здравствуйте, Aikin, Вы писали:
A>Здравствуйте, AlexNek, Вы писали:
A>Полностью поддерживаю ваших "практиков". Именно так и нужно делать, ИМО.
S>>>Команда из 3-х человек. Проект — небольшой десктоп с#/c++. AN>>Несколько маловато людей. A>Это не людей маловато, а проект небольшой. Судя по всему меншьше чем те с которыми ты привык работать.
возможно, "маленькие проекты" я просто делаю сам. AN>>Но вначале нужен разработчик архитектуры и желательно оппонент. A>Нужны. A>Набросок архитектуры тоже нужен.
Это зависит от многих факторов. Например, мы сейчас "ждем" завершение этапа другой команды.
Так занялся одной вспомогательной прогой. Кроме того что она МДИ и с риббоном, больше я ничего не знаю, даже то что она в конце концов будет делать кроме нужного функционала.
AN>>По крайней мере, один человек должен четко "видеть" все программу, он же должен четко определять "путь разработки", любое отклонение от пути должно обязательно с ним согласовываться и обсуждаться. Он же пишет "скелет", на который команда добавляет "мясо". A>А вот это для такой маленькой команды не обязательно. Люди, скорее всего, будут сидеть в одной комнате и всегда смогут договориться. А раз проект маленький, то и косяки любо достаточно просто исправить или достаточно быстро обнаружить.
Мне кажется, это заблуждение. Не всегда все просто исправить и быстро обнаружить, особенно если нет "системы тестирования", а в малой команде ее часто нет. Пару лет назад мы вот тоже втроем немного работали: один отвечал за базу, второй все остальное, третий только тестировал. Одну часть пришлось переписать, после недели борьбы. Одну ошибку нашли случайно решив подшутить над коллегой.
Здравствуйте, itarchitect.ru, Вы писали:
IR>С учетом, того что это форум по управлению проектами. IR>Главное, что нужно сделать до написания кода это согласовать требования и архитектуру системы с заказчиком. IR>Избавляет от кучи лишней работы.
помогает в основном при "качании прав" и "отмазок".
Обычно получается так
Еще не видел ни одного помещения разработчиков без подобной картинки
D>В идеале, то потом. В реале обычно это параллелится. На самом деле, насколько доверяете разработчикам.
Золотые слова.
D>Опытным можно дать классы без интерфейсов, они сами договорятся.
Лучше наоборот — дать только интерфейсы, а уж в процессе пользования оных уже и возникнет понимание, чего не хватает. Так проще создавать loosely coupled systems, ну а тестировать такие системы намного проще и удобнее.
Re[4]: Что нужно для проекта перед написанием кода
Здравствуйте, AlexNek, Вы писали:
AN>Здравствуйте, itarchitect.ru, Вы писали:
IR>>С учетом, того что это форум по управлению проектами. IR>>Главное, что нужно сделать до написания кода это согласовать требования и архитектуру системы с заказчиком. IR>>Избавляет от кучи лишней работы. AN>помогает в основном при "качании прав" и "отмазок". AN>Обычно получается так AN>Еще не видел ни одного помещения разработчиков без подобной картинки
Согласование помогает заставить людей прочитать документацию проекта. Затем они выдадут свои замечания к вашему решению. Это именно то, что вам нужно.
Есть система, которая существует в голове разработчиков, а есть система, которая существуют в голове заказчика. Если нормально организовать согласование документов, то возникает диалог между разработчиками и заказчиками, который позволяет сблизить их понимание.
Ещё очень помогает показ работающих прототипов заказчику.
В методологии внедрения Oracle есть демонстрация минимум двух прототипов заказчику до начала первого тестирования.
Сначала показывают вертикальное решение для данного типа Заказчика. Собирают обратную связь.
Затем показывают докрученное решение и опять собирают обратную связь.
Согласование документов и показ прототипов дает очень хороший результат.
