×

Какая польза от Agile: несколько кейсов из практики

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

Из хаоса в Скрам

Артем Быковец, Certified Scrum Master, Agile Coach:

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

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

Первый месяц я занимался изучением окружения, при этом еще ничего не менял и не внедрял. Затем провел 1×1 с каждым членом команды. Спрашивал, чем этот специалист занимался последние 3 месяца, что сделал за это время, что нового отдал пользователям. Ответы были в духе: «Я работал над Competera». Добиться конкретики — какой функционал добавили, какие именно проблемы решили — не удавалось.

Затем я пошел общаться с Sales & Business Developers. Оказалось, что они не могут подписать некоторые контракты, «потому что программисты чем-то своим заняты». То есть продажи и разработка были очень сильно расфокусированы: сейлзы пытались продать то, чего еще нет, а программисты разрабатывали то, что пока еще можно было и не разрабатывать.

В ходе работы в нескольких продуктовых командах мы внедрили максимально чистый Скрам: двухнедельные итерации, планнинг, ревью инкремента с участием представителей бизнеса и, конечно, ретроспективы. Перед планингом я как Скрам-мастер требовал, чтобы владелец продукта пообщался с каждым отделом — маркетингом, продажами, поддержкой и другими. Стояла задача выяснить, что хотят пользователи, что «болит», что мы уже пообещали. Позже мы также создали PAINS Канбан-доску и регулярно просматривали ее во время рефайнментов. Это помогало расставить приоритеты в разработке. В спринт мы брали по кусочку работы из каждой категории.

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

В других командах внедрили Скрамбан: мы планировали только около 60% спринта, а остальные 40% времени закладывали для того, чтобы оперативно реагировать на падающие задачи с продакшена. Например, если звонил клиент и говорил, что у него что-то не работает, мы могли сразу разобраться с его вопросами и не угробить планы на спринт. Если нам везло и в течение спринта и с продакшена ничего не прилетало, то мы просто добирали задачи из бэклога.

Как мы сформировали эти 40%? Первые несколько спринтов мы просто брали в работу все срочные задачи и уже по факту разработки оценивали их в сторипоинтах относительно запланированных задач. Спустя месяц-полтора накопилась статистика, сколько задач мы можем планировать, а сколько в среднем влетает с продакшена.

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

Затем к нам даже пришли коллеги из маркетинга и продаж, вдохновились выстроенными процессами в R&D и попросили внедрить подобное и у них. Им хотелось уменьшить хаотичность и добиться прогнозируемости. Правда, на том этапе Скрам в продажах не зашел, но некоторые практики они взяли — к примеру, раз в пару дней стали проводить стендапы, чтобы синхронизироваться, начали делать ретроспективы.

Дальше — еще интереснее. Чтобы как-то стыковать тактические задачи на уровне команд и департаментов и стратегические на уровне всей компании, мы внедрили OKR — Objectives and Key Result. Этот фреймворк популярен в крупных компаниях, таких как Intel, Google, LinkedIn. Он заключается в том, что бизнес задает цели на год, затем годовые цели распадаются на квартальные. Каждый отдел компании думает, какими своими личными целями он может приблизить компанию к этим результатам.

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

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

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

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

Изобретая Скрам

Сергей Семенов, Certified Scrum Master, Certified Facilitator:

«А почему ты выбрал Scrum? Как встал на эту тропу, с чего всё началось?» Отвечая на такие вопросы, я иногда шучу, что так получилось, что когда-то я его изобрёл сам...

5,5 лет назад я даже не слышал о таких словах, как Agile, Скрам, бэклог, ретроспектива. В то время я занимался разработкой и администрированием баз данных в крупной не IT-компании (700+ сотрудников). Тогда и произошел переломный момент в моей карьере.

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

Снежный ком тикетов в HelpDesk нарастал. Начальники, мягко говоря, не справлялись с ситуацией и подходили к вопросу творчески. К примеру, говорили так: «Если прилетает новый тикет, то сразу перекидывайте его назад и просите уточнить требования или смоделировать ситуацию. Главное, чтобы на нашем отделе было поменьше тикетов. А если перекидывать назад, у нас будут нормальные показатели».

