Agilean — убийца Lean и Agile

image

Гибридная методология управления на основе ценностей


В этой статье мы расскажем вам об Agilean («Эджайлин») как методе создания гибридных инструментов на базе Lean и Agile и шире об Agilean как о философии управления бизнесом с плацдарма ценностей.

Немного поговорим о нюансах физиологии и психологии человека, исходя из которых была сформулирована логика метода Agilean, и, в заключении, разберем практический пример и принципы применения этого гибридного метода для решения бизнес-задач.

Счастье в труде или понимание дофаминовой основы мотивации сотрудников


Рассматривая биологические системы и механизмы, созданные Природой (можете подставить сюда «Бог», «Высшие силы» или любое другое слово, которое вам больше нравится), нельзя не восхищаться тем, насколько сложны и в то же время гармоничны и надёжны, инженерные решения, применённые в строительстве человеческого организма. Многим из них миллионы лет, но они остаются неизменными и продолжают успешно выполнять свои функции, несмотря на радикально изменившиеся условия применения.

Вечная актуальность и эффективность этих решений обеспечивается тем, что они строятся не на контекстных условиях, а на базовых принципах. Разберём одно их них, а именно механизм «непрерывного улучшения» и стремления к постоянному развитию. Своеобразный физио-психологический kaizen человека.

При создании эффективного организма перед природой лежала задача, как сделать так, чтобы каждая особь популяции непрерывно стремилась не только к размножению и укреплению своей безопасности, но и к непрерывному развитию и улучшению всех аспектов существования популяции.

Как и с другими основными инстинктами, Природа решила эту задачу при помощи связки «рептильный мозг» человека + гормональная система.

При «социально-неправильном» поведении человека рептильный мозг отдаёт команду гормональной системе применить «кнут» в виде выделения гормона депрессии и саморазрушения – кортизола, и «пряник» — в виде выделения гормона мотивации и предвкушения счастья – дофамина при «социально-правильном» поведении.

Решение того, как понимать, какое социальное поведение человека правильное (направленное на развитие популяции) и какое неправильное (направленное на что угодно кроме развития популяции), тоже было простым, надёжным и элегантным, как всё, что делает Природа.

Наш туповатый «рептильный» мозг просто считывает, что думают о нашем поведении окружающие нас люди, используя наши мысли на этот счёт. Если мы считываем реакцию социума на наши действия как одобряющую, то древний мозг открывает дофаминовые краники, наполняющие нас радостью, предвкушением награды, а также энергией и неутомимой волей к преодолению преград по дороге к цели.

Вспомните момент, когда вы взялись за важный проект, результаты, которого, как вы точно знали, могли сильно продвинуть вас и упрочить ваше карьерное положение, и с каждым успешным шагом ваш мозг затоплял вас радостным предвкушением. Вам хотелось думать только о проекте и о его целях, вы могли без устали работать по 20 часов в день, и просыпались наполненными кипучей позитивной энергией, несмотря на недосып и нездоровый режим питания.

Но вам наверняка не составит труда вспомнить и те моменты, когда успех проекта был под угрозой – стресс, беспокойство и страх, если риски неудачи были не фатальны. А при полном провале, когда вы понимали, что успех проекта практически недостижим, вы ощущали депрессию, апатию, невозможность заставить себя сделать хоть что-либо и стойкое желание «бросить всё и уехать в Гагры».

Кортизол и дофамин — проделки старой доброй матушки Природы, которая без тени сомнения готова подвергнуть нас любым страданиям, если мы не приносим пользу популяции, но не откажет и в награде, если мы полезны.

Именно поэтому человек, оказывающийся в бездействии неминуемо тяготеет к искусственной генерации дофамина в виде таких быстрых удовольствий, как наркотики, алкоголь, обжорство и т.д.

— Это всё занимательная информация, — скажете вы. – Но причём здесь Lean, Agile и управление бизнесом?

Ок. Давайте рассмотрим причём здесь управление бизнесом и какой практический смысл для нас, людей дела, имеет вся эта информация.

Theory of Constraints для механизмов и людей


