Agile, Scrum, разработка ПО Archives – Страница 11 из 30

Диагностика продуктовых команд как поток

Представим, что у нас есть продуктовая команда. Ну или группа людей, которые очень хотели бы таковой стать. Ну или мы хотим, чтобы они стали – не суть. Предположим, что с этой командой мы какое-то время поработали: разобрались в её рабочем процессе, особенностях, составе, области ответственности… Реализовали набор практик, помогающих работу/результаты структурировать, визуализировать, организовывать, измерять и улучшать. Всё на основе важных принципов и исходя из определённого, нового продуктово-гибкого mindset’а (это слово я на русский перевести затрудняюсь). Итого: первоначальные инвестиции сделаны, далее ожидается более самостоятельное движение этой команды вперёд. Возникают важные управленческие вопросы: как убедиться, что команду можно “отпускать в более свободное…

Что говорят продуктовые команды и что они на самом деле имеют в виду—10 советов по диагностике проблем в команде

Проблемы в команде имеют негативное влияние на продукт и ваших сотрудников в долгосрочной перспективе. Есть множество способов, которыми они могут проявить себя. В этой статье я собрал опыт десяти лет создания цифровых продуктов в кросс-функциональных командах. Я не стану затрагивать вопросы за пределами продуктовой команды, такие как плохой процесс продаж, непонятные запросы, запутанные бизнес-требования. Прочитав эту подборку, вы сможете выявить типичные симптомы, которые, в свою очередь, помогут с диагностикой проблем. Все команды и ситуации уникальны, но некоторые проблемы являются повторяющимися, а понимание проблемы — это половина пути к её решению. 1 «Наши клиенты ☠️… Они не способны понять, что мы…

Новый сезон вебинаров CleverTALK: регистрация открыта

Уже на следующей неделе начнётся новый сезон вебинаров CleverTALK, регистрация уже открыта. В программе: 12 ноября. Технический долг: как бороться с невидимым врагом. Ведущая: Светлана Сапегина. Регистрация 18 ноября. ITIL в 2020 и 2020 в ITIL: как этот год повлиял на содержание ITIL 4 и что в ITIL 4 может быть особенно полезным в 2021. Ведущие: Роман Журавлёв и Олег Скрынник. Регистрация 26 ноября. Ключевые принципы и практики высокопроизводительной продуктовой команды. Ведущий: Олег Скрынник. Регистрация 10 декабря. Опыт организации продуктовой команды: часть 2. Ведущая: Светлана Сапегина. Регистрация 17 декабря. Каталог услуг 2021 (тема уточняется). Ведущий: Дмитрий Исайченко. Регистрация

Как сформировать культуру “гражданских” разработчиков

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

Технический долг: как не стать жертвой невидимого врага

Зачастую о техническом долге говорят как о плохо сделанной работе. Но брак есть брак, он порождает отходы, а не долги. А технический долг может накапливаться незаметно и становится видимым, только когда бороться с ним уже очень сложно. Когда на рынке открывается долгожданное окно возможностей, что вы выберете: адаптацию и развитие вашего продукта в максимально короткие сроки или проработку качества? Каждый раз выбирая скорость, вы закладываете бомбу замедленного действия под разработку, и очень важно вовремя остановить обратный отсчет, пока не произошло фатальных разрушений. Как понять, когда и какие действия по управлению техническим долгом следует предпринимать? Кто соучаствует в работе над техническим…

Технический долг и беклог

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

Три визуализации, которыми я объясняю Agile

Хорошая визуализация помогает объяснять достаточно сложные вещи. Вместо большого количества слов достаточно одной картинки. У большинства консультантов есть свои любимые визуальные метафоры. Михаэль Вильямс в своей статье рассказывает о визуальных метафорах, которые он использует для объяснения принципиально важных моментов в организации работы по Agile. Когда я учился в школе, я сделал открытие. Я обнаружил, что я посредственно запоминаю числа, даты и формулы, но при этом фантастически легко запоминаю изображения и истории. Если я нашел способ изобразить что-то визуально, есть хороший шанс, что я запомню это навсегда. Если нет, то увы… То, что появилось как подспорье в учебе, быстро стало моим…

Есть ли польза от оценок трудозатрат разработчиков для самих разработчиков?

Мы знаем, что заказчикам и заинтересованным сторонам проекта нужны оценки по срокам реализации задач. На их основании они строят планы, расставляют приоритеты и планируют даты поставки разрабатываемых продуктов. А что для разработчиков? Для них отдача совсем не очевидна. Да и в целом может показаться, что и пользы-то никакой нет, ведь оценки используются зачастую “против” разработчиков, поскольку интерпретируются и воспринимаются стейкхолдерами именно как обещания. Вполне естественно, что разработчикам без особого удовольствия дают оценки, ведь они могут повлечь неприятности. Однако, оценки могут принести однозначную пользу командам разработки – фактически, со временем они могут повысить статус команд разработки среди всех заинтересованных сторон и…

Кто тут крайний?

Забудем на минуту про единорогов, бирюзовые компании, холакратию и прочие мифические концепции. Они, конечно, где-то есть, но не очень рядом. Представим себе традиционную организацию, имеющую ИТ-департамент, устроенный, как водится, в виде иерархии. Ничего необычного. Часть этой иерархии – подразделение, где трудятся аналитики. Поймаем одного из них в коридоре и спросим: “Подскажи, дружище, на твой взгляд, чтобы всё в разработке ПО стало быстрее и качественнее, что нужно сделать?”. Во многих знакомых мне компаниях ответ будет примерно таким: “Известно что – разработчиков заменить на нормальных. Наши-то и бизнес не понимают, и код пишут так себе, а учиться и слушать никого не хотят…”….

Олег Скрынник, 4 октября 2020, последний комментарий 28 октября 2020

Семь распространённых мифов о DevOps

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

Разрешение конфликтов в Agile-командах

Большинство людей предпочло бы избегать конфликтов. Как специалисты по проектам, мы знаем, что это неизбежно, и мы также знаем, что несогласие может быть конструктивным. Но при этом мы не любим конфликты, и большинство из нас надеется, что кто-то другой возьмёт на себя их разрешение. Что ж, с гибкими командами это может быть сложно, потому что команда должна быть самоорганизованной, а значит, никто не должен вмешиваться и исправлять что-то за нас. Что с этим делать? Возможно, вы не склонны доверять статьям, в которых обсуждается управление конфликтами. Я уверен, что их авторы действуют из лучших побуждений, но говорить о стандартных моделях управления…

Портал №1 по управлению цифровымии информационными технологиями

Agile, Scrum, разработка ПО

Портал №1 по управлению цифровыми
и информационными технологиями