Comments 120
>Во-первых, проектировать надо всегда, даже если в проекте все «очевидно и так».
>Во-вторых, длительность проектирования и его цикличность будет зависить от того насколько сложен проект и насколкьо опытна команда исполнителя проекта.
ок. зачем остальной текст?
>Во-вторых, длительность проектирования и его цикличность будет зависить от того насколько сложен проект и насколкьо опытна команда исполнителя проекта.
ок. зачем остальной текст?
Что есть проектирование? Неделю думать о том как что делать? Или за 2 часа на обрывках бумаги накидать какие-то заметки? Или проектированием можно считать BDD?
Также надо учитывать размер системы и количество разработчиков которые будут ее разрабатывать. Так что «проектировать надо всегда» спорное выражение, все зависит от того какой смысл вы вкладываете в понятие «проектирование»
Также надо учитывать размер системы и количество разработчиков которые будут ее разрабатывать. Так что «проектировать надо всегда» спорное выражение, все зависит от того какой смысл вы вкладываете в понятие «проектирование»
Проектирование это и «Неделю думать о том как что делать» и «за 2 часа на обрывках бумаги накидать какие-то заметки» и сделать перерыв на один день, чтобы в голове информация улеглась.
Проектирование и анализ предметной области тесно связаны на мой взгляд. При этом четко рассказать что такое проектирование проблемматично — это процессы начиная от составления ТЗ и вплоть до создания структуры данных. Причем, на этапе проектирования структуры данных очень необходимо общаться с аналитиками, потому что обязательно будет возникать много вопросов типа «а как вот эти сузности связаны?».
Проектирование и анализ предметной области тесно связаны на мой взгляд. При этом четко рассказать что такое проектирование проблемматично — это процессы начиная от составления ТЗ и вплоть до создания структуры данных. Причем, на этапе проектирования структуры данных очень необходимо общаться с аналитиками, потому что обязательно будет возникать много вопросов типа «а как вот эти сузности связаны?».
Проектирование, на мой взгляд, начинается с понимания внутренних процессов заказчика.
Вот шьет контора сумки для ноутбуков (это реальный пример), из чего хош шьет.
Вроде как со стороны есть черная сумка определенной модели, есть красная.
Для покупателя интернет-магазина компании пофиг.
Есть картинка сумки.
Нравится >> покупаем и наоборот
Но тут вдруг выясняется, что у производителя есть крупные покупатели.
Которым нужно четко знать материал Oxford или Cordura.
А со стороны то хрен различишь.
Поэтому проектирование — это работа не столько программера, а скорее какого то персонажа который все знает о том, как заказчик может заработать денег, но заказчиком не является.
Вот шьет контора сумки для ноутбуков (это реальный пример), из чего хош шьет.
Вроде как со стороны есть черная сумка определенной модели, есть красная.
Для покупателя интернет-магазина компании пофиг.
Есть картинка сумки.
Нравится >> покупаем и наоборот
Но тут вдруг выясняется, что у производителя есть крупные покупатели.
Которым нужно четко знать материал Oxford или Cordura.
А со стороны то хрен различишь.
Поэтому проектирование — это работа не столько программера, а скорее какого то персонажа который все знает о том, как заказчик может заработать денег, но заказчиком не является.
ГОСТ Р ИСО/МЭК 12207-99 Информационная технология. Процессы жизненного цикла программных средств
Основные этапы (процессы) управления проектами:
— Подготовка и определение области управления.
— Планирование.
— Выполнение и контроль.
— Проверка и оценка.
— Завершение.
Основные этапы (процессы) управления проектами:
— Подготовка и определение области управления.
— Планирование.
— Выполнение и контроль.
— Проверка и оценка.
— Завершение.
отлично. планирование… планирование это когда тим лидер сказал программерам кто и что делает? или оценка срока разработки? или ...?
Планирование в контексте проектных технологий это определение целей и способов их достижения.
Планирование можно разбить на несколько этапов:
— Продолжительность каждого этапа
— Бюджет
— Необходимые ресурсы
— Критерии качества
Планирование можно разбить на несколько этапов:
— Продолжительность каждого этапа
— Бюджет
— Необходимые ресурсы
— Критерии качества
Поправка:
— Продолжительность каждого этапа Проекта.
— Продолжительность каждого этапа Проекта.
И еще дополнение:
Итогом Планирования должны быть Документы (ТЗ, Устав, и т.п.), которые в свою очередь станут «библией» на время проекта и для Тим лидера, и для программера и для Заказчика.
Итогом Планирования должны быть Документы (ТЗ, Устав, и т.п.), которые в свою очередь станут «библией» на время проекта и для Тим лидера, и для программера и для Заказчика.
лично для меня проектирование как для программиста это на бумажке накидал модули. покурил. почитал бумажку. поменял немного. еще покурил. сделал штуку которая все модули связывает. еще раз подумал что можно перерисовать и потом начала делать.
Интересно, что на момент разработки первых ГОСТов про организацию проектирования они даже мировых аналогов не имели.
Почему-то никто не пишет про самое главное — про итеративность. Сегодня большинство компаний используют итеративные методологии, поэтому умение распределять проектирование по итерациям (люблю слово «размазывать») является очень важным.
То что описал предыдущий автор — это классический пример антипаттерна «паралич анализа» (http://sourcemaking.com/antipatterns/analysis-paralysis). Бороться с ним очень просто: жестко таймбоксите нулевой спринт, требования готовьте в виде беклога (сверху подробного расписанные ЮС, снизу — эпики), архитектуру прорабатывайте сверху (не ныряйте глубоко), вовлекайте заказчика и общайтись с ним, если делаете прототипы — распределите их по спринтам, но с опережением разработчиков на один спринт.
Вообще если стоит такая проблема, используйте таймбоксинг везде, либо возьмите целиком готовую методологию Scrum. Есть желание написать статью, но нет времени, да и доклад делал на эту тему: ekt.agiledays.ru/ (Использование ICONIX для анализа требований в Scrum)
То что описал предыдущий автор — это классический пример антипаттерна «паралич анализа» (http://sourcemaking.com/antipatterns/analysis-paralysis). Бороться с ним очень просто: жестко таймбоксите нулевой спринт, требования готовьте в виде беклога (сверху подробного расписанные ЮС, снизу — эпики), архитектуру прорабатывайте сверху (не ныряйте глубоко), вовлекайте заказчика и общайтись с ним, если делаете прототипы — распределите их по спринтам, но с опережением разработчиков на один спринт.
Вообще если стоит такая проблема, используйте таймбоксинг везде, либо возьмите целиком готовую методологию Scrum. Есть желание написать статью, но нет времени, да и доклад делал на эту тему: ekt.agiledays.ru/ (Использование ICONIX для анализа требований в Scrum)
Итеративность хороша, тут даже обсуждать нечего.
Вот что стоит обсуждать, так это когда начинать первую итерацию?
На мой взглаяд это нужно делать после того как станет ясна основная задача «куда бежать?». А то может возникнуть ситуация:
— ну давай побежим на юг? побежали
— вы не туда бежите!
— ну тогда давай сбегаем на сервер? побежали
— вы опять не туда бежите.
И такие итерации могут продолжаться довольно долго, пока наконец-то кто-то не спросит у заказчика «так куда нам в конце концов-то бежать?»
Вот что стоит обсуждать, так это когда начинать первую итерацию?
На мой взглаяд это нужно делать после того как станет ясна основная задача «куда бежать?». А то может возникнуть ситуация:
— ну давай побежим на юг? побежали
— вы не туда бежите!
— ну тогда давай сбегаем на сервер? побежали
— вы опять не туда бежите.
И такие итерации могут продолжаться довольно долго, пока наконец-то кто-то не спросит у заказчика «так куда нам в конце концов-то бежать?»
Вы всегда знаете куда вы бежите. Вам нужно решать проблемы заказчика.
первый шаг к решению проблемы — узнать, в чем она заключается. по-моему речь как раз об этом
Это так только в одном случае — заказчик точно и однозначно описал задачу (для подвески картины вбить гроздь диаметром 5 мм и длиной 10 см в эту стену по нанесенной разметке, заглубить на 5 см).
Если задача задана менее точно (хочу тут на стенку что-нибудь красивое) можно долго бежать решать проблемы заказчика, но решение может оказаться далеким от оптимального (потратили кучу времени, повесили дорогую картину в золоченой раме, для ее подвески пришлось укрепить стену, а можно было просто наклеить качественные фотообои).
Если задача задана менее точно (хочу тут на стенку что-нибудь красивое) можно долго бежать решать проблемы заказчика, но решение может оказаться далеким от оптимального (потратили кучу времени, повесили дорогую картину в золоченой раме, для ее подвески пришлось укрепить стену, а можно было просто наклеить качественные фотообои).
Потому что очень часто итеративности нет, хотя ПМ и остальные думают что она есть.
Обычно заказчику интересен крупный цикл — заказали и внедрили. Склонять его на некоторые промежуточные подтверждения можно, но зачастую бесполезно — он не видит проблем до момента неупругого взаимодействия на этапе внедрения. При этом все внутренние циклы в процессе разработки — чистая видимость.
Обычно заказчику интересен крупный цикл — заказали и внедрили. Склонять его на некоторые промежуточные подтверждения можно, но зачастую бесполезно — он не видит проблем до момента неупругого взаимодействия на этапе внедрения. При этом все внутренние циклы в процессе разработки — чистая видимость.
Проектирование должно занимать 99% времени, сколько я не делал проектов, доскональное проектирование никогда не приносило вреда, более того всегда выигрывало время… Можно год писать код, а можно месяц обдумать и найти путь написать за неделю…
Чем раньше выявлена ошибка, тем легче её исправить.
Проектирование необходимо, чтобы потом не городить костылей.
Проектирование необходимо, чтобы потом не городить костылей.
Есть одно очень важное основополагающее правило: «Все создается дважды».
Необходимо всегда начинать представляя конечную цель, иначе результата не будет.
Необходимо всегда начинать представляя конечную цель, иначе результата не будет.
Почему-то в статье ни слова про тестирование.
Мне кажется, это говорит о том, что в этих проектах в примере тесты и не писались, или писались непоследовательно.
Все ведь очень просто — правильное применение тестов позволяет резко (я бы сказал, даже на несколько порядков) упростить внесение изменений в код. А это, в свою очередь, очень снижает необходимый объем предварительного проектирования.
Ситуация, когда требования к проекту полностью ясны заранее и не будут меняться со временем (при получении обратной связи от пользователей, например) — довольно редкие по нынешним временам.
Отсюда призывы (справедливые) действовать короткими итерациями, не заниматься архитектурной астронавтикой и не тратить слишком много времени на проектирование с учетом того, что до того, как проект выйдет в жизнь в каком-то виде, информации для проектирования все равно недостаточно.
Действовать короткими итерациями и не тратить много времени на предварительное проектирование можно исключительно при применении автоматического тестирования. Если оно не применяется, или применяется непоследовательно, или применяется неправильно, то все эти короткие итерации без проектирования действительно приведут к полной каше. Внесение изменений будет затруднено, вместо рефакторинга будет применяться костылинг, со всеми вытекающими.
С тестами же не сложно поддерживать код в хорошей форме и без длительного предварительного проектирования. При этом, по сравнению с «водопадом», появляются дополнительные преимущества (которые для многих сфер деятельности являются решающими для успеха): быстрое получение прототипа, актуальные данные о требованиях, простота внесения изменений.
Вопрос о том, сколько именно времени тратить на проектирование — не основной, т.к. это только следствие способа разработки.
Мне кажется, это говорит о том, что в этих проектах в примере тесты и не писались, или писались непоследовательно.
Все ведь очень просто — правильное применение тестов позволяет резко (я бы сказал, даже на несколько порядков) упростить внесение изменений в код. А это, в свою очередь, очень снижает необходимый объем предварительного проектирования.
Ситуация, когда требования к проекту полностью ясны заранее и не будут меняться со временем (при получении обратной связи от пользователей, например) — довольно редкие по нынешним временам.
Отсюда призывы (справедливые) действовать короткими итерациями, не заниматься архитектурной астронавтикой и не тратить слишком много времени на проектирование с учетом того, что до того, как проект выйдет в жизнь в каком-то виде, информации для проектирования все равно недостаточно.
Действовать короткими итерациями и не тратить много времени на предварительное проектирование можно исключительно при применении автоматического тестирования. Если оно не применяется, или применяется непоследовательно, или применяется неправильно, то все эти короткие итерации без проектирования действительно приведут к полной каше. Внесение изменений будет затруднено, вместо рефакторинга будет применяться костылинг, со всеми вытекающими.
С тестами же не сложно поддерживать код в хорошей форме и без длительного предварительного проектирования. При этом, по сравнению с «водопадом», появляются дополнительные преимущества (которые для многих сфер деятельности являются решающими для успеха): быстрое получение прототипа, актуальные данные о требованиях, простота внесения изменений.
Вопрос о том, сколько именно времени тратить на проектирование — не основной, т.к. это только следствие способа разработки.
Что бы что-то тестировать надо сначала определиться что есть правильно, а что нет. В общем для проекта — это ТЗ, в частностях определяется проектированием.
Собственно заменять проектирование тестированием — это примерно как 42.
Собственно заменять проектирование тестированием — это примерно как 42.
Я, по правде говоря, не понял, что Вы написали)
Правильно с точки зрения кода — DRY, KISS, loose coupling. YAGNI в разумных пределах. Средства для достижения DRY и тд описаны в книжках по паттернам проектирования, например. Из всего этого вытекают конкретные архитектурные решения. С чем тут определяться-то, и причем тут тесты?
Или тут терминологическая проблема? Я использовал термин «проектирование» в смысле «формирование мнение о том, КАК делать, как организовывать код».
Правильно с точки зрения кода — DRY, KISS, loose coupling. YAGNI в разумных пределах. Средства для достижения DRY и тд описаны в книжках по паттернам проектирования, например. Из всего этого вытекают конкретные архитектурные решения. С чем тут определяться-то, и причем тут тесты?
Или тут терминологическая проблема? Я использовал термин «проектирование» в смысле «формирование мнение о том, КАК делать, как организовывать код».
Сначала надо узнать что должен делать код, после чего — как. Организацией кода проектирование заканчивается.
Ну да. Только можно думать о том, что и как должен делать код, заранее, 1 раз, в начале разработки. А можно думать об этом постоянно.
Если думать об этом постоянно, то не обязательно столько думать об этом в начале, пытаясь предугадать все варианты развития событий. Чтобы это постоянное думание и переделывание было возможным, нужны тесты. Постоянное думание и переделывание имеет то преимущество, что структура кода и функционал проекта определяется текущими накопленными знаниями о требованиях, а не прошлогодними домыслами.
Если думать об этом постоянно, то не обязательно столько думать об этом в начале, пытаясь предугадать все варианты развития событий. Чтобы это постоянное думание и переделывание было возможным, нужны тесты. Постоянное думание и переделывание имеет то преимущество, что структура кода и функционал проекта определяется текущими накопленными знаниями о требованиях, а не прошлогодними домыслами.
Не всегда можно написать тесты, порой тесты вырождаются в написание кода
Напишите мне пожалуйста тест для модуля генерации расписания занятий университета.
Напишите мне пожалуйста тест для модуля генерации расписания занятий университета.
Вот вы плавно подошли к тому, что проектировать лучше прототипипуя :)
Лучше, но только при решении определенного круга задач. Для решения задач другого рода надо использовать другие подходы.
Очертите круг задач, который должен решаться прототипированием
Я не совсем корректно выразился. Под кругом задач я понимал совокупность «опыт команды + задача на проект». Если у команды есть опыт разработки аналогичных проектов, то есть смысл сразу начинать с прототипа, если проект сам по себе небольшой и планируется его закончить через пару месяцев, то просто обязательно начинать с прототипа.
Много всяких «но». Нет и не может быть единого алгоритма выполнения проектов по созданию программной системы.
Много всяких «но». Нет и не может быть единого алгоритма выполнения проектов по созданию программной системы.
Да что ж такое, опять ничего не понял, простите ;)
> Не всегда можно написать тесты, порой тесты вырождаются в написание кода
Звучит примерно как «не всегда можно правильно питаться, порой правильное питание вырождается в зарядку по утрам». Это что, довод в пользу того, что правильное питание нисколько не продлевает жизнь, не улучшает самочувствие и не снижает необходимость подолгу лежать в клиниках? Вторая часть (про написание кода/зарядку по утрам) при этом непонятна и загадочна.
> Напишите мне пожалуйста тест для модуля генерации расписания занятий университета
Даже не знаю, что сказать. То-ли это пример реальной практической задачи, к которой якобы неприменим подход с тестами, то-ли это такая попытка выразить мнение о том, что к непойми чему тесты написать нельзя, то-ли что. Гадать не буду, подожду разъяснений)
> Не всегда можно написать тесты, порой тесты вырождаются в написание кода
Звучит примерно как «не всегда можно правильно питаться, порой правильное питание вырождается в зарядку по утрам». Это что, довод в пользу того, что правильное питание нисколько не продлевает жизнь, не улучшает самочувствие и не снижает необходимость подолгу лежать в клиниках? Вторая часть (про написание кода/зарядку по утрам) при этом непонятна и загадочна.
> Напишите мне пожалуйста тест для модуля генерации расписания занятий университета
Даже не знаю, что сказать. То-ли это пример реальной практической задачи, к которой якобы неприменим подход с тестами, то-ли это такая попытка выразить мнение о том, что к непойми чему тесты написать нельзя, то-ли что. Гадать не буду, подожду разъяснений)
Я имел ввиду, что не всегда можно использовать ТДД и аналогичные методики, и не ко всем задачам можно написать тесты «с нуля». Существуют такие, которые без очень детального анализа просто невозможно реализовать.
Это пример реальной практической задачи, которая решалась как одна из подсистем более крупного проекта.
Это пример реальной практической задачи, которая решалась как одна из подсистем более крупного проекта.
Тестировщики склонны переоценивать значимость тестирования. Значимость тестирования сильно зависит от методологии разработки, которая в свою очередь зависит от команды. В среднем % значимости тестирования в общем успехе проектов на моей практике редко превышало 8%. 8% — это количество рабочих часов, включая рабочие часы и разработчиков и тестировщиков, проведёнными непосредственно над bug&fix.
По этому я прямо запрещаю своим сотрудникам посвящать более 10% своего времени написанию тестов (исключение — интеграционные тесты).
По этому я прямо запрещаю своим сотрудникам посвящать более 10% своего времени написанию тестов (исключение — интеграционные тесты).
Тестирование важно, но если досконально не спроектировать то уйдет больше времени на перепроектирование в последствии.
Помнится проект, где «умельцы» решили использовать проектирование в процессе написания кода… Так 4 месяца писали и с места не сдвинулись, т к все уходило на обговаривание текущего набора заданий и в последствии на их изменения.
По моему мнение нужно проектировать от большего к меньшему — создаем каркас (скелет) пишем код, а потом навешиваем «мясо» — в процессе написания кода — проектируем более мелкие детали. Но конечно все «мясо» по максимуму должно учитываться и в процессе проектирования «скелета» :)
Помнится проект, где «умельцы» решили использовать проектирование в процессе написания кода… Так 4 месяца писали и с места не сдвинулись, т к все уходило на обговаривание текущего набора заданий и в последствии на их изменения.
По моему мнение нужно проектировать от большего к меньшему — создаем каркас (скелет) пишем код, а потом навешиваем «мясо» — в процессе написания кода — проектируем более мелкие детали. Но конечно все «мясо» по максимуму должно учитываться и в процессе проектирования «скелета» :)
У меня сложилось впечатление, что мы все тут разработчики-полупроектировщики и исходя из своих идеализированных мнений пытаемся доказать истинность заключений этих мнений.
Вот если посмотреть, то столько мнений, даже если есть сторонники полноценного проектирования, то и они между собой спорят, т.к. по-разному подходят к этому процессу.
И все же каждый из нас работает так, как ему удобно или как его научили. Можно проектировать месяцами и нифига дельного не написать, а можно обладать талантом, чутьем, небольшим везением, и сразу написать как надо.
А можно использовать методологии проектирования, которые, кстати, придуманы не глупыми людьми и давно используются, причем использовать эти самые методологии в связке с опытом, талантом и что у каждого из Вас там еще есть…
Вот если посмотреть, то столько мнений, даже если есть сторонники полноценного проектирования, то и они между собой спорят, т.к. по-разному подходят к этому процессу.
И все же каждый из нас работает так, как ему удобно или как его научили. Можно проектировать месяцами и нифига дельного не написать, а можно обладать талантом, чутьем, небольшим везением, и сразу написать как надо.
А можно использовать методологии проектирования, которые, кстати, придуманы не глупыми людьми и давно используются, причем использовать эти самые методологии в связке с опытом, талантом и что у каждого из Вас там еще есть…
Тз хорошо для прроектов, у которых есть четкая схема работы, и вы или заказчик четко предстовляете как это должно работать. У меня так получалось, что почти всегда создавались проекты, у которых не было четкого понятия как оно должно работать в итоге. И в таких проектах писалось тз, но о нем забывали через месяц за ненадобностью, так как проект после месяца своего существования полностью поменял линию развития, то есть старое тз не было нужно уже. Потом через месяц еще раз поменял линию развития и так 5 раз за год. Все дело в том что проет новый в отрасли, ну или точнее новый как для заказчика так и для разработчика. Я еще не видел не одного живого веб проекта, который бы развивался как это было задуманно изначально. (и я не про рюшечки, а про пренципиальные вещи)
Время потраченное на тз ушло впустую, а все тонкости показал прототип, и только после 2 лет существования прроекта стало до конца ясно что в итоге должно получиться. И вот на этом этапе его надо с нуля переписывать, опять же скорее всего без тз, так как уже все разработчики представляют себе как это все должно работать, где тут тонкости и косяки.
Прототип обязательно нужен тогда, когда ты не знаешь конечной цели, и действительно бежишь то на север то на юг. Но когда ищешь золото, никогда точно не знаешь где оно будет находиться. Знал бы прикуп жил бы в сочи, ну и так далее
На мой взгляд интерактивность гораздо важнее планирования. И планировать работу и развитие проекта более чем на 2 недели я смысла не вижу. За 2 недели в живом проекте меняется очень многое, а иногда чуть ли не вся идеология
Время потраченное на тз ушло впустую, а все тонкости показал прототип, и только после 2 лет существования прроекта стало до конца ясно что в итоге должно получиться. И вот на этом этапе его надо с нуля переписывать, опять же скорее всего без тз, так как уже все разработчики представляют себе как это все должно работать, где тут тонкости и косяки.
Прототип обязательно нужен тогда, когда ты не знаешь конечной цели, и действительно бежишь то на север то на юг. Но когда ищешь золото, никогда точно не знаешь где оно будет находиться. Знал бы прикуп жил бы в сочи, ну и так далее
На мой взгляд интерактивность гораздо важнее планирования. И планировать работу и развитие проекта более чем на 2 недели я смысла не вижу. За 2 недели в живом проекте меняется очень многое, а иногда чуть ли не вся идеология
Нужно было спланировать отсутствие ТЗ и архитектуру строить с учетом того, что проект будет переписан 5 раз за год.
А проект потом сдавали по какому ТЗ? :) Или согласовывали уточнения?
Модель, именуемая «водопадом» обычно предполагает разработку аванпроекта (вникаем в задачу, готовимся писать ТЗ), согласование ТЗ, эскизный проект (предлагаем концепцию решения задачи), уточнение ТЗ, технический проект (предлагаем конкретные решения), уточнение ТЗ, разработку и сдачу продукта.
Разумеется, полностью эта схема применяется только на масштабных проектах, но и при небольших задачах на нее можно оглядываться как на образец, который можно упростить.
Модель, именуемая «водопадом» обычно предполагает разработку аванпроекта (вникаем в задачу, готовимся писать ТЗ), согласование ТЗ, эскизный проект (предлагаем концепцию решения задачи), уточнение ТЗ, технический проект (предлагаем конкретные решения), уточнение ТЗ, разработку и сдачу продукта.
Разумеется, полностью эта схема применяется только на масштабных проектах, но и при небольших задачах на нее можно оглядываться как на образец, который можно упростить.
А проект мы никому не сдавали, это бесконечный проект, который делается внутри компании для самой компании.
Вся проблема в том, что вектор развитиязависит от задач маркетинга, саппорта клиентов, требований партнеров и так далее. А эти вещи нельзя предсказать изначально.
Постоянно приходит рапорты из разных отделов о таких вещах, которые не то что не получилось бы сразу грамотно разрулить, в начале проектирования, а о них вообще никто не подозревал, хотя много людей думало.
И иногда такие вещи меняют все.
И если так происходит постоянно, то ТЗ устаревает быстрее чем пишется.
ТЗ можно писать на 1 конкретную, небольшую, задачу, (не больше 1-2х недель на выполнение). И писать его тогда когда проект готов к разработке и внедрению этой задачи, а не заранее. (Решили сейчас внедрить какую нить фишку, обсуждается все, пишется тезисно ТЗ, иногда разработка интерфейса от юзабелиста, программная разработка и внедрение, следующая задача и все по кругу).
ТЗ — это как первые обзоры айфонов (2007г), когда они писались вроде все звучало адекватно, но елси их почитать сейчас…
Вся проблема в том, что вектор развитиязависит от задач маркетинга, саппорта клиентов, требований партнеров и так далее. А эти вещи нельзя предсказать изначально.
Постоянно приходит рапорты из разных отделов о таких вещах, которые не то что не получилось бы сразу грамотно разрулить, в начале проектирования, а о них вообще никто не подозревал, хотя много людей думало.
И иногда такие вещи меняют все.
И если так происходит постоянно, то ТЗ устаревает быстрее чем пишется.
ТЗ можно писать на 1 конкретную, небольшую, задачу, (не больше 1-2х недель на выполнение). И писать его тогда когда проект готов к разработке и внедрению этой задачи, а не заранее. (Решили сейчас внедрить какую нить фишку, обсуждается все, пишется тезисно ТЗ, иногда разработка интерфейса от юзабелиста, программная разработка и внедрение, следующая задача и все по кругу).
ТЗ — это как первые обзоры айфонов (2007г), когда они писались вроде все звучало адекватно, но елси их почитать сейчас…
Кстати, да, иногда нужно подождать реализации двух-трех фич, чтобы потом нужную сделать за пару дней, а не за пару месяцев. Понимание этого будет только когда на руках будет реально функционирующий модуль.
Если проект внутри компании и исключительно для компании — это одно. А если проект для внешнего заказчика и заказчик серьезно относится к делу, то без хорошего ТЗ не обойтись.
Да, оно может изменяться по соглашению с заказчиком при обнаружении новых проблем или появлении новых предложений.
Да, оно может изменяться по соглашению с заказчиком при обнаружении новых проблем или появлении новых предложений.
Но в большинстве случаев за эти изменения будете платить вы из своего кармана.
Почему из своего кармана?
Есть ТЗ версии 1. В процессе работы я вижу, что могу предложить заказчику более качественное решение. Я предлагаю ему согласовать изменение ТЗ, сроком и стоимости работ. Получаем ТЗ версии 2.
Если он не соглашается — остается при старом ТЗ и соответствующих функциях/сроках/стоимости.
Есть ТЗ версии 1. В процессе работы я вижу, что могу предложить заказчику более качественное решение. Я предлагаю ему согласовать изменение ТЗ, сроком и стоимости работ. Получаем ТЗ версии 2.
Если он не соглашается — остается при старом ТЗ и соответствующих функциях/сроках/стоимости.
Покажите мне проект, который на 100% был сделан по ТЗ, и это не была курсовая работа.
А никто не говорит про 100% ТЗ, составление ТЗ это лишь один из этапов, и конечно оно постоянно дорабатывается на протяжении всего этапа разработки.
Если доработки возникают в процессе работы, значит система была плохо спроектирована или недостаточно продумана.
Ах черт, забыл еще, что условия реальности изменились.
Ах черт, забыл еще, что условия реальности изменились.
Ирония, это конечно хорошо =)
Да, реальный мир меняется, требования меняются, зазкачики меняются, но хорошо спроектированная система остается в своем фундаменте неизменной.
Да, реальный мир меняется, требования меняются, зазкачики меняются, но хорошо спроектированная система остается в своем фундаменте неизменной.
И, иногда, никому не нужной.
А какая выгода-то в том, чтобы системе оставаться в «фундаменте» неизменной? Причем не обязательно неизменной, а только при условии того, что спроектирована система «хорошо»?
Можно ведь просто сделать внесение изменений в систему легкой операцией (используя тесты и т.д.) и обойтись без этого массивного фундамента, с которым всегда возможна пара веселых варианта:
1) либо его хрен сломаешь при переезде
2) либо он на гусенечной тяге с дизельным генератором — при том, что нужен-то был всего лишь сарай
Можно ведь просто сделать внесение изменений в систему легкой операцией (используя тесты и т.д.) и обойтись без этого массивного фундамента, с которым всегда возможна пара веселых варианта:
1) либо его хрен сломаешь при переезде
2) либо он на гусенечной тяге с дизельным генератором — при том, что нужен-то был всего лишь сарай
Но если Вы заложили фундамент под сарай, то на нем уже небоскреб не построите, а если заказчик сказал: «ой у того домика такие потрясные балкончики на пятом этаже, достройте мне еще три этажа»?
Дак в том-то и дело, что построю, т.к. дом леплю из полуразумных наноматериалов (они пока еще не вырвались на свободу и не поработили человечество), и любое изменение в системе — несложная операция.
Для этого и нужны тесты.
Без них все было бы так, как пишете — сарай и оставался бы сараем: стукнешь в стену — отвалится флюгер.
Для этого и нужны тесты.
Без них все было бы так, как пишете — сарай и оставался бы сараем: стукнешь в стену — отвалится флюгер.
Мне очень нравится, что разговор перешел в такое детсадовское русло. Очень показательно)
— А у меня супермегапушка!
— А у меня базука и супермегамегащит от супермегапушки и поэтому я победил!!!
— А у меня галлактический отражатель. Бе-бе-бе.
В данной ситуации это самое лучшее, что могло произойти.
То, что разговор сам по себе перешел в такое русло, явно сигнализирует о том, что, по сути, мы тут приводим доводы, которые основаны на нашем личном опыте, на личных переживаниях, ощущениях и фантазиях, и которые оттого имеют мало смысла для оппонента.
— А у меня супермегапушка!
— А у меня базука и супермегамегащит от супермегапушки и поэтому я победил!!!
— А у меня галлактический отражатель. Бе-бе-бе.
В данной ситуации это самое лучшее, что могло произойти.
То, что разговор сам по себе перешел в такое русло, явно сигнализирует о том, что, по сути, мы тут приводим доводы, которые основаны на нашем личном опыте, на личных переживаниях, ощущениях и фантазиях, и которые оттого имеют мало смысла для оппонента.
Одна из целей проектирование свести кол-во ошибок к минимуму. А доработки, это уже «Стадия сопровождения». На этой стадии анализируются дополнительные требования (функционал) к системе, возникающие во время «боевой» эксплуатации.
Вы никогда в жизни не предусмотрите все ошибки. Я в это не верю.
можно предусмотреть появление большинства ошибок и хотя бы предположить как они будут решаться если возникнут.
Обязательно предусматривайте ошибки, которые возникнут от разрушения носителей информации при попадании в них метеорита.
Я и не говорю что все ошибки. Я говорю — Большинство. А тот % что я не могу предусмотреть это мои Риски. И на основании рисков я увеличиваю время и сумму договора.
Google V8. 100% по ТЗ. Впрочем, как и любая другая реализация ЯП
если задумываться о прототипировании vs проектирование — всплывает вопрос: а когда оно оправдано?
Тут автоматически всплывают вопросы:
1) какого рода должна быть система?
а) По принципу работы (распределенная по нескольким станциям на основе задач / Сконцентрирована в одном месте / Управляемая из одного центра и с миграцией задач между станциями / прочее)?
б) По объему обрабатываемых данных (мало / много / очень много / ппц как много)?
в) По возможности влияния на тип входных и выходных данных (мы / не мы / частично мы / по большей части мы)?
г) По времени работы системы?
д) многое другое?
2) известно ли нам что должно в результате получиться?
3) Каково отношение нас к поставленной задаче?
Итого: Встает много вопросов уже после ответов на приведенные вопросы. А потом еще будут. А вектор не известен. А результат требуют. Зачастую, чтобы понять и самим узкие места ДО подписания убийственных бумаг полезно сделать прототип (кстати, копните в RUP, про управление проектами, а в частности про то, как выиграть проект в конкурсе), или, если есть время — несколько прототипов, чтобы ПРЕДПОЛОЖИТЬ что к чему и ОБСУДИТЬ на реальном примере с заказчиком, который, кстати, понимает то, что видит, а не то, что блещет словами «Объект», «Триггер», «Сущность» и прочее. Но в комментарии этого всего не изложишь. Вектор я вроде бы задал. Дальше вроде бы понятно =)
Тут автоматически всплывают вопросы:
1) какого рода должна быть система?
а) По принципу работы (распределенная по нескольким станциям на основе задач / Сконцентрирована в одном месте / Управляемая из одного центра и с миграцией задач между станциями / прочее)?
б) По объему обрабатываемых данных (мало / много / очень много / ппц как много)?
в) По возможности влияния на тип входных и выходных данных (мы / не мы / частично мы / по большей части мы)?
г) По времени работы системы?
д) многое другое?
2) известно ли нам что должно в результате получиться?
3) Каково отношение нас к поставленной задаче?
Итого: Встает много вопросов уже после ответов на приведенные вопросы. А потом еще будут. А вектор не известен. А результат требуют. Зачастую, чтобы понять и самим узкие места ДО подписания убийственных бумаг полезно сделать прототип (кстати, копните в RUP, про управление проектами, а в частности про то, как выиграть проект в конкурсе), или, если есть время — несколько прототипов, чтобы ПРЕДПОЛОЖИТЬ что к чему и ОБСУДИТЬ на реальном примере с заказчиком, который, кстати, понимает то, что видит, а не то, что блещет словами «Объект», «Триггер», «Сущность» и прочее. Но в комментарии этого всего не изложишь. Вектор я вроде бы задал. Дальше вроде бы понятно =)
Из собственного опыта (наша компания делает сайты, в основном с нестандартными запросами, для них мы и используем проектирование): очень часто к нам приходят клиенты и говорят примерно следующее: «У меня есть деньги, я хочу сайт для продажи слонов, что вы можете мне предложить?». Естественно мы в этом случае высылаем ему небольшую анкетку, говорим голосом и после делаем коммерческое предложение, но что именно нужно сделать — остается не совсем понятным… мы знаем, в данном случае тип сайта и список основного функционала, но не более. После этого, мы начинаем именно проектировать: исследуем конкурентов заказчика, постоянно предлагаем ему разные идеи реализации и слушаем его идеи, создаем макеты страниц с расположением блоков и т.д. и т.п.
В результате таких вот действий, у нас появляется довольно внушительный документ, который мы называем ТЗ. В нем есть: полное видение концепции, описание всего функционала до мельчайших подробностей, схематические макеты расположения элементов на странице, требования к документации и т.д. Буквально все, что необходимо.
Для примера: недавно делали корпоративный сайт для довольно крупной многопрофильной компании, сайт, конечно, не совсем стандартный, там был и календарь записи на тренинги, и социальные элементы и некоторые другие функции, так вот наше ТЗ вышло примерно в 150 страниц!!! Хоть и делали мы его долго, зато процесс разработки пошел как по маслу: пришлось переделать всего несколько элементов в дизайне и функционале. В результате сайт получится конфеткой. Так что проектирование — очень важная штука!
В результате таких вот действий, у нас появляется довольно внушительный документ, который мы называем ТЗ. В нем есть: полное видение концепции, описание всего функционала до мельчайших подробностей, схематические макеты расположения элементов на странице, требования к документации и т.д. Буквально все, что необходимо.
Для примера: недавно делали корпоративный сайт для довольно крупной многопрофильной компании, сайт, конечно, не совсем стандартный, там был и календарь записи на тренинги, и социальные элементы и некоторые другие функции, так вот наше ТЗ вышло примерно в 150 страниц!!! Хоть и делали мы его долго, зато процесс разработки пошел как по маслу: пришлось переделать всего несколько элементов в дизайне и функционале. В результате сайт получится конфеткой. Так что проектирование — очень важная штука!
Не записывайте изучение предметной области в проектирование.
Изучение предметной области — есть начальный этап проектирования.
ТЗ может написать и человек, который знает предметную область. Написание ТЗ и проектирование — разные вещи.
В утверждении и согласовании ТЗ просто обязаны принимать участие люди от исполнителя проекта, котоыре знакомы с разработкой (это либо аналитики, либо архитекторы, либо ведущие программисты). Иначе если Вам ТЗ напишет человек, не знакомый с программированием, или человек, которому это дальше не писать, то вы по этому ТЗ не сможете написать реальную систему, потому что это чисто теоретически даже невозможно будет сделать. И вот как раз на этапе согласования ТЗ должны вносится изменения в него, дабы потом было что реализовывать.
Или Вы у себя в команде сначала подписываете контракт с заказчиком, а потмо открываете его ТЗ?
Или Вы у себя в команде сначала подписываете контракт с заказчиком, а потмо открываете его ТЗ?
Вы никогда не разрабатывали продукты для финансового сектора? ТЗ пишет аналитик, который вообще не шарит, как это потом будет спроектировано. Его задача — написать решение его проблем.
Разрабатывал. В этом и проблема, что большинство аналитиков не шарит как это будет спроектировано, а должны бы — настолько бы меньше проблем было!
Немножко хочу вмешаться в ваш разговор :)
Клиент многое не знает, но тем не менее часто пытается написать ТЗ, потом он присылает ТЗ разработчикам, оно представляется из себя отдаленное видение системы, которую хочет получить клиент… далее хороший разработчик берет это «ТЗ» и существенно дорабатывает его, доводит до совершенства совместно с клиентом, при этом каждый делает ту часть, которую хорошо знает: клиент в основном говорит с точки зрения своего бизнеса, а разработчик пытается понять его бизнес и говорит в основном с точки зрения технологий. Профит: отличная система, которая решает бизнес-задачу(и).
Клиент многое не знает, но тем не менее часто пытается написать ТЗ, потом он присылает ТЗ разработчикам, оно представляется из себя отдаленное видение системы, которую хочет получить клиент… далее хороший разработчик берет это «ТЗ» и существенно дорабатывает его, доводит до совершенства совместно с клиентом, при этом каждый делает ту часть, которую хорошо знает: клиент в основном говорит с точки зрения своего бизнеса, а разработчик пытается понять его бизнес и говорит в основном с точки зрения технологий. Профит: отличная система, которая решает бизнес-задачу(и).
У… так вы далеко уйдете.
Я много разных ТЗ видел. Такие мне больше всего нравятся.
Я тоже видел такие ТЗ. Обычно хороши тем, что можно наворотить откровенной фигни и потом отмазаться со словами «в ТЗ написано, что слон должен быть розовым — получите розового слона, а то, что краска смывается — это не наша проблема».
Мне они нравятся тем, что там нет псевдо-мишуры, которая больше отвлекает, чем помогает.
Приведите пример «мишуры»?
К примеру, нужно было описать цвет автомобиля. Составитель ТЗ решил проявить инициативу и описать все в объектном виде. Создал сущность «краска», различные свойства краски, создал «формы покраски», описал объекты применения красок. Постарался на славу, одним словом.
А в реальности достаточно было одного текстового поля, куда бы все заносилось. Потому что фотография все решала.
А в реальности достаточно было одного текстового поля, куда бы все заносилось. Потому что фотография все решала.
А контекст применения данного описания?
Если речь об описании для маляра, то за «одно текстовое поле и фотографию» он бы матерился долго и упорно, а если речь о сайте объявлений, то ваш вариант подходит. Без контекста степень «мишуровости» не оценить.
К тому же, если вам не нравится ТЗ, так выскажите замечания и не согласуйте до их устранения. ТЗ — документ, согласуемый двумя сторонами.
Если речь об описании для маляра, то за «одно текстовое поле и фотографию» он бы матерился долго и упорно, а если речь о сайте объявлений, то ваш вариант подходит. Без контекста степень «мишуровости» не оценить.
К тому же, если вам не нравится ТЗ, так выскажите замечания и не согласуйте до их устранения. ТЗ — документ, согласуемый двумя сторонами.
Для того, чтобы знать что проектировать — нужно изучить предметную область. Иначе вы спроектируете совсем не то, что нужно.
Кстати, и с прототипированием имели дело. Как-то клиент прислал довольно большой прототип своего портала, на чистом html. Мы оценили, сделали предложение, клиент согласился, говорит: «Работаем!». Но прототип же не сделаешь приложением к договору!? Нужно писать по нему техническое задание, которое будет приложением к договору и по которому юридически будет приемка работ! Ну значит пишем мы по этому прототипу короткое ТЗ, клиент торопит, мол формальность, не тяните резину. Потом присылаем ему это ТЗ для утверждения, он вспоминаем: «А я ж еще и вот это хотел!? И это добавьте! И еще тут поменяйте...». Клиент — король, дополнения вполне дельные, на пользу порталу, мы включаем…
Процесс разработки таил много сюрпризов. Сначала начались сюрпризы у нас внутри: программист делает по прототипу и смотрит в ТЗ, видит что в ТЗ функционал, которого нет в прототипе, идет к менеджеру проекта с вопросом, на что получает логичный ответ: «Делай как в ТЗ, это новое требование клиента»… дальше идет разбирательство как все-таки это делать, ведь ТЗ не точное, клиент вроде говорил работать по прототипу и сильно торопил, а ТЗ делалось для договора… далее сыпятся вопросы клиенту, в основном чтобы он окончательно утвердил, а клиент как всегда не торопится… далее серьезное затягивание сроков… На этом проблемы не заканчиваются: далее у команды появляются вопросы по прототипу — он ведь не рабочий сайт с которого нужно копировать, он только образно показывает как должно быть и то не все… схема: программист — менеджер проекта — клиент опять повторяется, сроки опять затягиваются.
Подходит срок сдачи проекта — проект не готов, клиент звонит и говорит: «Где проект? Мне нужно сегодня показывать директору?», на что получает логичный ответ: «Вы конечно извините, но проект еще не готов, мы с Вами многие моменты на лету обсуждали и не очень та и быстро, прототип — это не работающий сайт»…
В общем все это закончилось сданным проектов, но не в срок и кучей негатива от клиента. Не знаю как кому, но мне подход прототипирования явно не нравится!
Процесс разработки таил много сюрпризов. Сначала начались сюрпризы у нас внутри: программист делает по прототипу и смотрит в ТЗ, видит что в ТЗ функционал, которого нет в прототипе, идет к менеджеру проекта с вопросом, на что получает логичный ответ: «Делай как в ТЗ, это новое требование клиента»… дальше идет разбирательство как все-таки это делать, ведь ТЗ не точное, клиент вроде говорил работать по прототипу и сильно торопил, а ТЗ делалось для договора… далее сыпятся вопросы клиенту, в основном чтобы он окончательно утвердил, а клиент как всегда не торопится… далее серьезное затягивание сроков… На этом проблемы не заканчиваются: далее у команды появляются вопросы по прототипу — он ведь не рабочий сайт с которого нужно копировать, он только образно показывает как должно быть и то не все… схема: программист — менеджер проекта — клиент опять повторяется, сроки опять затягиваются.
Подходит срок сдачи проекта — проект не готов, клиент звонит и говорит: «Где проект? Мне нужно сегодня показывать директору?», на что получает логичный ответ: «Вы конечно извините, но проект еще не готов, мы с Вами многие моменты на лету обсуждали и не очень та и быстро, прототип — это не работающий сайт»…
В общем все это закончилось сданным проектов, но не в срок и кучей негатива от клиента. Не знаю как кому, но мне подход прототипирования явно не нравится!
Потому что таких продажников как у вас надо в шею гнать. Не прототипы виноваты в том, что кто-то вовремя не остановил заказчика дополнительным счетом на оплату услуг.
Простите, а на каком основании будет этот счет?
Дополнительный счет был, это обычно не останавливает клиентов у которых есть цель сделать максимально качественный продукт.
Да и речь не о том, это не такая большая проблема в данном случае. Основной срыв сроков был именно из-за прототипа.
Конечно, не буду спорить, может дело именно в нас, т.к. мы не работаем с прототипами, а в основном с проектированием. Но люди ведь не глупые: если бы можно было обойтись без вопросов и «просто делать» — срыва сроков не было бы.
Да и речь не о том, это не такая большая проблема в данном случае. Основной срыв сроков был именно из-за прототипа.
Конечно, не буду спорить, может дело именно в нас, т.к. мы не работаем с прототипами, а в основном с проектированием. Но люди ведь не глупые: если бы можно было обойтись без вопросов и «просто делать» — срыва сроков не было бы.
А ларчик просто открывался — в статье, на которую вы ссылаетесь, речь шла о продуктовой разработке, а у вас, похоже, заказной.
Большинство участников таких дискуссий, (как тут принято говорить, «95%» :) ) похоже, просто не знакомы с фундаментальными различиями в этих рынках.
Из этих различий проистекает и разность подходов к разработке.
Большинство участников таких дискуссий, (как тут принято говорить, «95%» :) ) похоже, просто не знакомы с фундаментальными различиями в этих рынках.
Из этих различий проистекает и разность подходов к разработке.
Да разница между ними небольшая.
да, казалось бы, на уровне бабла, небольшая — в продуктовой разработке вы сначала сливаете деньги, а потом зарабатываете (если повезёт), а в заказной вы сначала продаёте услуги, получаете бабло (зарабатываете), а потом сливаете (платите зарплату)
но для процесса, как оказывается, огромная :)
ладно, напишу отдельным постом, поговорим
но для процесса, как оказывается, огромная :)
ладно, напишу отдельным постом, поговорим
Хотелось бы услышать, поговорим.
Ну вот как бы не прошло и года: www.slideshare.net/maieutic/4-9323615
Лично мне не импонирует вообще формула рентабельности. Она имеет существенный недостаток — не учитывает деньги. Не расходы, а именно доходную часть. Чтобы получить рентабельность проекта, нужно, чтобы прибыль превышала банковский процент. Желательно многократно. При данном условии нет разницы, какую бизнес-модель или модель изготовления продукта или сервиса выбирать. В этой формуле еще стоит учитывать актуальность решаемой задачи. В одной из самых первых моих статей я приводил график, который наглядно показывает, что если пропустить точку максимального развития или нагрева рынка, или развития какой-либо технологии, то дальнейшие капиталовложения будут рентабельными по вашей форуле, но не рентабельными в реальности.
Да и время входит в стоимость.
Да и время входит в стоимость.
Конечно тут для процесса разница огромна. Полностью согласен.
beskov, читал у вас в блоге список литературы для аналитиков, а можете что нибудь посоветовать на тему проектных технологий по внедрению и адаптации готового ПО?
Ох, не хотел я ввязываться в обсуждение этих двух тем про проектирование, ох не хотел :)
В общем, как тут уже сами авторы статей заметили в комментариях — (Первая мысль) прототипирование — это только один из способов проектирования. На мой взгляд, автор первой статьи хотел донести некоторые моменты из Getting Real, что нужно избежать ситуации, когда люди продолжают «проектировать» даже тогда, когда уже можно приступать к реализации прототипа.
Далее, хочу сказать про прототип — прототип можно рассматривать с двух разных позиций — прототипом может являться как набор интерфейсов, в которые заложена модель предметной области, его можно использовать для демонстрации заказчикам системы, чтобы сразу выявить несоответствия. И это очень ценная вещь. Также, прототипом может быть каркас (в архитектурном смысле) будущей системы, который «наводит на мысли» архитекторов проекта. И это не менее ценная вещь. И ни то, ни другое не имеет ничего общего с написанием документации, а является способом достижения результата проекта. Итак — Вторая мысль — прототипирование != проектирование и они друг друга не взаимозаменяют, а одно является способом достижения другого.
Далее, моя точка зрения — качество кода и количество костылей не зависит от подхода, а зависит от грамотности менеджера проектов, тимлида и архитекторов. Ну и самих разработчиков тоже, но прежде всего все же от вышеперечисленных управленцев. Прототип — это не обязательно сырой и нерабочий код с костылями, и многие части вполне могут быть перенесены в рабочий проект. За тем насколько прототип подходит для переноса в продакшн-ветку репозитория проекта следит менеджер проекта или тимлид. Прототип вполне может содержать рабочий код, покрытый тестами и содержащий все комментарии.
Странно также, что ни слова не сказано о разных аспектах проектов — есть «системная» часть, платформа, основа для системы, а есть прикладная часть, отвечающая за предметную область. И без детального рассмотрения второго (требований предметной области) очень сложно сформировать требования для самой платформы.
> «либо вносить изменения в существующий код, но это все равно редактирование существующего кода, это внесение новых ошибок и трата времени программистов»
С такой мыслью в корне не согласен. Неужели кто-то думает, что написанный однажды код никогда не будет меняться? Будет в любом случае, поэтому использование прототипа в рабочем проекте чаще всего хорошая идея. И да, рефакторинг — это не пустое слово. По крайней мере должно быть таким в серьезном проекте.
Раз уж тема тесно связана с архитектурой в принципе (проектирование вообще очень связано с архитектурой) — могу заодно посоветовать почитать про Onion Architecture.
Мыслей, как обычно, миллион, но надо когда-то остановиться :)
Хочу отметить, что меня всегда умиляют то и дело всплывающие аргументы, что «архитектор должен быть талантливым, а то все пойдет прахом» или «новые разработчики нахерачат невесть чего, если не будет документации». Новые разработчики в любом случае нахреначат невесть чего, независимо от того, сколько вы проектировали или прототипировали, писали ли документацию или тесты, или нет.
Поэтому не стоит поднимать подобные темы в отрыве от контекста. Давайте предполагать, что архитектор неуч — и у нас при любом подходе получится говно, а не проект. Давайте предполагать, что команда безмерно талантлива, и, поверьте, они справятся с проектом, и, если надо, выяснят детали у заказчиков, и создадут нужные прототипы. И поэтому — Третья мысль — в любом случае все нужно делать с головой.
В общем, как тут уже сами авторы статей заметили в комментариях — (Первая мысль) прототипирование — это только один из способов проектирования. На мой взгляд, автор первой статьи хотел донести некоторые моменты из Getting Real, что нужно избежать ситуации, когда люди продолжают «проектировать» даже тогда, когда уже можно приступать к реализации прототипа.
Далее, хочу сказать про прототип — прототип можно рассматривать с двух разных позиций — прототипом может являться как набор интерфейсов, в которые заложена модель предметной области, его можно использовать для демонстрации заказчикам системы, чтобы сразу выявить несоответствия. И это очень ценная вещь. Также, прототипом может быть каркас (в архитектурном смысле) будущей системы, который «наводит на мысли» архитекторов проекта. И это не менее ценная вещь. И ни то, ни другое не имеет ничего общего с написанием документации, а является способом достижения результата проекта. Итак — Вторая мысль — прототипирование != проектирование и они друг друга не взаимозаменяют, а одно является способом достижения другого.
Далее, моя точка зрения — качество кода и количество костылей не зависит от подхода, а зависит от грамотности менеджера проектов, тимлида и архитекторов. Ну и самих разработчиков тоже, но прежде всего все же от вышеперечисленных управленцев. Прототип — это не обязательно сырой и нерабочий код с костылями, и многие части вполне могут быть перенесены в рабочий проект. За тем насколько прототип подходит для переноса в продакшн-ветку репозитория проекта следит менеджер проекта или тимлид. Прототип вполне может содержать рабочий код, покрытый тестами и содержащий все комментарии.
Странно также, что ни слова не сказано о разных аспектах проектов — есть «системная» часть, платформа, основа для системы, а есть прикладная часть, отвечающая за предметную область. И без детального рассмотрения второго (требований предметной области) очень сложно сформировать требования для самой платформы.
> «либо вносить изменения в существующий код, но это все равно редактирование существующего кода, это внесение новых ошибок и трата времени программистов»
С такой мыслью в корне не согласен. Неужели кто-то думает, что написанный однажды код никогда не будет меняться? Будет в любом случае, поэтому использование прототипа в рабочем проекте чаще всего хорошая идея. И да, рефакторинг — это не пустое слово. По крайней мере должно быть таким в серьезном проекте.
Раз уж тема тесно связана с архитектурой в принципе (проектирование вообще очень связано с архитектурой) — могу заодно посоветовать почитать про Onion Architecture.
Мыслей, как обычно, миллион, но надо когда-то остановиться :)
Хочу отметить, что меня всегда умиляют то и дело всплывающие аргументы, что «архитектор должен быть талантливым, а то все пойдет прахом» или «новые разработчики нахерачат невесть чего, если не будет документации». Новые разработчики в любом случае нахреначат невесть чего, независимо от того, сколько вы проектировали или прототипировали, писали ли документацию или тесты, или нет.
Поэтому не стоит поднимать подобные темы в отрыве от контекста. Давайте предполагать, что архитектор неуч — и у нас при любом подходе получится говно, а не проект. Давайте предполагать, что команда безмерно талантлива, и, поверьте, они справятся с проектом, и, если надо, выяснят детали у заказчиков, и создадут нужные прототипы. И поэтому — Третья мысль — в любом случае все нужно делать с головой.
Как-то работал в компании где до меня программа писалась… для простоты будем считать что 5 лет.
Это была телефония, и это было куча модулей конечного оборудования к которым мы подключаемся через ISA шину.
Потом начали подключаться через сокеты. Потом появилось просто вот НОВОЕ оборудование, голосовые кодеки какие-то и так далее — сущности не предсказанные изначально.
Система работала как часы. Да только иногда считала RTP потоки SIPа раздельными радиоканалами базовой станции( ну а какая в принципе разница? )
Костылей было относительно мало. Ну разве только моя часть E1 была абсолютно автономной и общалась с со своим коннектором(врапером) в головной системе по сокетам.
Ну так про что я :)
Вот эту замечательную систему, которую писали ГОДЫ, и в которой было все хорошо и очень красиво — ООП, шедулеры, Сайбейз и кросплатформеность… Мы ее перепроектировали.
Заняло всего три месяца. Система стала примерно в 20 раз меньше в обьеме по любому измерению и в теже самые 20 раз стабильнее…
А суть сей басни такова: сколько не проектируй — через месяц после начала внедрения все равно поймешь что что-то не так, или просто придумаешь как можно было сделать лучше.
Это была телефония, и это было куча модулей конечного оборудования к которым мы подключаемся через ISA шину.
Потом начали подключаться через сокеты. Потом появилось просто вот НОВОЕ оборудование, голосовые кодеки какие-то и так далее — сущности не предсказанные изначально.
Система работала как часы. Да только иногда считала RTP потоки SIPа раздельными радиоканалами базовой станции( ну а какая в принципе разница? )
Костылей было относительно мало. Ну разве только моя часть E1 была абсолютно автономной и общалась с со своим коннектором(врапером) в головной системе по сокетам.
Ну так про что я :)
Вот эту замечательную систему, которую писали ГОДЫ, и в которой было все хорошо и очень красиво — ООП, шедулеры, Сайбейз и кросплатформеность… Мы ее перепроектировали.
Заняло всего три месяца. Система стала примерно в 20 раз меньше в обьеме по любому измерению и в теже самые 20 раз стабильнее…
А суть сей басни такова: сколько не проектируй — через месяц после начала внедрения все равно поймешь что что-то не так, или просто придумаешь как можно было сделать лучше.
Robert Martin однажды высказал схожую мысль.
Изменения требований влияют на проект. Из-за этого проект начинает обрастать костылями, появляются неиспользуемые участки кода, которые забыли удалить и прочее.
В итоге он рекомендует переписывать любой проект, переосмысляя бизнес-требования, раз в 6-7 лет.
Ключевые участки кода, которые чаще всего претерпевали изменения — раз в 3-4 года.
Это достаточное время для того, чтобы словить все шишки и иметь представление о том, как сделать правильно.
kashey, согласен с вами на все сто!
Изменения требований влияют на проект. Из-за этого проект начинает обрастать костылями, появляются неиспользуемые участки кода, которые забыли удалить и прочее.
В итоге он рекомендует переписывать любой проект, переосмысляя бизнес-требования, раз в 6-7 лет.
Ключевые участки кода, которые чаще всего претерпевали изменения — раз в 3-4 года.
Это достаточное время для того, чтобы словить все шишки и иметь представление о том, как сделать правильно.
kashey, согласен с вами на все сто!
Зеркальность мнений говорит в основном о том, что ситуации бывают разные, а не о том, что кто-то в корне не прав. Мне эта тема довольно близка, на AddConf2010 делал доклад на смежную тему.
Если вкратце, к тезису «Каждому проекту своя методология» кроме «и архитектура» сложно что-либо добавить.
От себя скажу, что в одном проекте где-то на 90 человеко-лет основные проблемы были как в излишне «красивой» архитектуре так и в чрезмерном увлечении чистыми прототипами.
В других проектах было по-разному, но чаще всего сталкивался с задачами, к которым continuous design вполне применим.
Если вкратце, к тезису «Каждому проекту своя методология» кроме «и архитектура» сложно что-либо добавить.
От себя скажу, что в одном проекте где-то на 90 человеко-лет основные проблемы были как в излишне «красивой» архитектуре так и в чрезмерном увлечении чистыми прототипами.
В других проектах было по-разному, но чаще всего сталкивался с задачами, к которым continuous design вполне применим.
А как определить, какая методология лучшим способом подойдет к данному продукту?
Приведу классическую ссылку по теме (хоть ее и наверняка все читали) —
Каждому проекту своя методология (Алистер Коберн): citforum.ru/SE/project/meth_per_project
Также, на мой взгляд, полезно прочитать в этом ключе еще две статьи (вторая на английском и достаточно спорная — приведенные аргументы сильно зависят от ситуации):
Проектирования больше нет? (Мартин Фаулер): citforum.ru/SE/project/design_dead
Continuous Design (Джим Шо): www.martinfowler.com/ieeeSoftware/continuousDesign.pdf
P.S. От себя добавлю, что есть и большая зависимость от команды, потому что не для каждого проекта можно ее подобрать индивидуально. Например, для критичных краткосрочных проектов использовать неопробованную методологию довольно опасно.
Каждому проекту своя методология (Алистер Коберн): citforum.ru/SE/project/meth_per_project
Также, на мой взгляд, полезно прочитать в этом ключе еще две статьи (вторая на английском и достаточно спорная — приведенные аргументы сильно зависят от ситуации):
Проектирования больше нет? (Мартин Фаулер): citforum.ru/SE/project/design_dead
Continuous Design (Джим Шо): www.martinfowler.com/ieeeSoftware/continuousDesign.pdf
P.S. От себя добавлю, что есть и большая зависимость от команды, потому что не для каждого проекта можно ее подобрать индивидуально. Например, для критичных краткосрочных проектов использовать неопробованную методологию довольно опасно.
Что работало для нас:
— накидали на бумаге основные идеи функциональности и дизайна
— сделали HTML/CSS/jQuery макет (с дизайном, шедшим в ASP.NET MVC по умолчанию) с тестовыми данными, записанными прямо в коде и в JSON-файлах — никой базы данных, никакой бизнес логики
— обсудили, переделали, убрали лишнее, что-то добавили
— убрали (закомментировали в коде) все, без чего можно обойтись в первом релизе, оставили самый минимум
— написали логику, базу, в общем все «кишки»
— сейчас идет интенсивное тестирование, пройден пик открытых/исправленных багов
Я вам скажу — если бы мы не применили такой подход, первого релиза нам было бы не видать еще не известно сколько времени.
P.S. 37 Sgnals rules! ;)
— накидали на бумаге основные идеи функциональности и дизайна
— сделали HTML/CSS/jQuery макет (с дизайном, шедшим в ASP.NET MVC по умолчанию) с тестовыми данными, записанными прямо в коде и в JSON-файлах — никой базы данных, никакой бизнес логики
— обсудили, переделали, убрали лишнее, что-то добавили
— убрали (закомментировали в коде) все, без чего можно обойтись в первом релизе, оставили самый минимум
— написали логику, базу, в общем все «кишки»
— сейчас идет интенсивное тестирование, пройден пик открытых/исправленных багов
Я вам скажу — если бы мы не применили такой подход, первого релиза нам было бы не видать еще не известно сколько времени.
P.S. 37 Sgnals rules! ;)
Sign up to leave a comment.
Надо ли тратить время на проектирование?