В современном мире разработки программного обеспечения, где изменения происходят с ошеломляющей скоростью, гибкая методология завоевывает популярность благодаря своей итеративной и гибкой природе. Однако адаптация традиционных стратегий ручного тестирования может представлять собой сложную задачу. Целью данной статьи является изучение лучших практик для успешной интеграции ручного тестирования в среду гибкой разработки.
В далёком 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 фреймворк под метрики команды.
Сегодня хотелось бы рассмотреть основной список методологий применимых в тестировании и самый простым языком описать для чего каждая годна.
Около года назад мы в команде всерьез задумались о пересмотре сроков среднесрочного планирования. И всему виной наш любимый производственный календарь РФ. Но начнем издалека.
Традиционно мы привыкли встречаться раз в три месяца, квартал, ставить цели, возвращаться через квартал подводить итоги, ставить новые цели и так до бесконечности (хочется верить).
Но 2022 год стал для нашей компании поворотным периодом. Мы занимаемся разработкой онлайн-доски для совместной работы, где можно проводить стратегические сессии, ретро, брейнштормы, построение воронок продаж и т.д. И лишившись значимой доли иностранных конкурентов, нам представилась отличная возможность занять большую нишу рынка.
Чтобы достичь этой цели, мы решили сделать необычное (конечно, нет) – сделать ставку на масштабирование команды, улучшение процессов планирования и разработки. Самое главное: выпустить версию 2.0. Это должна была быть написанная с нуля новая онлайн-доска, которая возьмёт всё самое лучшее от предыдущих двух лет существования продукта (версии 1.0), но для новой целевой аудитории - бизнеса. В том числе с возможностью поставки в контур заказчика. Спойлер: мы это сделали.
При этом надо было помнить, что компания является стартапом и не может позволить себе раздуть ФОТ, погрязнуть в кризисе роста и потерять общую эффективность, которая складывается из результатов каждого члена команды.
Глядя на все это, мы решили попробовать спланировать следующий год. И тут у нас случилось интересное озарение.
Все предыдущие года, мы ставили себе цели на периоды по три месяца: с января по март, с апреля по июнь, с июля по... Ну вы поняли. И нас все устраивало, но был важный нюанс. Все это время мы работали супер небольшой командой, часть из которой была представлена аутстафом и жила вообще не по трудовому календарю РФ. Что уж говорить про фаундеров, которые всеми силами выбирались из долины смерти, иногда забывая про сон.
Л - Добрый день, дорогие зрители, сегодня мы продолжаем нашу серию репортажей «Стартаперы Кварцевой Лощины». С вами снова я, независимый журналист, Лайер Бала-Больё, и сегодня наш гость - талантливый селфмейд, добившийся всего сам, 19-летний сын известного миллиардера, стартапер Жу̒лико Бары̒гги младший.
Жулико уже выпустил два сверхполезных и сверхнужных приложения, это всем известный SriiPee для заказа пиццы прямо с унитаза и HeyGey – апп для поиска скоплений бородатых мужчин в клетчатых рубашках, любящих фруктовые коктейли и самокаты. Последнее приложение даже автоматически предустанавливается в каждый новый грушефон.
Жулико, вы только что были спикером на проходящем в Сан-Дьябло Блаблатоне и упомянули такую интересную вещь, как ШвабрОпс - можете рассказать нашим зрителям, что это такое и с чем его едят.
Ж – Привет, Лайер, привет всем. Да, на Блаблатоне я рассказывал про ШвабрОпс – это новое перспективное направление в IT. Дело было так. Я маялс…т.е. интенсивно работал в офисе и обратил внимание, что какой-то очкастый толстый задрот ходит туда-сюда из кабинета в кабинет. Я спросил секретаршу – кто это такой? Она ответила – это наш ДевОпс.
Л – Ага.
Ж – А я, если честно, даже не знаю, кто это такой. Но мне тут же в голову пришла идея. А что, если он возьмет в руки швабру и будет протирать пол, пока ходит туда-сюда.
Л – Угу.
Ж – Ну и все, собственно. Я подумал-подумал и решил – а зачем нам уборщица?! Пусть этот дев…как его там…в общем – пусть он еще и пол протирает параллельно. Это же какая экономия получается!
Хабр, привет! Я Саша, Product Manager в Ozon. Хочу сегодня поговорить с вами об исследовании зависимостей между подсистемами проекта, в частности, и повышении прозрачности процессов в разработке в общем.
Обычное дело: в команду приходит заказчик, приносит суперзадачу — киллер-фичу, которая по приблизительным оценкам будет приносить не меньше N денег в секунду. Очень важная и нужная штука. Потом проходит 3 месяца, а фича так и не появляется на проде. Более того, команда к ней так и не приступала.
Почему?
– вместо суперзадачи команда занимается какой-то ерундой — проблемы с приоритизацией;
– команда не поняла, что фича принесёт реальные деньги и насколько это важно — сложности с коммуникацией с заказчиком;
– недостаточно описаны требования, команда отфильтровала задачу как «не готовую к взятию в работу» — продакт не доработал;
– задача потерялась в недрах бэклога — продакт проглядел.
Все эти варианты говорят нам о наличии рассинхрона команд, ожиданий и реальности, рассинхрона подсистем относительно общего процесса, вследствие этого команда(ы) делает «не то» «не так» или не делает вовсе.
Давайте разбираться — расскажу вам об инструменте, который поможет выявлять приводящие к подобным ситуациям серые зоны, нестыковки, зависимости между подсистемами проекта; поможет всё это дело визуализировать и анализировать. Инструмент я назвала картой зависимостей.
