паттерн стратегия

[_Bers]

Сообщение от Utkin

Его развитие должно быть предусмотрено и описано заранее. Иначе это опять косяк организации. Даже научные разработки в идеале должны предусматривать различные варианты событий. А если проект типовый (например, клиент-сервер-бд), то никаких развитий и фантазий там быть не должно. Все уже придумали и довольно давно.

Нет. Не должно. Поскольку никто никому никаких расписок не давал и клятв не приносил. Немножко наивно говорить о "долге".

Это уж как повезет. Какой то коллектив собаку съел на очередном "клиент-сервер".
А для какого то коллектива - это все новое и в диковинку.

К тому же, невозможно заранее предсказать все возможные сценарии развития продуктов компании.


Само слово "развитие" предполагает освоение новых материалов.
Грубо говоря, если вы в сотый раз поднимаете сервер, то для вас это занятие уже пройденный и хорошо изученный материал.
Для вас это не будет "развитием".

Однако проектам свойственно развиваться.
То есть, программистам приходится проявлять творчество и решать новые для них задачи.

Так то я конечно с вами согласен - чем меньше творчества в работе, тем лучше налажен бизнес-конвейер.

Но вот почему то, мне на практике постоянно приходится думать творчески.

Даже в условиях, когда казалось бы уже есть готовый фрейморк, опытный коллектив, и все такое прочее.

Внезапно оказывается, что в угоду новым растущим требованиям к продуктам компании, требуется поддержка все более мощного функционала о котором раньше никто даже и не задумывался.

Прикручивать его приходится к существующему движку в условиях легаси. И сделать это нужно вчера. Потому что бизнес не ждет.


Мне повезло в том, что довелось работать с действительно талантливым рулевым.

От него я научился одному важному пониманию:

Здесь и сейчас - решить четко поставленную задачу. И не тратить времени и сил на попытки предусмотреть все варианты возможного развития.

Когда программист проектируя механизм думает:
"а вот вдруг пользователю ещё захочется..."

Ну или:

"а вдруг в будущим мы захотим изменить..."

Это - ошибка, способная вызвать перерасход средств компании ещё больше, чем ошибки связанные с недостаточно тщательным проектированием.

[Utkin]

Нет. Не должно. Поскольку никто никому никаких расписок не давал и клятв не приносил. Немножко наивно говорить о "долге".

О как все запущено. Есть такая вещь называемая техническое задание - самый распространенный документ где и расписаны все основные долги. Помимо этого существуют еще документы описывающие экономические и временные затраты. В общем с Вами все ясно - бегом читать проектирование информационных систем, дабы больше не писать ересь. Остальное уже можно не читать - фантазии на тему развитий проекта и творчество в информационных проектах не имеют ничего общего с реальностью

[_Bers]

Сообщение от Utkin

О как все запущено. Есть такая вещь называемая техническое задание - самый распространенный документ где и расписаны все основные долги. Помимо этого существуют еще документы описывающие экономические и временные затраты. В общем с Вами все ясно - бегом читать проектирование информационных систем, дабы больше не писать ересь. Остальное уже можно не читать - фантазии на тему развитий проекта и творчество в информационных проектах не имеют ничего общего с реальностью

О как. Ну думайте, что хотите.

Кстати, эти ваши "документы описывающие экономические и временные траты" на деле не имеют ни малейшего отношения к проектированию архитектуры продукта.

Вообще никакого.
Это две никак не связанные друг с другом области.

[Utkin]

Кстати, эти ваши "документы описывающие экономические и временные траты" на деле не имеют ни малейшего отношения к проектированию архитектуры продукта.

Вообще никакого.
Это две никак не связанные друг с другом области.

Гуглим программная инженерия и больше здесь свою глупость не показываем.

[_Bers]

Сообщение от Utkin

Гуглим программная инженерия и больше здесь свою глупость не показываем.

Поменьше пафоса.

Теория - это конечно хорошо.

Однако в условиях реального сурового мира далеко не все так красиво, как в умных книжках, на картинках, или в умах менеджеров.

[Utkin]

Однако в условиях реального сурового мира далеко не все так красиво, как в умных книжках, на картинках, или в умах менеджеров.

Именно это я и хотел сказать про данный паттерн .

Поменьше пафоса.

Здесь нет никакого пафоса. Попробуйте что-нибудь заказать, что-то чуть более серьезней чем студенческий диплом, хоть здесь же на форуме. Первый вопрос будет - сколько платите, второй - где ТЗ? Вот я и посмотрю как Вы начнете там вертеть носом - это надо улучшить, а здесь добавить .

