Методологии SCRUM, Agile, Kanban и т.д. с точки зрения руководителя и разработчика

Добрый день! Хотелось бы в следующем видео услышать ваше мнение про всякие методологии разработки, типа SCRUM, Agile и т.д. Какую методологию предпочли бы вы как руководитель и как разработчик? Действительно ли они повышают продуктивность команды? Стоит ли изучать этот вопрос разработчику?

Какими критериями руководствуются при выборе методологии разработки. В частности Кабан и Agile. Сюда же преимущества и недостатки данных методологий.

От Скрам мастера слышал следующее, что Agile в чистом виде не используется не в одном проекте. Согласны ли вы с этим утверждением и если да, то почему так выходит?

[zatraun]

От одного из лекторов слышал, что большинство проектов работает по методологии HDD - hope driven development. Всё делается как придется, но с надеждой, что получится хорошо.

[destroyer_]

Есть еще методологии "всего по чуть чуть" и "мы не знаем как мы работаем, но всем говорим что у нас все по скраму"

[catchchange]

Очень интересное обсуждение методологий! Тоже порой думаем, какой подход эффективнее: гибкость Agile или структурированность Kanban. Для себя открыли сервис Strive, в онлайне работать проще и приятнее) В работе заметно, что чистый Agile встречается редко, а каждый проект подстраивает методологию под свои задачи. Особенно ценно услышать мнение, как выбрать подход, чтобы балансировать продуктивность и комфорт команды! Спасибо!

[miniminimalist]

Пришёл с работы, думал 5 минут ютуб проверить, попал на ваш канал и залип уже на 5 часов... Спасибо большое за ваш труд, Сергей, очень хорошие видео! :)

[YauhenKavalchuk]

О, шикарно!!! Это было интересно послушать!

[Yarik_K_Zhelobyts_kyy]

Вітаю, чудово, здоров'я, благословінь, миру.

[pimenaus]

Сергей, спасибо за видео! Неплохо описан взгляд менеджера и инженера на все эти подходы. Не хочу показаться пуристом и не буду придираться к мелочам (рассказать точно до мелочей - это был бы серьезный вызов), хочу просто немного по верхам вас поправить. Смотрите, то что вы описывали касающееся выпуска MVP - это подход Lean Startup, у которого есть конкретный автор (Если не ошибаюсь Эрик Риз) и он не имеет никакого отношения к Lean Manufacturing придуманному на Тойоте. Так же как и Канбан Метод, который сейчас используют в IT тоже не имеет никакого отношения к Lean Manufacturing и используемому там Канбану. Здесь вопрос скорее в том, что как раз Lean Manufacturing не смогли применить к IT-разработке из за того, что есть очень сильная специфика. Lean Manufacturing сделан для материального мира, производства материальной продукции и производственных цепочек, которые требуют достаточно мало умственной работы (когнитивных навыков). Современный же Канбан Метод, который был придуман в конце 2000-х как раз в нашем любимом IT (зачатки этого подхода появились в Microsoft) и он придуман именно для процессов требующих большого количества когнитивной работы и выпуска нематериальных продуктов. Помимо того, что современный Канбан не имеет никакого отношения к Lean (а во многих вещах действует ровно наоборот) он не имеет никакого отношения к Agile, это подход который был придуман как альтернатива тем подходам, которые мы привыкли называть гибкими, чтобы избегать тех проблем, которые они вызывали при внедрении. Если будет интересно, то готов на эту тему пообщаться, можете меня в FB найти или в телеге, буду рад конструктивному диалогу

[chillwavemusic]

Как менеджер не в IT (пока ;) добавлю: для управления необходимо отталкиваться от задач и предмета вопроса, а не от названия методологии и её подбора.
Например, для простых, одноступенчатых задач - определил, довёл исполнителю / команде, проверил.
Для комплексных проектов - постоянный контроль, сверка, корректировка, запуск.

[Ogr]

Как всегда, просто, ясно, доходчиво о сложных и многогранных вещах.
Сергей, спасибо.

[MeHous]

Достаточно понятное объяснение методологий, спасибо.
Очень интересно будет посмотреть ролик с вашим мнение по поводу плюсов и минусов этих методологий, почему от каких-то то уходят и другим приходят.

[illiafuncan]

Знаю и работаем только по технологии ASAP - as soon as possible :)
Понимаю, что это краткий экскурс в методики, но мне это нужно было, чтобы хотя бы общее представление иметь. В книгах довольно запутано пишется, имхо :))
Спасибо за видео!

[igorshaula]

как начался разговор на менеджерскую тему - сразу как-то мутно стало... :) а за ролик спасибо

[jewgenijmoldawski]

Вот хорошо сказал: у одних работает, у других нет. Независимо от метода все решает компетентность и работоспособность команды и руководителей.

[expertpromo]

Спасибо. Доступно, без лишнего пафоса

[cookiemonster]

Чорт побери так! Відсутність взаємовиключень це головна особливість, що ускладнює процес вивчення методологіїй.

[svtlichnijj]

Дякую за цікаву і достатньо повну відповідь.

[ellsham]

Аджайл и скрам это красивая обёртка для того, чтоб выжимать из разраба все соки

[GreatNorthernWar]

Сходил на конференцию по Kanban, у. У нас это хайп сейчас) Но все понимают, что это не истина. Актуальны все методы, какой подойдёт вам, зависит от ваших кейсов и контекста. Сергей, как всегда спасибо за контент

[natty]

Часто противопостовляемая (для контраста - опять же маркетинг!) аджайл методам упомянутая здесь технология, называемая "водопад" (на самом деле, я думаю, это термин, неверно переведенный с английского и не отражающий сути - правильно должно быть как "каскад" или "каскадная технология" или просто "последовательная разработка"). Этот неэффективный и нежизнеспособный метод организации разработки, иногда случающийся на заре становления программирования, действительно имел место и иногда имеет место и в наши дни. Возможно к нему склонны военные, хотя я не думаю что только они - скорее это общечеловеческая некомпетентность, которой всегда хватало.
Давно признанно что разработка software это итеративный процесс и это было открыто еще в 70-80гг.
Более того многие подобные идеи использовались еще до возникновения программирования.
Например, в строительстве гидроэлектростанций - станцию запускали в несколько этапов, уже после первого этапа, еще до окончания строительства, она уже начинала давать ток и приносить прибыль. В несколько этапов запускают космические аппараты к далеким телам солнечной системы - сначала грубый запуск в нужном направлении, потом при первом приближении - анализ местоположения, цикл ориентации и корректировка траектории, при следующем приближении - итерацию повторяют. И так может быть несколько раз. Также стараются поступать и в программировании - как можно скорее запустить первую упрощенную версию системы, чтобы не только начать получать первую полезную отдачу от системы, но и ЧТО БОЛЕЕ ВАЖНО - получить feedback от заказчика, чтобы уточнить требования к системе (может быть даже изменившиеся) и вовремя ориентировать разработку в нужном направлении.

[TruVi-]

Как Вы правы.!.... Не существует "волшебной таблетки" на все случаи жизни.... Простота, новизна, чётко поставленные цели, большое желание работать, тесты + ЗДРАВЫЙ СМЫСЛ, который подсказывает как быстрее достичь нужный результат в конкретных ситуациях.