У продуктового отдела нет выстроенных процессов? Задачи ставятся через почту? Приоритеты по задачам не очевидны и команда ощущает фоновый стресс? Руководство не устраивала скорость выполнения инициатив? Что же делать...? Об этом читайте в статье!
Как провести незабываемую ретроспективу с нуля? Нескучные ретроспективы. Ретроспектива, которую мы заслужили.
Часть 1 Packman. Пиксельное ретро.
Всем привет, меня зовут Иван. Сегодня я расскажу как подготовить тематическую ретроспективу на одном подробном примере. Из названия можно понять, что это первая часть и каждой следующей части будет уделяться разбор одной целой ретро-встрече, также вы по итогу сможете внести свои корректировки и даже я предложу несколько вариантов проведения одной тематической ретроспективы. Это статья подойдет для тех, кто только начинает свой путь как scrum-мастер, а также для тех, кто хочет повысить насмотренность и взять что-то интересное для проведения своих фасилитационных встреч.
Предлагаю занять чуть времени на определения и структуры ретро.
Фасилитация — это процесс управления обсуждением и координации действий участников встречи, который помогает достичь конструктивных решений.
Меня зовут Дмитрий и я занимаюсь Agile трансформациями компаний и помогаю компаниям выстраивать процессы, а также являюсь основателем консалтингового агентства Smart units. Последние несколько лет выстраивал процессы заказной разработки, а также участвовал в крупных проектах реализации продукта вместе с вендором. И здесь набил много ошибок, а также сформировал набор правил того, как действительно нужно вести разработку продукта если вдруг вы являетесь либо Заказчиком, либо компанией которая предоставляет услуги по заказной разработки.
Та система, которую я опишу, позволит вам получать более быстрый и качественный результат при заказной разработке. А самим компаниям, которые делают заказную разработку, получать более счастливых клиентов, которые будут возвращаться за новым сотрудничеством.
В современном мире разработки программного обеспечения, где изменения происходят с ошеломляющей скоростью, гибкая методология завоевывает популярность благодаря своей итеративной и гибкой природе. Однако адаптация традиционных стратегий ручного тестирования может представлять собой сложную задачу. Целью данной статьи является изучение лучших практик для успешной интеграции ручного тестирования в среду гибкой разработки.
В далёком 2020 году мы решили отказаться от Скрама и перейти на канбаноподобную модель с парой элементов из фреймворка LeanDS. Это решило как минимум часть проблем, про которые я говорил в докладе - тенденция к выгоранию, искусственные разрывы экспериментов между спринтами, разрушение спринтов из-за внезапных задач, ухудшение качества кода и документации. И чуть ли не самое главное - после отказа от некоторых скрам-ритуалов значительно упали затраты времени и энергии на не особо нужные встречи и споры.
Спустя примерно два с половиной года и какое-то количество не самых удачных процессных экспериментов (например, OKR и квартальные цели) стало ясно, что что-то или сломалось, или изначально работало не очень хорошо. Вот примеры проблем, с которыми все четыре продуктовые команды (так мы называем ML-команды по разными направлениям - маммография, рентген лёгких, КТ лёгких, КТ мозга) регулярно сталкивались в пост-скрамной эпохе:
В продуктовых компаниях все задачи часто помещают в одну очередь. В итоге разработчики стрессуют из-за объема задач и дедлайнов, хватаются за разные таски, переключаются между ними и с трудом доводят дела до конца. А если прилетает что-то незапланированное, работа может встать на неопределенный срок.
Меня зовут Артур Нек, я управляющий партнер Kaiten и Канбан-консультант. В статье на примере своей компании расскажу, как выстроить процессы в небольшой команде разработчиков, чтобы она оперативно обновляла продукт, но не выгорала.
Привет! Хочу поделиться парой мыслей о представлении нефункциональных требований в формате User Story. Вы наверняка помните самый распространенный шаблон для историй. В шаблоне есть три части «кто», «хочет что», «чтобы что». Чтобы соблюдать такой формат, важно выделить действующие роли и цели для каждой истории. Для нефункциональных требований это бывает непросто и я часто думаю: «А нужно ли?».
Майк Кон в своем блоге пишет, что нефункциональные требования хорошо ложатся в стандартный шаблон пользовательской истории и что такой шаблон позволяет не забыть, почему это требование появилось. В статье «Нефункциональные требования как пользовательские истории» (Non-functional Requirements as User Stories) приведены кейсы, среди которых есть несколько «синтетические». Например, на мой вкус странно выглядит история вида «Как человек, говорящий на одном из латиноамериканских языков, я, возможно, когда-нибудь захочу запустить ваше программное обеспечение». Как работать с такой историей в бэклоге? Сможет ли команда адекватно ее декомпозировать на атомарные задачи?
Обычно бывает интересно почитать не только саму статью в блоге, но и комменты к ней. В комментариях к статье Майка Кона как раз есть похожие вопросы:
Всем привет! Меня зовут Сергей Сжёнов. Более 15 лет я работаю в ИТ-индустрии, а сейчас отвечаю за развитие облачных продуктов в beeline cloud.
В этой статье хочу поговорить о product management, запуске цифровых продуктов, поделиться личным опытом и размышлениями. Материал будет полезен тем, кто только начинает свой путь в этом направлении, и тем, кто давно в деле.
Скрам – это легкая методология, которая помогает людям, командам и организациям создавать ценности. Это простая и намеренно неполная система, которая позволяет пользователям полностью раскрыть свой потенциал и работать в режиме Agile.
В центре внимания Скрама находятся люди. Скрам организует проекты, используя кросс-функциональные команды, каждая из которых обладает всеми возможностями, необходимыми для реализации функциональности от идеи до конечной реализации.
Итак, погружайтесь и узнайте все об основных принципах Скрама... и все это менее чем за 10 минут.
Scrum Alliance
А с использованием методов линейного программирования.
Сталкивались ли вы с понятием линейного программирования? А его применением на практике? В университете мы изучаем разные разделы математики, нам рассказывают про математические модели и методы, однако вопросу их практического применения часто уделяется недостаточно внимания.
В статье я поделюсь основными тезисами моего доклада, представленного на конференции Analyst Days #16. В нём я постарался показать, как методы линейного программирования могут быть применены в работе команды, живущей спринтами. Под катом вас ждет альтернативный взгляд на планирование спринта.
Стартапы в последние пару лет, мягко говоря, оказались между Сциллой и Харибдой. Многие бизнесы начали сжиматься (а ЦБ стран жестить), а венчурные фонды внезапно стали очень бережливыми. Как поступают стартапы в США в эпоху неопределенности? Правильно, сразу сокращают персонал и закрываются. Сегодня все уже забыли оптимизм постковидного 2021 года.
Последние 10 лет я плотно работаю со стартапами, и рынок буквально кричит: "хватит выбрасывать на рынок тонны нового функционала, займитесь уже тем, что у вас получается хорошо”.
В рамках этого сотрудничества мы создали простую табличку, чтобы проанализировать как чувствуют себя новые фичи и как много мы в них инвестировали. В интернете очень много комплексных ROI-моделей, но простота этой таблицы в том, что ее данных достаточно чтобы начать двигаться в продуктовом направлении.
Scrum — это Agile-система управления проектами, «помогающая людям и командам инкрементно и совместно приносить пользу» — цитата со Scrum.org.
Agile не является: Библией разработки ПО, догматическим набором строгих правил, тикетами Jira или коучами Agile, суетящимися в вашей компании.
Тимлиду нужно наладить процессы в команде и повысить эффективность работы сотрудников. Один из способов это сделать — ограничить входящие задачи, то есть использовать WIP-лимиты. С их помощью сотрудники избавятся от завалов, начнут помогать друг другу, коллаборировать и работать быстрее.
Если руководитель ставит WIP-лимиты без аналитики, не объясняет команде и заказчикам, зачем нужны ограничения, всё может пойти наперекосяк. Сотрудники будут сидеть без дела или начнут брать задачи в обход менеджера. Я Андрей Сидоренко, сооснователь компании Neogenda, эксперт и тренер по Канбан методу. В статье расскажу, как грамотно ограничить количество задач и не навредить команде.
Привет, Хаброжители!
Привет! Меня зовут Артур Нек, я Kanban-консультант и управляющий партнер Kaiten. Как руководителю, мне важно знать, как идут дела в проекте и есть ли какие-то проблемы. Постоянно спрашивать об этом у сотрудников в чатах или на почте неэффективно, а на просмотр досок и карточек проекта уйдет много времени.
Вместо этого я использую визуализацию — накопительную диаграмму потока, которая помогает быстро составить картину происходящего. В этой статье я расскажу, что это за диаграмма, и на примерах разберу самые частые проблемы, которые она может показать.
Вы сталкивались с ситуацией, когда мобильное приложение или веб-сервис напоминают лоскутное одеяло? Action-кнопки прыгают по экрану, навигационные паттерны неожиданно меняются, а дизайн элементов интерфейса разнится в частях проекта?
А теперь представьте, что вы создаёте цифровой продукт в роли PO, CPO или CTO. Тогда вы столкнетесь не только с несогласованным дизайном, но также с неуправляемым бэклогом (план против реальности), задержками выпуска версий и постоянными переделками функционала после выхода в продакшн.
Крупные проекты живут с подобными проблемами, но у меня для вас хорошие новости: их можно решить. В статье поделюсь опытом организации производственных процессов для 100 команд разработки, чтобы упорядочить этот хаос.
Меня зовут Лена и я QA Engineer в Brickit, приложении для сканирования кубиков Lego. До этого мне довелось поработать в крупном зеленом банке. В этой статье я расскажу об отличиях корпорации и стартапа в разрезе процессов тестирования и разработки, а также дам несколько практических советов, которые в свое время пыталась отыскать в интернете.
Есть простая айтишная мудрость: «работает — не трогай». Она применима и к бизнесу. Но на практике без нововведений, хоть и редких, бизнес может не только перестать расти, но и начать стагнировать. И нередко изменения действительно оправданы и помогают улучшить показатели компании. Но только при условии, что к их внедрению подошли правильно, а не бросили сотрудников наедине с новыми инструментами, правилами или подходами.
Меня зовут Артур Нек, я Канбан-консультант, основатель компании Neogenda и управляющий партнер Kaiten. В статье расскажу, как управлять изменениями, чтобы не получить поток заявлений на стол.
Внутреннее состояние команды также важно как и работа, которую они выполняют.
Даже не используя сложный софт или техники, а только с помощью опросника и блокнота, лидерам команд следует отслеживать динамику состояния опыта своей команды с помощью метрик. Своевременно реагировать на их изменение и искать причины этих изменений. Например, можно взять и переработать простой продуктовый HEART фреймворк под метрики команды.
Сегодня хотелось бы рассмотреть основной список методологий применимых в тестировании и самый простым языком описать для чего каждая годна.