В далёких 80х Элияху Голдрат разработал «Теорию ограничений». Как гласит Википедия «Основной особенностью его методологии является то, что делая усилия над управлением очень малым количеством аспектов системы, достигается эффект, намного превышающий результат одновременного воздействия на все или большинство проблемных областей системы сразу или поочерёдно.

Подход теории ограничений основан на том, чтобы выявлять это ограничение и управлять им для увеличения эффективности достижения поставленной цели (для бизнеса ускорение и увеличение генерации прибыли). Где эффективность – это скорость достижения цели с минимально возможными затратами и без урезания цели по содержанию.»

Несмотря на то, что Теория ограничений постепенно эволюционировала как методология по решению любых системных проблемы малыми затратами, основное применение она получила в области оптимизации производственных процессов. По сути, все её действия направлены на повышение двух основных KPI работы оборудования — КИО (коэффициент использования оборудования) и КТГ (коэффициент технической готовности).

Если использовать её принципы совсем примитивно, то для создания максимально эффективной производственной цепочки вы должны устранить узкие места («бутылочные горлышки») процесса, настроить работу всех единиц оборудования в одном ритме и поддерживать техническое состояние каждой единицы оборудования в оптимальном для механизма состоянии – работе на полную проектную мощность с минимальным количеством сбоев.

В соответствии с принципами гибридного подхода Agilean, мы взяли эту методологию и применили к людям, однако при этом учитывая, что люди – не механизмы, и обеспечение максимального КИО (коэффициент использования оборудования) и КТГ (коэффициент технической готовности) для людей достигается другими методами.

После нехитрых рассуждений мы приходим к выводу, что для построения идеальных организационных процессов (в отличие от производственных) мы должны обеспечить 1) максимальную расшивку процесса коммуникации (потому что в отличие от механизмов, люди в организационном процессе приводят друг друга в движение при помощи коммуникации, а не шкивов и шестерней), 2) механизм постоянной мотивации, который будет заставлять каждую единицу человеческой цепи работать на своей максимальной проектной мощности при минимальной амортизации.

И если ценность свободной коммуникации как обеспечения быстродействия человеческих цепей (организаций) довольно известна и очевидна просвещённому кругу бизнес-деятелей, то ценность самоорганизации как единственного идеального инструмента вовлечения и мотивации сотрудников не для всех очевидна.

Более того (автор позволит себе небольшое лирическое отступление по этому наболевшему вопросу) HR-службы практически всех крупных современных российских компаний с упорством достойным лучшего применения продолжают наполнять свои корпоративные программы повышения вовлечённости сотрудников такими вещами, как «улучшение бытовых условий сотрудников», «путёвки для лучших сотрудников» и т.д. и т.п, каждый раз удивляясь, почему же результаты такой мотивации дают лишь кратковременный эффект.

Если бы они понимали принципы дофаминовой мотивации, им бы быстро стало очевидно, что их программы вовлечённости похожи на пичканье бездельника наркотиками – эффект кратковременный и с каждым разом всё более малоощутимый, а синдром отмены разрушительный.

Какие же принципы дофаминовой мотивации нужно знать, чтобы сделать вовлечённость ваших сотрудников максимально высокой, незатратной для компании, постоянной и самовозобновляемой.

Принципы эти просты:

  • «Амбициозные, но достижимые цели» — «рептильный мозг» выдаст сотруднику много дофаминовой энергии-мотивации, только если он сам считает, что цель важна. Но также цель должна быть достижимой, потому что страх «кортизольного» кнута не позволит ему действовать в случае высокой вероятности провала.
  • «Самоорганизация» — «рептильный мозг» откроет дофаминовые краники только в случае если поставленная задача будет подчёркивать высокую ценность человека в глазах популяции — сравните постановку задачи руководителем: «Эдуард, компания решила запустить важный для компании проект, и мы считаем, что только вы можете привести его к успеху, подумайте и предложите наилучший вариант его реализации» и «Эдуард, проект очень важный, так что я написал вот тут детальный план, где расчертил всё до мелочей, следуйте ему неукоснительно и отчитывайтесь о продвижении каждый день утром и вечером».