Когда и этот подход не помогал, изобрели другой — с кодовым названием «Наверняка». Он заключался в том, чтобы принимать запросы на разработку новой функциональности по шаблону, в основе которого был использован ГОСТ 80-90-х годов с вишенкой на торте: обязательный для заполнения раздел об экономической выгоде в случае реализации запрашиваемого функционала. Другими словами, IT-отдел требовал у бизнеса экономическое обоснование на разработку, без которого футболил тикеты. Бизнес был не просто недоволен, он был взбешен такой работой.

Вскоре на работу вышел новый IT-директор.

Так получилось, что я был единственным администратором баз данных в отделе и по совместительству T-SQL разработчиком (с бэкграундом системного аналитика и релиз-инженера). Я отлично ориентировался в технической стороне работы программ, за которые отвечал IT-отдел, поскольку основная часть логики была реализована в виде хранимых процедур и триггеров.

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

Я рассказал свое видение ситуации, называя вещи своими именами и понимая, что за эти слова меня могут уволить (на тот момент я был в штате всего месяцев 5). Но работать без изменений в этом окружении мне уже не хотелось. К моему удивлению, IT-директор спросил: «А потенции у тебя хватит навести здесь порядок?». Какая тонкая манипуляция! И я ответил, что хватит. Забегая наперед, скажу, что её таки хватило :)

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

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

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

Один из разработчиков в итоге выдал: «Понимаешь Серега, я работаю тут уже 2 года, делаю 3 тикета за неделю, а мне таких еще 5 прилетает. А на мне их и так уже 60, и этот снежный ком постоянно растет. Какой смысл мне вкалывать и стараться — все равно нас никто не ценит и все будут недовольны. А ещё наши заказчики не могут договориться между собой, что приоритетней. Я только начну что-то делать, как кто-то прибегает и требует сделать отчёт, поскольку от него зависят бонусы его отдела, или другую срочную доработку. И стоит над душой, пока я ее не сделаю. А цирк начинается, когда таких заказчиков двое, трое, и они между собой выясняют, чем мне заниматься. Если я беру тикеты в работу по принципу FIFO, то вот и получается, что тикет, который пришел сегодня, попадет в работу через полгода. А потом еще жалуются, что долго ждут. А мне что делать?»

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

Вот только согласно политике компании тикет должен быть на кого-то назначен: потому-то они и накапливались. Вот незадача, что же делать? А что если перевести все тикеты на себя? Тогда я по сути стану хранителем бэклога (правда, такого слова я тогда тоже еще не знал). Нет, не то пальто: в таком случае у меня будет бардак с тикетами в HelpDesk.

И вот оно решение, простое, как пробка, доступное в тех условиях: мы создали фейкового сотрудника в HelpDesk и абсолютно все тикеты перебросили на него. Дали ему имя Герасим, а фамилию придумали айтишную — Софтенко. И наконец-то у разработчиков стало пусто в HelpDesk — красота.

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

Также на каждый департамент мы определили некий процент от общего скоупа на спринт. Таким образом, мы смогли брать в спринт как минимум по 1-2 задачи от каждого департамента, тем самым повысив прозрачность и выровняв ожидания.

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

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

Прошло несколько месяцев, мы выработали устойчивый процесс. Недельные спринты начинались с планирования и заканчивались подведением итогов и определением шагов по улучшению. Мы попадали в коммитмент на 90-100%. На протяжении спринта мы ежедневно общались, обсуждали прогресс — собирались в одном и том же месте, в одно и тоже время, все длилось 15-30 минут. Узнаете стендап? А нам казалось, что это придумали мы и это наша находка.

В результате мы не только систематически выполняли обязательства по взятым в спринт задачам, мы ещё и подняли нашу производительность в 3-4 раза в первые 2 месяца и удерживали эту скорость на протяжении 10 месяцев. А потом меня переманили в PocketBook, и я сменил работу :)

Мы подняли customer satisfaction c явного минуса до хорошего плюса. Чтобы убедиться, можете посмотреть отзывы от директоров и начальников департаментов в моем LinkedIn.

