company_banner

Agile: 9 вредных советов

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

    Григорий Остер.


    На конференциях, митапах, вебинарах все дают полезные советы по Agile. И никто их не ценит — ни советчиков, ни советы. А мы решили по совету Григория Остера найти побольше новых друзей — потому что мы дружелюбные — и дать вам вредные советы по Agile.



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


    2. Если вы Agile-коуч, сразу приходите к руководству, говорите кучу незнакомых слов и требуйте революции. Libertе, Еgalitе, Fraternitе. Можете даже принести с собой маленькую гильотинку и показать, как режутся косты и сокращается персонал. Скорее всего вас не поймут — но ведь это их проблема, а не ваша. А когда увидят предполагаемые траты на тренинги и внешний консалтинг – сразу же согласятся. Потому что топ-менеджеры обожают тратить деньги непонятно куда — после этого у них появляется возможности поговорить с любимыми инвесторами, которых так трудно заманить на встречу.


    3. Приходите в свой отдел и уверенно объявляйте, что с понедельника у вас Agile, а для этого с пятницы у вас Scrum. Давление, непрозрачность, непонятные слова – сотрудники будут вам благодарны и Agile-трансформация пойдёт быстрее. Весело и быстро — как на санках с Эвереста.


    4. Сразу же обещайте золотые горы: «Вот, если мы станем Agile, мы перевыполним план в 3 раза или выполним проект в 4 раза быстрее». Никто не знает, как будет, потому никто не оспорит ваши слова. И вы всегда будете правы — а это приятно.


    5. Лучше всего начинать Agile-трансформацию c IT — ни в коем случае не втягивайте смежные подразделения. Пусть они не знают, как вам классно и здорово. Не делитесь полезностям, фичами и кейсами. Если они спросят, чем вы занимаетесь, никогда не рассказывайте и делайте загадочное выражение лица. Вызывайте здоровую корпоративную зависть. И вам это вернётся сторицей и дружелюбием.


    6. Через месяц после начала Agile-транформации гордо выходите на сцену всех конференций, до которых дотянетесь. DevOps? Ок. Ежегодное собрание МАГАТЭ — вообще отлично. Участвуйте во всех внешних мероприятиях, всем рассказывайте, что вы стали «бирюзовой» организацией. И пусть у вас до сих пор генеральный карает всех по вертикали раз в две недели, никому не верит, а служба безопасности обыскивает ваши квартиры, пока вы на работе. Вы уже «бирюзовые» через месяц. И пусть кто-то оспорит — у генерального бита есть с надписью «самому эффективному руководителю «красной» организации». Самое главное — это пиар. Сегодня среда или четверг? Значит с понедельника называйтесь «бирюзовой» организацией.


    7. Самый главный совет. Agile — это история о том, как меньше общаться с клиентом и конечным пользователем. Люди сами не знают, чего хотят, а вы прекрасно знаете их потребности. Можете даже бейсболки клиентам на входе раздавать с надписью «I don't know». Они всё равно нихт шпрехен инглиш. Клиентам будет приятно, а вам весело. Если клиентам дать волю, они напридумывают что-то, а вам всё менять. Ещё и работать придётся. Вы лучше всех знаете своего клиента и услугу. И нечего с клиентом церемониться.


    8. Ни в коем случае не создавайте лишних сущностей. Это ещё монах Оккам придумал. Если нанимать каких-то непонятных Scrum master и product owner, пусть это будет один человек. Его задача — четко сообщить команде, что нужно сделать команде, если они ещё когда-то в жизни захотят увидеть свою зарплату. После этот незаменимый человек проведёт ретроспективу и станет вашим личным психологом. Не умножайте сущностей — бритва Оккама рулит.


    9. Самое вредное и ненужное мероприятие в скраме и Agile-культуре — это ретроспектива. Люди два часа обсуждают, что им нравится и что мешает. Мы же взрослые люди и понимаем, что нравится им получать зарплату, а мешает врожденная лень. Понятно, что Agile-коуч хочет показать свою полезность, но пусть показывает ее другим способом.


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


    Составляла вредные советы Марина Алекс marina_alex, CEO University of Business Agility, автор и основной спикер Слёрма Agile Слёрм Agile.


    Southbridge
    Обеспечиваем стабильную работу highload-проектов

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

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

      +2
      Все тут боятся коронавируса, а надо Agile. Жаль что у больных этой заразой летальность низкая… Не ну правда ну блин методика организации работы… Вы серьезно? Что ж вы с ГОСТами так не носитесь — там тоже грамотно написано что и как нужно проектировать и в каком порядке
        +2
        Потому что по ГОСТУ нельзя «фигак, фигак ив продакшен» ;-)
          –2
          Agile не про ГОСТ, и даже не про ИТ. Agile про людей.
          Agile и ГОСТы живут в разных измерениях.
            +2
            Либо здесь врут либо я чего-то не понимаю. Ну или это вы чего-то не догоняете. ГОСТы описывают все. Если чего нет в ГОСТАх значит оно либо ненужно, либо скоро там будет. И да в ГОСТах тоже есть «про людей»
              0
              Либо здесь врут либо я чего-то не понимаю

              А где там что-то про ГОСТы?

              Если чего нет в ГОСТАх значит оно либо ненужно, либо скоро там будет.

              Очень интересное заявление. Про тот же секс у нас в ГОСТАх много написано? Или он не нужен? :)

              И да в ГОСТах тоже есть «про людей»

              Но не всё что есть про людей есть в гостах?
                0
                Либо здесь врут либо я чего-то не понимаю.


                Да, с этим беда.
                Вроде у людей в ИТ в среднем формальная логика должна быть лучше развита. Но нет.

                Я немало с кем сталкивался, кто утверждал, что agile про ИТ.
                На вопрос «почему», указывали на заголовок.
                Я в ответ: «Ну ок, в заголовке есть software development, а в самой декларации есть что-нибудь более детальное про ИТ?»

                Как ни странно, Agile Manifesto ничего ИТ-специфичного не декларирует.
                Только про людей, и все что связано с людьми.

                зы
                И в ГОСТах тоже есть про людей.
                Но с другого аспекта.
                  +2
                  Понимаете в чем проблема — в подмене понятий. Здесь конкретно МЕТОДОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.
                  Разработка программного обеспечения — это не про людей, это про процесс!
                  А если посмотреть внимательно — а какие методолгии вообще есть? В один ряд с этим непотребством встают реальные совокупности методов разработки — итерационный и водопад. Почему непотребство? Потому что под определение «метод» никак не подходят ни «идеи» не «принципы» Где последовательные шаги для достижения результата? Вот это вот: «сначала берем человека потом инструмент, потом делаем то-то...» А всем любителям порассуждать что там ничего нет про именно разработку ПО процитирую:

                  Принципы, которые разъясняет Agile Manifesto:

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

                  А насчет ГОСТов — таки да секс во время разработки и производства промышленной продукции и ПО абсолютно не нужен.) Потому его там и нет) А вот если поищите то и водопад и тем более итерационную или спиральную разработку найдете — называться будет не так но оно, поверьте, регламентировано и прописано.

                  И в заключение — дорогие менегеры! Не пытайтесь натянуть сову на глобус! Что работает с ПО не работает с физическими объектами. Если в ПО спрятать лапшу и кошмар в коде легко — о внешнем виде кода ни кто кроме вас знать не будет. То извините с другими вещами хрен! Минимум это будет видно, максимум законы физики не дадут кошмару работать изначально, либо после первой же поломки с помощью отвертки найдут всю вашу «гибкость» внутри и больше вы ничего не продадите — это я на примерах пояснил. Продукт может получиться качественный только при грамотно поставленных изначальных требованиях — никак иначе!
                    –1
                    Где последовательные шаги для достижения результата?

                    В конкретных методиках вроде скрама и канбана.

                    Что работает с ПО не работает с физическими объектами

                    Очень категоричное утверждение. Тот же канбан и водопад например в информатику пришли из индустрии.

                    А вот если поищите то и водопад и тем более итерационную или спиральную разработку найдете — называться будет не так но оно, поверьте, регламентировано и прописано.

                    Вы наверное уже поискали и вам не составит труда процитировать то что вы нашли? Или это только ваши предположения?

                    Продукт может получиться качественный только при грамотно поставленных изначальных требованиях — никак иначе!

                    С чего вы решили что аджайл работает без грамотно поставленных изначальных требований? Именно в этом плане он от того же водопада ничем не отличается.
                      0
                      если в манифесте вместо «программное обеспечение» подставить что-нибудь другое, например «услуга» или «изделие», что-нибудь принципиально изменится?

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

                      Продукт может получиться качественный только при грамотно поставленных изначальных требованиях — никак иначе!

                      Так это ж никто не оспаривает.
                      Вопрос только в подходах.
                      Можно сказать, уважаемый… (HR, юрист, бухгалтер, кладовщик и пр.), пока вы не напишите внятное ТЗ, мы палец о палец не ударим.
                      А можно сказать, давайте выясним, почему у вас эта проблема, и вместе найдем ее решение.
                        0
                        Э-э-э. Весь человеческий опыт говорит, что любой манифест приводит к «анархии, отсутствию целей и т.д.»
                        Начиная с 10 заповедей и нагорной проповеди.
                        Хорошие же манифесты были.
                        К чему привели…
                        Манифест, он про людей.
                        Т.е. чтобы манифест работал нужны строго определенные люди с психофизическими характеристиками.
                        Их либо с 0 лет воспитывают, либо они извращают манифест до полной противоположности.
                          0
                          Э-э-э. Весь человеческий опыт говорит, что любой манифест приводит к «анархии, отсутствию целей и т.д.»

                          Нет, не говорит.

                          Начиная с 10 заповедей и нагорной проповеди.
                          Хорошие же манифесты были. К чему привели…

                          И к чему они по вашему привели такому ужасному? Ну вот именно они и если посмотреть всю ситуацию «в сумме»?
                            0
                            «В сумме» они привели к
                            1) К массовым убийствам во имя веры
                            2) Продажи «индульгенций», т.е. коммерциализация религии
                            3) Расколу и различные трактовки «догматов веры»

                            В общем как обычно.
                            Люди начали использовать «идею» для решения своих меркантильных задач.
                              0
                              И это всё к чему они по вашему привели? То есть никаких других последствий не было? только эти и/или только негативные?
                              И тогда ещё следующий вопрос: а если бы десяти заповедей не было, то всё то что вы сейчас перечислили обязательно бы не произошло?
                                0
                                1) Нет не все. Это просто показатель, как намерения отличаются от реальности
                                2) Были. Как минимум чужаков перестали сразу резать и жрать, а вначале выясняют какому богу молиться.
                                3) Не произошло бы. Т.к. это особенности «имплементации»
                                  0

                                  Естественно намерения не всегда воплощаются в жизнь на 100%. Но они часто ведут как минимум к улучшению ситуации. И христианство в общем-то тоже к этому привело. И на мой взгляд как минимум до Средневековья от христианства было больше пользы чем вреда.


                                  А уж утверждать что жадность, нетерпимость и ненависть к чужакам это "особенности имплементации христианства" это вообще смешно. Всё что вы перечислили встречалось и в куче других религий. И не только в монотеистических.

              –1
              На мой взгляд вредным советом под номером «0» должно идти что-то вроде «Рассказывайте всем что Agile это 'серебрянная пуля', которая не то что подходит, а даже просто необходима абсолютно любой [ИТ-]фирме».

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

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