Михаил отличная аллегория на Scrum. Согласен с тем, что можно комбинировать классическую методику управления проектами и Scrum. Некоторые замечания: - По мимо водопадной модели управления проектами, существуют и боле сложные модели, например V образная модель. Применяется для проектов, в которых цена ошибки ПО велика. - Существует нулевой спринт, на котором Scrum master определяет метрики. Product Owner определяет реперные точки или выходы ключевых версий. - У скрам мастера есть инструменты влияния на команду. Он обладает всеми необходимыми кнутами и пряниками. Он фиксирует закрытие задач. Он проводит "утилизацию" рабочего времени. - Методику скрам расширяют инструменты Lean. Например Матрица компетенций.
Легализация бардака - да, когда известно, как должен выглядеть и работать продукт. Когда требования к продукту меняются (многопользовательский продукт) альтернативы нет, лучше управляемый бардак, чем упорядоченное движение в неправильном направлении.
Спорно, мой опыт показывает, что в ИТ проектах, где уровень кастомизации купленной коробки велик, а понимание конечной цели у Заказчика расплывчато, классический водопад - это гарантированный срыв срока, и даже расширение бюджета не спасёт. А вот Agile как раз неплохо себя показывает.
Хочу чутка заступиться за скрам :) Михаил, если уж к первоисточнику, то нужно было к Sutherland-у или Schwaber-у ехать (ни тот, ни тот, не толстый). Ну и несколько моментов которых вы неверно с тренинга с собой унесли: - Скрам не требует взаимозаменяемости членов команды - Также не требует людей высокой квалификации Скрам прекрасно масштабируется и для этого есть несколько различных фреймворков. После двух дневного тренинга глубина вашего понимания скрам очень и очень начальная, поэтому очень многие ваши комментарии споры. Я бы посоветовал не списывать скрам со счетов а познакомиться с этим зверем поближе и попрактиковаться примерно столько же сколько практикуетесь на строительных проектах. А потом уже судить его по всей строгости.
***** Про "чаще всего" согласен. И без ценностей, на которых базируются аджайл (AgileManifesto.org) и скрам (commitment, courage, focus, openness, respect) на самом деле ничего никуда не полетит. И как я часто говорю на тренингах без доверия и ответственности, тоже мало чего хорошего сделаешь :).
Насчет легализации бардака сказано правильно, но от энтропии в разработке ПО никуда не деться - требования заказчика почти всегда имеют высокую неопределенность даже при наличии ТЗ, т.к. пока пользователь не потыкает в интерфейсе программы, он, скорее всего, не способен представить по ТЗ конечный результат и соотнести его со своим идеализированным представлением о том, как он хочет в программе работать. Заказчик редко берет на себя ответственность за соответствие ТЗ со пожеланиями своих внутренних пользователей, перекладывая эту ответственность на разработчиков. Поэтому идея Agile заключается в поэтапной разработке и улучшении продукта до тех пор пока клиент не скажет "стоп". А сказать "стоп" он заинтересован, т.к. каждая итерация стоит денег, и он 5 раз подумает, стоит ли оплачивать итерацию ради какой-нибудь бесполезной фигни. Идеологи Agile просто признали факт, что по ТЗ работать в большинстве случаев не получается, т.к. заказчики не умеют думать на необходимом уровне абстракции. Бывают ситуации, когда внутренние пользователи клиента не заинтересованы в во внедрении, но саботировать проект они будут за деньги заказчика, а не за время разработчика. Так что у Agile есть вполне конкретная область применения - это проекты, в которых погрешность планирования делает планирование бессмысленным.
В строительстве как раз,где высокую неопределённость можно возместить с помощью экспертов гибкие методологии ,возможно, и нет смысла применять.Аджайл и скрам будет эффективней, где непонятно что делать и к какому результату нужно прийти(особенно в рамках долгосрочных проектах)Так как ни команда ни заказчик сами до конца не могут знать что нужно.Сейчас в строительстве это не так востребовано, так как технологии и потребности заказчика там не так стремительно меняются,как в ,например IT. И к слову не все кто считают себя скрам мастерами понимают аджайл ценности(не в обиду Вам, много скрам мастеров и среди айти не до конца их понимают и то что без них скрам не работает)
Спасибо, посмотрел.Очень рад за строительную индустрию, так как сам имею диплом инженера-строителя и нам 5 лет назад рассказывали,что строительство одна из самых отстающих в плане авоматизации(не знаю может у меня универ отсталый,хотя КУбГТУ в краснодарском крае считается лучшим). Мне кажется и сейчас это только на уровне крупных компаний жизнеспособно для внедрения,после универа работал в 3х строительных компаниях,где управление было сравнимо с армией(выполни задачи во имя компании,даже если она не имеет смысла, все стоны снизу(даже важные для бизнеса) руководством либо полностью игнорируются,либо жёстко пресекаются),особенно где были госзаказчики,да и технологии в строительстве на уровне 70-80х годов на 70%. Вот я и перекочевал в IT,тут люди в основе более продвинутые и гибкие) Насчёт BIM.В моделировании при работе с заказчиком скорее всего аджайл будет очень уместен,дабы добиться максимальной удовлетворённости заказчика и ускорения согласования требований. В областях, где применимо креативное мышление аджайл приносит бОльшую пользу и могу связать с человеком,если хотите, который расскажет о крутом кейсе в работе с архитектурным отделом и внедрением там аджайла. При строительстве непосредственно, скорей всего аджайл не имеет смысла применять, так как это восновном Good practices по Киневину (посмотрите видео) и здесь скорей всего будет более уместен ватерфол.Так как после моделирования, согласования требований проекта, более менее чётко ясно,к какому конкретному результату нужно прийти.В IT разработке через пол года требования к проекту могут претерпеть координальные изменения со всеми вытекающими. Предполагаю, учитывая динамику развития технологий в строительстве тоже скоро без гибких методологий нельзя будет обойтись,комбинируя всё в меньшей степени с ватерфолом.Компании ,которые смогут создать правильный баланс уже сейчас смогут на голову вырасти по сравнению с теми,кто только ватерфолом работает.
Конечно всё хорошо сказал(расказал)! Но не предложил норм альтернативу против этих методологий. На пример я не одну из этих методологий не пользовался но всё таки надо соблюдать какие не было бы закономерности! А так по твоим словам если не быть норм специалистом (в команде) то scrum и agile не поможет. Да и правильно это им самые лучшие методологии тоже вряд ли помогут. В прочем норм рассказал!
ситуация такая, собирается команда недоуч... "высококвалифицированных" "сверхъспециализированныхъ" профессионалов и особо тупой и борзый сынуля главного акционера манаГер с большой буквы Г уверовавший в свое величие на роли СКРАМ мастера. Клиент понятно ничего не понимает в программировании и не может объяснить важные особенности бизнес логики. Заказать эксперта со знанием смежных областей программирования и сферы деятельности клиента -- жаба душит. Манагер нервничает. Что бы не дрочить мозг команде (это явно не поможет делу), манагера отправляют дрочить мозг клиенту, что бы тот принял то что получилось, потому что за*бали. Вывод: в команде на роли лидера должен быть специалист высокой квалификации с обширными навыками, который и сам может все сделать и указать на ошибки своих подчиненных. С клиентом должен работать специалист с образованием в прикладной сфере, разбирающийся в бизнес логике клиента и с базовыми знаниями в информатике (что бы мог понять что важно для программистов). А сынуля акционера должен сидеть на стуле и загадочно улыбаться.
Мда. Как и все черно-белое, очень спорно. У нас в компании тоже сначала была мода на годовой план. 3 года была. Потом наконец все поняли, что если компания - лидер рынка, то надо не то что пошевеливаться, а нестись жестко вперед и резко реагировать на изменения. Скрам нужен там где неопределенность и постоянные изменения. Поэтому в нашем проекте намечаются стратегические задачи на год на половину команды, остальная часть команды работает при полном отсутствии плана, по запросу в реальном времени. Внедрения еженедельные, вся разработка в скраме. Так мы получаем реализацию стратегии и гибкость одновременно. Прибегает биз в понедельник - Ааа, надо вот так! В пятницу на проме. Ну и конечно, скрам без ресурсов не работает, люди нужны опытные и в достаточном количестве. А для этого нужно менеджменту прилагать нужные усилия. Кстати, есть у меня еще один проект, там такое ПО своеобразное, которое очень умное и незаменимое, но девелопится втрое дольше первого. Поэтому там скрам не применяется, а используется стандартный подход с подготовкой ТЗ, согласованием, оценкой, планированием и исполннием при минимуме СиАров. Скрам там не имеет смысла, потому что любое изменение - месяц работы дева, это очень дорого и заказчики сто раз думают, прежде чем что-то менять.
"Легализация бардака" - прям вижу у человека на стене кучи дипломов и сертификатов (в том числе сертификата scrum mastera, как сам признался). Если есть желание применять "методологии" - надо в коучи идти. На подобии описанного в выступлении "большого американского мужика". А если есть желание делать проекты чтобы всем было хорошо - применяйте здравый смысл. и не надо плевать в зеркало, если ...
![[#2024MAMA] BIGBANG (빅뱅) - 뱅뱅뱅 (BANG BANG BANG) + FANTASTIC BABY | Mnet 241123 방송](http://i.ytimg.com/vi/EQsYfiPR9uM/mqdefault.jpg)
Михаил отличная аллегория на Scrum. Согласен с тем, что можно комбинировать классическую методику управления проектами и Scrum. Некоторые замечания:
- По мимо водопадной модели управления проектами, существуют и боле сложные модели, например V образная модель. Применяется для проектов, в которых цена ошибки ПО велика.
- Существует нулевой спринт, на котором Scrum master определяет метрики. Product Owner определяет реперные точки или выходы ключевых версий.
- У скрам мастера есть инструменты влияния на команду. Он обладает всеми необходимыми кнутами и пряниками. Он фиксирует закрытие задач. Он проводит "утилизацию" рабочего времени.
- Методику скрам расширяют инструменты Lean. Например Матрица компетенций.
Легализация бардака - да, когда известно, как должен выглядеть и работать продукт.
Когда требования к продукту меняются (многопользовательский продукт) альтернативы нет,
лучше управляемый бардак, чем упорядоченное движение в неправильном направлении.
Спорно, мой опыт показывает, что в ИТ проектах, где уровень кастомизации купленной коробки велик, а понимание конечной цели у Заказчика расплывчато, классический водопад - это гарантированный срыв срока, и даже расширение бюджета не спасёт. А вот Agile как раз неплохо себя показывает.
Хочу чутка заступиться за скрам :)
Михаил, если уж к первоисточнику, то нужно было к Sutherland-у или Schwaber-у ехать (ни тот, ни тот, не толстый).
Ну и несколько моментов которых вы неверно с тренинга с собой унесли:
- Скрам не требует взаимозаменяемости членов команды
- Также не требует людей высокой квалификации
Скрам прекрасно масштабируется и для этого есть несколько различных фреймворков.
После двух дневного тренинга глубина вашего понимания скрам очень и очень начальная, поэтому очень многие ваши комментарии споры. Я бы посоветовал не списывать скрам со счетов а познакомиться с этим зверем поближе и попрактиковаться примерно столько же сколько практикуетесь на строительных проектах. А потом уже судить его по всей строгости.
***** Про "чаще всего" согласен. И без ценностей, на которых базируются аджайл (AgileManifesto.org) и скрам (commitment, courage, focus, openness, respect) на самом деле ничего никуда не полетит. И как я часто говорю на тренингах без доверия и ответственности, тоже мало чего хорошего сделаешь :).
Насчет легализации бардака сказано правильно, но от энтропии в разработке ПО никуда не деться - требования заказчика почти всегда имеют высокую неопределенность даже при наличии ТЗ, т.к. пока пользователь не потыкает в интерфейсе программы, он, скорее всего, не способен представить по ТЗ конечный результат и соотнести его со своим идеализированным представлением о том, как он хочет в программе работать. Заказчик редко берет на себя ответственность за соответствие ТЗ со пожеланиями своих внутренних пользователей, перекладывая эту ответственность на разработчиков.
Поэтому идея Agile заключается в поэтапной разработке и улучшении продукта до тех пор пока клиент не скажет "стоп". А сказать "стоп" он заинтересован, т.к. каждая итерация стоит денег, и он 5 раз подумает, стоит ли оплачивать итерацию ради какой-нибудь бесполезной фигни. Идеологи Agile просто признали факт, что по ТЗ работать в большинстве случаев не получается, т.к. заказчики не умеют думать на необходимом уровне абстракции. Бывают ситуации, когда внутренние пользователи клиента не заинтересованы в во внедрении, но саботировать проект они будут за деньги заказчика, а не за время разработчика.
Так что у Agile есть вполне конкретная область применения - это проекты, в которых погрешность планирования делает планирование бессмысленным.
Хаха, очень смеялся в начале, Михаил, спасибо!
Безумно правдиво, так и работаем в айти
В строительстве как раз,где высокую неопределённость можно возместить с помощью экспертов гибкие методологии ,возможно, и нет смысла применять.Аджайл и скрам будет эффективней, где непонятно что делать и к какому результату нужно прийти(особенно в рамках долгосрочных проектах)Так как ни команда ни заказчик сами до конца не могут знать что нужно.Сейчас в строительстве это не так востребовано, так как технологии и потребности заказчика там не так стремительно меняются,как в ,например IT. И к слову не все кто считают себя скрам мастерами понимают аджайл ценности(не в обиду Вам, много скрам мастеров и среди айти не до конца их понимают и то что без них скрам не работает)
Спасибо, посмотрел.Очень рад за строительную индустрию, так как сам имею диплом инженера-строителя и нам 5 лет назад рассказывали,что строительство одна из самых отстающих в плане авоматизации(не знаю может у меня универ отсталый,хотя КУбГТУ в краснодарском крае считается лучшим).
Мне кажется и сейчас это только на уровне крупных компаний жизнеспособно для внедрения,после универа работал в 3х строительных компаниях,где управление было сравнимо с армией(выполни задачи во имя компании,даже если она не имеет смысла, все стоны снизу(даже важные для бизнеса) руководством либо полностью игнорируются,либо жёстко пресекаются),особенно где были госзаказчики,да и технологии в строительстве на уровне 70-80х годов на 70%.
Вот я и перекочевал в IT,тут люди в основе более продвинутые и гибкие)
Насчёт BIM.В моделировании при работе с заказчиком скорее всего аджайл будет очень уместен,дабы добиться максимальной удовлетворённости заказчика и ускорения согласования требований.
В областях, где применимо креативное мышление аджайл приносит бОльшую пользу и могу связать с человеком,если хотите, который расскажет о крутом кейсе в работе с архитектурным отделом и внедрением там аджайла.
При строительстве непосредственно, скорей всего аджайл не имеет смысла применять, так как это восновном Good practices по Киневину (посмотрите видео) и здесь скорей всего будет более уместен ватерфол.Так как после моделирования, согласования требований проекта, более менее чётко ясно,к какому конкретному результату нужно прийти.В IT разработке через пол года требования к проекту могут претерпеть координальные изменения со всеми вытекающими.
Предполагаю, учитывая динамику развития технологий в строительстве тоже скоро без гибких методологий нельзя будет обойтись,комбинируя всё в меньшей степени с ватерфолом.Компании ,которые смогут создать правильный баланс уже сейчас смогут на голову вырасти по сравнению с теми,кто только ватерфолом работает.
Конечно всё хорошо сказал(расказал)!
Но не предложил норм альтернативу против этих методологий.
На пример я не одну из этих методологий не пользовался но всё таки надо соблюдать какие не было бы закономерности!
А так по твоим словам если не быть норм специалистом (в команде) то scrum и agile не поможет. Да и правильно это им самые лучшие методологии тоже вряд ли помогут.
В прочем норм рассказал!
ситуация такая, собирается команда недоуч... "высококвалифицированных" "сверхъспециализированныхъ" профессионалов и особо тупой и борзый сынуля главного акционера манаГер с большой буквы Г уверовавший в свое величие на роли СКРАМ мастера. Клиент понятно ничего не понимает в программировании и не может объяснить важные особенности бизнес логики. Заказать эксперта со знанием смежных областей программирования и сферы деятельности клиента -- жаба душит. Манагер нервничает. Что бы не дрочить мозг команде (это явно не поможет делу), манагера отправляют дрочить мозг клиенту, что бы тот принял то что получилось, потому что за*бали. Вывод: в команде на роли лидера должен быть специалист высокой квалификации с обширными навыками, который и сам может все сделать и указать на ошибки своих подчиненных. С клиентом должен работать специалист с образованием в прикладной сфере, разбирающийся в бизнес логике клиента и с базовыми знаниями в информатике (что бы мог понять что важно для программистов). А сынуля акционера должен сидеть на стуле и загадочно улыбаться.
Мда. Как и все черно-белое, очень спорно.
У нас в компании тоже сначала была мода на годовой план. 3 года была. Потом наконец все поняли, что если компания - лидер рынка, то надо не то что пошевеливаться, а нестись жестко вперед и резко реагировать на изменения. Скрам нужен там где неопределенность и постоянные изменения. Поэтому в нашем проекте намечаются стратегические задачи на год на половину команды, остальная часть команды работает при полном отсутствии плана, по запросу в реальном времени. Внедрения еженедельные, вся разработка в скраме. Так мы получаем реализацию стратегии и гибкость одновременно. Прибегает биз в понедельник - Ааа, надо вот так! В пятницу на проме. Ну и конечно, скрам без ресурсов не работает, люди нужны опытные и в достаточном количестве. А для этого нужно менеджменту прилагать нужные усилия.
Кстати, есть у меня еще один проект, там такое ПО своеобразное, которое очень умное и незаменимое, но девелопится втрое дольше первого. Поэтому там скрам не применяется, а используется стандартный подход с подготовкой ТЗ, согласованием, оценкой, планированием и исполннием при минимуме СиАров. Скрам там не имеет смысла, потому что любое изменение - месяц работы дева, это очень дорого и заказчики сто раз думают, прежде чем что-то менять.
Смеялся громко :))
Михаил, я кажется работал недавно в чем-то подобном. Мозг поломал немного
"Легализация бардака" - прям вижу у человека на стене кучи дипломов и сертификатов (в том числе сертификата scrum mastera, как сам признался). Если есть желание применять "методологии" - надо в коучи идти. На подобии описанного в выступлении "большого американского мужика". А если есть желание делать проекты чтобы всем было хорошо - применяйте здравый смысл. и не надо плевать в зеркало, если ...