Наш успех я связываю со следующими изменениями:

  1. Мы перенесли все тикеты с разработчиков в сторонку. Накопившаяся гора тикетов больше не давила и не подавляла желание работать на результат.
  2. Начали работать спринтами и проводили командные встречи.
  3. Процесс стал прозрачным и для команды разработки, и для бизнеса. Команда сама оценивала и принимала решение, сколько задач брать, чтобы их завершить к концу спринта. В свою очередь департаменты видели, над чем работает IT-отдел, и получали готовый инкремент в конце каждой недели.
  4. Прекратились «шатания» и «нависания» над столами разработчиков. Ребята были счастливы, что могут просто спокойно делать свою работу, и их больше не отвлекают.
  5. Разработчикам начали давать положительный фидбэк со стороны бизнеса, их хвалили и ценили. Это давало +100 к мотивации. Команда начала чувствовать, что она приносит пользу бизнесу.
  6. Команде разработки были присущи ценности: открытость, уважение, доверие, взаимоподдержка, обязательства, работа на результат.
  7. Дружественная атмосфера в IT-отделе.
  8. Фокус на сотрудничество с заказчиком, а не игра с ним в футбол.
  9. Открытость и прозрачность для бизнеса: в любой момент времени каждый мог видеть, над чем работает IT-отдел.

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

Канбан внутри «водопада»

Анна Лаврова, PM, Certified Scrum Master, SAFe Agilist:

Расскажу историю о том, как внутри классического «водопада» мы вставили Канбан как способ работы с приоритетами и оптимизации огромного потока входящих задач.

На входе: digital-агентство с 10+ активными проектами. Их средний размер — 3 месяца, в команде 6 человек. К тому же, были короткие и быстрые спецпроекты раз в месяц и промопроекты, которые нужно провернуть за три дня. Вдобавок: запросы от существующих клиентов и их пользователей, а также несколько внутренних проектов «для разминки» и опять же оптимизации всего, что происходит.

Digital-агентство — часть устоявшейся другой медийной компании. Все проекты продаются без утверждения сроков с командой и без готового ТЗ, но с дедлайном. Представьте себе онлайн-версию журнала, типа Forbes. У нас не всегда были готовые сверстанные статьи и фотографии, но было понимание, когда же выйдет новый выпуск и его outline — тема, заглавная идея и наброски основных секций (статей).

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

Все работа с клиентом и продуктом была организована по каскадной модели. Работать итеративно инкрементально, получить Скрам-роли было невозможно. Потому, чтобы прекратить переключения, мы приняли решение внедрить Канбан.

Идея: создать доску, на которой будут вертикально отображены процессы, а горизонтально — проекты (в Jira это делается за счет swimlane). Эти проекты будут перетягиваться вверх-вниз и вправо-влево в зависимости от приоритетов. Свои приоритеты будут и у задач внутри каждого проекта.

Я как Digital PM отвечала за эту самую доску и приоритеты. Главным челленджем было правильно описать процессы, чтобы задачи не перескакивали через колонки и не могли возвращаться. По ходу дела колонки перестраивались и переформатировались несколько раз. Важной находкой было вынесение в отдельную колонку арт-ревью — мы быстро поняли, что это и есть основное «узкое место» одной из стадий работы.

Доска в Jira: свимлейн — это проект, а вертикальная колонка — процесс

Каждую неделю команде озвучивали «проект недели» — проект с наивысшим приоритетом. Только после выполнения всех задач по нему можно было приступать ко второму, третьему внутреннему проекту. Также мы сделали супер свимлейн highest urgent important — сюда попадали задачи от клиентов. Например, на мобильной версии сайта потерялся логотип или поломалась картинка, кнопка перестала быть кликабельна и т. п.

Одна из договоренностей, которая очень важна при внедрении Канбана — адекватная работа с приоритетными задачами. То есть если та или иная задача попадает в топ-приоритетность, то первый, кто освободился, берет ее и не говорит: «Не хочу, не буду». Дальше, когда приоритетные задачи выполнены, можно заниматься теми, которые больше по душе.

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

Челленджем работы с Jira была автоматизация процессов, которая помогла с метриками. Когда задача перетягивалась в одну из колонок, запускался внутренний таймер, который далее помогал измерить lead time, cycle time, time to production, waste in queue time.

Также мы сделали физическую доску, где писали все ключевые даты по проектам и их стадии.

Что не сделали: не приняли практику ретроспектив. Однако приняли lessons learned как часть процесса и проводили встречи, похожие по формату на lean coffee.

В планах — больше автоматизаций.

В результате получили:

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

Скрам и несдвигаемые дедлайны

Андрей Троянов, Delivery Lead and Agile PM:

