Каждая команда, которая ведёт разработку ПО в соответствии с практиками Agile, имеет бэклог продукта или по крайней мере думает, что он у неё есть. Кажется, что это очень простой инструмент, но на практике я регулярно сталкиваюсь с неумением им пользоваться для планирования работы разработчиков. Давайте попробуем разобраться, для чего нужен бэклог продукта и как извлечь из него максимум пользы.
Action Bias: склонность к реагированию и действию, даже если это не приведёт к положительным результатам. «Делать хоть что-то» создаёт иллюзию загрузки ресурсов полезной работой.
Эта статья показывает 27 распространённых антипаттернов продуктового бэклога, включая процесс уточнения бэклога продукта, ограничивающих успех вашей Скрам-команды.
С какими возможными проблемами столкнутся современные производители программного обеспечения при оценке, разработке стратегии и составлении дорожной карты будущего с использованием известных моделей зрелости.
Менеджеры обладают всеми возможностями, чтобы заставить команду страдать Как менеджеры, мы находимся в наилучшем положении, чтобы погрузить в уныние наши команды. Если вы менеджер, стремящийся действительно максимально причинить боль своим людям, обратите внимание! Мы рассмотрим три самых популярных способа. Правда, мы сфокусируемся только на антипаттернах управления проектами, при том, что есть много других возможностей сделать людей в вашей команде несчастными. Эти техники управления приводят к медленной разработке и помогут сделать ваши проекты менее эффективными. При достаточном усилии менеджера разработчики могут полностью провалить свою миссию. Описанные приёмы дают возможность не только сделать команду несчастной, но и полностью разрушить вашу компанию! Злые…
Продуктовый подход можно, на мой взгляд, использовать даже в тех случаях, когда у нас нет классических продуктов. Такое использование, разумеется, требует осмысления, его не следует применять под копирку, по аналогии, или потому, что все вокруг так теперь делают.
Очень часто можно наблюдать ситуацию, когда выполняется много задач из бэклога, все участники команды максимально загружены работой, но как такового существенного улучшения свойств продукта нет. Продукт обрастает функциональностью бессистемно, теряется целостность бизнес-логики, ожидаемых больших изменений не происходит. При этом зачастую ещё и количество задач в бэклоге неубывает, а наоборот, кажется, задачи множатся, как гремлины под дождём. И всё равно бизнес заказчики недовольны темпом работы. Хотя стоит иметь в виду, что их на самом деле интересует не то, как быстро разработчики умеют писать код, а темп улучшения продукта, заложенный в целевую картину развития бизнеса. Каскадирование целей Бизнес инвестирует в развитие продуктов…
Многие «внедряют» DevOps, но немногие получают ожидаемое благо для бизнеса. Почему? Причина очень проста: те, кто добивается коммерческой выгоды, точно знают, на чем следует сосредоточиться, чтобы правильно использовать методологию DevOps в организации. Они также знают, что ценность для бизнеса — это конечная цель DevOps, а ценность начинается и заканчивается во взаимодействии с потребителем. Есть 4 ключевых элемента для правильного использования DevOps в организации. Они просты, но при этом являются теми аспектами, которые наиболее часто игнорируют. DevOps будет очень эффективен в обеспечении бизнес-ценности для клиентов, если и только тогда, когда эти аспекты будут соблюдаться. Вот эти 4 ключевых составляющих DevOps :…
На прошедшей неделе на сайте DevOps.com было опубликовано короткое интервью под названием «Agile и DevOps для киосков» («Agile and DevOps for Kiosks» — можно и посмотреть/послушать, и прочитать расшифровку) с Сэмом Зайтцем, основателем и CEO компании Grubbrr. Компания занимается технологиями в области самообслуживания (точнее, self-ordering) — киоски самообслуживания (аэропорты, банки, рестораны [в первую очередь фастуфуд] и т.д.). Пара любопытных моментов.Во-первых, Сэм указывает на то, что в последнее время спрос на такие технологии стремительно растёт. Он объясняет это несколькими факторами. Это происходит ввиду повышения минимально уровня оплаты труда (президент Байден продвигает повышение до 15 долларов США за час) — использование труда…
Недавно на одной из внутренних тусовок, где обсуждали Канбан для продуктовых команд, мимоходом была озвучена мысль о том, что коэффициент эффективности потока нынче уже не в моде, поскольку не учитывает задачи, зависшие в производственной системе.Попробую возразить. Для того, чтобы это сделать, стоит напомнить, что это за метрика, и сделать пару уточняющих охват заметки замечаний. Коэффициент эффективности потока (FE) показывает какую долю времени, проведённого задачей (work item) в производственной системе (т.е. lead time, LT), задача действительно обрабатывалась (т.е. велась работа над её решением). Если просуммировать это «чистое» время обработки мы получим так называемое время обработки — process time (PT, aka touch…
Одной из наиболее эффективных стратегий, приводящих горе-руководителей к провалу, является концепция неограниченной незавершённой работы. Отсутствие лимитов на задачи «в работе» (Work in Progress) легко оправдывается необходимостью «эффективно использовать ресурсы», «делать больше» чтобы недопустить «слив актива». Все знают, что величайшее преступление — позволить кому-либо сидеть без дела и «расслабляться» при загрузке менее 125%. Большинство гибких/бережливых/модных/цифровых трансформаций подвигают организации создавать ценность самого высокого качества с наименьшими затратами времени. Это непростые цели, требующие реальных изменений при сосредоточенной поддержке руководства. Проблема с этими целями заключается в том, что трудно оценить, насколько вы к ним продвинулись, улучшилась ли организация или нет. Чтобы случайно не допустить…