Pull to refresh

Comments 23

Боюсь, что на КПВД в «правильном» варианте, как раз и изображен процесс выкидывания всего написанного и построения с нуля на каждом этапе) Потому как если из скейта сделать самокат еще можно, то велосипед — это совершенно другая конструкция с другим принципом действия и вообще другой архитектурой)
Достаточно грубая абстракция, но больше идет акцент на то, что колеса без машины сами по себе бесполезны :)
Есть переосмысленная версия такой картинки
image
Соглашусь! Эта мне нравится больше! :)

Противоречия нет, просто пунктами -2, -1 и 0 в последней строке должны были идти первые три из средней. В последней строке изображен только переход от мотоцикла к автомобилю.

Рефакторинг

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


Вы с архитектурой не перепутали случайно?
Я не автор, но рискну утверждать, что автор не перепутал. В случае MVP крайне редко (если вообще) в самом начале разработки есть хоть какое-нибудь чёткое понимание того, что получится в итоге. Поэтому архитектура, которая казалось наиболее подходящей в, скажем, первые пару месяцев разработки, затем, в один прекрасный момент, может превратиться в «палку в колесе», когда выяснится, что на её основе сложно и дорого реализовать бизнес-требование, появившееся буквально вчера после очередной встречи с потенциальным покупателем продукта.

Поэтому в MVP, как нигде, «рулит» принцип минимально достаточной архитектуры и постоянного перепроектирования из Extreme Programming.
Спасибо за комментарий :) Ответ мне более чем импонирует!
Я своим вопросом, больше хотел услышать конкретику по тем свойствам рефакторинга, которые были написаны в предложении, т.к. по моему мнению, эти характеристики больше применимы к понятию архитектуры, но никак не рефакторингу.

Что такое гибкий рефакторинг? Что такое масшатабируемы рефакторинг? В классике Фаулера я не припоминаю таких вещей. Возможно у 6thSence и ee команды выработались свое понимание и свои подходы, которые можно назвать гибким и масштабируемым рефакторингом.
Может имелось в виду: сохранение гибкости и масштабируемости путем рефакторинга? Ну например поняли в процессе что двигаемся немного не туда, и старая архитектура не подходит — ну и занялись рефакторингом.
«если становится очевидным, что какая-то часть приложения не является гибкой или потенциально не способной к масштабированию, то стоит остановиться и исправить положение»
Остановиться и исправить положение – к теме рефакторинга :)

А вот BaseCamp, бывшие 37 Signals, в своей книге Getting Real (PDF) обосновывают, что первую версию таки стоит сделать в спешке, испробовать, сделать выводы и выбросить.

Обязательно ознакомлюсь, спасибо! :) Вероятно, автору разработка обходится крайне дешево)
Пара вещей из моего опыта.
К любому прототипу относитесь так, как относитесь к готовому продукту. Был случай, когда команду попросили сделать прототип за очень сжатые сроки. Для сокращения времени разработки были взяты несколько продуктов: CMS для обучения, CMS для онлайн магазина, Citrix, настольное приложение в Citrix-е. В результате получился франкенштейн, но вполне рабочий и удовлетворяющий заказчика. Но дальше случилось то, что заказчик захотел в продакшн и не захотел тратить время и деньги на переделку. Результат печален. Никогда так не делайте…

Второй комментарий по дизайну. Дизайн — именно то, на что обращают вмимание заказчики/пользователи. Как ни странно, но удобное и красивое приложение будет продаваться лучше, чем более функциональное. Поэтому не ленитесь сделать удобно и по-возможности минимально красиво. Благо можно взять тот-же bootstrap, который из коробки даёт сразу очень неплохой дизайн при минимуме усилий…
Плохой пример. Неграмотный заказчик и/или плохая работа менеджеров, которые не смогли донести до заказчика суть прототипа. В результате получилось, что «скупой платит дважды».
Я бы не стал обвинять менеджеров или заказчика в данном конкретном случае. Скорее просто возникли проблемы в коммуникациях между заказчиком и аналитиками и дальше с разработчиками. Возможно заказчик изменил своё мнение, когда увидел работающий прототип и его устроила его функциональность…
Но с тех пор для меня правило — сразу делать хорошо. И это спасло меня от подобных ошибок уже раза 2-3.
> Я бы не стал обвинять менеджеров или заказчика в данном конкретном случае. Скорее просто возникли проблемы в коммуникациях

Минутку… А разве не менеджеры ответственны именно за коммуникации?
Можно обвинить разве что в отсутствии общей терминологии с заказчиком.

Я догадываюсь, что происходило всё по следующему сценарию:
Заказчик: нужно сделать прототип системы за минимальный срок и как можно дешевле, чтобы я мог найти инвестора. А там уже сделаем как надо…
Менеджер: Ок.
Менеджер (аналитикам, программистам): Заказчику нужен прототип подешевле. Есть десктопное приложение, нужно запустить его в облаке. Попробуйте использовать готовые решения чтобы было быстрее и дешевле. Потом всё переделаем
Программисты: А точно потом переделаем?
Менеджер: Ага, не парьтесь…
Программисты: Ок.
(тут много работы и совещаний с заказчиком)
Заказчик: О, выглядит отлично и даже работает. Молодцы ребята! Можно в продакшн!
Менеджер: Ээээ… А как же переделать?
Заказчик: Ну деньги кончились, а система готова… В продакшн!!!
Программисты: oO Это же прототип… Так нельзя…
Менеджер (программистам): Угу, но заказчик сказал идти в продакшн…
Программисты: Б… Ну ок.
В некомпетентности надо такого менеджера обвинить.
Потому что он в договоре с заказчиком должен был эти риски предусмотреть и зафиксировать, просто переводить все хотелки на разработчиков.
В вашем примере он совершенно нефункциональное звено в пищевой цепочке:
У заказчика деньги и идея.
У программистов умение и результат.
И только менеджер в этой истории ничем не отвечает, а только работает попугаем.
Безотносительно к позиции делать сразу хорошо, её я разделяю.
Просто приведённая модель ситуации вызывает справедливые на мой взгляд претензии именно к менеджерской составляющей.
Складывается впечатление, что тут дело в различных понятиях.
То, что описано в статье больше походит на полноценную разработку продукта (с наличием ресурсов), а не на проверку работоспособности идеи (с недостатком ресурсов).
Все относительно, в формате крупной компании наши численные ресурсы считались экономией. Для мелкого стартапа это было бы эквивалентно полноценной команде :)
Sign up to leave a comment.