Кейс, о котором я расскажу, произошел в компании, которая занимается разработкой игр. Изначально модель работы была приближена к Waterfall, но по ряду причин заказчики приняли решение внедрить Скрам на одном из основных проектов. Заодно планировали сравнить эффективность предыдущего и нового подходов. Итак, я приступил к внедрению гибкого фреймворка — полностью «с нуля».

Поначалу было довольно сложно. Во-первых, сама индустрия не особо предрасполагает к поставке небольших, итеративных, несущих ценность заказчику фич. Приблизительная длительность проектов компании — 4–5 месяцев, все проекты имеют точный, оговоренный с заказчиками и отмеченный роадмапом срок сдачи. И во-вторых, не каждому техническому специалисту приходится по душе Скрам и его ценности. В общем, задача была довольно интересной :)

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

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

Проблемных мест в процессе внедрения тоже было немало:

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

— Груминг. Раньше функциональные требования в компанию разрабатывались на основе объемного технического задания — без этого проекты не запускались. В процессе разработки функциональные требования практически не менялись. Чтобы адаптировать этот момент к гибкому подходу, мы решили, что по окончании старого проекта владелец продукта и дизайнер будут планировать новый проект поэтапно.

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

— Тестирование. До начала внедрения гибких методологий в компании был принят такой жизненный цикл ПО: сначала итерация разработки всего большого продукта, после — его общее тестирование. Внедряя Скрам, мы перешли на постоянное функциональное тестирование и во время спринта.

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

— Обязательное Code Review. До этого в компании вообще не использовалась такая практика. В итоге удалось договориться с заказчиками, чтобы в каждой задаче отводить на Code Review 30 минут.

Подведу итог. За 2 месяца мы внедрили новый подход к работе с требованиями, перешли на практику Continuous Design, ввели регулярное Code Review. Эти изменения упростили и повысили эффективность работы с отделами разработки и дизайна игры. Вместе с тем, качество поставляемого продукта существенно улучшилось.

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

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось1
До обраногоВ обраному0
LinkedIn

Схожі статті




Найкращі коментарі пропустити

Agile он как религия — или веришь, или нет. А польза от него только тем, кто получает бабки за проведение курсов и сертификаций

А вы не думали спросить не у скрам/аджайл коучей в чем польза аджайла, а у разработчиков?

У меня одного от скрама такое ощущение что это для тех кому в жизни скучно и хочется собрать митинг?
Все эти дейли, планнинги, сраннинги, демо, ретроспективы, писькоспективы, детализации ну и так и далее и тому подобное что там еще положено.
В одной конторе реально на «скрам» митинги, подготовку к ним и хоть какие-то выводы с них уходило легко 40% рабочего времени у всей команды (ну и конечно же 100% скрам мастера) — я даже не поленился подсчитать всё по часам, но документ давно сгорел.
Самое мясо — это когда сидишь три часа (два раза в неделю!) и смотришь как заказчик на экране старательно сидит, сопит в две ноздри и пытается найти нужную кнопку на клавиатуре заполняя описание задачи в борде. Присутствие всей команды на сем сакральном процессе конечно же обязательно и не обсуждается.
Зато да, качество и скорость значительно увеличиваются. В основном — качество и скорость получения зарплаты «сертифицированными специалистами» :)

Опять церковь свидетелей Agile распроповедовалась. А потом повсеместное надувание щёк и карго-культ «единственно верных практик».

Я как Digital PM отвечала за эту самую доску и приоритеты.

Это все что нужно знать о проектном менеджменте.

87 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.
вытренировать прИемника

после этого статью не читал — но осуждаю

У меня одного от скрама такое ощущение что это для тех кому в жизни скучно и хочется собрать митинг?
Все эти дейли, планнинги, сраннинги, демо, ретроспективы, писькоспективы, детализации ну и так и далее и тому подобное что там еще положено.
В одной конторе реально на «скрам» митинги, подготовку к ним и хоть какие-то выводы с них уходило легко 40% рабочего времени у всей команды (ну и конечно же 100% скрам мастера) — я даже не поленился подсчитать всё по часам, но документ давно сгорел.
Самое мясо — это когда сидишь три часа (два раза в неделю!) и смотришь как заказчик на экране старательно сидит, сопит в две ноздри и пытается найти нужную кнопку на клавиатуре заполняя описание задачи в борде. Присутствие всей команды на сем сакральном процессе конечно же обязательно и не обсуждается.
Зато да, качество и скорость значительно увеличиваются. В основном — качество и скорость получения зарплаты «сертифицированными специалистами» :)

