Comments 13
Вторая картинка это практически образец того, как не надо делать, если хочешь инкрементальности для пользователя. Между мотоциклом и автомобилем нет ничего общего, за исключением двигателя внутреннего сгорания. Значительная часть пользователей после такого того, как им вместо мотоцикла предложат автомобиль, которым к тому же придётся заново учиться управлять, просто молча уйдёт и никогда не вернётся.
Думаю метафора на второй картинке подразумевала немного другое. Имеется ввиду, что стоит выпустить концептуально тот продукт, что планируется, а доводку до идеала производить в процессе.
Многие же сталкиваются с тем, что видят только начальный и конечный этап не представляя промежуточный, что и приводит к долгостроям.
Многие же сталкиваются с тем, что видят только начальный и конечный этап не представляя промежуточный, что и приводит к долгостроям.
Многие же сталкиваются с тем, что видят только начальный и конечный этап не представляя промежуточный, что и приводит к долгостроям.
То есть мотоцикл это концептуально тот же продукт, что и автомобиль, а автомобиль это просто мотоцикл, доведённый до идеала? И промежуточных этапов между ними не должно быть?
Концептуально пользователь хочет ехать. А скорость и комфорт будут достигнуты с новыми версиями.
Да картинка от samsdemon лучше показывает суть, но и та, что в посте также с задачей справляет. Главное относится к метафоре, как к метафоре )))
Да картинка от samsdemon лучше показывает суть, но и та, что в посте также с задачей справляет. Главное относится к метафоре, как к метафоре )))
Концептуально пользователь хочет ехать.
Видимо, на картинке из поста в четвёртом этапе надо было рисовать железнодорождый состав. Концептуально проблемы пользователя решены, этапов разработки по прежнему 4, так что картинка с железнодорожным составом справляется со своей задачей не хуже той, что в посте.
Как пользователь. Я хочу заплатить за полный функционал. За ущербный платить нет желания. Если я иду покупать машину, мне нужно все: колёса, педали, комфорт, подушки безопасности.
Как разработчик. Разрабатывая продукт, обычно постановка такая: давайте хоть что-нибудь. А после поставки первого варианта, и ввода эксплуатацию ожидания такие: должно работать основное всё. Не может быть такого, что система отчётности показывает отчёты, но не даёт распечатать. Это означает, что продуктом нельзя пользоваться, он не готов.
Если говорить про фичи, т.е. вещи, расширяющие возможности продукта, добавляющие как те же задачи можно выполнять лучше, проще, удобнее, пушистее, то это тоже к картинке не относится. Это просто развитие продукта.
CI это не про то, что сделать какой-то полуфабрикат и пустить в эксплуатацию. Это контроль заказчика за исполнением и своевременные корректировки.
Как разработчик. Разрабатывая продукт, обычно постановка такая: давайте хоть что-нибудь. А после поставки первого варианта, и ввода эксплуатацию ожидания такие: должно работать основное всё. Не может быть такого, что система отчётности показывает отчёты, но не даёт распечатать. Это означает, что продуктом нельзя пользоваться, он не готов.
Если говорить про фичи, т.е. вещи, расширяющие возможности продукта, добавляющие как те же задачи можно выполнять лучше, проще, удобнее, пушистее, то это тоже к картинке не относится. Это просто развитие продукта.
CI это не про то, что сделать какой-то полуфабрикат и пустить в эксплуатацию. Это контроль заказчика за исполнением и своевременные корректировки.
Опять таки, смотря что разрабатывать. Давайте делать самолёт, вот с таким подходом? Или медицинское оборудование, м? Быстрее дадим какую-то поделку, а упадёт, да и фиг с ним. Умрёт пациент на столе, да и ладно. Потеряет заказчик деньги, из-за того, что секьюрные данные утекут? Да фигня вопрос. Зато по несколько фич в день! Что же там за фичи такие, которые за день-два делаются?
Я не буду особо ванговать, если скажу, что речь идёт исключительно о прикладных задачах. Если вы конкретно заморочились и сделали за пол года год, вменяемый фреймворк, учли множество факторов, то да. Потом можно выдавать результат хоть каждый день.
Если речь идёт про подвинуть картинку на 5 пикселей вправо, а сделайте сюда загрузку файлов, а сюда подсказка пусть вываливается. Ну боже мой, о чём речь?
Просто у разных направлений разная реальность. Те, кто топят за «ежедневную» поставку фич, похоже работают с простыми прикладными задачами, с решением которых справится даже обезьяна.
Я не буду особо ванговать, если скажу, что речь идёт исключительно о прикладных задачах. Если вы конкретно заморочились и сделали за пол года год, вменяемый фреймворк, учли множество факторов, то да. Потом можно выдавать результат хоть каждый день.
Если речь идёт про подвинуть картинку на 5 пикселей вправо, а сделайте сюда загрузку файлов, а сюда подсказка пусть вываливается. Ну боже мой, о чём речь?
Просто у разных направлений разная реальность. Те, кто топят за «ежедневную» поставку фич, похоже работают с простыми прикладными задачами, с решением которых справится даже обезьяна.
MVP же? Или я чего-то не понял
Популярный комикс на заглавной картинке очень хорошо иллюстрирует такой подход. На верхнем примере, который озаглавлен «Как не надо делать», пользователь недоволен всеми шагами, кроме последнего. В нижнем он недоволен только на первом шаге, но начиная со второго шага ему нравится все больше и больше. Более того, конечным результат на нижнем рисунке нравится ему гораздо больше, чем на верхнем.
Меня сама концепция «нужно понравится» удивляет. Судя по статье, основная задача — это понравится пользователю. Значит подход «сделай уродский вырвиглаз дизайн с котиками, который понравится жене заказчика, но не решает никаких задач», это как раз и есть тот самый вектор постановки вопроса? :)
Да будут счастливы все те, кто уверен наперед что он знает как оно должно быть. Автомобиль, переднеприводный, мощность до 200 киловатт, дизель, салон кожаный темный, купе, крыша нежесткая. И кому рынок ответит не фи, а да-да-да.
Пока ты не вышел в прод и не получаешь реальную, еще раз, реальную обратную связь, а не инженерные предположения как оно должно быть, и должно быть ли вообще, можно пилить все что угодно.
И скорость прогресса, после выхода в прод, получения обратной связи от людей кто будет пользоваться, вырастает в разы. Ну вот реально. кто пробовал, тот знает.
Но желаю удачи с уверенностью знания наперед. :)
Пока ты не вышел в прод и не получаешь реальную, еще раз, реальную обратную связь, а не инженерные предположения как оно должно быть, и должно быть ли вообще, можно пилить все что угодно.
И скорость прогресса, после выхода в прод, получения обратной связи от людей кто будет пользоваться, вырастает в разы. Ну вот реально. кто пробовал, тот знает.
Но желаю удачи с уверенностью знания наперед. :)
Мой каммент относится к автору, не к переводчику.
Опять какой-то теоретический булшит про итеративную разработку без примеров, деталей и конкретики.
В итеративной разработке существует 100500 разных стратегий и подходов. При разработке основная цель это реализовать целевую функцию! И судя по картинке автора, КМТ должен был начать с рогатки, но в реальности это не так. Целевая функция может быть реализована не оптимальна/ не полностью, но так или иначе первый шаг к решению проблемы уже будет сделан.
Переводчику +, автору жирный минус, пересказывает теорию без опыта.
Опять какой-то теоретический булшит про итеративную разработку без примеров, деталей и конкретики.
Принцип итеративной разработки можно применить к почти любой области, а не только к той, с которой взаимодействует пользователь.Именно, Итеративной разработке уже 100500 лет, видимо современные программисты совсем далеки от пика индустриализации, производства и конструирования. То же семейство оружия Калашникова Михаила Тимофеевича (КМТ), вполне себе результат итеративного подхода.
В итеративной разработке существует 100500 разных стратегий и подходов. При разработке основная цель это реализовать целевую функцию! И судя по картинке автора, КМТ должен был начать с рогатки, но в реальности это не так. Целевая функция может быть реализована не оптимальна/ не полностью, но так или иначе первый шаг к решению проблемы уже будет сделан.
Как можно непрерывно интегрировать проект каждый день, если для его завершения требуются месяцы, а не дни?Не верно выбрана целевая функция или стратегия реализации. На сегодня сложно найти задачу, которую пришлось бы решать заново. При реализации целевой функции как правило переиспользуют уже существующие технологии и компоненты, жертвуя простотой, скоростью, универсальностью, гибкостью и т.д. но только для того чтобы понять, что реализация целевой функции принесет выгоду.
Вместо того, чтобы спрашивать «как построить большой проект?», вы должны спросить: «как разделить большой проект таким образом, чтобы я мог построить самый маленький полезный кусок?»Чем больше шкаф — тем громче падает. Изначально строить большой проект — утопия. Как пример история Линукса и гита. Линус решал свою узкую задачу, а получилось вон чего.
Идея итеративной разработки заключаетсяв поиске различных способов решения проблемы. Она нацелена на то, чтобы реализовать большой проект двигаясь небольшими шагами, а не нацеливаться сразу на конечную цель.Автор несет бред, никто с нуля большого ничего не делает, это противоречит основному закону эволюции: новая форма получается и предыдущей устойчивой формы, доказавшей свою жизнеспособность, при этом не факт, что новая форма будет жизнеспособна.
Переводчику +, автору жирный минус, пересказывает теорию без опыта.
Sign up to leave a comment.
Программируй меньше, думай больше… инкрементально