Бережливая разработка программного обеспечения VS Бережливый стартап. Это то же самое? Различия?

Эти понятия обычно смешиваются везде. Кажется, что оба основаны на Lean, но это все. Суть подхода Lean Startup, по-видимому, заключается в разработке MVP (минимально жизнеспособного продукта) . Принимая во внимание, что суть бережливой разработки программного обеспечения, по-видимому, заключается в устранении потерь .

Можем ли мы так сказать?

  • Бережливая разработка программного обеспечения — это принципы
  • Lean Startup — это методология, которая применяет эти принципы.
  • Канбан — это метод применения либо этих принципов, либо той методологии.
В этом посте автор объясняет разницу на красивом примере: http://oxzigen.com/category/lean-software-development/

Ответы (2)

Я бы предложил, чтобы бережливая разработка программного обеспечения подробно обсуждалась Мэри Поппендик и Томом Поппендик .это методология, тесно связанная с семейством Agile методологий разработки программного обеспечения, таких как Extreme Programming и Scrum, каждая из которых имеет свои собственные акценты в дизайне, ритуалы и сообщество. Однако в основе всей культуры Lean/Agile лежит убеждение в том, что быстрые циклы обратной связи — когда обратная связь должна быть в форме «живых» реакций (таких как всплески продаж или использования) из «реальной среды» (от клиенты, потенциальные клиенты и пользователи, что наиболее важно) — необходимы для обнаружения важных, но ложных предположений, часто скрытых в документах по планированию или требованиям. Таким образом, вы можете думать об экосистеме практик Lean/Agile как о средствах обеспечения быстрых циклов обратной связи — «потерпеть неудачу, чтобы быстрее добиться успеха» — для выявления и управления рисками, связанными с ложными предположениями о среде разработки.

«Бережливый стартап» просто применяет идею использования быстрых циклов обратной связи, чтобы выявить ложные предположения для развития клиентов и бизнес-стороны организации. Стив Бланк придумал этот термин и создал процессы, связанные с «развитием клиентов», которые Эрик Рейс построил для разработки «обучения стартапу».

Канбан — это инструмент, как вы упомянули, который можно использовать в любом стиле управления проектами, даже в водопадном.

Спасибо. Вы правы, но я продолжаю исследовать и нашел две статьи, которые объясняют это проще (я думаю). Поэтому я также написал свой собственный ответ. Что вы думаете?
Я думаю, что статьи, на которые вы ссылаетесь, хорошо объясняют идеи, но я иногда замечал, что люди сосредотачиваются на практиках и могут не понимать, «почему» они стоят за ними. На самом деле, понимание того, «почему» стоит, например, за MVP, может помочь нам разработать наиболее эффективный из возможных. Нам может не понадобиться графический дизайнер для целевой страницы. Возможно, нам даже не понадобится целевая страница. Мы делаем все возможное, чтобы получить знания, необходимые для принятия обоснованных решений.
Полностью согласен. Собственно, это я и хочу прояснить этими статьями. Если мы прочитаем первые результаты Google, люди (такие как я) думают (ошибочно), что MVP — это минимальная программная реализация. Вы проясняете это еще больше с этим комментарием. Спасибо! :)

Я думаю, что следующие несколько статей идеально подходят для того, чтобы легко понять разницу.

Из oxzigen.com — бережливая разработка программного обеспечения :

Методологии Lean IT и Lean Startup легко спутать. (...) Я иногда использую аналогию с рестораном, чтобы описать эти разные роли. Согласно этой аналогии, действия по бережливому стартапу происходят в основном в «столовой», где есть прямой контакт с клиентами. (...) С другой стороны, бережливые ИТ-деятельности в основном происходят на «кухне». Их цель состоит в том, чтобы поставлять высококачественный продукт быстро и эффективно.

Из w2lessons.com - анализ минимального жизнеспособного продукта :

Одним из фундаментальных и наиболее неправильно понимаемых принципов бережливого стартапа является минимально жизнеспособный продукт (MVP). (...) Для начала вы должны смотреть на MVP не как на продукт, а как на эксперимент. (...) Дело в том, что реальный продукт вообще не обязательно должен существовать. (...) Вместо создания целой системы создайте простую целевую страницу с несколькими скриншотами от вашего графического дизайнера (вспомните about.me).