Agile *

Около года назад мы в команде всерьез задумались о пересмотре сроков среднесрочного планирования. И всему виной наш любимый производственный календарь РФ. Но начнем издалека.

Традиционно мы привыкли встречаться раз в три месяца, квартал, ставить цели, возвращаться через квартал подводить итоги, ставить новые цели и так до бесконечности (хочется верить).

Но 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 повлиял на нашу компанию и почему я уверен в его огромном потенциале.

Всем привет! Меня зовут Дмитрий, я более 7 лет занимаюсь трансформациями компаний и построением процессов в области создания продуктов и управления проектами с помощью Гибких подходов управления Agile. Недавно меня пригласили в один развивающийся американский стартап, который делает SAAS B2B продукт.

Если вы знакомы с подходом к документированию, предложенным Саймоном Брауном, вы могли заинтересоваться им, но, возможно, задавались вопросом о его реализации. Этот репозиторий заполняет пробел, представляя конкретный шаблон реализации подхода, который состоящего из:

1. Модели архитектуры программного обеспечения как код, построенные с использованием Structurizr Lite
2. Документация, созданная с помощью шаблона Arc42
3. Журнал решений, созданный с помощью ADR Tools

Предполагается хранение этой документации в репозитории и работа с ней так же, как и с кодом.

"Преимущество Scrum-команд — способность к обучению", — часто ли слышали такое? Звучит как суперсила из комиксов Marvel! Только представьте, вместо "человек-паук" у нас "человек-скрам", который вместо паутин метает стики-ноты и вместо борьбы с преступностью учит нерадивых разработчиков, не желающих понимать скрам-магию!

А вот так выглядит обучение в повседневной жизни: вы купили мебель с инструкцией для сборки. Сначала вы думаете: "О, это будет легко", а затем проводите всю ночь, пытаясь понять, куда идет этот чертов шуруп! Но в конце вы учитесь и даже начинаете получать удовольствие от процесса сборки, а следующий шкаф собираете быстрее.

Любые аналогии условны, давайте разберёмся, как обстоят дела в реальной организации, которая выбрала Agile с целью получить преимущество от супер-способности к обучению. В общем, друзья, я хочу поделиться с вами новым подходом, основанным на неопределенности в требованиях и навыках, к которому я пришел, через свой опыт запуска новых команд.

Всем привет, я Карим Аминов, Head of QA в компании Test IT. Компания является частью одного холдинга Yoonion, который объединяет под общим брендом цифровые продукты для удобства работы бизнеса. Наши команды разработали два известных инструмента - это Test IT и TeamStorm.

Цель моей статьи — помочь наладить вывод релизов качественно и в срок всем, кто так или иначе связан с обеспечением качества на проекте. Также я надеюсь, что мой рассказ найдет отклик у всех, кто занимается релизами. 

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

Scrum — это гибкий подход к управлению проектами, который в последнее время приобрел большую популярность в области разработки программного обеспечения. Позволяя командам работать над сложными задачами коллективно, Scrum выделяется уникальной структурой и упором на постоянное обучение и совершенствование.

В нашем новом интервью для блога Comindware на Habr.com, Алина Балашова, опытный Scrum-мастер из Comindware, раскрывает детали своего опыта.

Привет! СИБУР — не просто одна из крупнейших нефтехимических компаний мира, это в принципе довольно большая компания с кучей разных процессов, множеством людей (как штатных специалистов, так и постоянных внешних подрядчиков). А еще — с большим количеством разных продуктовых команд, которые трансформируются, масштабируются, обмениваются разработчиками и аналитиками, в общем, всё это весьма динамично, быстро и всегда затачивается под конкретную задачу.

В этом посте мы хотим побольше рассказать о том, как у нас всё устроено. Команд у нас много, как и используемых или стеков, так что говорить будет и верхнеуровнево, и на примере конкретной команды CRM.

Потому что CRM – это «скелет» сквозного процесса продажи и обслуживания клиентов. И там, как в едином котле смешиваются воедино и сложные задачи для разработчиков (попробуй всё интегрируй, как надо, и сделай так, чтобы работало), и для аналитиков, а сколько тут чисто бизнесовой части и тонкостей в процессах — вообще туши свет.

