Agile - а был ли SCRUM?
Рет қаралды 27,092
9 жыл бұрынСКАЧАЙТЕ онлайн-курс по Управлению проектами ►►► www.pmsmart.ru/pminstitute/?ut...
Мой взгляд на проблемы и возможности применения гибкого управления проектами (Agile и Scrum).
Несомненно, SCRUM подход к управлению достоин применения.
Но, несмотря на то, что Agile и SCRUM кажутся простыми к внедрению, по факту есть мало организаций, которые реально могут заявить, что являются Agile и работают в среде SCRUM.
По большей части, речь идет о симуляции SCRUM и попытке легализовать свой бардак, дав ему красивое название Agile.
✨✨✨Подписывайтесь на канал: kzfaq.info...
👇👇👇 РЕКОМЕНДУЕМЫЕ ЭКСПРЕСС ВИДЕО-КУРСЫ 👇👇👇
🔹 Практикум по управлению проектами - www.pmpshop.ru/171217-intensiv...
🔹Управление рисками в MS Project - www.pmpshop.ru/risk-web/180324
🔹Инициация проекта - www.pmpshop.ru/initiation/landing
🔹Планирование проекта - www.pmpshop.ru/planning
🔹Риски проекта - www.pmpshop.ru/Risk-002-Trip
🔹Шаблоны проектных документов - www.pmsmart.ru/shablony-dokum...
🔹Должностные инструкции - www.pmsmart.ru/dolzhnostnye-i...
🔹Интегральный шаблон проекта - www.pmpshop.ru/blueprint
🔹Гибкое управление проектами - www.pmsmart.ru/agile-base-trip...
🔹Команда проекта - www.pmpshop.ru/project-team/tr...
🔹Переговоры в проектах - www.pmsmart.ru/peregovory-trip...
🔹Жесткие переговоры в проектах - www.pmsmart.ru/tough-negotiati...
✨✨✨Присоединяйтесь к профессиональному сообществу:
Vkontakte: pmsofonov
Facebook: / pmsofonov
Telegram: t.me/pminstitute
Instagram: / pmsofonov
Интересные видео:
🔹 Управление проектами от А до Я • Управление проектами о...
🔹 MS Project 10 • MS Project 2016 за 30 ...
🔹 PMBOK 10 kzfaq.info?o=U&vide...
🔹 Введение в управление проектами • Введение в управление ...
🔹 Управление проектами - онлайн курс • Video
🔹 Топ 10 терминов по управлению проектами • Проектное управление -...
🔹 Agile - а был ли SCRUM? • Agile - а был ли SCRUM?
🔹 MS Project 2016 - как использовать правильно • MS Project 2016 - как ...
🔹 Agile методология • Agile методология
🔹 Методы управления проектами за 5 минут (Живая запись) • Методы управления прое...
🔹 Сравнение Oracle Primavera и MS Project • Сравнение Oracle Prima...
🔹 PMBoK - с чем его едят и анекдот в подарок! • PMBoK - с чем его едят...
🔹 SCRUM - области применения • SCRUM - области примен...
🔹 ТОП 3 качества руководителя проекта (менеджера проекта) • Video
🔹 Управление проектами - практический инструмент • Управление проектами -...
🔹 Стандарты управления проектами
• Управление проектами -...
🔹 Microsoft Project 2016 & Project Online • Microsoft Project & Pr...
🔹 Внедрение PMBoK • Внедрение PMBoK
🔹 Как подготовиться к сертификации на PMP • Как подготовиться к се...
🔹 Стейкхолдеры проекта - заинтересованные участники проекта • Стейкхолдеры проекта -...
🔹 Менеджмент управления проектами • Курсы управления проек...
🔹 Жизненный цикл проекта • Жизненный цикл проекта
🔹 Управление проектами - практический инструмент 2 • 01/23 Курсы управелния...
🔹 Признаки проекта • Признаки проекта
🔹 Управление мудаками проекта (реализацией проекта) • Управление мудаками пр...
🔹 Руководитель проекта (Менеджер проекта) - функции • Руководитель проекта (...
🔹 Треугольник ограничений • Треугольник ограничений
🔹 Команда проекта - тест Белбина • Команда проекта - тест...
🔹 Организационные структуры (оргструктуры) проекта • Организационные структ...
🔹 Процессы управления проектом • Процессы управления пр...
🔹 MS Project 2016 Календарь рабочих дней • MS Project 2016 Календ...
🔹 Agile - стратегии внедрения • Agile - стратегии внед...
#SCRUM #Agile #Kanban
@user-hh2fe7pb7e 7 жыл бұрын
Легализация бардака - да, когда известно, как должен выглядеть и работать продукт. Когда требования к продукту меняются (многопользовательский продукт) альтернативы нет, лучше управляемый бардак, чем упорядоченное движение в неправильном направлении.
@dashkinrv 9 жыл бұрын
Михаил отличная аллегория на Scrum. Согласен с тем, что можно комбинировать классическую методику управления проектами и Scrum. Некоторые замечания: - По мимо водопадной модели управления проектами, существуют и боле сложные модели, например V образная модель. Применяется для проектов, в которых цена ошибки ПО велика. - Существует нулевой спринт, на котором Scrum master определяет метрики. Product Owner определяет реперные точки или выходы ключевых версий. - У скрам мастера есть инструменты влияния на команду. Он обладает всеми необходимыми кнутами и пряниками. Он фиксирует закрытие задач. Он проводит "утилизацию" рабочего времени. - Методику скрам расширяют инструменты Lean. Например Матрица компетенций.
@RepinsRus 8 жыл бұрын
Спорно, мой опыт показывает, что в ИТ проектах, где уровень кастомизации купленной коробки велик, а понимание конечной цели у Заказчика расплывчато, классический водопад - это гарантированный срыв срока, и даже расширение бюджета не спасёт. А вот Agile как раз неплохо себя показывает.
@ADadiani 8 жыл бұрын
Насчет легализации бардака сказано правильно, но от энтропии в разработке ПО никуда не деться - требования заказчика почти всегда имеют высокую неопределенность даже при наличии ТЗ, т.к. пока пользователь не потыкает в интерфейсе программы, он, скорее всего, не способен представить по ТЗ конечный результат и соотнести его со своим идеализированным представлением о том, как он хочет в программе работать. Заказчик редко берет на себя ответственность за соответствие ТЗ со пожеланиями своих внутренних пользователей, перекладывая эту ответственность на разработчиков. Поэтому идея Agile заключается в поэтапной разработке и улучшении продукта до тех пор пока клиент не скажет "стоп". А сказать "стоп" он заинтересован, т.к. каждая итерация стоит денег, и он 5 раз подумает, стоит ли оплачивать итерацию ради какой-нибудь бесполезной фигни. Идеологи Agile просто признали факт, что по ТЗ работать в большинстве случаев не получается, т.к. заказчики не умеют думать на необходимом уровне абстракции. Бывают ситуации, когда внутренние пользователи клиента не заинтересованы в во внедрении, но саботировать проект они будут за деньги заказчика, а не за время разработчика. Так что у Agile есть вполне конкретная область применения - это проекты, в которых погрешность планирования делает планирование бессмысленным.
@KirillSkobelev 8 жыл бұрын
Хаха, очень смеялся в начале, Михаил, спасибо! Безумно правдиво, так и работаем в айти
@Blackie6 9 жыл бұрын
Хочу чутка заступиться за скрам :) Михаил, если уж к первоисточнику, то нужно было к Sutherland-у или Schwaber-у ехать (ни тот, ни тот, не толстый). Ну и несколько моментов которых вы неверно с тренинга с собой унесли: - Скрам не требует взаимозаменяемости членов команды - Также не требует людей высокой квалификации Скрам прекрасно масштабируется и для этого есть несколько различных фреймворков. После двух дневного тренинга глубина вашего понимания скрам очень и очень начальная, поэтому очень многие ваши комментарии споры. Я бы посоветовал не списывать скрам со счетов а познакомиться с этим зверем поближе и попрактиковаться примерно столько же сколько практикуетесь на строительных проектах. А потом уже судить его по всей строгости.
@Blackie6 9 жыл бұрын
***** Про "чаще всего" согласен. И без ценностей, на которых базируются аджайл (AgileManifesto.org) и скрам (commitment, courage, focus, openness, respect) на самом деле ничего никуда не полетит. И как я часто говорю на тренингах без доверия и ответственности, тоже мало чего хорошего сделаешь :).
@mikhailsklyarenko 7 жыл бұрын
В строительстве как раз,где высокую неопределённость можно возместить с помощью экспертов гибкие методологии ,возможно, и нет смысла применять.Аджайл и скрам будет эффективней, где непонятно что делать и к какому результату нужно прийти(особенно в рамках долгосрочных проектах)Так как ни команда ни заказчик сами до конца не могут знать что нужно.Сейчас в строительстве это не так востребовано, так как технологии и потребности заказчика там не так стремительно меняются,как в ,например IT. И к слову не все кто считают себя скрам мастерами понимают аджайл ценности(не в обиду Вам, много скрам мастеров и среди айти не до конца их понимают и то что без них скрам не работает)
@mikhailsklyarenko 7 жыл бұрын
Спасибо, посмотрел.Очень рад за строительную индустрию, так как сам имею диплом инженера-строителя и нам 5 лет назад рассказывали,что строительство одна из самых отстающих в плане авоматизации(не знаю может у меня универ отсталый,хотя КУбГТУ в краснодарском крае считается лучшим). Мне кажется и сейчас это только на уровне крупных компаний жизнеспособно для внедрения,после универа работал в 3х строительных компаниях,где управление было сравнимо с армией(выполни задачи во имя компании,даже если она не имеет смысла, все стоны снизу(даже важные для бизнеса) руководством либо полностью игнорируются,либо жёстко пресекаются),особенно где были госзаказчики,да и технологии в строительстве на уровне 70-80х годов на 70%. Вот я и перекочевал в IT,тут люди в основе более продвинутые и гибкие) Насчёт BIM.В моделировании при работе с заказчиком скорее всего аджайл будет очень уместен,дабы добиться максимальной удовлетворённости заказчика и ускорения согласования требований. В областях, где применимо креативное мышление аджайл приносит бОльшую пользу и могу связать с человеком,если хотите, который расскажет о крутом кейсе в работе с архитектурным отделом и внедрением там аджайла. При строительстве непосредственно, скорей всего аджайл не имеет смысла применять, так как это восновном Good practices по Киневину (посмотрите видео) и здесь скорей всего будет более уместен ватерфол.Так как после моделирования, согласования требований проекта, более менее чётко ясно,к какому конкретному результату нужно прийти.В IT разработке через пол года требования к проекту могут претерпеть координальные изменения со всеми вытекающими. Предполагаю, учитывая динамику развития технологий в строительстве тоже скоро без гибких методологий нельзя будет обойтись,комбинируя всё в меньшей степени с ватерфолом.Компании ,которые смогут создать правильный баланс уже сейчас смогут на голову вырасти по сравнению с теми,кто только ватерфолом работает.
@murodtatibayev3232 6 жыл бұрын
Конечно всё хорошо сказал(расказал)! Но не предложил норм альтернативу против этих методологий. На пример я не одну из этих методологий не пользовался но всё таки надо соблюдать какие не было бы закономерности! А так по твоим словам если не быть норм специалистом (в команде) то scrum и agile не поможет. Да и правильно это им самые лучшие методологии тоже вряд ли помогут. В прочем норм рассказал!
@GlincoGlinco 7 жыл бұрын
Мда. Как и все черно-белое, очень спорно. У нас в компании тоже сначала была мода на годовой план. 3 года была. Потом наконец все поняли, что если компания - лидер рынка, то надо не то что пошевеливаться, а нестись жестко вперед и резко реагировать на изменения. Скрам нужен там где неопределенность и постоянные изменения. Поэтому в нашем проекте намечаются стратегические задачи на год на половину команды, остальная часть команды работает при полном отсутствии плана, по запросу в реальном времени. Внедрения еженедельные, вся разработка в скраме. Так мы получаем реализацию стратегии и гибкость одновременно. Прибегает биз в понедельник - Ааа, надо вот так! В пятницу на проме. Ну и конечно, скрам без ресурсов не работает, люди нужны опытные и в достаточном количестве. А для этого нужно менеджменту прилагать нужные усилия. Кстати, есть у меня еще один проект, там такое ПО своеобразное, которое очень умное и незаменимое, но девелопится втрое дольше первого. Поэтому там скрам не применяется, а используется стандартный подход с подготовкой ТЗ, согласованием, оценкой, планированием и исполннием при минимуме СиАров. Скрам там не имеет смысла, потому что любое изменение - месяц работы дева, это очень дорого и заказчики сто раз думают, прежде чем что-то менять.
@alexeybeloushko7240 6 жыл бұрын
ситуация такая, собирается команда недоуч... "высококвалифицированных" "сверхъспециализированныхъ" профессионалов и особо тупой и борзый сынуля главного акционера манаГер с большой буквы Г уверовавший в свое величие на роли СКРАМ мастера. Клиент понятно ничего не понимает в программировании и не может объяснить важные особенности бизнес логики. Заказать эксперта со знанием смежных областей программирования и сферы деятельности клиента -- жаба душит. Манагер нервничает. Что бы не дрочить мозг команде (это явно не поможет делу), манагера отправляют дрочить мозг клиенту, что бы тот принял то что получилось, потому что за*бали. Вывод: в команде на роли лидера должен быть специалист высокой квалификации с обширными навыками, который и сам может все сделать и указать на ошибки своих подчиненных. С клиентом должен работать специалист с образованием в прикладной сфере, разбирающийся в бизнес логике клиента и с базовыми знаниями в информатике (что бы мог понять что важно для программистов). А сынуля акционера должен сидеть на стуле и загадочно улыбаться.
@tolpenok 4 жыл бұрын
Смеялся громко :))
@DmMakarovUA 9 жыл бұрын
Михаил, я кажется работал недавно в чем-то подобном. Мозг поломал немного
@user-gl2rr6ft7t 6 жыл бұрын
"Легализация бардака" - прям вижу у человека на стене кучи дипломов и сертификатов (в том числе сертификата scrum mastera, как сам признался). Если есть желание применять "методологии" - надо в коучи идти. На подобии описанного в выступлении "большого американского мужика". А если есть желание делать проекты чтобы всем было хорошо - применяйте здравый смысл. и не надо плевать в зеркало, если ...
Михаил Софонов - Управление проектами
Рет қаралды 37 М.
SOFIADELMONSTRO
Рет қаралды 69 МЛН
АйТиБорода
Рет қаралды 519 М.