При чем здесь вотерфол? Будто других подходов к XP нету, то что сейчас называют «скрам» — это сплошной культ карго, как у голых негров прыгающих вокруг «железной птицы» в ожидании что оттуда еда посыпется.
Например у одной компании с которой я работал процессы были поставлены прекрасно — «кто-то» создавал стори в беклоге (я на это онлайн не смотрел, «кто-то» — это продакт овнер с бизнес-требованиями, CTO и архитех в формате междусобойчика, стратеги в общем), потом «кто-то» это все приоритизировал, еще «кто-то» чесал репу над анализом требований и над тем чтобы они были внятными, потом «кто-то» дробил это на задачи и грубо эстимейтил (на уровне «день-неделя-месяц-год» и если что — дробил дальше на этапы), потом «кто-то» делал из этого «спринт» с четкими deliverables.
И только потом это всё попадало к нашему рядовому девелоперу — вполне вероятно без единого митинга с его участием. У девелоперов был запас времени чтобы поставить себе детальные эстимейты, задать вопросы если что не ясно (в коментах к таске а не на митинге со всеми) и озвучить если что не так. Ах, да, временных рамок у «спринта» не было — «пока не будет готово», и таких «спринтов» было много — если остались задачи только по QA вся тима не сидит и дрочит как в скраме а берет задачи со следующей борды.
И самое главное — все еще ни одного обязательного митинга с участием нашего девелопера :)
Еженедельный технический митинг имеет четкий список тем — все могут учавствовать но никакой обязаловки. Демо тоже — сидеть делать необычайно умную морду не обязательно (продакт овнер показывает и отвечает на вопросы топов, лид отдувается за команду).
По итогу — моя работа все равно состояла явно больше чем на 40% из митингов и общения но при этом тима могла спокойно работать без дебильных разборок на тему того что «а я в прошлый раз демо делал» а также «программисты — личности нетрадиционной сексуальной ориентации и сдают таски в QA за день до конца спринта!» и сидения в митингах целыми днями.

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

это другая крайность :)

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

Дальше, ну а нахер мне как деву ходить на митинги где кто-то сидит и заполняет юзерстори? Мне что, делать больше в жизни нечего? Я лучше пойду себе пройдусь, все три часа.
Продакт оунер был, на секундочку, на стороне заказчика :)
CTO и архитектор — тоже там.

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

Разговор о другом — о том что дев, который хочет сидеть в коморке и кодить свой код, если его запихать на 10 митингов в неделю суммарной длительностью 15 часов радостнее и продуктивнее нихрена не станет.

вот это однозначно херня, как и двойной эстимейт, вначале кто-то а потом исполнитель

Рамки вообще были, просто не жесткие. Если конец спринта подходит а нихера не готово — то эта ситуация разруливалась ручками, скрипта как в скраме (не успел? ну и хер с ним, перенесется на следующий!) не было. И это не двойные эстимейты а триаж на уровне «просто-сложно-очень сложно», один хер в спринт идет то что нужно бизнесу и тут какбэ логично что 100 раз за 2 недели переписать все с ноля не получится вне зависимости от размера команды, а вот 100 опечаток поправить очень даже может одинокий джун даже если он каждую надпись будет пол часа искать.
Скрамовский покер, в общем, тоже ничем не лучше когда тебя просят показать циферку по стори в которой ты нихера не понимаешь потому что ту часть системы ты вообще никогда не видел и делать это все равно будешь не ты.

То что скрам как-то там влияет на повышения — тоже скорее всего миф

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

И не в скраме дело.

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

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

(здесь должна быть картинка с чуваком выброшенным в окно классическая)

Я прекрасно знаю что такое незаменимость — был один кейс где коллеге предложили повышение зп на не много не мало а $3000 (и нет, у него было не 500 баксов в месяц). Правда он вежливо отказался — решил что нервы дороже.

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

А какие умные слова вы еще знаете?

Вспоминание о ватерфоле после наезда на Agile многое говорит о человеке.

это когда сидишь три часа (два раза в неделю!)

Зря совок ругаем. Оперативки там проходили гораздо быстрее и продуктивнее без всяких там скрумов. Ну максимум минут 30 и не каждый день. А если был сложный вопрос, тогда начальник оставлял кого это касается, остальных отпускал