[Kostia]

Есть такая вещь называемая техническое задание - самый распространенный документ где и расписаны все основные долги.

А как же Agile?

Вот я и посмотрю как Вы начнете там вертеть носом - это надо улучшить, а здесь добавить .

А что если это клиент который уже много лет исправно платит за сопровождение?

[Аватар]

Вот не приходилось в топовых фирмах работать где заказ, ТЗ и внедрение под ключ. И раньше, когда в мелкой фирме занимался разработкой для сторонних организаций, и сейчас на предприятии - все время разработка и постоянное изменение. Примерно в стиле как _Bers описал

[_Bers]

Сообщение от Utkin

Именно это я и хотел сказать про данный паттерн .
Здесь нет никакого пафоса. Попробуйте что-нибудь заказать, что-то чуть более серьезней чем студенческий диплом, хоть здесь же на форуме. Первый вопрос будет - сколько платите, второй - где ТЗ? Вот я и посмотрю как Вы начнете там вертеть носом - это надо улучшить, а здесь добавить .

Паттерн "сратегия" вообще не имеет никакого отношения к проблемам менеджемента проектов.

Что касается ТЗ - это компетенция разработчика, а не заказчика.
ТЗ - это этап разработки непосредственно перед созданием кода.
Когда уже вся необходимая документация готова (такие документы, как "дизайн-проект", "требования к проекту", и др).

Сбор всей необходимой документации выполняет разработчик, а не заказчик.

Все, что требуется от заказчика - изложить свои желания.
Заказчик вообще не факт что разбирается в айтишной области.
Он платит деньги, что бы разработчик сделал ему "хорошо".

зы: я - разработчик.
У меня есть опыт работы как с заказчиками, так и с программистами (и артистами), и с разработчиками.

Знаете чем отличается "программист" от "разработчика" ?

Первому требуется ТЗ, но не требуется понимание общей картины.
Он тупо отрабатывает по ТЗ, и ему наплевать, как именно его творение будет кем то использоваться.

Второму требуется понимание общей картины происходящего. А ТЗ он и сам себе сформирует.

[Utkin]

А как же Agile?

Это тоже описывается в ТЗ.
Далее:

Гибкий подход к управлению требованиями не подразумевает далеко идущих планов (по сути, управления требованиями просто не существует в данной методологии), а подразумевает возможность заказчика вдруг и неожиданно в конце каждой итерации выставлять новые требования, часто противоречащие архитектуре уже созданного и поставляемого продукта. Такое иногда приводит к катастрофическим «авралам» с массовым рефакторингом и переделками практически на каждой очередной итерации.

Из-за чего собственно весь сыр-бор и разгорелся.

А что если это клиент который уже много лет исправно платит за сопровождение?

И пусть платит дальше.

Примерно в стиле как _Bers описал

В мелкой конторе да, в крупной такой фокус не прокатит.

Паттерн "сратегия" вообще не имеет никакого отношения к проблемам менеджемента проектов.

Про это я Вам и писал, указывая на пост 11.

Что касается ТЗ - это компетенция разработчика, а не заказчика.

ТЗ это компетенция системного аналитика. Системный аналитик на стороне заказчика предпочтительней (для обеих сторон). Иное дело, что в мелких конторах особо этими вещами не заморачиваются.
Был заказчиком - схема следующая:
1. Договор
2. Документация к договору (ТЗ и пр.).
3. Разработчик формирует макет приложения (была московская контора - у них в частности вообще есть каркас на приложения вида клиент-сервер-бд, они переклепывают его в три дня). На этом этапе заказчик еще может сказать, что ему не нравится (опять же ни в какую детализацию на уровне классов и объектов никого не пускают).
4. Заказчик получает готовый продукт в яркой коробочке и сопроводительную документацию.

За это время программистов ни разу не видел.
Это общая схема. Если речь идет о госконторе, то с огромной вероятностью проект будет выставлен на торги (как правило по 44-ФЗ) и там вообще все жестко. ТЗ в таком случае предоставляет заказчик (если речь не идет о сговоре), данная информация публична (то есть каждый может на каких-нибудь закупках просмотреть требования к проекту). Заказчика в таком случае дополнительно может контролировать его учредитель, в таком случае как Вы понимаете никаких фантастических ситуация типа "хочу по-другому" просто не может быть.