Комментарии 27
Типа как опера постоянно выпускает недельные сборки своего браузера?
В чем смысл делать даже ежедневные билды - мне понятно. Непонятно, в чем смысл их выпускать публично.
В том случае, если это preview, предварительная версия - понятно. Энтузиасты скачают, посмотрят, потестируют. А если не предварительная? Надо ли ее качать всем пользователям? Или подождать (чего? ведь все версии будут короткими).
В том случае, если это preview, предварительная версия - понятно. Энтузиасты скачают, посмотрят, потестируют. А если не предварительная? Надо ли ее качать всем пользователям? Или подождать (чего? ведь все версии будут короткими).
ежедневные билды делаются для исправления ошибок. Вы, видимо, багрепорты не отправляли просто =). Отправляешь багрепорт. Получаешь на емейл лейбл "fixed", спешно сливаешь последний билд - и смотришь - заработало так как надо или нет. Особенно это акуально для тех кто сам поправить положение вещей не может, залезая в исходный код.
Хм... Что значит "заработало так как надо или нет". Если fixed - то естественно заработало. Мы же тестируем. И если пользователи отправляли багрепорты, при выпуске билда будут исправлены ВСЕ известные ошибки, а не по одной.
блин ну подумайте вы чуть шире. Софт бывает разный. Пользователи тоже. Например: "ааааа у меня этот документ не открывается". "Оо. это баг, с документами которые сохранены в ночное время!!". "Баг починили - качайте последний билд и у вас все заработает".
Бывают ошибочки которые не столь важны для всех пользоватлеей сразу, но очень важны для тех кто их заметил (что, впринципе, очевидно). Делая релиз после каждого такого исправления - будете портить нервы большей части пользователей, но радовать тех кто баг обнаружил.
Бывают ошибочки которые не столь важны для всех пользоватлеей сразу, но очень важны для тех кто их заметил (что, впринципе, очевидно). Делая релиз после каждого такого исправления - будете портить нервы большей части пользователей, но радовать тех кто баг обнаружил.
вы имеете ввиду частые _релизы_ или частые _билды_ ?
Не могу ничего ответить по сути вашего вопроса, но я думаю что тут могут быть 2 случая:
1) Раздражение от того, что все время что-то не работает, приходится обращаться постоянно к разработчикам и фиксить ошибки. По сути - выполнять работу, которая мне не нравится, но отнимает время и не платят за нее деньги.
2) Появление ощущения своей причастности к разработке программы, её отладки и т.д. А это может вылиться в привязанность к продукту и появлении бесплатного пиар-ресурса.
1) Раздражение от того, что все время что-то не работает, приходится обращаться постоянно к разработчикам и фиксить ошибки. По сути - выполнять работу, которая мне не нравится, но отнимает время и не платят за нее деньги.
2) Появление ощущения своей причастности к разработке программы, её отладки и т.д. А это может вылиться в привязанность к продукту и появлении бесплатного пиар-ресурса.
Мне кажется, что мелкие релизы в качестве основного пути развития продукта означают что продукт уже сформировался и ничего принципиально нового тут ждать не стоит. В этом случае фичи обычно не связаны между собой, поэтому держать их в системе контроля версий годами смысла нет - лучше или продуманее они от этого не станут.
Если компания параллельно с мелкими релизами не готовит что-то грандиозное - дела продукта плохи. Модернизируя каждые несколько месяцев самолет (который каждый раз летает и даже лучше прежнего) мы на Луну не улетим никогда :-)
Если компания параллельно с мелкими релизами не готовит что-то грандиозное - дела продукта плохи. Модернизируя каждые несколько месяцев самолет (который каждый раз летает и даже лучше прежнего) мы на Луну не улетим никогда :-)
Имеются в виду не публичные релизы, если вы так волнуетесь о публичности. XP вообще не следует разрывать на кусочки, пытаясь понять, а тем паче употребить каждый из них в отдельности.
Small Releases предназначены для заказчика (customer) в том смысле, в котором это опредляет методология XP, то есть пользователя, или группы пользователей, интересы которых решает продукт, но при присутсвии заказчика релизить продукт в обычном смысле этого слова, наверняка, не стоит. В идеальном варианте заказчик практически является частью команды, и его задача - эти самые релизы оценивать.
Да, Opera, похоже, идет по пути публикации своих релизов для широких масс, ибо заинтересованы в ранних билдах браузера в основном хорошо прокачанные веб-мастера, которые, в частности, могут дать адекватные оценки билдам. Частые публичные релизы в этом случае одновременно интегрируют в команду разрабочтиков армию хороших тестеров и берегут нервы оных. Если их завалить фичами, они просто не успеют их все пощупать.
Small Releases предназначены для заказчика (customer) в том смысле, в котором это опредляет методология XP, то есть пользователя, или группы пользователей, интересы которых решает продукт, но при присутсвии заказчика релизить продукт в обычном смысле этого слова, наверняка, не стоит. В идеальном варианте заказчик практически является частью команды, и его задача - эти самые релизы оценивать.
Да, Opera, похоже, идет по пути публикации своих релизов для широких масс, ибо заинтересованы в ранних билдах браузера в основном хорошо прокачанные веб-мастера, которые, в частности, могут дать адекватные оценки билдам. Частые публичные релизы в этом случае одновременно интегрируют в команду разрабочтиков армию хороших тестеров и берегут нервы оных. Если их завалить фичами, они просто не успеют их все пощупать.
Ну, речь идет именно о коммерческом софте, который продается, а не разрабатывается на заказ. С интеграцией заказчика в процесс разработки я очень даже согласен и small releases здесь естественно нужны и важны.
В том случае, который я рассматриваю (и случай Opera тут, похоже, тоже подходит) как такового заказчика нет, но есть группа фанатов, которая следит, голосует и высказывается.
Однако короткие релизы выпускаются не для них а вообще для всех, публично. И продаются.
В том случае, который я рассматриваю (и случай Opera тут, похоже, тоже подходит) как такового заказчика нет, но есть группа фанатов, которая следит, голосует и высказывается.
Однако короткие релизы выпускаются не для них а вообще для всех, публично. И продаются.
Если честно продавать короткие релизы как-то странно. Это может быть нормально когда вы "продаете" доступ в виде ключа к скачиваемому продукту, а делать такое для какой-либо коробочной версии на любом носителе - имхо не стоит, потому как в коробке клиент ожидает качественный продукт, а если при запуске ему сообщают что версия продукта v1.07-smallrelease-324 build 259 (11.10.2007) то очень многие задумаются - "а что это я купил - бета версию, и за свои деньги я им еще баги буду вылавливать ?"
Для коротких релизов мне кажется лучше делать авто-обновления (мы не практикуем к сожалению таких релизов и поэтому мое мнение может быть достаточно субъективно), т.е. есть минимум 2 ветки (например как у uTorrent) - одна стабильный продакшен 1.6 и ветка 1.7betaX
Соответственно продакшен не проверяет автоматически обновления вообще, только по явному вызову. Бета версия же наоборот - проверяет всегда ( желательно с возможностью отключить эту фичу или перевести в разряд уведомлений - например как в XP - неплохо сделан автоапдейт).
Для коротких релизов мне кажется лучше делать авто-обновления (мы не практикуем к сожалению таких релизов и поэтому мое мнение может быть достаточно субъективно), т.е. есть минимум 2 ветки (например как у uTorrent) - одна стабильный продакшен 1.6 и ветка 1.7betaX
Соответственно продакшен не проверяет автоматически обновления вообще, только по явному вызову. Бета версия же наоборот - проверяет всегда ( желательно с возможностью отключить эту фичу или перевести в разряд уведомлений - например как в XP - неплохо сделан автоапдейт).
Пардон, я не пояснил. "Продавать короткие релизы" не значит, что за каждый из них денег берут. Чаще всего схема такая - покупается продукт и год апдейтов, потом еще можно по годам апдейты покупать. Т.е. в прямом финансовом смысле клиент не страдает, наоборот даже, он успевает за свой год хоть что-то новенькое получить.
Имхо продукт должен быть очень качественным и развиваться серьезными темпами ( или наполенение должно быть наиболее актуальным, например как тот же Консультант Плюс) чтобы клиент докупал второй\третий год апдейтов. Во всех остальных случаях (если нету требований доступа к "горячим" данным) - докупать год апдейта не очень хочется. За год обычно продукт интегрируется в систему клиента, осваиваются все особенности и баги текущей версии и порядок работы с продуктом уже можно "документировать". В таком случае не видно смысла - зачем апдейтить продукт который будет "на 2 фичи лучше" и иметь возможность "сломать" или порядок работы или интеграцию продукта. Автообновляемые продукты интересны "гикам" или тем, кому обновление критично. В продакшене же наоборот должна быть максимальная стабильность имхо, а "получить что-то новенькое" для большинства серьезных клиентов созвучно с "получить гемморой с текущей работой".
Вы, кстати, планируете заняться, и потому разбираетесь, или уже практикуете?
Мы практикуем длинные мажорные релизы (сначала были по полгода, сейчас уже до года разрослись, т.к. система разрослась), но в то же время минорные релизы с багфиксами и мелкими улучшениями выходят часто (примерно раз в месяц). При этом мы имеем правило исправлять все известные ошибки, т.е. совесть не позволяет нам делать новые фичи не исправив старые баги.
Но XP (agile development) считается модным и конкуренты указывают как преимущество то, что у них major releases (публичные, естественно) часто выходят. Мне интересно выяснить реальные преимущества и недостатки того и другого подхода.
Но XP (agile development) считается модным и конкуренты указывают как преимущество то, что у них major releases (публичные, естественно) часто выходят. Мне интересно выяснить реальные преимущества и недостатки того и другого подхода.
В Agile-методологиях частые релизы практикуются для того, чтобы получить оперативную обратную связь от пользователей. Там все практики направлены на то, чтобы в любой момент времени состояние разрабатываемого продукта было близко к релизному. И для тех компаний, которым важно получать обратную связь от пользователей как можно быстрее, использование Agile является плюсом (и, как правило, преимуществом).
Собственно, это вопрос к вам: насколько вашим пользователям важны частые релизы? Ключевое слово в моем вопросе - "вашим". Поскольку это главное во всей этой истории - это пользователи. Ваши пользователи. Если вам есть что выдавать на гора раз в несколько недель, и получение быстрой обратной связи от пользователей для вас ценно - это супер! Выдавайте и получайте. Если у вас не получается быстро делать фичи и/или быстрая обратная связь пользователей для вас не важна - вряд ли имеет смысл делать чистые релизы. И конкуренты здесь не при чем - главную роль играют пользователи
Собственно, это вопрос к вам: насколько вашим пользователям важны частые релизы? Ключевое слово в моем вопросе - "вашим". Поскольку это главное во всей этой истории - это пользователи. Ваши пользователи. Если вам есть что выдавать на гора раз в несколько недель, и получение быстрой обратной связи от пользователей для вас ценно - это супер! Выдавайте и получайте. Если у вас не получается быстро делать фичи и/или быстрая обратная связь пользователей для вас не важна - вряд ли имеет смысл делать чистые релизы. И конкуренты здесь не при чем - главную роль играют пользователи
в случае публичных релизов, мнээ... тут надо кое-что отметить.
в каком-то смысле это, действительно, бета-тестинг. Но. публичный бета-тестинг подразумевает очень и очень приличное внутреннее тестирование. То есть как минимум регресии нет, а все новое "в основном работает"
и это действительно хороший способ связи с пользователем, в том плане чтобы отследить, а в нужную ли сторону развивается продукт, и вовремя остановиться, если что.
в каком-то смысле это, действительно, бета-тестинг. Но. публичный бета-тестинг подразумевает очень и очень приличное внутреннее тестирование. То есть как минимум регресии нет, а все новое "в основном работает"
и это действительно хороший способ связи с пользователем, в том плане чтобы отследить, а в нужную ли сторону развивается продукт, и вовремя остановиться, если что.
Мне не известно ни одного случая, когда бы при использовании small release вырезались фичи. "В нужную сторону развивается продукт" нужно не следить, а планировать. У кого хорошее видение - создает хороший продукт, у кого плохое - никакой. Пользователей слушать, конечно, нужно. Но не в стиле "они хотят виджет - значит будет виджет". Этак можно сделать совсем не тот продукт, который начинался. Вот, к примеру, захотят пользователи Хабра фотогалерею, и что - делать на Хабре галерею?
ну если "слушать" в таком стиле ("нам виднее, чего пользователи хотят"), тогда можно хоть как релизить, разница небольшая.
я говорю о ситуации, когда делается запланированная функциональность, делается как предполагалось, доводится до более-менее живого состояния и отдается пользователям. После чего появляется обратная связь: "да, клёвая фича, но мы сталкиваемся со следующей проблемой: ..." Как правило, "следующую проблему",которая может быть как недоделкой реализации, так и проектирования, на сайте разработчика предусмотреть/смоделировать сложно.
я говорю о ситуации, когда делается запланированная функциональность, делается как предполагалось, доводится до более-менее живого состояния и отдается пользователям. После чего появляется обратная связь: "да, клёвая фича, но мы сталкиваемся со следующей проблемой: ..." Как правило, "следующую проблему",которая может быть как недоделкой реализации, так и проектирования, на сайте разработчика предусмотреть/смоделировать сложно.
Многий софт с частыми релизами я просто не обновляю, допустим download master - там обновлять уже и добавлять нечего. баги они все-равно не правят - сколько не писал я на форуме
А вот например miranda-im я обновляю сразу - появляются новые фичи, исправляются ошибки - и все полезно.
Лучший на мой взгляд выход - давать пользователям доступ к nightly builds, а сами релизы проводить не очень часто
А вот например miranda-im я обновляю сразу - появляются новые фичи, исправляются ошибки - и все полезно.
Лучший на мой взгляд выход - давать пользователям доступ к nightly builds, а сами релизы проводить не очень часто
> Мне интересно, насколько эта практика имеет смысл и пользу при разработке коммерческих программных продуктов. Нужны ли пользователям на самом деле частые релизы? Какой им интерес выступать, по сути, постоянными бета-тестерами?
Никакого. Но пользователи скорее всего заинетересованы в развитии продукта. Существует опасность, что если команда нацелена на выпуск одного большого релиза в квартал, например, то продукт будет развиваться слишком медленно. Всегда можно сказать — это пойдёт в следующий релиз, в этот уже не успевает собрать и тщательно оттестировать. Ах, релиз через пять месяцев? Ну, простите. И даже такая медлительность не спасёт пользователя от недотестированных багов. Неделя до релиза, и вдруг всплывает критичная проблема или безумно нужная заказчику новая функциональность. Всё равно в релиз что-то добавят, даже с риском продлем на продакшене. Так не лучше ли сразу работать в представлении, что релизиться надо часто?
> Мне представляется, что короткие релизы не позволяют планировать заранее большие изменения. Насколько такая практика способствует (или не способствует) сохранению идейной и архитектурной целостности продукта?
Ну почему? Практически всегда большую функциональность можно разбить на небольшие куски для сборки и выкладки.
И ещё — сложности возникают только при строго последовательной разработке, но кто мешает её распараллелить? Тогда можно часто релизить мелочёвку, и редко — что-то большое и прекрасное.
Я сама именно по такой схеме работаю (http://www.control-freak.ru/tag/packages/), и — получается ведь.
Никакого. Но пользователи скорее всего заинетересованы в развитии продукта. Существует опасность, что если команда нацелена на выпуск одного большого релиза в квартал, например, то продукт будет развиваться слишком медленно. Всегда можно сказать — это пойдёт в следующий релиз, в этот уже не успевает собрать и тщательно оттестировать. Ах, релиз через пять месяцев? Ну, простите. И даже такая медлительность не спасёт пользователя от недотестированных багов. Неделя до релиза, и вдруг всплывает критичная проблема или безумно нужная заказчику новая функциональность. Всё равно в релиз что-то добавят, даже с риском продлем на продакшене. Так не лучше ли сразу работать в представлении, что релизиться надо часто?
> Мне представляется, что короткие релизы не позволяют планировать заранее большие изменения. Насколько такая практика способствует (или не способствует) сохранению идейной и архитектурной целостности продукта?
Ну почему? Практически всегда большую функциональность можно разбить на небольшие куски для сборки и выкладки.
И ещё — сложности возникают только при строго последовательной разработке, но кто мешает её распараллелить? Тогда можно часто релизить мелочёвку, и редко — что-то большое и прекрасное.
Я сама именно по такой схеме работаю (http://www.control-freak.ru/tag/packages/), и — получается ведь.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Публикации
Короткие релизы vs Длинные релизы