Привет, Хаброжители!
Что такое Agile? Как гибкие подходы могут помочь в работе, бизнесе или даже в обычной жизни? В этой статье вы узнаете, что Agile-принципам можно следовать даже при приготовлении новогоднего оливье. Будет полезно всем, кто хотя бы раз сталкивался с таким непростым делом, как подготовка новогоднего стола!
Всем привет! На связи снова Петрова Марина — QA Lead в Сloud.ru. Сегодня поделюсь опытом оценки и оптимизации процессов тестирования с помощью модели зрелости TMMi. Наша команда использует TMMi с третьего квартала 2022 года: за это время мы не раз оценили процессы и адаптировали модель для команд, которые работают в Agile-парадигме, но обо всем по порядку.
Привет! Это Дмитрий Гайдук, менеджер в АТОМе по корпоративным и онлайн-сервисам.
Каждое инженерное и программное решение в АТОМе – это отдельный продукт. Но если вырывать эти продукты из контекста, они останутся отдельными разрозненными решениями. Для нас крайне важно изменить само восприятие автомобиля и создать опыт, который задействует все сплетение новых технологий. Проекция дополненной реальности на лобовое стекло, голосовой ассистент, продвинутая система помощи водителю и множество других решений должны соединяться с эргономическими особенностями электромобиля, и только тогда они станут цельной экосистемой.
Как это работает?
Разберем на примере АТОМ-такси. Главная особенность этой модели – отсутствие переднего пассажирского кресла. Очевидное преимущество такого решения: у клиента больше места для ног. Менее очевидное: ничто не перекрывает обзор. Вид на город становится практически панорамным.
Ретроспектива. Новогоднее ретро. Как погрузить команду в Christmas mood?
Всем привет, это вторая часть статей о готовых шаблонах проведения ретроспектив. Эта статья посвящена новогодней рестроспективе. Новый год, декабрь месяц, подарки, глинтвейн, сугробы, «Гарри Поттер», «Один дома», селёдка под шубой…
Всё не перечислить, да и не нужно, ведь наша ретроспектива определит ваши планы на декабрь, январь и февраль. Да-да, это чистая правда.
Меня зовут Александр Шаповалов, я руководитель отдела разработки систем расчёта и доставки Mediascope. Количество людей и задач в нашем отделе росло постепенно. Когда в моей команде был только один сотрудник, было легко держать весь рабочий контекст на листке бумаги и в голове: аналитика, архитектура, стек, взаимодействие с заказчиком. Но когда нас стало больше 10, я заметил, что часть аспектов стала ускользать из фокуса. Любые ручные проверки для такого объёма задач не приемлемы, поэтому мы внедрили калибровку процессов с помощью метрик разработки.
У продуктового отдела нет выстроенных процессов? Задачи ставятся через почту? Приоритеты по задачам не очевидны и команда ощущает фоновый стресс? Руководство не устраивала скорость выполнения инициатив? Что же делать...? Об этом читайте в статье!
Как провести незабываемую ретроспективу с нуля? Нескучные ретроспективы. Ретроспектива, которую мы заслужили.
Часть 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, эксперт и тренер по Канбан методу. В статье расскажу, как грамотно ограничить количество задач и не навредить команде.
