Как же вы ловко передёрнули про мои слова, что якобы экономическая эффективность не самое важное:) Продолжаю настаивать, что экономическая эффективность, в том виде, в котором вы рассказали про риски и прибыль, не самый главный критерий при выборе методологии.
Простой пример: вы хотите купить цветы своему любимому человеку, в одном киоске красивые и свежие, но 5000, а в другом поломанные и вялые, но 100р. Вы решаете купить за 100. Попробуйте теперь рассказать при вручении подарка об экономической эффективности:)
Все перечисленные «наиболее важные вещи» — влияют на экономическую эффективность в итоге
Вот тут пошла чистая философия. И не поспоришь и к теме не понятно как относится.
Про Канбан не совсем понял, что вы этим хотели сказать и как это относится к моему комментарию? Вы в этом видите главное различие или не согласны с тем, что Канбан не подходит для разработки ПО с нуля.
У меня сложилось впечатление, что вы либо менеджер, либо экономист и никогда не участовали в разработке и проектировании ПО. Я угадал? Описывая экономическую эффективность вы совершенно упускаете как минимум потребности заказчика и технический аспект разрабатываемой системы.
Низкий риск и низкая прибыль… это что-то околоводопадное
А как же длительность проекта, а как же риск изменения требований, а как же технические риски, такие как риски неправилно выбранных технологий, неправильно понятых требований, неверно спроектированной системы? Вы этого ничего не учитываете. Да, у вас будут небольшие накладные расходы на организацию процесса, но вы понимаете, что вы можете разработать совсем не то что нужно и не факт, что вообще уложитесь в сроки?
Низкий риск и высокая прибыль… и это (не поверите), канбан
Это вообще ерунда, которую комментировать даже не хочется. Почитайте тут в комментариях про разницу между Скрамом и Канбаном.
Высокий риск и высокая прибыль ...— подходит гибкий метод,
Тут главное что это за риски, от этого плясать надо. Если риск — жёсткие сроки, длителность проекта небольшая, а все требования известны, понятны и не поменяются, а техническое решение проверенно, то почему бы не взять водопад.
Высокий риск и низкая прибыль
Тут опять-таки всё зависит от ситуации.
Ваш критерий экономической эффективности (про риски и прибыль) можно учитывать при выборе методологии в составе других критериев, среди которых есть и более важные. Вы же ставите его во главу угла. Ниже наиболее важные на мой взгляд:
Тип ПО (life-critical, mission critical, встраиваемое по, и т.п.)
Меняются ли требования
Сложность технического решения
Известны ли технологии
Длителность проекта
Размер и состав команды
Требования к качеству
Производительность, надёжность и отказоустойчивость
Правельно заданный вопрос — половина ответа. Пока же я не вижу ничего лучше стартапа. Размер команды мало о чём скажет. Большая часть гибких методологий рассчитана на небольшую команду. Состав команды — вещь слишком многогранная. Понятно что чем опытней команда тем лучше, но как это соотносится с методологиями — не совсем чётко прослеживается.
В сфере IT в больших корпорациях все может сильно разниться от команды в команде.
Всё именно так в организации в которой я работаю.
Скорее это зависит от размера конкретного проекта.
Вот с этим соглашусь, всё-таки размер проекта более решающую роль играет чем размер компании.
«гибкость» и «форализованность» — это не антонимы. И незачем их противопоставлять.
А я их и не противопоставляю. Также как не противопоставляю скорость и качество. Вопрос в том куда смещать акценты.
«нужен ли вам формализованный подход». Ответ на него всегда «да»
тут всё-таки имеется в виду степень формализма. Условно говоря в Скраме не так много процессов расписано по сравнению с RUP и поэтому я позволяю себе называть его не формализованным подходом.
Ну попробуйте заказчику задать вопрос, который у вас тут написан
А этот вопрос и блок-схема не для заказчика. Она создана в обучающих целях, чтобы просто подать сравнение разных методологий в новом формате.
Ну неверно утверждать, что основа Скрама — это непрерывное улучшение Срама.
В чём отличие Скрама и Канбана? Канбан в первую очередь конвейер по добавлению фич. Если необходимо много времени тратить на архитектуру, инфраструктуру то он уже начинает плохо работать. Поэтому он так хорошо прижился в проектах поддержки, и не так хорошо в проектах продуктовой разработки. Скрам же позволят создавать сложные приложения с нуля. Постоянные улучшения это конечно же не главное, но это одна из «фишек» Скрама. Действительно, она существенная, но всё-таки не главная в сравнении Скрама и Канбана. Я подумаю над тем как пересмотреть данный элемент блок схемы!
Очень хорошо что вы написали такой развёрнутый комментарий. Теперь по пунктам:
Она не только из практик состоит. Там много чего еще есть
Изначально XP был придуман и развит сообществом как методология состоящая в основном из 12 практик. Почитайте Фаулера и других людей, которые двигали эту методологию в начале нулевых. Другое дело что всё меняется, совершенствуется, появляются свои вариации и подходы, которые улучшают методологию. Несомненно в XP есть много чего ещё. Я ведь написал в статье, что расскажу про упоминаемые методологии очень кратко, а 12 практик это базис на котором основывется методология. Кому интересно могут почитать об XP более подробно.
ерунда. Стартап стартапу рознь.
Я считаю часть про стартапы наиболее спорна в моей статье и другие люди также указывали мне на это. Так что ваша критика вполне справделива. Тем не менее, я считаю важным указать на то что зачастую методология может задушит энтузиазм и я в своей практике часто видел такое. Стартапы как нельзя лучше демонстрируют это. Я ведь в начале статьи указал, что нет универсального набора условий и моя статья написана для того, чтобы обратить внимание на основные моменты. У вас стартап и у вас методология не душит энтузиазм? Поздравляю, значит к вам это не относится.
RUP не такой уж и формализованный.
Я не работал с RUP и я читал статьи сотрудников IBM о том как сделать RUP гибким и я в курсе, что его можно адаптировать под что угодно. В реальности же вы будете работать в RUP по аджайлу только тогда, когда инфраструктура вашей компании тесно интегрирована с продуктами IBM. В ином случае никто не будет применять RUP там, где нужен гибкий подход. RUP, как и другие Unified Process, создавался как раз как формализованный подход в первую очередь. Я, например, участвовал в проектах где применялся адаптированный EssUP в качестве гибкой методологии и могу сказать, что такой подход работает. Но опять-таки никто не будет покупать EssUP и тратить время и усилия по адаптации в свой проект, если это не навязано компанией, проще взять Скрам. Вообще все эти UPы, как мне кажется, существуют только в больших корпорациях, как раз там где все процессы расписаны и применяется формализованный подход во всём.
тоже какое то мутное утверждение. Скорость — это нисколько не продуктивность, а качество ни в каком месте не инженерия (по крайней мере не только она). Вы точно Кента Бека читали?
Вот здесь я считаю, вы высказали распространённое заблуждение относительно XP. То, что вы использовали парное программирование и tdd не означает, что вы работали по XP. XP — это когда вы используете все 12 практик. Об этом и пишет Кент Бек. В реальности XP — методология крайне сложная во внедрении и успехов с ней можно добиться только накопив достаточный опыт. Конечно же нельзя утверждать, что скорость — продуктивность, и качество — инженерия, я это и не пытаюсь этого делать. Другое дело что вы не добьётесь высокой скорости разработки не повысив продуктивность работы, и не добьётесь высокого качества, если не будете использоват передовые и сложные технологии (например, парное программирование и tdd как вы описали). Смысл в том, что бизнесу не всегда нужно качество, а зачастую гораздо важнее разработать хоть что-то работающее, а допилить можно и после релиза. В этом случае, я уверен, Скрам подойдёт гораздо лучше XP, особенно если у вас неопытная команда. Конечно же, вы можете быть более продуктивными с XP, но ведь мы помним, статья обращает внимание на моменты, а не навязывает единственно верный подход
И усовершенствования процесса — вообще не фишка скрама.
С этим я не согласен, но оставлю это на ваше усмотрение. Столько уже копий сломано по поводу Скрама, каждый считает, что понимает его лучше. Опять поднимать это тему не очень хочется. Ваше мнение — ваше мнение. Тем не менее комментарий полезный.
По поводу RAD и RUP отчасти согласен, однако в организации где я работаю выбор между Agile и Waterfall делается легко, более того, есть проекты работающие как на Waterfall так и на Agile. Такое ощущение, что вы работаете в крупной закостенелой компании, где очень сложно что-то поменять, но не везде так как вы описываете.
RUP, RAD и XP редкость в России на мой взгляд, однако всегда полезно их знать и черпать оттуда какие то идеи.
Причина плевков в сторону не-ройсовских водопадов это то, что именная такая модель часто приводит к провалу крупных проектов. Ройсовские водопады, с их возможностью возврата на предыдущий этап, на мой взгляд, всё равно хуже итеративной модели. Не стоит забывать, что в то время, когда Ройс написал свою статью, процесс разработки был совершенно иным. Отлаживали в уме и на листочке, писали на перфокартах, относили их в компьютерный центр, ждали неделю когда протестируют, а потом исправляли ошибки. Понятно что в то время итеративный подход был неприменим, не говоря уж о TDD, непрерывной интеграции и т.п.
а например если у вас много общей логики (десятки тысяч строк кода), то будете один и тот же код реализовывать на разных языках, а потом поддерживать две версии одного и того же?
dependency service в xamarin это всё-таки не совсем IOC+DI. он в документации позиционируется как способ вызывать нативный код из общего кода. как он себя поведёт при большом количестве зависимостей? можно ли с помощью него зарегистрировать синглтон? сможет ли он создавать объекты, где зависимости инжектятся через конструктор? думаю ответ на все вопросы — нет.
от фреймворка мне нужно, чтобы он автоматически биндил View и ViewModel, и создавал ViewModel и вообще сам заботился о его жизненном цикле. чтобы он умел передавать параметры из одной ViewModel в другую. чтобы он умел показывать сообщения и ошибки из ViewModel во View в соответствии с паттерном, ещё я хотел бы мощную реализацию интерфейса ICommand, чтобы была возможность использовать генерики, параметры и асинхронность. Также хотелось бы всяких приятых плюшек, например готовые конвертеры на разные случае жизни, поддержку настроек, локалиации и т.п… Всё это можно реализовать самому или найти на просторах инета, но хотелось бы чтобы всё это было в одном месте, чтобы фреймворк поддерживался и развивался.
По вашему получается, что тщательное тестирование происходит только в V-Model, а спиральная модель — то же самое что итеративная, только зачем то выделено 4 этапа.
На мой взгляд главная особенность V-Model — связь этапов анализа и проектирования с этапом тестирования. Пример: пока аналитик уточняет требования, тестировщики продумывают высокоуровненвые методы и подходы к тестированию, пока архитектор проектирует систему, тестировщики продумывают тест-планы, пока архитекторы проектируют компоненты системы, тестировщики создают тест-кейсы, инструменты, инструкции и т.п. Т.е. к тому времени пока мы подойдём к реализации уже есть куча документации, не только по требованиям и архитектуре, но и по тщательно продуманному тестированию.
Важная особенность спиральной модели — на этапе анализа риска мы создаём концепты, прототипы и модели чтобы попробовать оценить и разрешить риск до того, как приступим к реализации
А что можно было бы использовать вместо MvvmCross? MVVMLight — вроде как не кроссплатформенный, по крайней мере был, на момент начала проекта. Caliburn.Micro лично мне не очень нравится. Использовать MVVM без MVVM-фреймворка значит самому написать MVVM-фреймворк в процессе написания приложения.
Простой пример: вы хотите купить цветы своему любимому человеку, в одном киоске красивые и свежие, но 5000, а в другом поломанные и вялые, но 100р. Вы решаете купить за 100. Попробуйте теперь рассказать при вручении подарка об экономической эффективности:)
Вот тут пошла чистая философия. И не поспоришь и к теме не понятно как относится.
Про Канбан не совсем понял, что вы этим хотели сказать и как это относится к моему комментарию? Вы в этом видите главное различие или не согласны с тем, что Канбан не подходит для разработки ПО с нуля.
А как же длительность проекта, а как же риск изменения требований, а как же технические риски, такие как риски неправилно выбранных технологий, неправильно понятых требований, неверно спроектированной системы? Вы этого ничего не учитываете. Да, у вас будут небольшие накладные расходы на организацию процесса, но вы понимаете, что вы можете разработать совсем не то что нужно и не факт, что вообще уложитесь в сроки?
Это вообще ерунда, которую комментировать даже не хочется. Почитайте тут в комментариях про разницу между Скрамом и Канбаном.
Тут главное что это за риски, от этого плясать надо. Если риск — жёсткие сроки, длителность проекта небольшая, а все требования известны, понятны и не поменяются, а техническое решение проверенно, то почему бы не взять водопад.
Тут опять-таки всё зависит от ситуации.
Ваш критерий экономической эффективности (про риски и прибыль) можно учитывать при выборе методологии в составе других критериев, среди которых есть и более важные. Вы же ставите его во главу угла. Ниже наиболее важные на мой взгляд:
Правельно заданный вопрос — половина ответа. Пока же я не вижу ничего лучше стартапа. Размер команды мало о чём скажет. Большая часть гибких методологий рассчитана на небольшую команду. Состав команды — вещь слишком многогранная. Понятно что чем опытней команда тем лучше, но как это соотносится с методологиями — не совсем чётко прослеживается.
Всё именно так в организации в которой я работаю.
Вот с этим соглашусь, всё-таки размер проекта более решающую роль играет чем размер компании.
А я их и не противопоставляю. Также как не противопоставляю скорость и качество. Вопрос в том куда смещать акценты.
тут всё-таки имеется в виду степень формализма. Условно говоря в Скраме не так много процессов расписано по сравнению с RUP и поэтому я позволяю себе называть его не формализованным подходом.
А этот вопрос и блок-схема не для заказчика. Она создана в обучающих целях, чтобы просто подать сравнение разных методологий в новом формате.
В чём отличие Скрама и Канбана? Канбан в первую очередь конвейер по добавлению фич. Если необходимо много времени тратить на архитектуру, инфраструктуру то он уже начинает плохо работать. Поэтому он так хорошо прижился в проектах поддержки, и не так хорошо в проектах продуктовой разработки. Скрам же позволят создавать сложные приложения с нуля. Постоянные улучшения это конечно же не главное, но это одна из «фишек» Скрама. Действительно, она существенная, но всё-таки не главная в сравнении Скрама и Канбана. Я подумаю над тем как пересмотреть данный элемент блок схемы!
Изначально XP был придуман и развит сообществом как методология состоящая в основном из 12 практик. Почитайте Фаулера и других людей, которые двигали эту методологию в начале нулевых. Другое дело что всё меняется, совершенствуется, появляются свои вариации и подходы, которые улучшают методологию. Несомненно в XP есть много чего ещё. Я ведь написал в статье, что расскажу про упоминаемые методологии очень кратко, а 12 практик это базис на котором основывется методология. Кому интересно могут почитать об XP более подробно.
Я считаю часть про стартапы наиболее спорна в моей статье и другие люди также указывали мне на это. Так что ваша критика вполне справделива. Тем не менее, я считаю важным указать на то что зачастую методология может задушит энтузиазм и я в своей практике часто видел такое. Стартапы как нельзя лучше демонстрируют это. Я ведь в начале статьи указал, что нет универсального набора условий и моя статья написана для того, чтобы обратить внимание на основные моменты. У вас стартап и у вас методология не душит энтузиазм? Поздравляю, значит к вам это не относится.
Я не работал с RUP и я читал статьи сотрудников IBM о том как сделать RUP гибким и я в курсе, что его можно адаптировать под что угодно. В реальности же вы будете работать в RUP по аджайлу только тогда, когда инфраструктура вашей компании тесно интегрирована с продуктами IBM. В ином случае никто не будет применять RUP там, где нужен гибкий подход. RUP, как и другие Unified Process, создавался как раз как формализованный подход в первую очередь. Я, например, участвовал в проектах где применялся адаптированный EssUP в качестве гибкой методологии и могу сказать, что такой подход работает. Но опять-таки никто не будет покупать EssUP и тратить время и усилия по адаптации в свой проект, если это не навязано компанией, проще взять Скрам. Вообще все эти UPы, как мне кажется, существуют только в больших корпорациях, как раз там где все процессы расписаны и применяется формализованный подход во всём.
Вот здесь я считаю, вы высказали распространённое заблуждение относительно XP. То, что вы использовали парное программирование и tdd не означает, что вы работали по XP. XP — это когда вы используете все 12 практик. Об этом и пишет Кент Бек. В реальности XP — методология крайне сложная во внедрении и успехов с ней можно добиться только накопив достаточный опыт. Конечно же нельзя утверждать, что скорость — продуктивность, и качество — инженерия, я это и не пытаюсь этого делать. Другое дело что вы не добьётесь высокой скорости разработки не повысив продуктивность работы, и не добьётесь высокого качества, если не будете использоват передовые и сложные технологии (например, парное программирование и tdd как вы описали). Смысл в том, что бизнесу не всегда нужно качество, а зачастую гораздо важнее разработать хоть что-то работающее, а допилить можно и после релиза. В этом случае, я уверен, Скрам подойдёт гораздо лучше XP, особенно если у вас неопытная команда. Конечно же, вы можете быть более продуктивными с XP, но ведь мы помним, статья обращает внимание на моменты, а не навязывает единственно верный подход
С этим я не согласен, но оставлю это на ваше усмотрение. Столько уже копий сломано по поводу Скрама, каждый считает, что понимает его лучше. Опять поднимать это тему не очень хочется. Ваше мнение — ваше мнение. Тем не менее комментарий полезный.
RUP, RAD и XP редкость в России на мой взгляд, однако всегда полезно их знать и черпать оттуда какие то идеи.
Например Scrum и SAFe — совершенно разные методологии, которые поддерживают принципы Agile и реализуют итеративную модель жизненного цикла.
от фреймворка мне нужно, чтобы он автоматически биндил View и ViewModel, и создавал ViewModel и вообще сам заботился о его жизненном цикле. чтобы он умел передавать параметры из одной ViewModel в другую. чтобы он умел показывать сообщения и ошибки из ViewModel во View в соответствии с паттерном, ещё я хотел бы мощную реализацию интерфейса ICommand, чтобы была возможность использовать генерики, параметры и асинхронность. Также хотелось бы всяких приятых плюшек, например готовые конвертеры на разные случае жизни, поддержку настроек, локалиации и т.п… Всё это можно реализовать самому или найти на просторах инета, но хотелось бы чтобы всё это было в одном месте, чтобы фреймворк поддерживался и развивался.
На мой взгляд главная особенность V-Model — связь этапов анализа и проектирования с этапом тестирования. Пример: пока аналитик уточняет требования, тестировщики продумывают высокоуровненвые методы и подходы к тестированию, пока архитектор проектирует систему, тестировщики продумывают тест-планы, пока архитекторы проектируют компоненты системы, тестировщики создают тест-кейсы, инструменты, инструкции и т.п. Т.е. к тому времени пока мы подойдём к реализации уже есть куча документации, не только по требованиям и архитектуре, но и по тщательно продуманному тестированию.
Важная особенность спиральной модели — на этапе анализа риска мы создаём концепты, прототипы и модели чтобы попробовать оценить и разрешить риск до того, как приступим к реализации