Под катом:

• как устроено взаимодействие между командами;

• что ждет новичка, пришедшего работать в СИБУР;

• какие есть пути развития карьеры в целом и своих навыков в частности;

• почему круто, когда разраб может просто приехать на завод и лично посмотреть, кто пользуется его продуктом;

• почему у тестировщика в целях вполне себе может быть конверсия интернет-магазина (и это нормально);

• почему B2B-рынок интереснее, чем пресытившийся B2C.

Слово «ретроспектива» произошло от латинского “retro” – «обратно, назад» и “spectare” – «смотреть, созерцать», то есть буквально оно означает «Взгляд в прошлое». 

Ретроспектива в командах разработки не новое явление. После нее в идеальном мире следующие этапы работы точно будут лучше! Правда, правда. 

Всем привет! Меня зовут Саша Комбаров, я исполнительный директор в Amiga. Мой опыт в заказной разработке более 8 лет. Делюсь самым полезным :) В материале расскажу, что такое ретро, зачем и как проводить ретроспективу и как мы проводим собрания по методу «Четырех Ч». А также расскажу, как мы внедрили ретро в отделы компании: управление, дизайн, маркетинг, продажи, тестирование и аналитика. И что это дало :)

«Архитектура с эволюционным развитием поддерживает управляемые, постепенные и последовательные изменения сразу в нескольких направлениях».

Из книги «Эволюционная архитектура. Поддержка непрерывных изменений»

Более 5 лет мы развиваем бесплатное мобильное приложение для работы с товарами. Проект растет и стабильно приносит прибыль, на прод поставляются новые фичи. Но мы заметили, что ежемесячно команда не успевала выполнить 100% из запланированного пула работ. Каждый раз, как по замкнутому кругу, мы пытались ответить на вопрос: «Как так получилось и когда, что мы опять одну фичу не допилили?». Но все встало на свои места, когда мы внедрили процесс капасити в работу и прозрачность загрузки команды стала явной.

Я менеджер проектов в SimbirSoft Светлана, и в этой статье поделюсь опытом подсчета капасити команды и предложу свой вариант работающей формулы, опираясь на свой опыт.

Все, кто занимается разработкой программного обеспечения, так или иначе слышали про Kanban или применяли его в работе. Это — инструмент методологии Agile, который подходит для своего круга задач.

Но Kanban придумали совсем не разработчики: еще 60 лет назад его внедрила компания Toyota на своем производстве. И он стал частью общей философии компании, которая получила название Lean Manufacturing — «бережливое производство». Успехи Toyota и ее подхода очевидны: на 2022 год компания занимает первое место в мире по числу проданных автомобилей — 10,48 млн, опережая Volkswagen AG на 2,22 млн штук.

И между производством автомобилей и разработкой ПО напрашивается параллель. Давайте попробуем разобраться, в чем же особенности TPS (Toyota Production System), откуда все это появилось и как применяется в современной разработке.

Всем привет, меня зовут Андрей Гирин, и я agile-коуч в РТЛабс. Десять лет назад я был руководителем проекта с небольшой командой, а сейчас помогаю строить команды другим.

Недавно я был с воркшопом, посвящённым star map, на профессиональной конференции для тимлидов Saint TeamLead Conf, о чём моя коллега Екатерина не так давно писала в посте.

Эта небольшая статья о том, как и почему эта идея вообще появилась.

Австралийский Atlassian, разработчик Trello и Jira, вынес последнее предупреждение: «Осталось 30 дней». Потом все данные пользователей из России и Беларуси будут удалены. Многие мои знакомые до последнего надеялись, что этого не случится, а сейчас срочно ищут, куда переехать. 

Я тестирую разные системы управления проектами 4 года. Последний год российские сервисы растут как грибы после дождя. Лучше выбирать те, что на рынке давно. Вот 5 проверенных вариантов, советую попробовать их в первую очередь. В конце – сравнительная таблица.