Хе-хе, оказываеься мой любимый процесс — это был «совок» в исполнении американцев. Забавненько.

может просто через жопу применили фреймворк? Может беда была в хаосе в процессах и слабой дисциплине/професионализме людей, что им не хватало 10% времени как прописано в гайде?
Или это «сертифицированные спецы» принуждали по 40-50% сидеть в митинг румах?

К самому скраму меня меньше претензий чем к его реализациям. Хотя он мне и на бумаге не очень нравится — все равно слишком много митингов на мой вкус, особенно когда на ретро сидишь как дебил и пытаешься выдавить из себя что-то там что тебе не понравилось. Спринт как спринт, ёпта. Печенье было невкусное, о!
А реализации — это очень часто полный трешак и культ карго. «Сертифицированные» забывают обьяснить что это фреймворк а не религиозный ритуал (или может то что слово «фреймворк» переводится не как «религиозный ритуал») и что его НУЖНО подгонять под себя и оптимизировать. И скорее всего перед тем как его вводить вообще нужно сесть и подумать как это должно выглядеть и не мог ли бы продакт овнер посопеть в две ноздри и помучится со своим убогим умением набирать текст сам а не на митинге со всеми?
Но нет — начинается вот это вот всё «вот тут вам нужно то, вот там вам нужно это, а потом все должны водить хоровод», тьфу.

А где в аджайл манифесте про митинги то?

Упс, «опечаточка» :) Имелся в виду скрам, конечно же.

ну так может вопросы должны быть к рукожопым адептам, а не к инструменту и манифесту в целом?)
Ну и я бы начинал с вопроса «Нужен ли он нам и какую проблему мы хотим решить?»
Тогда и применения фреймворка не вызывало бы чувства стыда и что из тебя делают последователя культа карго ;)

Я там слегка промахнулся — имелся в виду конкретно скрам а не аджайл в целом (хоть они у нас и равнозначны) есть и нормальные аджайл процессы которые мне очень понравились.
К сожалению на этот вопрос обычно отвечают не те люди которые им потом пользоваться :)
Меня, лично, еще ни разу не спрашивали. Но было бы забавно — «Эй, ты, там, как там тебя, ты же на нас работаешь? Вот скажи — нам нужен скрам? А то говорят модно стильно молодежно, качество и скорость повышается!», а я такой — «Нет, не нужен!» (немая сцена, включается подходящая случаю музыка).

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

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

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

А вообще да, ты прав — вслух я этого обычно не говорю, потому что лиду должно всё нравиться. Держу марку :)

Надеюсь для того чтобы поднять мне зарплату на 1000$ до уверенно-рыночного уровня :)

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

рекорд пока что — предложение +$2000 от текущей зарплаты.

Сколько ж он сидел то на одном месте?

Не обязательно сидеть очень долго, можно сидеть продуктивно — приходишь как интермид, а через год-полтора ты уже проходишь собеседование на синьора без проблем (или даже на лида при достаточной наглости) а зарплата-то уже даже как на интермида не блещет. Вот и получаются такие прикольные ситуации.
У меня лично похожее было когда я на дотнет перешел — пришел как слабый интермид, прошло буквально пол года и я уже (очень) легко проходил собеседования на синьора, благо в дотнете ничего феерически сложного нету. Только вот в компании к такому стремительному росту были как-то вообще не готовы, особенно в плане зарплаты. Так что для опции «свалить на +1000» хватает пол года, проверено лично.

для опции «свалить на +1000» хватает пол года

Сколько раз?

Если при этом каждый раз менять технологию — то можно повторять до бесконечности пока не надоест. Вопрос ведь был в том «сколько сидел на одном месте» а не «какие еще были обстоятельства».

Если при этом каждый раз менять технологию

Если прибавлять к нулю — можно хоть каждый день. Интересна же верхняя граница.

А что тут интересного — 250к в год в Штатах, вот и верхняя граница.

Пожалуй, но мы же говорим в контексте Украины.

Пролезть на 250к+ позицию по удаленке? :)

Свалить на +2к не проблема если до этого это несколько лет работал за еду. +2к к 2к это уже интереснее. А к 5к?

Ну, после 5к нужно уметь крутиться и пользоваться воображением, но иметь доход 7к в месяц будучи просто девелопером в Украине это все еще вполне реально.