Очевидно, что в первом случае рептильный мозг считает высокую важность человека для популяции и затопит его дофаминовой мотивацией, а во втором, безошибочно поймёт, что важен для популяции как раз руководитель, а Эдуард лишь тупой инструмент, способный только на выполнение чьих-то инструкций. Собственно и вместо энергии во втором случае Эдуард получит кортизольную дубину, от которой любая мысль о выполнении такого задания вызовет опущенные руки, стойкую зевоту и желание выполнить его максимально формально, а лучше вообще от него уклониться.

Зная эти принципы психо-физиологического механизма мотивации человека и трансформировав их в определённый набор культурных ценностей, мы можем выстраивать идеальный организационный формат любой бизнес-деятельности, точечно выбирая, адаптируя и гибридизируя инструменты из любых бизнес методологий.

То есть применяя и гибридизируя Теорию ограничений Голдратта к человеческому взаимодействию мы можем вывести следующие коэффициенты – КИЭ (коэффициент использования энергии) и КЭГ (коэффициент энергетической готовности). Также с учётом этих принципов легко сформулировать культурные ценности, создающие условия для повышения этих коэффициентов и привести примеры инструментов из разных бизнес методологий, которые мы можем для этого использовать.

image

Agilean на практике – бизнес-кейс компании “X”


Теперь, когда основные принципы Agilean-философии изложены, мы приведем пример их практического применения, для того, чтобы было ясно, как метод гибридной разработки инструментов на базе этой философии может приносить реальную ценность бизнесу.


image
image
image
image
image

Бизнес-результаты трансформации:

  • Финансовые показатели, поставленные клиентом как целевые на весь срок реализации (8 месяцев), достигнуты за первый месяц внедрения.
  • Выполнены и перевыполнены все операционные KPI, поставленные на отчётный период
  • В рамках проекта сгенерированы решения по операционным улучшениям в несколько десятков раз превышающие изначальные целевые финансовые показатели и сходные показатели по нескольким аналогичным проектам, внедряемым на других бизнес-единицах по классическим Lean-методологиям
  • Повышена мораль и вовлечённость коллектива
  • Успешная культурная трансформация зафиксирована в рамках пилотного проекта

«И одно кольцо, чтобы править всеми…»


На примере данного бизнес-кейса продемонстрированы преимущества методологии Agilean над классическими методологиями и философиями оптимизации бизнеса типа Lean, Agile, ToC и всех подобных существующих на сегодняшний день. Они заключаются в следующем:

  • Нет необходимости «внедрения методологии и философии», не надо заучивать нюансы и тонкости применения методологий, которые разрабатывались в другом контексте, возможно отличном от вашего
  • Легко диагностировать проблемы и предложить улучшения только на основании только диагностики состояния основных ценностей
  • Вы можете создавать новые, изменять и гибридизировать существующие инструменты, отталкиваясь от конкретного случая, конкретных проблем и контекста на базе понимания ценностей и общей бизнес логики
  • Быстрое внедрение, быстрые и ощутимые улучшения

По сути основанный на понимании психофизиологических процессов мотивации человека метод Agilean – это шаг на следующую ступень разработки и понимания методологий по повышению эффективности бизнеса. Он представляет набор принципов, объединяющий все существующие методологии, может объединять и использовать любые инструменты повышения эффективности и раскрывает простые принципы выбора или создания инструментов под конкретную проблему.
Поделиться публикацией

Похожие публикации

AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 48

    +7
    Шиза косит наши ряды.
      0
      Шиза — не энурез, жить можно! :-b
      +1
      На примере данного бизнес-кейса продемонстрированы преимущества методологии Agilean над классическими методологиями и философиями оптимизации бизнеса типа Lean, Agile, ToC и всех подобных существующих на сегодняшний день.

      Но может быть результаты краткосрочные достигнуты просто по тому, что на это было обращено пристальное внимание руководства?
      Или как вариант ЗП исполнителям подкинули :)
        –2

        Нет, материальной мотивации не было. А пристальное внимание руководства точно помогло для первого импульса, который помог сподвигнуть людей (особенно миддл менеджмент) к начальным изменениям.
        Рядовве сотрудники в принципе были готовы поддержать такие изменения так как работали в условиях перманентного стресса, отставания от плана и абсурда в целеполагании. Они и являются основной движущей силой механизмов Agilean, так как один раз попробовав свободу самоорганизации и получив высокие результаты минимумом усилий, ни за что не вернутся к старой системе

          0
          один раз попробовав свободу самоорганизации и получив высокие результаты минимумом усилий, ни за что не вернутся к старой системе

          Я общался с руководством и работниками одной «бирюзовой» организации.
          Со стороны руководства прямо таки цитирование ваших слов. Со стороны сотрудников — «задолбала эта бирюзовость», проблемы не решаются, ответственных не найти.
          Кроме того, делая такие заявления нужно учитывать местные реалии. Если другой работы нет, то люди делают все, чтобы заработать какие то деньги. Вне зависимости от бирюзовости организации. И опять же, если ЗП крайне низкая, то никакая «бирюзовость» не поможет.
          Еще замечу, что то, что ранее называлось «здравый смысл», теперь обзывается множеством названий: «цепь», «леан», «агиле», 5 сигм и прочая и прочая.
            0

            По моему опыту основная проблематика введения Agile заключается в том, что люди не понимают что этот самый Agile не работает "локально". То есть нельзя перевести на Agile только девтимы а всё остальное оставить как есть.


            По хорошему надо всю фирму под это дело "перестраивать" и самое главное клиентов. Иначе на мой взгляд ничего хорошего из этого не получится. И многие фирмы делают именно такую ошибку и в результате начальство довольно что "у нас теперь аджайл", а работники страдают от диссонанса структур и процессов.

              0

              Именно так. Потому что отталкиваются от инструмента или методологии а не от ценностей.
              В Agilean они бы не "внедряли Agile в девтимах" а решали проблемы со Свободой коммуникаций, Психологической безопасностью, Непрерывным улучшением и Гибкостью


              Оттуда выпали бы совсем другие меры а не локалтная трансформация одной команды

              0

              Agilean — не равно "бирюзовость". А там где сотрудники плюются от "бирюзовости" и там где плюются от "Agile" ситуация одна — неправильное понимание и применение.
              Например бирюза работает только там где уровень развитости сотрудников в духе "внутреннего энтерпренёрства" очень высокий. То есть каждый сотрудник высококомпетентный самомотивированный профессионал, которому не нужны указания, чтобы знать куда двигаться, и нужна только координация чтобы достигать вместе большего.
              Согласитесь такие команды редки. Просто нужно знать на каком уровне развития сотрудников какой инструмент внедрять

                +1
                каждый сотрудник высококомпетентный самомотивированный профессионал

                Это утопия, где-то рядом с коммунизмом.
                  0

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

                    +1
                    В небольших стартапах чаще всего такие команды и собираются.

                    А как надолго хватает самомотивированности? Пока не женился?
                      0

                      Ничто не вечно под луной

                        +1
                        Ну я и говорю. Метод управления, нуждающийся для своей работы в наличии у коллектива определённых свойств, которыми в принципе обладают только небольшие коллективы, и только временно, не может быть принят на предприятии, ожидаемый срок существования которого измеряется десятками лет.
                          0

                          Есди вы про бирюзу, то да я тоже вижу что для крупного предприятия это может быть и выполнимая задача, но весьма трудоемкая — придется вложить огромные силы и средства в развитие каждого сотрудника индивидуально. Есть такие компании но им пришлось кроме всего прочего и избавляться от процентов 30 команды. В общем это сложная и неоднозначная тема. Но выполгимая

                            0
                            развитие каждого сотрудника индивидуально

                            И повторять эту процедуру, когда у него запал кончится.
                0

                Постоянно это слышу, но прописаных практик по "здравому смыслу" найти не могу. Как, например, в здравом смысле релизы планируются? А как проверяется скорость/готовность выполнения фич? А трудоёмкость каждой задачи? А важность задачи? Это наверное меньше 1% того, на что в аджайле есть прямые непротиворечивые ответы.


                А со "здравым смыслом" как разобраться чтобы каждый от управляющего директора до последнего разраба/qa имели консистентную картину в головах? А не перетягивал одеяло в соответствии со своим пониманием картины мира.


                Очень хочется посмотреть как это сработает хотя бы в среднего размера департаменте команд на 25-40.

                  0
                  Т.е. до аджайла проекты ИТ сферы не делали? Делали и весьма хорошо.
                  А вопросы, которые вы задали решаются достаточно просто. Собираетесь, задаете вопросы и принимаете по ним решения, как вам это нужно.
                  Каждый тянет одеяло на себя это нормально, это в человеческих свойствах. Если можешь получить ресурсы, пытаешься их получить. Если амбиций хватает, конечно.
                  А после какого то размера, размер уже не сильно играет. Все бьется на команды и работает. Я работал в «небольших» департаментах по вашей системе оценке.
                  До 200 человек. На этом уровне разницы в организации процесса между 50 человек и 200 человек не заметил.
                  Да и в целом по фирме (порядка 4000 человек) все похоже.
                    0
                    Т.е. до аджайла проекты ИТ сферы не делали? Делали и весьма хорошо.

                    Это немного демагогия, не находите? Вместо аджайла можно подставить любое слово. Например система контроля версий, CI, юнит-тесты, код-ревью и так далее…


                    А вопросы, которые вы задали решаются достаточно просто. Собираетесь, задаете вопросы и принимаете по ним решения, как вам это нужно.

                    Как определить, на какую дату назначить релиз? Или наоборот, какие фичи будут готовы к заранее известной дате релиза? Предлагаете поверить на слово?


                    Я вполне допускаю, что если каким-то чудом собрать в одном офисе достаточно умных и замотивированных на результат людей, то какой-то (пускай значительной) части аджайл-церемоний можно и избежать. Но я ни разу не видел, чтобы это работало на практике. Возможно у нас разный опыт

                      0
                      Это немного демагогия, не находите? Вместо аджайла можно подставить любое слово. Например система контроля версий, CI, юнит-тесты, код-ревью и так далее…

                      Нет, не нахожу.
                      Контроль версий технический инструмент, по поводу необходимости которого нет никаких холиваров. Это понятно, удобно и нужно.
                      Остальное вами перечисленное также применяется при необходимости.
                      А вот когда начинаются менеджерские практики, тут оказывается не все однозначно.
                      У меня опыт разный. И с использованием айджал и без оного. Я не увидел большой разницы. Гораздо в большей степени зависит от компетентности и мотивированности людей. А айджалы это просто инструмент, который можно применять, а можно и не применять. Не серебряная пуля. Так же как и прочие кайдзены, сигмы и прочая и прочая. Какие то моменты ото всюду можно надергать и адаптировать под себя, не превращая в карго культ, тогда будет хорошо. Когда работает тот самый плохо формализованный «здравый смысл». А так, формально прописанные штуки, отличная вещь для имитации работы людей, которые на самом деле могут не рубить фишку, не понимать процесс. Но изображают понимание и выкатывают видимость, видите, мол, все делаем по феншую, значит мы молодцы, а проекты буксуют по объективным причинам.
                      Ну как вариант.
                      Я не против формализации, я обеими руками за. Но я за то, чтобы за ширмой этой формализации не терялась суть. Как тут хороший пример сохранил себе:
                      "— Я правильно интерпретирую семантику вопроса, но полностью игнорирую его суть.
                      — Не могли бы вы привести пример?
                      — Мог бы."
                      Так и с айджалом по аналогии. Цель все таки не процедуры айджаловские, а реализация командой продукта на выходе. Это главное. С сопуствующими фишками.
                        0

                        "Какие то моменты ото всюду можно надергать и адаптировать под себя, не превращая в карго культ" — согласен. Весь Agilean именно об этом

            +4
            Как я это вижу.

            До: некомпетентное начальство хочет чувствовать себя начальством, и поэтому лезет к работникам и мешает работать (всё время).

            После: игры начальства с работниками регламентированы и ограничены по времени, у работников появляется свободное время для того, чтобы делать работу, поэтому она начинает делаться. Начальник чувствует себя начальником, но им не является, функции начальника исполняет кто-то из толковых работников (самоорганизация).

            Написанное в статье — как раз регламент игр.
              0

              Этот фактор точно присутствует, но и работа самих сотрудников тоже переформатирована от бездумного индивидуального выполнения задач на работу с группой, анализ собственной эффективности и непрерывное улучшение.


              Работа руководства перефокусировалась на предоставление чётких стратегических KPI, методологический коучинг подчиненных (само собой они были сначала этому обучены), и защиту команды от внешних воздействий.

                0
                защиту команды от внешних воздействий


                Вот это очень здорово, ценно и полезно на мой взгляд, думаю за это вам там многие благодарны.
                  –1

                  Так и было

              0

              Ну визуализация это вообще старый инструмент

                +5

                Ох какой песец… Как вы читали Голдратта если потом пытаетесь "увеличить коэффициент использования энергии" в общем, хотя до этого говорили что метод "бутылочного горлышка" состоит как раз в противоположном — улучшение малыми затратами одного места, а не попыток улучшить везде и всё?
                Заголовок — желтуха, как вот эта хрень связана с agile и lean вообще непонятно. Изобрели очередное громкое слово для недоруководителей.
                Что потом подкрепляется словами "Нет необходимости «внедрения методологии и философии»". Т.е. вы натянули рефлексы собаки Павлова на человека и утверждаете что решили все проблемы, моментально, без побочных эффектов и без необходимости помочь и научить людей думать по-другому? Трешачок.

                  0

                  "коэффициент использования энергии" не относится к Голдратту. Я написал что по факту все усилия ТоС влияют на КИО. Что вас тут смущает не пойму потому что это именно так и есть и оспорить этот факт невозможно.


                  Я ничего не натягивал — откройте любую научную статью про дофамин и мотивацию и прочитайте сами.


                  Эта "хрень" связана с Lean и Agile тем что максимально эффективно использует инструменты и той и другой методологии избавившись от недостатков каждой.


                  Я не говорю что нет "необходимости помочь", я говорю что при правильной конфигурации системы "необходимость помочь думать по-другому" минимальна, так как происходит learning by doing

                  +1
                  примере данного бизнес-кейса продемонстрированы преимущества методологии Agilean над классическими методологиями и философиями оптимизации бизнеса типа Lean, Agile, ToC и всех подобных существующих на сегодняшний день

                  Если честно то я не вижу каких-то особых преимуществ. То есть вы их конечно перечислили, но все эти преимущества имеет и "обычный" Agile. А вот преимуществ вашей методики по сравнению с ним я не вижу.


                  Да и какой-то принципиально новой методологии я честно говоря не вижу. Обычное "натягивание" и подстраивание Agile на свою ситуацию.

                    0

                    По сути Agile в идеальном понимании и есть Agilean. Но в своём реальном состоянии Agile пока слищком заточен под IT, в нём недостаточно системно реализован компонент кайзен (системные механизмы непрерыаных улучшений) и он перезарегламентирован всеми этими "евангелистами Agile" которые просто остановивщиеся в своем развитии консультанты, которые хотят сшибать денежку за минимальные знания. Они настаивают что Agile-решения должны регламентироваться до каждого мини шажка и не признают на деле гибридизации и экспериментов.


                    В этом смысле Agilean и есть тот самый "правильный Agile" абсолютно свободный в экспериментах и гибридизации подходов и инструментов под задачу

                      0
                      В этом смысле Agilean и есть тот самый "правильный Agile" абсолютно свободный в экспериментах и гибридизации подходов и инструментов под задачу

                      Вы извините но "правильный Agile" это просто правильный Agile. И для того чтобы делать Agile правильно не нужны какие-то новые сущности и новые названия.


                      И даже если вы назовёте это Agilean или ещё как-то, то это никак не защитит вас от "евангелистов Agilean", которые точно так же будут:


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

                      П.С. И не поймите меня неправильно, я не считаю вашу методику саму по себе чем-то плохим или ущербным. Просто это на мой взгляд не "убийца Agile", а только один из вариантов его реализации.

                        0

                        Новые сущности нужны, так как пока ни в одной трактовке Agile нет гибридизации и создания новых инструментов "от контекста". Везде пытаются натягивать контекст на инструмент.
                        Более того я считаю что Agilean — это попытка выйти на верхний уровень где основное ценности, а все методологии типа Lean, ToC, Agike и т.д. Суть просто локальные проявления законов этой Вселенной организационного управления. Так что имхо абсолютно точно нужен такой пересмотр. Это как разрабатывать механизмы отталкиваясь от законов физики. Сейчас фигурально выражаясь это разработка механизмов способом копирования других механизмов.


                        Про консультантов согласен но учитывая принцип свободной гибридизации, зарегламентировать эту методологию будет сложней

                          0
                          Новые сущности нужны, так как пока ни в одной трактовке Agile нет гибридизации и создания новых инструментов "от контекста"

                          Вот об этом пожалуйста поподробнее. Я может чего-то не понимаю, но у меня другое видение ситуации.


                          Про консультантов согласен но учитывая принцип свободной гибридизации, зарегламентировать эту методологию будет сложней

                          Вы походе смешиваете Agile как методологию с конкретными вариантами иеализации вроде того же Scrum. Но вас же никто не заставляет брать имеющиеся варианты и вы можете придумать свой. Что вы кстати на мой взгляд и сделали.


                          То есть как я это вижу вы скорее придумали альтернативу Scrum, а не альтернативу Agile.

                            0

                            Сейчас в Agile есть много фреймворков и каждая провозглашает что только одна она правильная, ни одна не провозглашает "разные фреймворки могут применяться в зависимости от контекста и условий, а в определенных случаях они могут совмещаться, гибридизироваться, или на их базе могут строиться новые, совсем другие". Что было бы как раз правильным Agile подходом. Но сейчас на практике такого нет.


                            Смотрите у Agile ценности: Люди и взаимодействие важнее процессов и инструментов.
                            Работающий продукт важнее исчерпывающей документации.
                            Сотрудничество с заказчиком важнее согласования условий контракта.
                            Готовность к изменениям важнее следования первоначальному плану.


                            У Agilean ценности: Свободная коммуникация, Психологическая безопасность, Непрерывное улучшение и Гибкость


                            Какие более универсальны и лкгко адаптируемый под любой бизнес контекст бищнес отрасли?


                            Так что у меня изменение и на уровне Скрам и на уровне Аджайл

                              0
                              Сейчас в Agile есть много фреймворков и каждая провозглашает что только одна она правильная, ни одна не провозглашает "разные фреймворки могут применяться в зависимости от контекста и условий, а в определенных случаях они могут совмещаться, гибридизироваться, или на их базе могут строиться новые, совсем другие". Что было бы как раз правильным Agile подходом. Но сейчас на практике такого нет.

                              Я соглашусь что такое часто встречается. Очень часто. Но при этом всё-таки не абсолютно везде. И как я уже писал выше это скорее проблема "исполнителей", а не самой методики. И на мой взгляд эта проблема будет у любой методики такого "типа".


                              Какие более универсальны и лкгко адаптируемый под любой бизнес контекст бищнес отрасли?

                              Ок, теперь немного понятнее о чём речь. На мой взгляд "проблема" ваших ценностей в их размытой формулировке. И в том что они местами "конфликтуют" друг с другом.
                              Если совсем упрощать, то приходит мой коллега/начальник с каким-то "гибким улучшением", а я ему в ответ что это несовместимо с моей "психологической безопасностью". И как этот конфликт будет решён в средней фирме? На мой взгляд скорее всего введением какого-то жёсткого "приоризирующего" правила. И рано или поздно этих правил будет много.

                                0

                                Ну я точно не изобретал чегото что никогда нигде никем не пробовалось. Я скорее взял идею и концептуализировал, упорядочил и оформил в более или менее стройную методологию (я пока в начале пути и она будет конечно дорабатываться ибо пока сыровата). И исходил я чисто из практического применения. Революция данная методология не совершит, но точно поможет расшивке таких мифов как "Lean и Agile не работают". А учитывая какие суперуспешные результаты она даёт на практике, ценность (как минимум пока для меня).


                                По поводу вашего случая — вот именно такие случаи возможны при классических внедрениях Lean и Agile. В Agilean всегда превалирует ценность. Если психологическая безопасность нарушена — значит будем делать по другому. Но опять же надо понимать — психологическая безопасность это когда атмосфера в команде позитивная, открытая и демократичная, каждый может высказывать любые глупые идеи и нет никакого иерархического давления на свободу общения.


                                Если человеку предлагают поработать а он не хочет, прикрываясь психологической безопасностью, то конечно будет рассмотрено почему он так чувствует, но в итоге такой токсичный человек просто сам будет выдавлен командой, которая все таки обьединилась для получения результата а не для благостного ничегонеделанья

                          0
                          Невозможно «делать Эджайл», это манифест, декларация в стиле «это лучше того» и занимает одну страницу. Делать можно, например, Скрам.
                            0

                            Вы ошибаетесь. Agile и манифест Agile — разные вещи

                              0
                              В чем же конкретно ошибка? Эджайл — подход к формулированию методологии. Скрам — реализация методологии в форме методики. Дадите ссылку на описание методики Эджайл?
                                0
                                Ошибка в том, что Agile — это философия. Agile манифест — это сформулированные в IT-контексте и для IT-контекста основные законы и постулаты этой философии.

                                Методики Agile нет, но «делать Agile» — вполне себе можно. Есть даже такое понятие «Do Agile» — то есть организация своей деятельности в духе философии Agile.
                                  0
                                  Не думаю: О'Джайл — это просто разновидность гербалайфа в приложении к IT
                                    0
                                    Действительно. Если технологических критериев нет, как в случае со Скрамом, тогда любой «художник» может объяснить, что он тут видит суслика.
                                    0
                                    Хм… Всегда интересовал этот вопрос… Вот работаю я по «водопаду». Приходит ко мне Заказчик, говорит мне надо вот тут фичу доработать. Я ее дорабатываю, но отправляю его делать необходимые документы (запрос на изменение, спецификацию требований). Я не agile? На этапе опытной эксплуатации, возникает проблема — я ее решаю, но потом вношу изменение в проектную документацию — я не agile?
                                      0
                                      «Я не agile?»

                                      Ну плодить бюрократию и бумагооборот — это точно не Lean и не Agile)
                                        0

                                        Серьёзно? Вы делаете изменения просто по устной договорённости с заказчиком? Без спецификаций и документации?


                                        Если у вас "in house" разработка это ещё может быть и будет работать. Но если у вас экстерные клиенты…

                                          0
                                          Да, делаем, но мы не занимаемся разработкой и даже не в IT
                                        0

                                        Так, как вы это описываете, вы на самом деле не работаете по "водопаду".


                                        То есть agile это или нет надо ещё разбираться. Но это точно не "водопад" :)

                                          0
                                          А что в вашем понимании «водопад»? Если это рафинированный вариант Концепция->Проектирование->Разработка->ОПЭ, строго последовательно и без отклонений, то это работает на очень ограниченном сегменте проектов. Если работать с системами ERP-класса, то там приходится комбинировать. И действительно быть agile, т.е. следовать ценностям Agile, а если глянуть на последовательность работ, то в принципе это модернизированный водопад, примерно как и говорил Винстон Ройс.
                                          upd. И кстати, согласен с VMichael, «то что ранее называлось здравым смыслом...» Стараюсь всегда руководствоваться им, а не только методичкой :)
                                            0

                                            Ну если совсем упрощать то на мой взгляд "водопад" это действительно когда у вас есть определённая последовательность и вы её жёстко придерживаетесь.


                                            Плюс я бы ещё наверное причислил к особенностям "водопада" и достаточно большие по объёму "пакеты" и относительно длительное время на разработку прежде чем готовый результат видит заказчик.


                                            И я бы сказал что то, что вы описываете, скорее ближе к какому-нибудь канбану чем к "водопаду".

                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                        Самое читаемое