Быстрая разработка часто завязана на использование ПО с открытым кодом. Это увеличивает сложность цепочек зависимостей. Нужно что-то делать, чтобы снизить риски. Потребуется действительно беспрецедентный уровень контроля не только над тем, что разрабатываем сами, но и над тем, что мы используем.
В этой статье показана важность трансляции ценности ИТ для руководителей с использованием подхода, ориентированного на результат, и даны советы по выполнению.
CustDev, CJM, USM, MAU/DAU, продуктовые команды, настоящие дорожные карты, ускорение в разы – это всё не про Enterprise. Или нет?
Обычно, когда в компании возникает потребность в организационных изменениях, сотрудники проходят соответствующее обучение, но часто на этом всё и заканчивается. Никакой магии не происходит, работа не перестраивается, потому что теоретической базы недостаточно, чтобы изменения случились.
Помимо усвоения новой информации нужны реальная практика,
понимание того, какую последовательность шагов надо предпринять, чтобы всё это заработало в конкретной организации и мотивация сотрудников.
Чем тут могут помочь деловые игры?
Разговоры про ускорение разработки программного обеспечения ведутся уже много лет. Насколько ожидания оправданы? Можно ли ускориться, и как сильно? И главное – что для этого нужно?
В Agile наша вера в то, что сплочённость и состояние команды в порядке, может зависеть от положительных сигналов, которые мы подсознательно предпочитаем.
Каждая команда, которая ведёт разработку ПО в соответствии с практиками Agile, имеет бэклог продукта или по крайней мере думает, что он у неё есть. Кажется, что это очень простой инструмент, но на практике я регулярно сталкиваюсь с неумением им пользоваться для планирования работы разработчиков. Давайте попробуем разобраться, для чего нужен бэклог продукта и как извлечь из него максимум пользы.
Action Bias: склонность к реагированию и действию, даже если это не приведёт к положительным результатам. «Делать хоть что-то» создаёт иллюзию загрузки ресурсов полезной работой.
Эта статья показывает 27 распространённых антипаттернов продуктового бэклога, включая процесс уточнения бэклога продукта, ограничивающих успех вашей Скрам-команды.
С какими возможными проблемами столкнутся современные производители программного обеспечения при оценке, разработке стратегии и составлении дорожной карты будущего с использованием известных моделей зрелости.
Менеджеры обладают всеми возможностями, чтобы заставить команду страдать Как менеджеры, мы находимся в наилучшем положении, чтобы погрузить в уныние наши команды. Если вы менеджер, стремящийся действительно максимально причинить боль своим людям, обратите внимание! Мы рассмотрим три самых популярных способа. Правда, мы сфокусируемся только на антипаттернах управления проектами, при том, что есть много других возможностей сделать людей в вашей команде несчастными. Эти техники управления приводят к медленной разработке и помогут сделать ваши проекты менее эффективными. При достаточном усилии менеджера разработчики могут полностью провалить свою миссию. Описанные приёмы дают возможность не только сделать команду несчастной, но и полностью разрушить вашу компанию! Злые…