Реально, но в большистве случаев даже +100 уже будет успех.

При чем за воображением далеко ходить не нужно, вот пример, но таких, наверное, не много www.eventbrite.com/...​ament-tickets-39038946540. И туда нужно попасть.

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

Да, за хорошую зп нужно впахивать. Оно может быть по-разному интересно на разных этапах. Но то, что в Украине можно так зарабатывать это уже радует.

Ну, откровенно говоря, это не совсем «в Украине» — я даже не уверен есть ли у них юрлицо здесь. Технически это обычная удаленка, а удаленку можно и без Crossover найти. Другое дело что этим нужно озадачиться и поработать над целью к чему не все готовы, да и запас наглости нужен.

Я думаю, что еще зависит все конкретно от фирмы и людей которые в ней работают. Если процессы в фирме не правильно построенные, то конечно будут такие ситуации

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

Зачем 3 часа? И почему заказчик что-то пишет? В фирме где сейчас работаю у нас на гроуминг два раза в неделю и занимает всего 1 час по технике помодоро (25 минут работает 5 минут перерыв и снова 25 минут работаем), за это время проходим в беклоге только то, что успели. Получается что при такой постоянное методике, в беклоге всегда есть айтемы, +\- понятно какое следующее задание и кто чем займется.

Мне кажется что при правильном подходе получается все очень даже хорошо.

особенно когда на ретро сидишь как дебил и пытаешься выдавить из себя что-то там что тебе не понравилось. Спринт как спринт, ёпта. Печенье было невкусное, о!

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

У меня к идее претензий особых нет, претензии к тому как это часто бывает реализовано.
Как по мне то даже 2 часа в неделю груминга со всей командой излишни — процесс можно поставить и более эффективно. В конце-концов у задач есть такая прелесть как «комментарии» — всегда можно асинхронно это вот всё обработать и укоротить всеобщее сидение.
Скрам хорош когда все хотят вообще нихера не делать и даже видимость работы не создавать, включая начальство и заказчика. Открываешь на митинге пустой айтем — приходится заполнить, что поделать! А то что до митинга это можно делать — лень ведь.

Претензия к ретро — тоже к реализации. Ну нечего сказать — так нечего, но нет, ритуал нарушен!

я просто оставлю это здесь.https://www.youtube.com/watch?v=2u0sNRO-QKQ (One Hacker Way Rational alternative of Agile — Erik Meijer) стоит послушать не только адептов но и критиков.

А вы не думали спросить не у скрам/аджайл коучей в чем польза аджайла, а у разработчиков?

Интересно, в чем польза аджайла?

А ее нет :-)

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

Agile он как религия — или веришь, или нет. А польза от него только тем, кто получает бабки за проведение курсов и сертификаций

а вы статью читали?) или это тоже польза описана только для сертификационных тренеров и курсов?

Опять церковь свидетелей Agile распроповедовалась. А потом повсеместное надувание щёк и карго-культ «единственно верных практик».

Я как Digital PM отвечала за эту самую доску и приоритеты.

Это все что нужно знать о проектном менеджменте.

Ох ребята, Agile в теории неплох, весьма неплох, но в реальности от него остается лишь название. Как всегда, реализация подкачала. И получается уже вот так: www.facebook.com/...​videos/10155111695310172

Я конечно не сертифицированный скрам мастер и даже не ПМ, но позвольте спросить — а какое отношение имеет Канбан к Аджайлу?

У них есть незаконнорожденный ребенок — скрамбан.

Scrum и Agile — это не одно и тоже ;)
Agile — это про приоритеты, принципы и ценности, а Scrum / Kanban / XP — набор конкретных практик (читай framework)

та невже?! а где я ляпнул, что одно и то же? справедливый вопрос был такой:

какое отношение имеет Канбан к Аджайлу?

, о скраме вааще речь не шла.
Спасибо.

У них есть незаконнорожденный ребенок — скрамбан.

и вправду.. где тут речь о скраме?)

вправду: если тренер грит, что скрамбан и скрам — это одно и то же, «не верь глазам своим» :8)

а я сказал «одно и тоже»?) давайте не будем перекручивать слова и манипулировать, а то так можно далеко зайти :)

а я сказал «одно и тоже»?

ну не я же тут грешное с праведным...

Вы не поверите, но как фреймворк разработки самое прямое. Это одна из agile методологий.

