Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 32
Про тег
<habracut>не забыли?
Наверняка забыл. А что с ним сделать надо и зачем?
Из документации:
Ваша новость в ленте целиком: могут и заминусовать.
<habracut> Используется только в текстах постов, скрывает под кат часть текста, следующую за тегом (будет написано «Читать дальше»). <habracut text="Подробности" /> Так можно превратить надпись «Читать дальше» в любой текст.
Ваша новость в ленте целиком: могут и заминусовать.
Думаю, вам намекают вставить его в статью после первого абзаца. ;)
Сократил запись в хабе. Это имели в виду?
>servitRM
Как задолбало читать в статьях комменты, таких подсказчиков, как Вы, в топе комментов статей.
Неужели трудно автору в личку написать?
Как задолбало читать в статьях комменты, таких подсказчиков, как Вы, в топе комментов статей.
Неужели трудно автору в личку написать?
По созданию и проектированию сайтов нашел хорошую подборку книг от МИФа
Было бы любопытно увидеть, как Вы проектируете — пошаговый процесс, от и до, на реальных примерах.
Я писал об этом в статье Что такое проектирование сайта и почему его нужно делать (от лица коллеги, потому что не было тогда своего аккаунта на Хабре) и по частям в других постах, но потом остановился, потому что понял, что методика существенно меняется с каждым новым проектом, надеюсь, в лучшую сторону. Общий подход сохранился, но детализация сильно поменялась. Планирую описать её заново с реальным кейсом в ближайшие пару месяцев.
Интересные мысли, но создается впечатление, что автор не знаком с работами классиков Agile, такими, как Кент Бек, Мартин Фаулер, Хенрик Книберг. Не говоря уже о каких-либо более сложных работах в этой области. Успешно применяю, то что можно обощить, как Agile уже около 10-ти лет.
1. Нет критериев эффективности конечного результата.
Как так? Гуглите по запросу «метрики Agile» и найдите, то что наиболее подходит для вас!
2. Непредсказуемость.
Как раз Agile направлен на то, что б получить результат. Но результатом в данном случае является то, что надо бизнесу, причем с точки зрения бизнеса. Мы принимаем за аксиому, что бизнес постоянно изменяется и это требует внесения изменений в ПО. Пример простой, есть компания которая продает скажем ноутбуки, и тут бизнес принимает решение, что нужно продавать еще и планшеты, потому что это перспективный рынок. До того, как появились планшеты бизнес ни на каком проектировании не мог предположить, что нужно такие требования к разработке выдвигать. Понятно, что нужно будет значительную часть системы переписать, но иначе бизнес упустит перспективную возможность, и об этом на этапе проектировании ничего не было известно. При этом, используя метрики и проектирование, можно в течении нескольких дней сказать сколько это времени займет и сколько будет стоить. Что очень хорошо для бизнеса. В Agile бизнес-решения принимает бизнес, а технические решения принимают — программисты. Ответственность в Agile должна приниматься всей командой, включая бизнес, иначе аджайла не будет. Так что аджайл в этом смысле с одной стороны предсказуем — из 20 спринтов последнего проекта, не правильно оценили время мы всего в двух и то из-за полного отсутствия информации.
Дольше и дороже.
Тут я просто ссылку на статью дам, которая все объясняет http://blog.scrumtrek.ru/2011/03/agile-waterfall.html
1. Нет критериев эффективности конечного результата.
Как так? Гуглите по запросу «метрики Agile» и найдите, то что наиболее подходит для вас!
2. Непредсказуемость.
Как раз Agile направлен на то, что б получить результат. Но результатом в данном случае является то, что надо бизнесу, причем с точки зрения бизнеса. Мы принимаем за аксиому, что бизнес постоянно изменяется и это требует внесения изменений в ПО. Пример простой, есть компания которая продает скажем ноутбуки, и тут бизнес принимает решение, что нужно продавать еще и планшеты, потому что это перспективный рынок. До того, как появились планшеты бизнес ни на каком проектировании не мог предположить, что нужно такие требования к разработке выдвигать. Понятно, что нужно будет значительную часть системы переписать, но иначе бизнес упустит перспективную возможность, и об этом на этапе проектировании ничего не было известно. При этом, используя метрики и проектирование, можно в течении нескольких дней сказать сколько это времени займет и сколько будет стоить. Что очень хорошо для бизнеса. В Agile бизнес-решения принимает бизнес, а технические решения принимают — программисты. Ответственность в Agile должна приниматься всей командой, включая бизнес, иначе аджайла не будет. Так что аджайл в этом смысле с одной стороны предсказуем — из 20 спринтов последнего проекта, не правильно оценили время мы всего в двух и то из-за полного отсутствия информации.
Дольше и дороже.
Тут я просто ссылку на статью дам, которая все объясняет http://blog.scrumtrek.ru/2011/03/agile-waterfall.html
Спасибо за комментарий. Я в статье говорю о подходе к разработке сайтов, а не о создании чего бы то ни было вообще в IT. Это узко-направленная оценка, а вы мне привели пример с ноутбуками и планшетами.
К сожалению, в практике разработки сайтов ни разу не сталкивался с тем, о чём вы говорите. Красивая теория, а на самом деле получается «делаем, как получится, получаем, что получится».
Вы сами хоть раз делали сайт, используя Agile и его метрики? Что получилось? Сравнивали с водопадной моделью?
К сожалению, в практике разработки сайтов ни разу не сталкивался с тем, о чём вы говорите. Красивая теория, а на самом деле получается «делаем, как получится, получаем, что получится».
Вы сами хоть раз делали сайт, используя Agile и его метрики? Что получилось? Сравнивали с водопадной моделью?
Agile — методология процесса
Проектирование — этап процесса
Бриф — документ
У вас какой то не академический взгляд на вещи. Как эти разноуровневые сущности можно сравнивать?
Проектирование — этап процесса
Бриф — документ
У вас какой то не академический взгляд на вещи. Как эти разноуровневые сущности можно сравнивать?
Я их сравниваю на уровне подхода к разработке, причём учитываю не только теорию, как вы правильно заметили, обвиняя меня в отсутствии должного академизма, а практику. На мой взгляд, это гораздо ценнее чисто научного подхода.
Как делаются на практике сайты:
1. Начинают с глубокого водопадного проектирования и дальше чётко без всякого agile следуют проекту.
2. Начинают с краткого брифа и дальше каким-то образом по нему идут, чаще всего, водопадно, собирая сайт по структуре разделов и кое-как описанным модулям.
3. Делают вводную — иногда это короткое проектирование, а иногда просто сбор требований — по методике agile и дальше разрабатывают по этой же методике.
Как делаются на практике сайты:
1. Начинают с глубокого водопадного проектирования и дальше чётко без всякого agile следуют проекту.
2. Начинают с краткого брифа и дальше каким-то образом по нему идут, чаще всего, водопадно, собирая сайт по структуре разделов и кое-как описанным модулям.
3. Делают вводную — иногда это короткое проектирование, а иногда просто сбор требований — по методике agile и дальше разрабатывают по этой же методике.
На уровне теории это сравнение действительно несколько спорно, понимаю. Но на уровне практического подхода очень даже.
Проектирование и бриф это вещи направленые на детализацию требований. Если вам все предельно ясно, и вы делаете типовое решение, то можете обойтись без прототипа и приступать к оформлению. Бриф скорей всего вам понадобится, для фиксации особенных клиентских требований.
А будете вы это реализовывать по средством agile методик или водопада, зависит от особенностей проекта. В случае типовых решений водопад имхо предпочтительнее.
А будете вы это реализовывать по средством agile методик или водопада, зависит от особенностей проекта. В случае типовых решений водопад имхо предпочтительнее.
Бриф — да. Проектирование — это не вещь, направленная на детализацию требований. Проектирование — это вещь, направленная на уточнение идеи, построение модели проекта под задачи, инструмент планирования и прогнозирования. Требования — лишь малая часть проекта.
Для меня «уточнение идеи, построение модели проекта под задачи» это и есть детализация требовний. Так как требования это "совокупность утверждений относительно атрибутов, свойств или качеств программной системы, подлежащей реализации". Извините, но я за общепринятую терминологию, которая базируется на теории выведеную из практики.
И требования не «инструмент планирования и прогнозирования», а лишь данные (отправная точка) для этих активностей. Ведь требования бывают разных уровней. Почитайте Коберна.
И требования не «инструмент планирования и прогнозирования», а лишь данные (отправная точка) для этих активностей. Ведь требования бывают разных уровней. Почитайте Коберна.
Проектирование полезно везде, кроме сайтов с бюджетом, не позволяющим проектировать.
Как насчёт заказчика, не желающего проектировать? «Вы профессионалы, я вам плачу, вот и делайте».
Как насчёт заказчика, не желающего проектировать? «Вы профессионалы, я вам плачу, вот и делайте».
*участвовать в проектировании
Заказчик нужен на стадии сбора требований.
Получив требования, вы занимаетесь проектированием.
Получив требования, вы занимаетесь проектированием.
Не уверен, что правильно понял вопрос, но попробую ответить. Участие заказчика — это предоставление необходимой информации — требований, бизнес-задач, о себе, своих продуктах/услугах и т.п. — и потом утверждение проекта. Если он не хочет делать первое, то с ним нельзя работать, а вот если он не хочет делать второе… Это вопрос, конечно, интересный. Не встречался ещё с таким, кто сказал бы: Вот вам миллион, на выходе хочу сайт классный. Как правило, заказчик хочет и способен утвердить ключевые моменты в проекте, а за остальное действительно ответственность берёт на себя разработчик.
Да, как раз речь об ключевых и не ключевых моментах. Ключевые собрали, начали проектировать, но оказывается какой-то важный момент опущен, а заказчик не может сейчас его прояснить. Останавливать проектирование и ждать заказчика? Начинать выполнять то, что уже ясно, до конца проект на разработав? Принимать решение за заказчика?
Александ, извините, но то, что вы называете «Agile» — таковым не является. Создаётся впечатление, что вы абсолютно не понимаете, о чем пишете. «Agile как метод создания сайта» — простите, но это бред. Первое, что нужно уяснить: Agile — это философия и в некоторой мере методология, но никак не «способ создания сайтов». Может, стоило сначала разобраться в предмете?
Понимаю, но смотрю на это под несколько иным углом. Я вижу и считаю, что есть такой метод подхода к разработке сайта: разработчики садятся и начинают делать сайт кусками и по ходу смотрят, что получится. Вы можете забросать меня цитатами из Википедии или scrum-сайтов, говорить о философии, феноменологическом подходе, спорить по терминологии, но это не меняет сути дела. Я написал не о теоретической трактовке, а о реальном практическом применении.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сравнение подходов к созданию сайта: проектирование, бриф и agile