Comments 14
Методологию, как и Родину, не выбирают.
В любой компании уже есть сложившиеся процессы. Эти процессы формируются годами. Создаётся организационная структура, допиливаются рабочие инструменты. Если вы пришли работать в компанию, вы не можете просто взять и выбрать методологию. Выбора между waterfall и XP в пределах одной компании просто не существует.
Если в компании используется RUP, значит, она сидит на инструментах Rational, на которых вообще всё является RUP'ом.
RAD сегодня существует только в книгах.
И даже если вы включили God mode (сами создаёте компанию и формируете с нуля команду для собственного нового продукта), вы не сможете просто так взять и выбрать методологию.
В любой компании уже есть сложившиеся процессы. Эти процессы формируются годами. Создаётся организационная структура, допиливаются рабочие инструменты. Если вы пришли работать в компанию, вы не можете просто взять и выбрать методологию. Выбора между waterfall и XP в пределах одной компании просто не существует.
Если в компании используется RUP, значит, она сидит на инструментах Rational, на которых вообще всё является RUP'ом.
RAD сегодня существует только в книгах.
И даже если вы включили God mode (сами создаёте компанию и формируете с нуля команду для собственного нового продукта), вы не сможете просто так взять и выбрать методологию.
По поводу RAD и RUP отчасти согласен, однако в организации где я работаю выбор между Agile и Waterfall делается легко, более того, есть проекты работающие как на Waterfall так и на Agile. Такое ощущение, что вы работаете в крупной закостенелой компании, где очень сложно что-то поменять, но не везде так как вы описываете.
RUP, RAD и XP редкость в России на мой взгляд, однако всегда полезно их знать и черпать оттуда какие то идеи.
RUP, RAD и XP редкость в России на мой взгляд, однако всегда полезно их знать и черпать оттуда какие то идеи.
Смешная диаграмма. Надеюсь, ей никто не воспользуется в жизни.
C чем именно несогласны?
Скажу от себя. Не суть метода определяет выбор, а требования по эффективности определяют выбор метода. Критерии на диаграмме берутся из различий методов, в то время как реально используемый метод чаще всего сочетание элементов практик (с преобладанием чего-то конечно).
Я уже писал тут эти мысли, но повторюсь. Метод не делает проект успешным, перечисленные методы — про организацию процесса разработки. Управление проектами лежит за рамками этих методов, и оно и отвечает за выбор производственного решения.
Теперь ближе к делу. Достаточным критерием эффективности является эффективность экономическая. Её можно измерять как соотношение прибыли к риску, и если исходить из этой метрики, мы должны выбирать тот метод, который это соотношение максимизирует.
Проблема аджайла (хотя я к нему отношусь ровно, спокойно, с пониманием :)) на самом деле, в том что он плохо разграничивает управление продуктом и проектом. Вот бэклог — это про список тасков или про список требований? :) Неоднозначно, хотя тут можно городить огороды, прав никто не будет (даже я:)). В сухом остатке имеем, что когда продукт отчуждается — нет смысла использовать полностью гибкие методы, так как затраты на организацию и поддержание этих методов сожрут немалую часть времени, в то время как профитов с этого нет. Когда проект инициативный (собственный) — гибкие методы позволяют решать достигать более точных результатов.
С точки зрения системного подхода, гибкие методы дают более быструю и тонкую подстройку продукта под окружение проекта, в то время как более длинные заранее спланированные разнозадачные водопадные итерации дают возможность оптимизировать/экономить.
Я уже писал тут эти мысли, но повторюсь. Метод не делает проект успешным, перечисленные методы — про организацию процесса разработки. Управление проектами лежит за рамками этих методов, и оно и отвечает за выбор производственного решения.
Теперь ближе к делу. Достаточным критерием эффективности является эффективность экономическая. Её можно измерять как соотношение прибыли к риску, и если исходить из этой метрики, мы должны выбирать тот метод, который это соотношение максимизирует.
- Низкий риск и низкая прибыль (например, это заказные проекты, услуга по сути) — нужен самый экономичный процесс, и я склонен полагать что это что-то околоводопадное — как минимум потому, что каждая задача делается один-два раза
- Низкий риск и высокая прибыль (случай монополии) — нужен метод, который позволит эту самую монополию не растерять. То есть быстро и качественно, и это (не поверите), канбан. Канбан обеспечивает качество возвратом задач.
- Высокий риск и высокая прибыль (конкурентный рынок, инициативные проекты и стартапы) — подходит гибкий метод, который постоянно выдает максимум результатов. Скрум короче.
- Высокий риск и низкая прибыль (начало работы с гос. организациями или другими крупными компаниями на конкурентном рынке) — тут лучше вообще перейти в другую нишу — поставок «комплектующих» для тех, кто работает на этом рынке. Если всё же работать на таком рынке, то нужен свой продукт, разрабатывать который можно спирально или по RUP (помесь водопада и гибких методов, водопадненькие итерации).
Проблема аджайла (хотя я к нему отношусь ровно, спокойно, с пониманием :)) на самом деле, в том что он плохо разграничивает управление продуктом и проектом. Вот бэклог — это про список тасков или про список требований? :) Неоднозначно, хотя тут можно городить огороды, прав никто не будет (даже я:)). В сухом остатке имеем, что когда продукт отчуждается — нет смысла использовать полностью гибкие методы, так как затраты на организацию и поддержание этих методов сожрут немалую часть времени, в то время как профитов с этого нет. Когда проект инициативный (собственный) — гибкие методы позволяют решать достигать более точных результатов.
С точки зрения системного подхода, гибкие методы дают более быструю и тонкую подстройку продукта под окружение проекта, в то время как более длинные заранее спланированные разнозадачные водопадные итерации дают возможность оптимизировать/экономить.
У меня сложилось впечатление, что вы либо менеджер, либо экономист и никогда не участовали в разработке и проектировании ПО. Я угадал? Описывая экономическую эффективность вы совершенно упускаете как минимум потребности заказчика и технический аспект разрабатываемой системы.
А как же длительность проекта, а как же риск изменения требований, а как же технические риски, такие как риски неправилно выбранных технологий, неправильно понятых требований, неверно спроектированной системы? Вы этого ничего не учитываете. Да, у вас будут небольшие накладные расходы на организацию процесса, но вы понимаете, что вы можете разработать совсем не то что нужно и не факт, что вообще уложитесь в сроки?
Это вообще ерунда, которую комментировать даже не хочется. Почитайте тут в комментариях про разницу между Скрамом и Канбаном.
Тут главное что это за риски, от этого плясать надо. Если риск — жёсткие сроки, длителность проекта небольшая, а все требования известны, понятны и не поменяются, а техническое решение проверенно, то почему бы не взять водопад.
Тут опять-таки всё зависит от ситуации.
Ваш критерий экономической эффективности (про риски и прибыль) можно учитывать при выборе методологии в составе других критериев, среди которых есть и более важные. Вы же ставите его во главу угла. Ниже наиболее важные на мой взгляд:
Низкий риск и низкая прибыль… это что-то околоводопадное
А как же длительность проекта, а как же риск изменения требований, а как же технические риски, такие как риски неправилно выбранных технологий, неправильно понятых требований, неверно спроектированной системы? Вы этого ничего не учитываете. Да, у вас будут небольшие накладные расходы на организацию процесса, но вы понимаете, что вы можете разработать совсем не то что нужно и не факт, что вообще уложитесь в сроки?
Низкий риск и высокая прибыль… и это (не поверите), канбан
Это вообще ерунда, которую комментировать даже не хочется. Почитайте тут в комментариях про разницу между Скрамом и Канбаном.
Высокий риск и высокая прибыль ...— подходит гибкий метод,
Тут главное что это за риски, от этого плясать надо. Если риск — жёсткие сроки, длителность проекта небольшая, а все требования известны, понятны и не поменяются, а техническое решение проверенно, то почему бы не взять водопад.
Высокий риск и низкая прибыль
Тут опять-таки всё зависит от ситуации.
Ваш критерий экономической эффективности (про риски и прибыль) можно учитывать при выборе методологии в составе других критериев, среди которых есть и более важные. Вы же ставите его во главу угла. Ниже наиболее важные на мой взгляд:
- Тип ПО (life-critical, mission critical, встраиваемое по, и т.п.)
- Меняются ли требования
- Сложность технического решения
- Известны ли технологии
- Длителность проекта
- Размер и состав команды
- Требования к качеству
- Производительность, надёжность и отказоустойчивость
Нет, не угадали. Я 10+ лет в коммерческой разработке ПО, программистом, аналитиком, PM'ом и зам. диром в разное время в разных городах в компаниях разного размера. Экономическое образование правда тоже есть, но вы так говорите, как-будто это что-то плохое :) Покажите диаграмму директору компании где работаете, и скажите что экономическая эффективность проекта — это не самое важное.
Все перечисленные «наиболее важные вещи» — влияют на экономическую эффективность в итоге. На самом деле есть даже показатель экономической эффективности для проектов, который учитывает риски, NPV.
Всё комментировать не буду, так как в целом только что ответил. Отвечу только на неконструктив про разницу между скрамом и канбаном :) В канбане, как и на гембе у Тойоты, всегда допустимо «остановить конвейер». Казалось бы зачем? Затем чтобы дефекты не передавать на следующий этап. Управление качеством встроено в процесс, в отличие от скрама.
Вы так вот сходу залезли в святая святых — методы организации разработки. Для многих их собственные методы и инструменты — священная корова, которую рожали в муках, как для авторов, так и для практиков этих методов. Так вот запросто вопрос не разрулить. Поищите тут на Хабре (Мегамозге теперь уже нынче), эти темы не раз и не два поднимались, консенсус и близко не найден.
Все перечисленные «наиболее важные вещи» — влияют на экономическую эффективность в итоге. На самом деле есть даже показатель экономической эффективности для проектов, который учитывает риски, NPV.
Всё комментировать не буду, так как в целом только что ответил. Отвечу только на неконструктив про разницу между скрамом и канбаном :) В канбане, как и на гембе у Тойоты, всегда допустимо «остановить конвейер». Казалось бы зачем? Затем чтобы дефекты не передавать на следующий этап. Управление качеством встроено в процесс, в отличие от скрама.
Вы так вот сходу залезли в святая святых — методы организации разработки. Для многих их собственные методы и инструменты — священная корова, которую рожали в муках, как для авторов, так и для практиков этих методов. Так вот запросто вопрос не разрулить. Поищите тут на Хабре (Мегамозге теперь уже нынче), эти темы не раз и не два поднимались, консенсус и близко не найден.
Как же вы ловко передёрнули про мои слова, что якобы экономическая эффективность не самое важное:) Продолжаю настаивать, что экономическая эффективность, в том виде, в котором вы рассказали про риски и прибыль, не самый главный критерий при выборе методологии.
Простой пример: вы хотите купить цветы своему любимому человеку, в одном киоске красивые и свежие, но 5000, а в другом поломанные и вялые, но 100р. Вы решаете купить за 100. Попробуйте теперь рассказать при вручении подарка об экономической эффективности:)
Вот тут пошла чистая философия. И не поспоришь и к теме не понятно как относится.
Про Канбан не совсем понял, что вы этим хотели сказать и как это относится к моему комментарию? Вы в этом видите главное различие или не согласны с тем, что Канбан не подходит для разработки ПО с нуля.
Простой пример: вы хотите купить цветы своему любимому человеку, в одном киоске красивые и свежие, но 5000, а в другом поломанные и вялые, но 100р. Вы решаете купить за 100. Попробуйте теперь рассказать при вручении подарка об экономической эффективности:)
Все перечисленные «наиболее важные вещи» — влияют на экономическую эффективность в итоге
Вот тут пошла чистая философия. И не поспоришь и к теме не понятно как относится.
Про Канбан не совсем понял, что вы этим хотели сказать и как это относится к моему комментарию? Вы в этом видите главное различие или не согласны с тем, что Канбан не подходит для разработки ПО с нуля.
Нет ни философии, ни передергивания. Экономическая эффективность проекта — это если очень грубо его поступления минус затраты (финансовый результат) с учетом того, когда эти поступления и затраты происходят (соотносятся по времени). Это практически и есть критерий NPV, и модельный и реальный уровень затрат по нему определяет уровень поступлений (на инициативном проекте это очевидно через продукт, на заказном поступления фиксированы по размеру чаще всего, но по времени могут уехать, что снижает экономическую эффективность). Причем тут нет курояичности, нельзя бесконечно вкладываться в разработку бесконечно повышая поступления, всё определено продуктом и рынком.
Возвращаясь к связи методов, качества, рисков и эффективности. Давайте представим себе два метода разработки для одного и того же ТЗ. Моя мысль в том, что выбор пролегает не в различиях между ними, а в разнице между эффектами от них. Все риски можно оценивать материально, и качество в терминах денег тоже можно оценить (и это часто делают), и затраты на методы можно оценить. Вот и остается только сравнивать (примерный набросок результатов в моем комментарии выше) денежную эффективность.
По моим наблюдениям, скрам, канбан и водопад — самые у нас в стране распространенные практики в инициативной и в заказной разработке, еще есть мода на критическую цепь, но это все равно водопад. Примерная логика экономического анализа может быть следующей. Смотрим риск, который можно определять по нижней границе как [ответственность поставщика за некачественный продукт * вероятность такого дефекта + затраты на весь проект включая разработку и обеспечение качества * вероятность отсутствия продаж], это будет максимум потерь для проекта, причем это сравнимый критерий. Теперь возьмем уже упомянутые скрам, канбан и водопад. В рамках одного проекта, гибкие методы своими техниками и практиками снижают вероятность дефекта с ответственностью, однако эти же техники и практики чаще всего обходятся не в копейки. И вот такими рассмотрениями можно уже оперировать при выборе, точнее в моей практике генеральные в подобном виде и запрашивают аналитику, прежде чем принять решение что-то менять в организации труда: что потратим и что приобретем. Просто деньги — это универсальные попугаи, которыми можно (и нужно) ранжировать альтернативы.
Возвращаясь к связи методов, качества, рисков и эффективности. Давайте представим себе два метода разработки для одного и того же ТЗ. Моя мысль в том, что выбор пролегает не в различиях между ними, а в разнице между эффектами от них. Все риски можно оценивать материально, и качество в терминах денег тоже можно оценить (и это часто делают), и затраты на методы можно оценить. Вот и остается только сравнивать (примерный набросок результатов в моем комментарии выше) денежную эффективность.
По моим наблюдениям, скрам, канбан и водопад — самые у нас в стране распространенные практики в инициативной и в заказной разработке, еще есть мода на критическую цепь, но это все равно водопад. Примерная логика экономического анализа может быть следующей. Смотрим риск, который можно определять по нижней границе как [ответственность поставщика за некачественный продукт * вероятность такого дефекта + затраты на весь проект включая разработку и обеспечение качества * вероятность отсутствия продаж], это будет максимум потерь для проекта, причем это сравнимый критерий. Теперь возьмем уже упомянутые скрам, канбан и водопад. В рамках одного проекта, гибкие методы своими техниками и практиками снижают вероятность дефекта с ответственностью, однако эти же техники и практики чаще всего обходятся не в копейки. И вот такими рассмотрениями можно уже оперировать при выборе, точнее в моей практике генеральные в подобном виде и запрашивают аналитику, прежде чем принять решение что-то менять в организации труда: что потратим и что приобретем. Просто деньги — это универсальные попугаи, которыми можно (и нужно) ранжировать альтернативы.
«Методология экстремального программирования (XP) – состоит из 12 практик» — да ладно. Она не только из практик состоит. Там много чего еще есть. Вальюсы и свое представление о жизненном цикле ПО. Практики — это практики.
«Стартапы характерны тем, что там, особенно в начальный период, всё строится на энтузиазме.» — ерунда. Стартап стартапу рознь. Да и с чего вы взяли, что методология и правила обязательно вредны для энтузиазма. Не замечал такого.
«Если же нам формализованный подход не нужен, тогда мы будем использовать, так называемые, гибкие методологии.» — крайне спорное утверждение. RUP не такой уж и формализованный. Гибкость (следование аджайл манифесту) не обязательно означает меньшую формализованность. Возможность меняться тоже требует формализации. Именно этим и занимается например Скрам. Нельзя так вольно раскидываться терминами.
«Скорость или качество? На самом деле здесь подразумевается немного более сложная формулировка: продуктивность или инженерия?» — тоже какое то мутное утверждение. Скорость — это нисколько не продуктивность, а качество ни в каком месте не инженерия (по крайней мере не только она). Вы точно Кента Бека читали? Речь о том, готовы ли вы вкладывать деньги в механизмы, которые нивелируют экспоненциальный рост стоимости внесения новых изменений. Пресловуто «качество» — это ровно про это. Это чистой воды бизнес вопрос. И именно его нужно задавать.
В моей практике всем известные парные программирования и tdd не только не тормозили разработку, а чаще ускоряли её. Говоря о затратах на «будущее проекта» в рамах XP мы имеем ввиду расходы в целом, включая найм подходящей команды, подготовку инфраструктуры и прочее.
«Скрам ориентирован на постоянное усовершенствование процесса.» — скрам ориентирован на управляемую готовность к внесению изменений. Проведение ретроспектив — это еще не скрам. И усовершенствования процесса — вообще не фишка скрама. Ретроспективиться можно в рамках любой методологии. Следовательно «нужны ли постоянные улучшения» — это не тот вопрос который нужно задавать выбирая Скрам. Сам по себе он сравнительно формализованный каркас. И отличают его прежде всего развитые механизмы итеративной работы (спринт фриз, велосити и прочее).
На Канбан переходят не когда «уже нечего улучшать», а когда команде позволяют скинуть Скрам, как оковы, которые помогают прежде всего заказчику понимать что будет готово через спринт и быть уверенным, что команда мотивирована своим коммитом. Нередко на Канбан переходят, когда просто не удается справиться со Скрамом.
V-Model, RAD не применял — комментировать не могу. Интересно было почитать про них в статье. Но про Скрам, Канбан и Экспи — я бы не рекомендовал следовать этой схеме. Видение авторов очень своеобразно и спорно.
«Стартапы характерны тем, что там, особенно в начальный период, всё строится на энтузиазме.» — ерунда. Стартап стартапу рознь. Да и с чего вы взяли, что методология и правила обязательно вредны для энтузиазма. Не замечал такого.
«Если же нам формализованный подход не нужен, тогда мы будем использовать, так называемые, гибкие методологии.» — крайне спорное утверждение. RUP не такой уж и формализованный. Гибкость (следование аджайл манифесту) не обязательно означает меньшую формализованность. Возможность меняться тоже требует формализации. Именно этим и занимается например Скрам. Нельзя так вольно раскидываться терминами.
«Скорость или качество? На самом деле здесь подразумевается немного более сложная формулировка: продуктивность или инженерия?» — тоже какое то мутное утверждение. Скорость — это нисколько не продуктивность, а качество ни в каком месте не инженерия (по крайней мере не только она). Вы точно Кента Бека читали? Речь о том, готовы ли вы вкладывать деньги в механизмы, которые нивелируют экспоненциальный рост стоимости внесения новых изменений. Пресловуто «качество» — это ровно про это. Это чистой воды бизнес вопрос. И именно его нужно задавать.
В моей практике всем известные парные программирования и tdd не только не тормозили разработку, а чаще ускоряли её. Говоря о затратах на «будущее проекта» в рамах XP мы имеем ввиду расходы в целом, включая найм подходящей команды, подготовку инфраструктуры и прочее.
«Скрам ориентирован на постоянное усовершенствование процесса.» — скрам ориентирован на управляемую готовность к внесению изменений. Проведение ретроспектив — это еще не скрам. И усовершенствования процесса — вообще не фишка скрама. Ретроспективиться можно в рамках любой методологии. Следовательно «нужны ли постоянные улучшения» — это не тот вопрос который нужно задавать выбирая Скрам. Сам по себе он сравнительно формализованный каркас. И отличают его прежде всего развитые механизмы итеративной работы (спринт фриз, велосити и прочее).
На Канбан переходят не когда «уже нечего улучшать», а когда команде позволяют скинуть Скрам, как оковы, которые помогают прежде всего заказчику понимать что будет готово через спринт и быть уверенным, что команда мотивирована своим коммитом. Нередко на Канбан переходят, когда просто не удается справиться со Скрамом.
V-Model, RAD не применял — комментировать не могу. Интересно было почитать про них в статье. Но про Скрам, Канбан и Экспи — я бы не рекомендовал следовать этой схеме. Видение авторов очень своеобразно и спорно.
Очень хорошо что вы написали такой развёрнутый комментарий. Теперь по пунктам:
Изначально 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, но ведь мы помним, статья обращает внимание на моменты, а не навязывает единственно верный подход
С этим я не согласен, но оставлю это на ваше усмотрение. Столько уже копий сломано по поводу Скрама, каждый считает, что понимает его лучше. Опять поднимать это тему не очень хочется. Ваше мнение — ваше мнение. Тем не менее комментарий полезный.
Она не только из практик состоит. Там много чего еще есть
Изначально 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, но ведь мы помним, статья обращает внимание на моменты, а не навязывает единственно верный подход
И усовершенствования процесса — вообще не фишка скрама.
С этим я не согласен, но оставлю это на ваше усмотрение. Столько уже копий сломано по поводу Скрама, каждый считает, что понимает его лучше. Опять поднимать это тему не очень хочется. Ваше мнение — ваше мнение. Тем не менее комментарий полезный.
Стартапы как нельзя лучше демонстрируют это… и моя статья написана для того, чтобы обратить внимание на основные моменты.
Я понимаю, но просто в целом вопрос «стартап?» — это ведь не тот вопрос который стоит задавать, чтобы понять нужно ли в принципе использовать какую то методологию. И про энтузиазм тоже не тот. Есть другие — правильные вопросы. Самый очевидный — это размер и состав проектной команды.
Вообще все эти UPы, как мне кажется, существуют только в больших корпорациях, как раз там где все процессы расписаны и применяется формализованный подход во всём.
В сфере IT в больших корпорациях все может сильно разниться от команды в команде. Но я не замечал, что стандартизованные методологии там (по крайней мере в сфере софтверных разработок) используются там чаще, чем в (условно) маленьких. Скорее это зависит от размера конкретного проекта. Уж не знаю насколько можно экстраполировать свой опыт на ситуацию в целом. Представление о том, как нужно идти по CMMI тоже менялось со временем.
Я вообще то говорил о том, что «гибкость» и «форализованность» — это не антонимы. И незачем их противопоставлять. Да и что это вообще за вопрос «нужен ли вам формализованный подход». Ответ на него всегда «да». Если в команде не один человек работает.
Вот здесь я считаю, вы высказали распространённое заблуждение относительно XP. То, что вы использовали парное программирование и tdd не означает, что вы работали по XP.
Вы сейчас домыслами занимаетесь. Взяли кусок фразы и попытались загнать свое представление обо мне в какой то свой шаблон. Шаблонное мышление не всегда полезно, тем более для такой статьи.
Я привел в пример распространненый мем о том, что ряд xp практик уменьшают «скорость» разработки. Упомянул самые известные в этом смысле. Вот и все. Это не означает, что у меня не было проектов, где бы xp использовался полностью.
Речь шла о том, что нужно четко понимать что такое «скорость» и «качество». Ну попробуйте заказчику задать вопрос, который у вас тут написан: «что для вас важнее — скорость или качество». Знаете какой будет ответ чаще всего? «И то и другое одинакого важно». А если вы еще попытаетесь рассказать, что «качество» — это какая то там инженерия, то он пальцем у виска покрутит. Скажет — нафик мне ваша инженерия, мне нужно бизнес решение моей задачи.
С другой стороны вопрос «хотите ли вы сейчас вкладывать деньги в то, чтобы через год стоимость внесения изменений не стала высока, а через 3 года проект не пришлось из-за этого выкидывать» — это вопрос на который можно дать ответ.
Столько уже копий сломано по поводу Скрама, каждый считает, что понимает его лучше.
Для меня большая загадка чего там спорить. По моему часто встречается попытки его усложнить, домыслить и воткнуть туда какие нибудь новые концепции. В это, вобщем то, довольно простое решение.
Ну неверно утверждать, что основа Скрама — это непрерывное улучшение Срама. Это не правда. Скрам подразумевает конечно такое, но спринты и беклоги в нем не для этого придуманы. Если вы можете ретроспективиться и в рамках Канбана и любой другой методологии. То согласно вашей схеме вам нужно задать совсем другой вопрос, выбирая Скрам.
Есть другие — правильные вопросы.
Правельно заданный вопрос — половина ответа. Пока же я не вижу ничего лучше стартапа. Размер команды мало о чём скажет. Большая часть гибких методологий рассчитана на небольшую команду. Состав команды — вещь слишком многогранная. Понятно что чем опытней команда тем лучше, но как это соотносится с методологиями — не совсем чётко прослеживается.
В сфере IT в больших корпорациях все может сильно разниться от команды в команде.
Всё именно так в организации в которой я работаю.
Скорее это зависит от размера конкретного проекта.
Вот с этим соглашусь, всё-таки размер проекта более решающую роль играет чем размер компании.
«гибкость» и «форализованность» — это не антонимы. И незачем их противопоставлять.
А я их и не противопоставляю. Также как не противопоставляю скорость и качество. Вопрос в том куда смещать акценты.
«нужен ли вам формализованный подход». Ответ на него всегда «да»
тут всё-таки имеется в виду степень формализма. Условно говоря в Скраме не так много процессов расписано по сравнению с RUP и поэтому я позволяю себе называть его не формализованным подходом.
Ну попробуйте заказчику задать вопрос, который у вас тут написан
А этот вопрос и блок-схема не для заказчика. Она создана в обучающих целях, чтобы просто подать сравнение разных методологий в новом формате.
Ну неверно утверждать, что основа Скрама — это непрерывное улучшение Срама.
В чём отличие Скрама и Канбана? Канбан в первую очередь конвейер по добавлению фич. Если необходимо много времени тратить на архитектуру, инфраструктуру то он уже начинает плохо работать. Поэтому он так хорошо прижился в проектах поддержки, и не так хорошо в проектах продуктовой разработки. Скрам же позволят создавать сложные приложения с нуля. Постоянные улучшения это конечно же не главное, но это одна из «фишек» Скрама. Действительно, она существенная, но всё-таки не главная в сравнении Скрама и Канбана. Я подумаю над тем как пересмотреть данный элемент блок схемы!
(удалил комментарий и перенес в правильную ветку)
Sign up to leave a comment.
Блок-схема выбора оптимальной методологии разработки ПО