Kanban is a popular framework used to implement agile software development. It requires real-time communication of capacity and full transparency of work. Work items are represented visually on a kanban board, allowing team members to see the state of every piece of work at any time.

www.atlassian.com/agile/kanban

То что канбан у них в аджайле ни о чем не говорит. Так легче продать (!). Ниже об этом уже написали. Даже с видео.
Стоит копнуть ближе и посмотреть что одно перпендикулярно другому. Канбан о том что «конвейер» не должен простаивать он не обязан при этом быть гибким. Аджайл же о «гибкости конвейера». ))

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

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

en.wikipedia.org/...​wiki/Kanban_(development. Нету там ничего гибкого.Все остальное маркетинг или попытки скрестить «гибкое» с «твердым».

Kanban is a method for visualizing the flow of work, in order to balance demand with available capacity and spot bottlenecks. Work items are visualized to give participants a view of progress and process, from start to finish. Team members pull work as capacity permits, rather than work being pushed into the process when requested.

Вы не ответили на вопрос, что такое Аджайл.

Читайте дальше статью:

The method does not prescribe a specific set of steps, but starts from existing context and stimulates continuous, incremental and evolutionary changes to the system. It aims to minimize resistance to change to facilitate it.

Так можно и в скраме в продукт беклог запихнуть изначально формализованные до последней запятой требования, выполнять их по скрам процедурам и визуально получить «идеальный» скрам. В этом случае в нем не будет ничего гибкого. Скрам позволяет найти проблемы как можно быстрее, Канбан позволяет наладить конвейер выполнения поставленных задач. Методология и фреймверки сами по себе не сделают процессы гибче или резистентнее, а наши цели и умение обращаться с инструментами менеджмента — могут сделать, в том числе и эффективнее.

Везде Канбан — это Аджайл

Нет. Как правило «везде», если говорим об IT, речь идет о том самом их ребенке — скрамбане, а не о оригинальном канбане.

Agile — это не методология, а про приоритеты и способ мышления. Это ценности и принципы построения ваших процессов. К сожалению — не многие прочитали дальше чем 4 ценности на главное странице и назвав это «маркетинговым булшитом» или «так это же очевидные вещи» просто закрыли. А там есть еще 12 принципов Agile манифеста... И вот если вы их прочитаете и сопоставите с тем, что написано в Kanban Guide by David J Anderson and Andy Carmichael (leankanban.com/guide) — то там сложно отрицать, что Канбан — это Agile процессный фреймворк ;)

то есть если бы я в детстве прочитал не 3 евангелия, а все то стал бы священником автоматически?

нет конечно, но позиция многих напоминает «не читал, но осуждаю»

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

и да, канбан никакого отношения к аджайлу не имеет

на чем базируется это утверждение?

п.с.: тот Канбан, что был на заводах в Японии — не имеет. А та версия, что адаптирована для Software Development — очень даже имеет ;)

канбан это просто доска куда ее не повесь. Хоть в скрам, хоть в rup, хоть под водопадом юзай. Т.е. можно сказать, что мы в аджайл методологии используем канбан доску. Но обратное не подразумевается. Утверждение «мы используем канбан» не должно автоматически подразумевать использование аджайла или скрама или бог знает еще чего.

Если Вы говорите «канбан доска», то да, согласен, — это инструмент, если канбан, подразумевая методологию, то нет. Канбан — это не только доска, канбаном еще называют методологию разработки, которая может быть и самодостаточной. У нее не так много ограничений.

Канбан — это не только доска в отношении фреймворка ;) Это еще лимиты, разные классы работ, Cumulative Flow Diagram, определенные принципы и правила игры ;)

Канбан — это Agile процессный фреймворк

вот только Kanban появился задолго до Agile (при чем есть мнение, что более правильное звучание カンバン все же ближе к камбан)

Скрам и ХР тоже появились раньше Аджайла ;)

Пожалуй, уместно будет и тут запостить эту ссылку www.youtube.com/watch?v=a-BOSpxYJ9Mt=646 :)

Конечно уместно. Кстати цитата из видео (примерно 1-я минута): Agile is dead. But, that doesn’t mean we have to stop doing it.

И вообще видео отличное. Оно не о том, что гибкая разработка — это плохо, а о том, что некоторые идеи и понятия иказили, чтобы было проще продавать консалтинг.

Підписатись на коментарі