Меня беспокоит Agile, и я хочу об этом поговорить

    image

    Меня зовут Екатерина Шалапанова, в DataArt я работаю с 2008 года, занимаюсь в основном управлением проектами. Иногда, правда, совмещаю эту роль с ролью системного аналитика. В индустрии с 2000 года, начинала карьеру программистом и незаметно для себя переродилась в менеджера, которой интересно заниматься смежными областями. Сразу уточню, что мое мнение может не совпадать с позицией компании, которую я тут представляю.

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

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

    Итак: почему Agile не работает?

    На самом деле, каждый проект несчастен по-своему, но, если копнуть глубже, все можно свести к трем основным причинам:

    • Это неправильная команда, и она делает неправильный Agile.
    • Agile плохо совместим с окружающей проект средой (т. е. компанией).
    • Этот проект по природе не совместим с Agile.


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

    Дальше — по несколько строк про каждую из этих причин.

    Это у вас Agile неправильный

    «Неправильный Agile» звучит, конечно, как оксюморон — как может быть однозначно правильным или неправильным подход, в основе которого лежит понятие гибкости?
    Все просто – команда не совсем понимает суть подхода и не делает вещей, необходимых для успеха проекта.

    Прежде чем идти дальше уточню, что под «командой» имею в виду не только разработчиков с тестерами и прочими технарями, а всех, кто так или иначе вовлечен в проект: конечные пользователи и их представители, менеджеры разного уровня, product owner, project sponsors и т. п.

    Для успешного проекта недостаточно крутых программистов (тестеров, дизайнеров, DBA...), а нужны еще, во-первых, вовлеченность пользователей и вменяемый product owner; во-вторых — четкая синхронизация усилий, которая выражается и в применении правильных практик (всех этих вот берндаунов, таскбордов, демов, континиус интегрейшенов и ретроспектив), и в распространении информации и о прогрессе каждой user story, и о смысле проекта как такового.

    Если сказать, что Agile — способ мысли, прозвучит пафосно, но, возможно, не совсем неверно. Как ни странно, я не помню ни одного успешного Agile-проекта, где участники не разделяли бы идеи Agile-манифеста (иногда даже не читая самого манифеста).

    Еще составляющая, которую не могу не упомянуть, — взаимное уважение всех участников команды. Мы должны уважать заказчика, заказчик должен уважать нас, команда должна прислушиваться к мнению каждого члена и иметь в виду его интересы.

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

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

    Итак, если есть ощущение «неправильного Agile»:
    • Начать с высокоуровневого целеполагания — убедиться, что и мы, и пользователи понимаем однозначно критерии успеха проекта (и нет, это не в срок поставить весь скоуп по оговоренной цене. Это скорее «пользователям очень надо, чтобы решилась вот эта проблема, для чего мы хотим сделать возможными вот эти use case»). Очень полезны также будут хотя бы базовые знания разработчиков в доменной области и их представление о пользователях.
    • Разобрать с командой практики и технологии процесса. Показать, как ежедневное честное обновление статуса помогает в достижении глобальных целей проекта.
    • Убедиться на всякий случай, что мы не забыли такие ключевые вещи, как acceptance criteria, early demos, ретроспективы и обратная связь.


    Agile плохо совместим с окружающей проект средой (компанией заказчика)

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


    Если компания давно уже как-то работает, менять сложившийся процесс бывает сложно а зачастую и невозможно (например, если по закону предприятие обязано объявить конкурс и зафиксировать требования и деньги, то...). Фиксированные требования и цена — явные признаки V-модели, и при работе, например, с российскими госкомпаниями у вас никакого чистого Agile не получится.

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

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

    С другой стороны, совсем вот брать и выкидывать старые правила, потому что они «не Agile», тоже не стоит. Есть всяческие полезные, хоть и занудные и бумагозатратные процедуры типа передачи кода в поддержку, или какой-нибудь внутренний или внешний аудит по безопасности продукта…

    Итого, если есть осознание, что окружающая среда не совсем дружелюбна к Agile:
    • Делим процессы вокруг на три группы: полезные (которые нужны чтобы код потом выжил в уже сложившейся инфраструктуре: security testing, configuration guides и т..д.), те, с которыми можно ужиться (какие-нибудь репортинги, шаблоны, требования к оформлению кода по ГОСТ или по унаследованным от процедурных языков корпоративным стандартам), и те, которые не совместимы с Agile совсем.
    • Первое превращаем в таски, добавляем в backlog, оцениваем, вздыхаем, что внезапно слегка вырос скоуп, и радуемся, что вытащили это на свет, и теперь примерно понятно, что делать.
    • Насчет вторых вступаем в переговоры с теми, кто за них отвечает в компании. Можно попробовать найти компромисс: согласовать более удобный нам шаблон или договориться о более подходящих KPI.
    • Самая большая проблема, конечно же, с третьими. Если уж так получилось, что вы ввязались в Agile-проект, зафиксировав на бумаге какие-то жесткие рамки, как только осознали масштабы бедствия, надо собирать заинтересованные стороны, включая заказчиков, чтобы придумать, как минимизировать ущербы и выйти с минимальными потерями. В конце концов, может случиться чудо, и у вас получится написать такое допсоглашение, которое изменит скоуп и сроки на те, что получились в итоге.


    Этот проект по природе не совместим с Agile

    Как ни тяжело Agile-евангелистам осознавать, но в мире есть много задач, в которых никакой Agile не будет работать.

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

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

    Еще хороший пример неприменимости конкретно Scrum — всяческие команды поддержки, когда внезапно прилетает тикет от юзера с нулевым приоритетом, и все бросают всё и чинят. Никакой предсказуемости и ритмичности уже не будет.

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

    Итак, мы начали делать в режиме Agile проект, который не совместим с идеей:
    • Прекратить пытаться делать Agile и начать строить более подходящий процесс. При этом совершенно необязательно отказываться от каких-то элементов процесса, которые ассоциируются с Agile, но работают везде.
    • V-модель с ее, на первый взгляд монструозной трассировкой требований до кода и от кода до тесткейса, работает как надо в случаях, для которых предназначена. Если что-то не подходит для творящего под iPhone стартапа, это не значит, что это плохо.
    • Может иметь смысл почитать про концепции ITIL, им уже 20 лет, и многие работают именно в них. В некоторых случаях Service Desk можно скрестить с Kanban, и получить на самом деле работающий true Agile-процесс.
    • Бывают еще всяческие индустриальные практики и собственные разработки больших компаний, которые могут подойти, особенно если вы решаете задачу, похожую на то, для чего они созданы.


    Напоследок очень хочется добавить, что серебряной пули, конечно же, не существует. И наверняка в вашем конкретном случае все может быть немножечко не так.

    Спасибо за внимание.
    DataArt
    175,00
    Технологический консалтинг и разработка ПО
    Поделиться публикацией

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

      +1
      > Но в мире есть много задач, в которых никакой Agile не будет работать

      Хорошая идея статьи: обзор разных методологий и разные типы проектов — что для чего лучше подходит.
        –2
        Есть куча классификаций и, к сожалению, серебренной пули нет. Вот, например, один из способов поклассифицировать проекты и подходы к их реализации.
          –1
          Esli naberus vremeni i terpeniay napishu...t.k. moay dissertaciay byla kaka raz na etu temy))
          +7
          SCRUM для постсовка не катит потому что

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

          • Руководство и разработчики чаще всего ригидны и не обладают возможностью видения перспективы,
            даже банальный анализ существующих подходов и интрументариев является непосильной задачей.
            Привет, Golden Hammer. Сайонара, долгосрочная поддержка.

          • Зачем разделять разработчиков на тестеров и программистов — высшую и низшую касту племенного сообщества.
            У вас по идее должен быть TDD/BDD? Пускай сами для своих же задач пишут тесты…
            Вы все же там такие Agile-ные экстремалы с RAD'ом…

          • Желание компенсироваться — «быть самым главны и/или самым умным» и подсознательно разделять всех на тех кто нравится, и тех, кто не нравится, порождая грибной менеджмент и поверхностную выработку требований.
            Привет, «Грибной менеджмент» и «Охота на ведьм».

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


          На самом деле V-model это не обязательно последовательный процесс, выработка требований может происходить вместе с выработкой спецификаций для интеграции — как говорится «разделяй и властвуй». Таким образом повышается приоритет приёмочного и интеграционного тестирования и их спецификации разрабатываются уже на этапе выработки требований.
          В таком случае V-model легко адаптировать под простой kanban.

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

          Ставьте контроль качества выше процессов выработки персонала — тогда будет толк.

          Ныть то что большая часть постсоветских хомячков пытаются адаптировать методологии разработанные для более здоровых и развитых западных социумов — бесполезно. У нас, да и в Европе, люди слишком больны для того же Scrum'a.
            0
            Это не scrum неправильный, это неправильные программисты! Если бы программисты были правильными, то scrum бы работал.
              0
              Советую ознакомится со спецификой компенсаторных процессов шизоидного психотипа личности в рамках коллективов с потребностью постоянной интенсивной оптимизации трудовых процессов. Потом уж судить кто «правильный», а кто «неправильный»…

              На самом деле, да, если бы программисты, и руководство, не компенсировалось в рамках рабочих процессов — SCRUM бы работал, но это нереально без аудита со стороны. Либо интенсификация рабочих процессов, и их оптимизации, должна полностью вытеснить возможность какой-либо компенсации, как это было, к примеру, в Яндексе.
                0
                Так я ж и говорю — дайте других программистов, с ними скрам точно на этот раз заработает.
                  0
                  Это рекурсивный процесс, нужен бесконечный источник программистов.
            +4
            Мой опыт говорит о том, что с Agile часто случается Карго Культ.
            Неуверенный в себе начальник требует Agile (или его заставили сверху), никто не понимает зачем это нужно и как это делать, все бегают и машут крыльями (делают итерации и стоят на совещаниях), но самолёт не летит… :(

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

              Если рассматривать организацию работы сотрудников как задачу параллельного программирования со своей синхронизацией, и различными scatter/gather map/reduce операциями — все становится довольно просто.
              0
              Самым ярким, конечно же, будет пример написания софта, управляющего космическими аппаратами — ну вот сложно раз две недели демонстрировать заказчикам посадку зонда на комету, получая в ответ замечания, что именно с точки зрения ученых-физиков стоило бы сделать по-другому.

              Пример несколько неудачный — можно демонстрировать моделирование посадки в симуляторе, с текущей версией софта.
              Но в целом да — та, где критично отсутствие багов, подход «постепенно увеличиваем качество» не сработает в лоб.
                0
                Скрам всё же не о «постепенном улучшении качества», а о «постепенном наращивании функционала». И в конце каждой итерации реализованный функционал должен быть именно что того качества, которое требуется. Другое дело, что размер итераций в особо ответственных областях может измеряться не неделями, а месяцами.
                  0
                  Согласен
                +6
                Выскажусь со своей колокольни. И вообще, я не менеджер, а разработчик, и, вероятно, во многом ошибаюсь, но всё же… На нескольких проектах был тимлидом.

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

                Вот, кстати, про заказчиков. Есть вещи, которые ни в какой Agile не укладываются, и которые менять нельзя. Рюшечками и плюшечками обвешивать проект можно бесконечно, но многие почему-то считают, что в гибкость входит смена технологии, кардинальная смена дизайна на поздних этапах разработки и т.д. Ну а чо, Agile же, правильно? Гибкость там и вот это всё. К сожалению, использование Agile иногда приводит к тому, что кто-то хочет банально сесть на шею, взяться за уши и рулить куда хочется. И такие явления надо пресекать на корню, решительно наплевав на всякое несоответствие любимой методологии.

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

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

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

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

                      К сожалению это входит в моё NDA — я не могу называть имён, контор и методов которые были использованы (уже спросил).
                        0
                        Я вас спросил не про то, могут они быть или нет, а про идеальную карьеру.

                        Вот был школьник, закончил школу.


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

                        Заполните пустоты, пожалуйста.

                        Я прицепился к " В больном коллективе программист становится менеджером, в здоровом — остаётся программистом. " — и мне стало интересно, откуда в здоровом обществе образуются менеджеры.
                          –1
                          Общество нездорово априори, спросите об этом любого психолога, или даже психиатра…
                            0
                            Есть мнение, что психологи и психиатры, такие же паразитирующие на людях сущности, как менеджеры и маркетологи.
                            Т.е. в знании самой психологии и прочих сопутствующих вещей ничего плохого нет. Так же как и в том же аджайле, самом по себе, ничего плохого нет. Но вот в том как люди применяют эти знания, есть многие беды…
                              0
                              Я и не отрицаю что есть очень много больних психологов и психиатров которые компенсируют свои расстройства посредством взаимодействия с клиентами — одни примитивные игры, генерализации и проекции…

                              Да, больные люди пытаются применить абстрактные принципы к реальным процессам без какой-либо адаптации.
                              Такое встречается вокруг да около.
                    0
                    ИМХО все нужно применять без фанатизма. К примеру, иметь то, что можно показать начальству/заказчику в конце недельного цикла очень даже полезно. Но зарываться в бумагах (был такой опыт), когда из 20 страниц реально полезными оказываются три строчки, а остальное — вода — тоже пользы особой не приносят. Другая крайность, когда нет ни ТЗ, ни четкого видения проекта, зато все дружно что-то делают, а закончив, переделывают заново. Такое оголтелое программирование :)
                      0
                      Писал ТЗ по ГОСТу для автоматизированных систем в 160 страниц для аппаратной рекламной RTB-биржи реального времени на Virtex7 ПЛИСке. В принципе простой перечень пунктов и пустые странички с заголовками — 84 страницы. И ни одной бесполезной или несодержательной строчки, только требования жирным шрифтом должен, не должен, может, не может etc как в любом RFC. Все они стали основой для приёмочных тестов и части пользовательских историй. Хотя основные пользовательские истории были разработаны ещё до выработки требований прототипа устройства…

                      ТЗ — штука сложная, советую изучить вводную статью.
                      Я ориентировался по ней, и адаптировал ГОСТ 34.602-89, писал в Latex'е с ESKDx.
                        0
                        Я же не спорю, что ТЗ может быть полезным :) У меня была задача, при определенных платежах снимать с клиентов комиссию — в одном случае в процентом соотношении, в другом — фиксированную сумму. Для этого прожектменеджером была написана бумага в 20 с лишним страниц! По моему разумению, это слишком. Зато все было по Agile :)
                          0
                          Agile'нец какой-то.
                          20 страниц при «полном Agile» — это диагноз, противоречит пункту 2.

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

                          Ну и ещё для полного счастья, советую ознакомится с реактивным манифестом.
                    +2
                    Не могу полностью согласиться со статьей, и даже отчасти с комментариями.

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

                    Это история из жизни, если что. Происходила на моей первой работе в качестве программиста.

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

                    То есть, scrum можно рассматривать как ролевую игру. Совсем не обязательно иметь реального заказчика, отдельного скрам-мастера и даже ставить в известность руководство. Достаточно, чтобы хотя бы один человек знал, что, как и зачем нужно делать, а остальные ему хотя бы не мешали и просто выполняли свою работу.

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

                    Однако, я хочу акцентировать внимание на том, что управление проектами — процесс творческий, и не нужно слепо следовать инструкциям. Нужно переосмысливать agile под конкретные команды и проекты.

                    Поэтому к означенным посадке зонда на комету и прошивке телефона agile вполне применим. Просто в роли заказчика будет выступать не реальный заказчик, а, например, начальник отдела или тим-лид.

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

                    И еще один тип проектов, где scrum'у точно не место, это хобби-проекты, и, в частности, опенсурс, создаваемый силами сообществ. Там тоже сложно что-либо планировать, так как человек может быть занят чем-то другим или просто ничего не делать, если не хочет.
                      0
                      у нас не было доски для скрама
                      Речь о канбан-доске? :-)
                        0
                        Нет, о scrum-доске. Но, внешне они похожи, только используются немного по-разному :-)
                          –1
                          А в чём отличие?
                            0
                            Я не настолько разбирался с канбаном, чтобы рассказать про отличия самостоятельно, но на английском есть описание в этом документе (страница 14).
                            Однако, есть на русском.
                              0
                              Так в чем же тогда разница между этими двумя досками? Да – вот эта маленькая «2» в средней колонке
                              на Kanban-доске. И всѐ. Эта цифра 2 означает что «в этой колонке может быть не более 2-х элементов
                              одновременно».

                              Зачем-то убрали ограничение (а убирать его нет никакого смысла) и вот у нас типа «новая доска» :-)
                                0
                                Ну, в общем да :-)
                        0
                        И еще один тип проектов, где scrum'у точно не место, это хобби-проекты, и, в частности, опенсурс, создаваемый силами сообществ. Там тоже сложно что-либо планировать, так как человек может быть занят чем-то другим или просто ничего не делать, если не хочет.

                        Практически во всех опен сорсных проектах есть милестоуны, которые в принципе можно считать чем-то вроде скрама. И, как ни странно, сообщество разработчиков им следует более или менее.
                          0
                          Ну, это не совсем то. Иначе мы сейчас с Вами договоримся, что и ватерфалл — это тоже почти скрам :-)
                          0
                          А почему «заказчик отсутствует как класс»? ГД — и есть точное воплощение product owner'а, который заинтересован в конечном продукте (игре).
                            0
                            Я оппонирую статье, там под заказчиком понимается именно заказчик. И если заказчику мы не можем каждую неделю демонстрировать посадку спутника на комету, то все, скрам не применим.

                            И, на мой взгляд, скорее, не геймдиз, а продюсер является product owner'ом в реальности. Геймдиз — человек подневольный. Другое дело, что часто продюсер — это лицо из руководства компании, и скрам ему до лампочки.
                          –1
                          Agile и прочий Scrum — это методы управления программистами людьми, далекими от программирования.
                          В АйТи денег много, вот и ломятся сюда кто попало. А работу-то делать надо. Вот и придумали методологию управления умными людьми людьми недалекими.
                          На самом деле, если ты в теме, говоришь с программистами на одном языке — рулить проектами легко без всяких скрамов. Говорю это основываясь на своем 8-летнем опыте.
                            +3
                            Опыт временем не меряют, его меряют способностью решать конкретные задачи, и разнообразием уже разрешённых.
                            Что бы 8 лет сайтики на CMS'ках да простых фреймворках штопать — много мозгу не нужно…

                            Давайте лучше поговорим как вы контролируете качество вашей продукции, и как вы решаете вопросы долгосрочной поддержки?
                            В 80% случаев ответ прост — никак.
                              0
                              Если вы сайтики на CMS'ках штопаете, то вопросы долгосрочной поддержки вас интересовать не должны :)
                                0
                                Ну большинство «серой массы» эти вопросы действительно интересовать не должны…

                                А для всех остальных, по минимуму нужно обеспечить постоянное отслеживание версий и обновление всех зависимостей и движков/фреймворков, проводить аудит безопасности всех сторонних решений. имхо Где-то 70% сайтов на Wordpress взламывают как раз таки из-за древности движка и всех его зависимостей.
                                –2
                                Вы не поверите, но в 80% случаев на контроль качества можно забить. И заказчики при этом буду довольны. Конечно это не распространяется на код работающий с медоборудованием, финансовыми транзакциями и т.п. Я к тому, что не надо делать вид, будто без контроля качества проект сразу обречен на гибель, а заказчик на неудовольствие.
                                  –1
                                  :roflmao: я посмотрю на размер их почты и количество тикетов поддержки, а также на различные дефейсы…

                                  busfactor == 1 неприемлем
                                    0
                                    Я до вас пытаюсь донести что существуют тысячи проектов, которые сложнее сайта визитки, но к которым не ставятся сверхжесткие требования надежности. И для них весь контроль качества — это тестирование самими программистами да прогонка заказчиком. И система тикетов может отсутствовать вообще. Просто нужно понимать, что то, что для крупной разработки является необходимостью, для мелких и средних проектов может стать обузой
                                      0
                                      Ну, а я пытаюсь донести что подобного рода заказчики — примитивные недоразвитые индивиды которым не хватает мозга подумать о том что может быть через год, или если их любимый «выполнятор» заболеет или помрёт… или ему просто станет неинтересно.
                                      Нянчится с такими — себя не уважать.

                                      Главное не «довольность» заказчика, а отсутствие головной боли через N месяцев.
                                        0
                                        Вы видимо слишком долго варились в одной специфической отрасли или имели очень много негативных примеров, когда весь проект был завязан на одного человека, поэтому я уже не рассчитываю вас в своей точке зрения. Так что будь по вашему.
                                          0
                                          Я был в разных отралях — начиная от разработки железа и драйверов, заканчивая вэбом, десктопными и мобильными приложениями, SaaS'ами и PaaS'ами. 8 из 10ти проектов делались через одно место, по этому я так скептически ко всему отношусь.
                                            0
                                            Вы правы. Но в определенный момент мне показалось, что если большая часть проектов делается, согласно моим представлениям, через известное место, но при этом мир не рушится, и, несмотря на всеобщее порицание такого порядка вещей, почти все в общем-то довольны им, то значит с моими представлениями что-то не так. К тому же я был свидетелем неоднократных примеров, когда качественный подход к разработке губил проект на стадии запуска — не хватало времени и ресурсов обеспечить качество. Более того, я был неоднократным участником проектов вида «перепишите эту дрянь, написанную студентами лишь бы работало». И у заказчиков были деньги на переписывание этой дряни, большие деньги, которых не было в тот момент, когда первая версия еще только создавалась.
                                              0
                                              Ничего не мешает писать и выкатывать MVP.
                                              Выкатывать его на рынок с одними лишь приёмочными тестами, получить прибыль и обратную связь от потребителей, а потом внедрять эволюционный рефакторинг и добавлять больше тестов. Хотя профилировать решения нужно в любом случае.

                                              Бюджета в 3000-4000$ обычно достаточно.
                                              У нас так почти не умеют.
                              0
                              Часто когда в коллективе нет дисциплины ее пытаются заменить Agile. Дисциплина от этого ниоткуда не появляется, но и Agile уже никуда не уйдет.
                                +2
                                Поднята дикая тема. О применимости подходов. Ваш местечковый опыт не говорит о применимости концепций в целом.

                                Вопрос следует рассматривать глубже. Почему Agile вообще появился?? Вот раньше УП в ИТ напоминало УП во многих других отраслях. Agile в виде XP появился в результате необходимости спасти (в Крайслере там или где — неважно) проект.

                                Еще более глубоко, сильную мысль скажу. Agile это ответ в первую очередь на некомпетентность заказчиков в ИТ-проектировании. Даже банальный waterfall способен завершить в срок в бюджет и с надлежащим качеством (я не скажу процент тех моих проектов лично, которые так произошли, но они были).

                                Если изначально ясно, что за изменения надо платить, почему бы это не ввести в процесс? Такая логика появилась, и в результате появился Agile (с его манифестом). Развитие ИТ опережало развитие традиционного бизнеса и его моделей в 90-00… Но сейчас этого НЕТ.

                                Agile — это способ переложить риски. Ввести его в тренд не удается, и не выйдет (имхо конечно), потому что бизнесу не нужна услуга, ему нужен продукт.
                                  0
                                  Согласен.
                                  Любому бизнесу в первую очередь нужен продукт, а не методы его производства.

                                  Основные Agile методологии в чистом виде неприменимы к существующим коллективам, и это прискорбно.
                                  Разрабатывать и тестировать новые методологии индивидуально для каждого коллектива, со всеми его особенностями — вот важнейшая задача менеджера в наше время. При этом количество «бумажек» обычно стремится к нулю. Нужно проводить индивидуальную работу с каждым сотрудником и отслеживать социальные связи, в том числе и те которые не относятся к работе. Частенько отдельно нанимают психоаналитиков, я лично знаком с несколькими случаями их работы в рамках средних коллективов (до 100 человек) и в общем-то «мне хватило»…

                                  Agile — это цель, а не средство… методология — средство, а не цель…
                                  Почему-то абстрактные средства все считают универсальными и применимыми к реальным проектам.
                                  0
                                  Некоторое время назад я изучал инновационный менеджмент, потом заметил, что многие подходы, но только уже без объяснения причин и в виде бездушного набора правил внезапно есть agile.
                                    0
                                    Ещё могу добавить по памяти из последних проектов:
                                    1. У PO нет времени сидеть с вами, выловить его на пару часиков раз в несколько недель большая удача, и он при этом почти всегда чем-то занят кроме вас
                                    2. PO просто увольняется, а проект нужно сдавать новому человеку или его заму, которому явно не до вас.
                                    3. Состав команды не может быть зафиксирован на итерацию. Если у компании есть другие проекты на поддержку, то сотрудников часто приходится перекидывать на баг-фиксинг в других проектах.
                                      0
                                      Текучка персонала — признак "дымохода" и "грибного менеджмента".
                                      Опосля грибного менеджмента приходит «чайка-менеджмент» (seagull management) — пришёл поорал, оставил за собой кучи проектного дерьма, которые потом нужно разгребать персоналу…

                                      Хотя лучше о них, как ни странно, почитать на лурке и поплакать.

                                      Почти все организационные антипаттерны являются признаками компенсаторных процессов у руководства.

                                      Опять же стоит решить вопросы
                                      1. Выработки требований
                                      2. Контроля качества
                                      3. Долгосрочной поддержки

                                      И все эти проблемы решаются через некоторое время.
                                        0
                                        А как решать такие проблемы, если компания бурно развивается, т.е. меняются бизнес-процессы, меняются команды и т.д.
                                          0
                                          Смена персонала не признак развития, смена персонала — признак наличия организационных проблем.
                                          Как говорится «крысы бегут с тонущего корабля»…

                                          Я не уверен что у вас там «бизнес процессы» меняются и что они вообще в наличии, скорее нет чёткого позиционирования продукта. В любом случае это нужно обсуждать отдельно, можете отписать в скайп — расcкажу пару душещипательных историй.
                                            0
                                            >расcкажу пару душещипательных историй
                                            Такие вещи многим интересны. Учиться лучше на чужих ошибках. Может статейку забабахаете на тему?
                                    0
                                    по-моему, вся проблема от того, что люди валят в кучу Agile манифест и Agile методологии :)
                                    Agile манифест — это все-таки о том, чем мы мотивируемся, когда принимаем решения :)

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

                                    Работающий продукт важнее исчерпывающей документации. Это не значит, что документация больше не нужна, потому что у на Agile. Работа никуда не делась, если документация требуется — надо ее делать. Просто лучше сделать продукт таким, чтобы документация ему была не нужна :)

                                    Сотрудничество с заказчиком важнее согласования условий контракта. Это не значит, что нам не нужен контракт. Просто надо выстраивать отношения с заказчиком. Если он будет вам доверять — он не будет пользоваться бумажой и вы разрешите проблемы лично :)

                                    Готовность к изменениям важнее следования первоначальному плану. Это не значит, что нам больше не нужно планировать. Просто мир меняется очень быстро, время жизни плана короткое. Не стоит зацикливаться на нем — он не истина :)

                                    Вообще — все это придумано задолго до АйТи, но мы прогрессивно адаптиуем хорошие практики только сейчас :)
                                      0
                                      Кстати, на счет
                                      все это придумано задолго до АйТи
                                      — тут я полностью согласен. Я временами увлекаюсь другими сферами деятельности кроме IT и вижу, что, например, полноценное проектирование происходит прежде чем начинаешь что-то ваять, при чем уровень проектирования и документации, как правило, выше чем это можно увидеть в IT. Из чего можно сделать вывод, что айтишники — ленивые люди с отблеском элитарности на своем ЧСВ, которые к работе подходят зачастую небрежно.
                                      0
                                      Сначала надо заиметь сильные профессиональные компетенции и опыт решения задач в своей зоне отвественности (программирование, тестирование, управление проектом, спонсорство или управление продуктом) — и только после гибкие процессы в полный рост, хоть бы и Scrum. Тогда все взлетит и облегчает всем жизнь. Точка.
                                        –4
                                        О, Катька, привет :-)
                                          0
                                          Спасибо большое, в отличие от большинства статей на тему «аджайл» очень конкретная и прямая.

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

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