Проблема:
Читаю топики и уж больно они оторваны от конкретики. Каждый приводит агрументы под свои требования — у кого-то система сложная и он rich domain model использует, у кого-то попроще и он счастлив с anеmic, другие вообще под хостинг решения пишут, в то время как у тертьих — statfull клиентов сотни и свои сервера в кластерах и т.д. без конца и края. Решение:
Предлагаю написать 1-2 типовых ТЗ и реализовать их в нескольких архитектурных подходах на нескольких инструментах. Вот типовые, на мой взгляд:
1. Тонкие клиенты (WebForms или WinForms).
2. Толстые клиенты (WinForms или WPF).
В обоих вариантах сделать наличие БД и:
— несколько длинных сценариев,
— несколько коротких сценариев,
— несколько ролей,
— несколько отчетов.
Ничего сложного, но с наличием ключевых вещей.
Предметную область выбрать понятную, типа магазина или еще чего-нибудь типичного для enterprise. Возражения:
Конечно, многие скажут, что время у них на это нет — однако время на флуд у них предостаточно
Или что они слишком круты, чтобы кому-то что-то доказывать, однако в этом случае их крутость ничего не стоит.
Некоторые не захотят "палить" свои наработки, но очевидно, что очень не многие (и весьма достойные) будут разбираться досконально и перенимать ваши подходы, зато найдется множество критиков, благодаря которым вы сможете получить интересные идеи. Результаты:
Думаю, что даже если требования будут обсуждаться и писаться несколько месяцев, а потом реализовываться на разных подходах и инструметых еще несколько месяцев, то в итоге через год, да хоть и полтора мы будем иметь очень хорошую основу для обсуждений, вместо того, чтобы флудить на форуме, плюс изъясняться станет на много проще на конкретных примерах. К тому же, даже если дальше обсуждения требований не пойдет — все равно требования обсуждать на много полезнее, чем абстрактные решения.
У самого времени не много, однако с использованием системы таск-трекинга можно будет не спеша работать в свободное время по желанию.
Здравствуйте, Ocenochka, Вы писали:
O>Проблема: O> Читаю топики и уж больно они оторваны от конкретики. Каждый приводит агрументы под свои требования — у кого-то система сложная и он rich domain model использует, у кого-то попроще и он счастлив с anеmic, другие вообще под хостинг решения пишут, в то время как у тертьих — statfull клиентов сотни и свои сервера в кластерах и т.д. без конца и края.
А в чем собственно проблема?
O> Решение: O> Предлагаю написать 1-2 типовых ТЗ и реализовать их в нескольких архитектурных подходах на нескольких инструментах. Вот типовые, на мой взгляд: O> 1. Тонкие клиенты (WebForms или WinForms). O> 2. Толстые клиенты (WinForms или WPF). O> В обоих вариантах сделать наличие БД и: O> — несколько длинных сценариев, O> — несколько коротких сценариев, O> — несколько ролей, O> — несколько отчетов. O> Ничего сложного, но с наличием ключевых вещей. O> Предметную область выбрать понятную, типа магазина или еще чего-нибудь типичного для enterprise.
Можешь начинать писать ТЗ, будет интересно. Главное чтобы было сложнее CRUD на 4 таблички (для решения такого даже кода писать не придется).
O> Возражения: O> Конечно, многие скажут, что время у них на это нет — однако время на флуд у них предостаточно
Флуд на форуме позволяет концентрироватся на ключевых вещах, разработка приложения неизбежно погружает тебя в детали.
O> Результаты: O> Думаю, что даже если требования будут обсуждаться и писаться несколько месяцев, а потом реализовываться на разных подходах и инструметых еще несколько месяцев, то в итоге через год, да хоть и полтора мы будем иметь очень хорошую основу для обсуждений, вместо того, чтобы флудить на форуме, плюс изъясняться станет на много проще на конкретных примерах. К тому же, даже если дальше обсуждения требований не пойдет — все равно требования обсуждать на много полезнее, чем абстрактные решения.
Флаг тебе в руки — начинай.
O> У самого времени не много, однако с использованием системы таск-трекинга можно будет не спеша работать в свободное время по желанию.
Можно захоститься на гуглокоде, сделать несолько веток под разные решения.
ЗЫ. Я считаю что выклдаывать на всеобщее обозрение стоит только тот код, качество которого отличается от идеального на бесконечно малую величину.
Здравствуйте, gandjustas, Вы писали:
G>ЗЫ. Я считаю что выклдаывать на всеобщее обозрение стоит только тот код, качество которого отличается от идеального на бесконечно малую величину.
Зачем? Главное чтобы код был в целом хорошим и показательным.
Здравствуйте, gandjustas, Вы писали:
G>ЗЫ. Я считаю что выклдаывать на всеобщее обозрение стоит только тот код, качество которого отличается от идеального на бесконечно малую величину.
Идей хорошая, но бесполезная, нужен PM. Исполнители скорее всего найдутся, PM нет. Предлагаю начать его поиски в теме управление проектами, может им там тоже нужен показательный процесс?
Здравствуйте, gandjustas, Вы писали:
G>А в чем собственно проблема?
То, что для вас проблем не существует я уже заметил
G>Можешь начинать писать ТЗ, будет интересно. Главное чтобы было сложнее CRUD на 4 таблички (для решения такого даже кода писать не придется).
"Можешь начинать" игнорировать мои посты
O>> Возражения: O>> Конечно, многие скажут, что время у них на это нет — однако время на флуд у них предостаточно G>Флуд на форуме позволяет концентрироватся на ключевых вещах, разработка приложения неизбежно погружает тебя в детали.
Без деталей — одно словоблудство, которое у некоторых неплохо получается, однако к реальности имеет весьма опосредованое отношение.
G>Флаг тебе в руки — начинай.
"Флаг тебе в руки" — начинай игнорировать мои посты и темы.
O>> У самого времени не много, однако с использованием системы таск-трекинга можно будет не спеша работать в свободное время по желанию. G>Можно захоститься на гуглокоде, сделать несолько веток под разные решения.
Инструменты — это личное дело каждого, главное результат.
Иногда мне кажется, что вам платят за флуд, который редко обходит хоть одно сообщение.
Прошу прощения у владельцев форума за сомнение в их честности
Здравствуйте, Ziaw, Вы писали:
Z>Идей хорошая, но бесполезная, нужен PM. Исполнители скорее всего найдутся, PM нет. Предлагаю начать его поиски в теме управление проектами, может им там тоже нужен показательный процесс?
Я могу попробовать быть PM'ом для anemic domain model с обоими типами клиентов. Опыта в этом мало — только для себя и еще для одного разработчика в 3-4 проектах был PM'ом, хотя тут вроде и проекты не должны быть большими.
Мне кажется, важнее сначала ТЗ написать с учетом опытов разных практиков, ведь уже на этом этапе могут возникнуть разногласия и риск неуложиться в небольшой объем ТЗ.
Здравствуйте, Ocenochka, Вы писали:
O> Я могу попробовать быть PM'ом для anemic domain model с обоими типами клиентов. Опыта в этом мало — только для себя и еще для одного разработчика в 3-4 проектах был PM'ом, хотя тут вроде и проекты не должны быть большими.
ПМ должен быть один и вести все проекты одновременно. Он же должен быть беспристарстным судьей и решать какие изменения в ТЗ происходят и когда.
O> Мне кажется, важнее сначала ТЗ написать с учетом опытов разных практиков, ведь уже на этом этапе могут возникнуть разногласия и риск неуложиться в небольшой объем ТЗ.
Хорошо, вариант один — придумаем предметную область.
Возьмем самую распостраненную у нас область автоматизации, торговлю. Допусти крупаная торговая организация покупает у оптовых поставщиков, продает магазинам, планирует сама открыть магазины. Торгует, допустим, книгами, поэтому назовем ее "Книжный дом". Что у нас есть? Поставищики, заказы, склады, продажи, остатки.
Второй вариант — берем уже готовую предметную область со схемой данных, тот же Northwind. По нему проще накидать требований, расписать УИ, перевести требования в задачи.
Я бы все-таки посоветовал не наезжать на участников, не думаю что это поспособствует реализации твоей идеи. И чуточку больше уважать мнение более опытных участников (я часто с кем-то не согласен, но понимаю что у многих людей опыта в несколько раз больше чем у меня, поэтому стараюсь все-таки себя пересилить и хоть немного прислушиваться).
Здравствуйте, MozgC, Вы писали:
MC>Я бы все-таки посоветовал не наезжать на участников, не думаю что это поспособствует реализации твоей идеи. И чуточку больше уважать мнение более опытных участников (я часто с кем-то не согласен, но понимаю что у многих людей опыта в несколько раз больше чем у меня, поэтому стараюсь все-таки себя пересилить и хоть немного прислушиваться).
Бесспорно, уважать других и прислушиваться к их мнению очень важно, но в случае с ganjustas'ом я, думаю, можно сделать исключение
Особенно, после его заявлений в стиле "можешь начинать" и "флаг тебе в руки", которые я к нормальным отнести никак не могу.
Не спорю, я видел логические мысли в его исполнении, однако процент от общей массы, по моим прикидкам, у него в районе нескольких единиц, зато ветка обсуждения будет в несколько раз меньше.
Здравствуйте, Ziaw, Вы писали:
O>> Мне кажется, важнее сначала ТЗ написать с учетом опытов разных практиков, ведь уже на этом этапе могут возникнуть разногласия и риск неуложиться в небольшой объем ТЗ.
Z>Хорошо, вариант один — придумаем предметную область. Z>Возьмем самую распостраненную у нас область автоматизации, торговлю. Допусти крупаная торговая организация покупает у оптовых поставщиков, продает магазинам, планирует сама открыть магазины. Торгует, допустим, книгами, поэтому назовем ее "Книжный дом". Что у нас есть? Поставищики, заказы, склады, продажи, остатки.
Ну вот опять не туда занесло.
Пишите сначала требования, к создаваемой системе, а потом уже будут поставищики, заказы, склады, продажи, остатки.
Наоборот делать не стоит.
Z>Второй вариант — берем уже готовую предметную область со схемой данных, тот же Northwind. По нему проще накидать требований, расписать УИ, перевести требования в задачи.
Тоже дохлый номер.
Здравствуйте, Ocenochka, Вы писали:
O>Здравствуйте, MozgC, Вы писали:
MC>>Я бы все-таки посоветовал не наезжать на участников, не думаю что это поспособствует реализации твоей идеи. И чуточку больше уважать мнение более опытных участников (я часто с кем-то не согласен, но понимаю что у многих людей опыта в несколько раз больше чем у меня, поэтому стараюсь все-таки себя пересилить и хоть немного прислушиваться).
O> Бесспорно, уважать других и прислушиваться к их мнению очень важно, но в случае с ganjustas'ом я, думаю, можно сделать исключение O> Особенно, после его заявлений в стиле "можешь начинать" и "флаг тебе в руки", которые я к нормальным отнести никак не могу. O> Не спорю, я видел логические мысли в его исполнении, однако процент от общей массы, по моим прикидкам, у него в районе нескольких единиц, зато ветка обсуждения будет в несколько раз меньше.
Дружище (с), написав подобный пост на форуме и будучи неготовым самостоятельно воплотить в жизнь ту идею, которую озвучил, ты только начинаешь новоую волну необоснованного флуда, холиваров и тому подобного.
Поэтому я ничего лучшего, чем "можешь начинать", сказать тебе не могу.
ЗЫ. Избавляйся от синдрома обиженного интиллегента.
Я считаю, что начальное ТЗ должно быть МАКСИМАЛЬНО ПРОСТЫМ. Иначе реализация может занять уже не несколько часов — и мало кто тогда решит начать реально делать. После реализации максимально простого ТЗ уже потихоньку можно будет его развивать.
Здравствуйте, gandjustas, Вы писали:
G>Ну вот опять не туда занесло. G>Пишите сначала требования, к создаваемой системе, а потом уже будут поставищики, заказы, склады, продажи, остатки. G>Наоборот делать не стоит.
О как. Телега впререди лошади? Ну напишите пример требований из которых можно получить предметную область, а не наоборот, как я предлагаю.
Здравствуйте, gandjustas, Вы писали:
O>> Бесспорно, уважать других и прислушиваться к их мнению очень важно, но в случае с ganjustas'ом я, думаю, можно сделать исключение O>> Особенно, после его заявлений в стиле "можешь начинать" и "флаг тебе в руки", которые я к нормальным отнести никак не могу. O>> Не спорю, я видел логические мысли в его исполнении, однако процент от общей массы, по моим прикидкам, у него в районе нескольких единиц, зато ветка обсуждения будет в несколько раз меньше. G>Дружище (с), написав подобный пост на форуме и будучи неготовым самостоятельно воплотить в жизнь ту идею, которую озвучил,
Ну вот опять. С чего ты взял, что не могу? Всю — конечно не могу, часть — могу, иначе бы не предлагал.
G>ты только начинаешь новоую волну необоснованного флуда, холиваров и тому подобного.
Что-то я не заметил, чтобы в моей ветке, кроме обсуждения тебя, был флуд
G>Поэтому я ничего лучшего, чем "можешь начинать", сказать тебе не могу.
Ты можешь ничего не сказать. Прошу прощения за стеб но на сообщения можно и ничего не отвечать.
G>ЗЫ. Избавляйся от синдрома обиженного интиллегента.
Это ты избавляйся, я себя к "интиллегентом" даже не отношу
Здравствуйте, Ziaw, Вы писали:
Z>О как. Телега впререди лошади? Ну напишите пример требований из которых можно получить предметную область, а не наоборот, как я предлагаю.
Он имел в виду что требования сначала должны быть в виде типа "Система должна помогать в приеме заказов от клиентов (магазинов), объединять их и отправлять поставщикам компании бла бла бла".
Здравствуйте, Ziaw, Вы писали:
O>> Я могу попробовать быть PM'ом для anemic domain model с обоими типами клиентов. Опыта в этом мало — только для себя и еще для одного разработчика в 3-4 проектах был PM'ом, хотя тут вроде и проекты не должны быть большими. Z>ПМ должен быть один и вести все проекты одновременно.
Вот это мне кажется не правильно.
Во-первых, роль PM'а не так уж велика в данном случае.
Во-вторых, вряд ли кто-то захочет "вести несколько проектов одновременно" в свободное время, чем бы эти проекты ни были.
Давайте подробнее о роли PM'а в данном случае: анализ требований особо делать не придется — думаю, каждый работающий над реализацией будет в состоянии прочитать и понять относительно простое ТЗ. Разбиение ТЗ на таски будет в каждом подходе свое — в anemic, например, отдельным таском будет написание объектной модели, еще одним таском — написание маппингов, если в качестве инструмента будет ОРМ. В rich отдельного таска для объектной модели вроде не будет. Хотя, конечно, будут и общие таски для любых подходов, типа, проектирование БД.
Z>Он же должен быть беспристарстным судьей и решать какие изменения в ТЗ происходят и когда.
Предлагаю требования зафиксировать перед реализацией. Потенциальные изменения можно было бы просто обсуждать с примерами реализации и вводить после согласия всех PM'ов (кем бы они не были).
O>> Мне кажется, важнее сначала ТЗ написать с учетом опытов разных практиков, ведь уже на этом этапе могут возникнуть разногласия и риск неуложиться в небольшой объем ТЗ. Z>Хорошо, вариант один — придумаем предметную область. Z>Возьмем самую распостраненную у нас область автоматизации, торговлю. Допусти крупаная торговая организация покупает у оптовых поставщиков, продает магазинам, планирует сама открыть магазины. Торгует, допустим, книгами, поэтому назовем ее "Книжный дом". Что у нас есть? Поставищики, заказы, склады, продажи, остатки.
Как-будто не с того края начали. С какого края начать — хороший вопрос.
Хинт: предлагаю сделать магазин с разными товарами, чтобы был объект "Товар", а от него уже наследовать конкретные товары — одно это может привести к многим тонкостям реализации. Правда, может возникнуть проблема большого ТЗ, поэтому и предлагаю начать с требований.
Z>Второй вариант — берем уже готовую предметную область со схемой данных, тот же Northwind. По нему проще накидать требований, расписать УИ, перевести требования в задачи.
Тогда упускается возможность каждой "команде" потренироваться в проектировании БД. Ведь в разных подходах могут быть разногласия, например, с идентификацией объектов.
Здравствуйте, MozgC, Вы писали:
MC>Он имел в виду что требования сначала должны быть в виде типа "Система должна помогать в приеме заказов от клиентов (магазинов), объединять их и отправлять поставщикам компании бла бла бла".
Только для этого надо понять, что есть заказы, клиенты, магазины, поставщики, etc. Т.е. определиться с предметной областью, что я и попытался сделать.
Здравствуйте, MozgC, Вы писали:
MC>Я считаю, что начальное ТЗ должно быть МАКСИМАЛЬНО ПРОСТЫМ. Иначе реализация может занять уже не несколько часов — и мало кто тогда решит начать реально делать. После реализации максимально простого ТЗ уже потихоньку можно будет его развивать.
Давайте искать компромис между "максимально простым", которое ничего интересного содержать не будет и "приближеной к реальности", которое никто не захочет делать из-за большого объема.
Примерно такое:
Есть магазин. Торгует разными товарами. Товары на складах, которые совмещены с пунктами выдачи. Так же, возможно, служба доставки.
Роли:
— клиент,
— менеджер (просмотр описаний и точного количества, установление скидок), [под сомнением].
— "складовщик" (для добавления нового товара), [под сомнением]
— директор (для просмотра отчетов).
Это по максимуму, поэтому, возможно, службу доставки имеет смысл сократить, как и две "сомнительные" роли.
Честно сказать, для меня область не очень знакомая, поэтому хотелось бы послушать того, что делал что-то подобное.
С точки зрения заказчика этого ПО, думаю растекать особо не имеет смысла относительно непротиворечивости данных при наличии ИБП и корректного завершения работы или о времени отклика, соответсвующему общепринятым нормам.
Здравствуйте, Ocenochka, Вы писали:
Z>>ПМ должен быть один и вести все проекты одновременно.
O> Вот это мне кажется не правильно. O> Во-первых, роль PM'а не так уж велика в данном случае. O> Во-вторых, вряд ли кто-то захочет "вести несколько проектов одновременно" в свободное время, чем бы эти проекты ни были.
ТЗ одно, задачи одни и те же, требуется их расписать, чекать выполнение и отслеживать потраченное время.
O> Давайте подробнее о роли PM'а в данном случае: анализ требований особо делать не придется — думаю, каждый работающий над реализацией будет в состоянии прочитать и понять относительно простое ТЗ. Разбиение ТЗ на таски будет в каждом подходе свое — в anemic, например, отдельным таском будет написание объектной модели, еще одним таском — написание маппингов, если в качестве инструмента будет ОРМ. В rich отдельного таска для объектной модели вроде не будет. Хотя, конечно, будут и общие таски для любых подходов, типа, проектирование БД.
Для чистоты эксперимента ТЗ должно быть одно, я бы даже сделал вплоть до экранов, чтобы разница была только в реализации.
O> Предлагаю требования зафиксировать перед реализацией. Потенциальные изменения можно было бы просто обсуждать с примерами реализации и вводить после согласия всех PM'ов (кем бы они не были).
Естественно.
O> Как-будто не с того края начали. С какого края начать — хороший вопрос. O> Хинт: предлагаю сделать магазин с разными товарами, чтобы был объект "Товар", а от него уже наследовать конкретные товары — одно это может привести к многим тонкостям реализации. Правда, может возникнуть проблема большого ТЗ, поэтому и предлагаю начать с требований.
Вобщем-то и книги могут оказаться лишь одним из направлений деятельности. Просто добавим в стори факт, что компания рассматривает возможности расширить ассортимент товаров, в какую сторону это пока коммерческая тайна.
O> Тогда упускается возможность каждой "команде" потренироваться в проектировании БД. Ведь в разных подходах могут быть разногласия, например, с идентификацией объектов.
