Agile *

Скрам  –  это легкая методология, которая помогает людям, командам и организациям создавать ценности. Это простая и намеренно неполная система, которая позволяет пользователям полностью раскрыть свой потенциал и работать в режиме Agile. 

В центре внимания Скрама находятся люди. Скрам организует проекты, используя кросс-функциональные команды, каждая из которых обладает всеми возможностями, необходимыми для реализации функциональности от идеи до конечной реализации. 

Итак, погружайтесь и узнайте все об основных принципах Скрама... и все это менее чем за 10 минут.

Scrum Alliance

А с использованием методов линейного программирования.

Сталкивались ли вы с понятием линейного программирования? А его применением на практике? В университете мы изучаем разные разделы математики, нам рассказывают про математические модели и методы, однако вопросу их практического применения часто уделяется недостаточно внимания.

В статье я поделюсь основными тезисами моего доклада, представленного на конференции Analyst Days #16. В нём я постарался показать, как методы линейного программирования могут быть применены в работе команды, живущей спринтами. Под катом вас ждет альтернативный взгляд на планирование спринта.

Стартапы в последние пару лет, мягко говоря, оказались между Сциллой и Харибдой. Многие бизнесы начали сжиматься (а ЦБ стран жестить), а венчурные фонды внезапно стали очень бережливыми. Как поступают стартапы в США в эпоху неопределенности? Правильно, сразу сокращают персонал и закрываются. Сегодня все уже забыли оптимизм постковидного 2021 года. 

Последние 10 лет я плотно работаю со стартапами, и рынок буквально кричит: "хватит выбрасывать на рынок тонны нового функционала, займитесь уже тем, что у вас получается хорошо”. 

В рамках этого сотрудничества мы создали простую табличку, чтобы проанализировать как чувствуют себя новые фичи и как много мы в них инвестировали. В интернете очень много комплексных ROI-моделей, но простота этой таблицы в том, что ее данных достаточно чтобы начать двигаться в продуктовом направлении.

Что такое Scrum?

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 месяца, а фича так и не появляется на проде. Более того, команда к ней так и не приступала. 

Почему? 

– вместо суперзадачи команда занимается какой-то ерундой — проблемы с приоритизацией;

– команда не поняла, что фича принесёт реальные деньги и насколько это важно — сложности с коммуникацией с заказчиком;

– недостаточно описаны требования, команда отфильтровала задачу как «не готовую к взятию в работу» — продакт не доработал;

– задача потерялась в недрах бэклога — продакт проглядел.

Все эти варианты говорят нам о наличии рассинхрона команд, ожиданий и реальности, рассинхрона подсистем относительно общего процесса, вследствие этого команда(ы) делает «не то» «не так» или не делает вовсе.

Давайте разбираться — расскажу вам об инструменте, который поможет выявлять приводящие к подобным ситуациям серые зоны, нестыковки, зависимости между подсистемами проекта; поможет всё это дело визуализировать и анализировать. Инструмент я назвала картой зависимостей.

Всем привет! Меня зовут Анна Мозер, я работаю тимлидом системных аналитиков в X5 Tech. Мне удалось поработать и в корпорации, и в стартапе, и в качестве фриланс Delivery Manager на этапе запуска стартап команды. 

Системный аналитик находится в центре между бизнесом и командой разработки и часто видит весь процесс целиком: от выявления требований до доставки реализации пользователю. Именно поэтому я всегда интересовалась тем, как устроены процессы в командах и принимала активное участие в их изучении и выстраивании.

Периодически мои друзья, знакомые, коллеги в кулуарах делятся тем, что процессы в их командах напоминают хаос. Они говорят: "Мы только и занимаемся тем, что тушим пожары" или "Я не знаю, чем буду заниматься на следующей неделе". И моё самое любимое: "Мы начали делать задачу, а на полпути потребности поменялись, и теперь нужно совсем другое. Но это же Agile…".

Хотя многие менеджеры объясняют это стремлением к гибкости и следованием Agile-философии, чаще всего такие признаки указывают на неправильное понимание и применение гибких методологий. Цель моей статьи – подсветить типичные ошибки менеджмента команды и рассказать об индикаторах того самого "недопонятого" Agile (я насчитала таких 10 штук). 

Не знаю, как в других странах, а у нас любят увлекаться идеей использовать какой-то, довольно узкий, инструмент, как панацею.

Получилось забить гвоздь молотком – получилось. Давайте попробуем с помощью молотка почистить фарфоровую посуду от налета. Ну очевидно же!

Не избежал этой участи и пресловутый Agile. Так называемые гибкие методологии разработки. Сработало в узком сегменте простых IT проектов – давайте везде его применим! В промышленности, в обучении – всюду, куда фантазии хватит его вставить.

А по факту – любой инструмент имеет ограниченную среду применения, и гибкие методологии – не исключение.

Мультизадачность и кроссплатформенность – два бича большинства областей IT. Вот и нам в отделе заказной и продуктовой разработки пришлось столкнуться с одновременным ведением нескольких потоков разработки на международном проекте, где то и дело было необходимо отлавливать зависимости и синхронизировать процессы.

Забегая вперед, могу сказать, что в итоге мы внедрили платформу в 18 странах присутствия заказчика, у нас на поддержке было около 10 тысяч касс в 379 магазинах. Мы выпустили 39 релизов, 82 патча и 73 хотфикса. И во всем этом нам очень помогал SAFe. Почему мы выбрали именно этот фреймворк, как внедряли в процесс международного проекта, что мы из него вынесли и при чем тут поезда, решил рассказать в этой статье.

Привет, меня зовут Дима, я ведущий ИТ бизнес-партнёр в Петрович-Тех. Сегодня расскажу вам историю о том, как мы запускали продуктовый подход в инхаус-разработке.

В 2020 году задачи бизнеса сыпались в «общий котел», коллеги из бизнеса буквально бились за ИТ-ресурсы по принципу «чьё важнее». Команды разработки формировались по принципу «кто делал что-то похожее», оценки делались примерные, с умножением на «пи» или на «е».

Эта статья о том, как мы разбирали 1С УТ на продукты и сервисы, запускали “почти что Scrum-подход с элементами Kanban”, учились отвечать на вопросы “сколько ждать хотя бы примерно?” и “когда уже будет готово?” через метрики и перцентили – и как в конечном итоге благодаря продуктовому подходу нам удалось удвоить пропускную способность команд.

Преодоление вызовов и максимизация выгод: история разработчика с SAFe

В современной сфере программной разработки методология SAFe (Scaled Agile Framework) выросла в нечто большее, чем просто структура. Она стала ориентиром для компаний, которые стремятся улучшить свои процессы и достичь масштабируемости. В этой статье я расскажу о нашем опыте перехода на SAFe и о том, как этот фреймворк изменил нашу парадигму разработки программного обеспечения для сетевого оборудования. Я, простой разработчик, поделюсь с вами историей, как SAFe повлиял на нашу компанию и почему я уверен в его огромном потенциале.