Привет, Хабр!
В свободное от основной работы время за последние 4 месяца я разработал инструмент для управления продуктами без использования принципов Agile и Kanban. Вместо доски и тикетов разработка ведется вокруг фич и их итераций.
Мне очень интересно ваше мнение. Изначально я сделал продукт платным, но после того, как мне в клочья слили карму на Реддите за попытку прыгнуть на Канбан, я решил, что метод слишком радикальный. Поэтому я сделал сервис бесплатным, чтобы люди могли посмотреть и высказать свое мнение.
В разработке я руководствовался принципом бритвы Оккама, и отсек все, что могло бы отвлекать разработчика непосредственно от разработки. Поэтому в этом инструменте нет тикетов, эпиков, тасок, спринтов и так далее. Только фичи и их итерации.
Я также ввожу понятие технического урона вместо технического долга в качестве эксперимента, возможно, вам будет интересно.
Посмотреть можно здесь (только на английском): https://www.swinlanes.com, в том числе там есть ссылка на Handbook, в котором объясняется новый подход. Веб-приложение не заработает на телефоне, нужно будет зайти с десктопа.
Буду ждать вашего мнения.
Комментарии (17)
rootdefault
08.10.2024 20:51Бегло посмотрел хэндбук и со своей колокольни скажу 2 вещи:
В каждом разделе обязательно встречаются слова «канбан» или «аджайл». Вам не кажется что стоит заняться описанием методологии, а не постоянным сравнением?
Из предыдущего пункта вытекает второй - краткого и понятного описания я не увидел (например алгоритма краткого или просто короткого в один абзац описания), вместо этого текст, которому не хватает той самой бритвы Оккама ;)
aerlinn13 Автор
08.10.2024 20:51По первому пункту две причины:
1) Я сталкиваюсь с тем, что мало кто понимает со слов, в чем заключается идея, поэтому сравнение с доминирующим инструментом мне показалось наиболее эффективной стратегией.
2) ядерная аудитория проекта, по крайней мере поначалу, будет состоять из тех, кого не устраивает канбан и они хотят попробовать что-то новое. Поэтому это также показалось мне потенциально эффективным.По второму пункту: описание проекта в одном абзаце:
Swinlanes is an iterative product management tool without any attached methodology — it doesn't uphold any specific principles or values beyond enabling teams delivering customer value in a sustainable way. It's constructed like a Russian doll, mirroring the way developers, designers, and product managers actually build products. Individual contributors work within developer lanes to deliver feature iterations, which together constitute features. The main idea revolves around the triad of developer lane, feature iteration, and feature.
Находится тут: https://handbook.swinlanes.com/main-concepts/swinlanes
Спасибо за Ваше мнение!
asantat
08.10.2024 20:51Это очень не похоже на описание принципов работы. Нет ни примера, ни понятного алгоритма, ни соглашения о терминологии (должно быть понятно, в каком смысле использованы термины). Если этого не будет в одном-двух абзацах, то и понятно ничего не будет читателю. Читатель изначально должен получить представление, чтобы при желании нанизать на него подробности из пособия. Никто не обязан читать Ваше пособие целиком, пытаясь воссоздать Ваши мысли и понять, что же Вы имели в виду. "Ментальный реверс-инжиниринг" довольно трудозатратен.
aerlinn13 Автор
08.10.2024 20:51спасибо за отзыв. Я подумаю, как это выразить, чтобы было проще визуализировать процесс. Благодарю.
ganqqwerty
08.10.2024 20:51По-моему, лучшим способом донести, про что проект было бы показать видео того как команда заполняет борду, таскает... простите, тыкает таски и как волшебно это все преображает.
aerlinn13 Автор
08.10.2024 20:51да, я оборудую демо продукт и буду записывать видео. На сайте очень базовое демо есть.
lovelymasculinity
08.10.2024 20:51На любителя, но начало хорошее.
Несколько вопросов/предложений:
Можно ли менеджить стейджи?
Визуально стейджи выглядят непонятно так как с первого взгляда отсутствуют описания стейджев их статус. Дальтоникам возможно будет сложно ориентироваться во всем этом.
Для переключения стейджа будет удобнее использовать дропдаун, а не щелкать на квадратик и ждать пока запрос выполнится.
Можно ли делать саб итерации, к примеру разбить итерацию на несколько задач?
Хорошо бы все таки иметь какую то доску с группировкой итераций по стейджам и их статусам, чтобы визуально можно было понять какие итерации надо тестировать, а какие разрабатывать.
Добавьте фильтры (по разработчикам и статусам) в ваши доски.
Как заасайнить фичу тестировщику и визуально понять кто из заасайненых людей девелопер, а кто тестировщик?
П.С.
У вас прикольный британско-русский акцент.
aerlinn13 Автор
08.10.2024 20:51Благодарю за отзыв!
Можно ли менеджить стейджи?
Прямо сейчас это можно делать только при создании воркспейса. В перспективе их можно будет менеджить на уровне продукта (квази-эквивалент доски в канбане).
Визуально стейджи выглядят непонятно так как с первого взгляда отсутствуют описания стейджев их статус.
Расчет на то, что позиции стейджей одинаковы и человек привыкает к их расположению. При наведении на стейдж появляется тултип с описанием стейджа и заассайненным человеком. Про дальтоников проверю. Но пока ресурса на accessibility к сожалению нет.Можно ли делать саб итерации, к примеру разбить итерацию на несколько задач?
пока такого плана нет, но я подумаю. Смысл в том, что внешним стейкхолдерам не должны быть важны таски, это уже микроменеджмент. А зачем исполнителю самому таски, если он сам пишет код и знает, что было уже сделано на бранче?Хорошо бы все таки иметь какую то доску с группировкой итераций по стейджам и их статусам, чтобы визуально можно было понять какие итерации надо тестировать, а какие разрабатывать.
+
Добавьте фильтры (по разработчикам и статусам) в ваши доски.
Концепта кастомной доски в Swinlanes нет и не будет. Вместо досок тут продукты. Это сделано для того, чтобы менеджеры не создавали кучу разных досок с разными фильтрами и так далее. Это микроменеджмент. Один продукт отображается в Swinlanes только однажды. Что касается средства фильтрации по разработчикам и статусам - что-то для решения этой задачи будет, но я еще думаю. Возможно, решение будет нетривиальным.
Как заасайнить фичу тестировщику и визуально понять кто из заасайненых людей девелопер, а кто тестировщик?Ассайн всех людей, задействованных на итерации, происходит при создании итерации. На экране фичи разрабы ассайнятся на карточке итерации слева, а на остальные стейджи - в дропдаунах справа вверху. При необходимости в процессе людей можно переассайнить, но ранний ассайн позволяет всем планировать свое время. Но опять же, и разрабы, и тестировщики ассайнятся на итерацию одновременно. Когда разработчик закрывает свой стейдж (с мигающего зеленого на просто зеленый), тогда к работе приступает тестировщик.
П.С. Спасибо! 5.5 лет в Англии имеют свои последствия.
П.П.С. Приглашаю вас в телеграм канал продукта, возможно вам будет интересно t.me/swinlanes
Andrey-Kotov
08.10.2024 20:51Название кликбейтное конечно, но осилил себя и почитал дальше. Я продакт, и у меня такие вопросы возникли:
Для какого типа проектов/продуктов/этапов/команд/компаний ваш фреймворк подходит больше для каких не подходит? Глупо говорить что Agile не оч, когда он совершенен (в определённых условиях). А так я сам упирался в границы Agile, скарма, канбана и ищу решения именно для таких ситуаций.
-
Как ваш фреймворк выглядит в контексте компании, а не программиста? Куда ложится планирование, бюджетирование, оценка, поддержка, маркетинг, клиенты, дизайны, тестирование и т.п. Agile затрагивает практически всю компанию.
Фичеориентированную команду я уже сам организовывал, когда неизвестность рынка была минимизирована почти в ноль, и фокус был на долгосрочном планировании бэклога, это было обусловлено продуктом, рынком, фин моделью и типом инвестиций. В иной комбинации условий это не было бы эффективным. Просто поменяв частоту раундов и уже бы зашёл водопад (с которым вы почему-то не сравниваетесь).
aerlinn13 Автор
08.10.2024 20:51Спасибо, что прочитали.
Это не фреймворк, а инструмент (веб-сервис) и метод работы с ним (не методология, это существенно). Подходит для продуктовой работы на любых этапах в организациях, где есть команды с количеством разработчиком от 3 и более - по моему мнению, если их меньше, процесс в принципе особо не нужен. Поэтому я не ожидаю, что метод подойдет для проектной работы, при разработке метода я на это не ориентировался - но как будет в реальной жизни если кто-то попробует, я не знаю.
Я придерживаюсь позиции, что продуктовой разработке нужен только метод координации SDLC и накопления спецификаций и базы знаний (документации). Принципы, ценности и философия в этом процессе не нужны, и часто могут быть использованы недобросовестными менеджерами для давления на разработчиков.
Я не думаю, что можно говорить, что что-то совершенно, особенно с учетом того, что Agile это доминирующая методология / философия, которая так или иначе используется всей современной продуктовой разработкой. Сейчас есть выбор либо мало аджайла (условный канбан) или много аджайла (Скрам, SAFe). Мой эксперимент - это попытка дать альтернативу.
2. Куда ложится планирование, бюджетирование, оценка, поддержка, маркетинг, клиенты, дизайны, тестирование и т.п.
Метод Swinlanes является узконаправленным и заточен исключительно под продуктовую разработку. Планирование, бюджетирование, дизайны и тестирование в процесс разработки входят и будут в будущем обеспечены функционалом. Поддержка, маркетинг, клиенты - непосредственно в продуктовую разработку не входят, поэтому Swinlanes соответствующего функционала иметь не будет. Оценка (estimation) выражается в соглашении о дедлайне между лидом итерации фичи и стейкхолдером, стори поинты не применяются. Что касается маркетинга и клиентов - я не уверен, как именно Agile там применяется, я не специалист. Я подозреваю, что Agile в этих сферах можно свести просто к понятию клиентоориентированности.
Я не сравниваю метод с Waterfall по той простой причине, что в большинстве компаний реальный Waterfall воплотить трудно, и сейчас он применяется редко. Лично я не сталкивался. Swinlanes – наследник итеративного подхода, который появился еще в 60-х годах. Agile методологии взяли его на вооружение и добавили очень много лишнего. Я бы хотел вернуть итеративный подход к истокам, отрезав это лишнее.
Именно поэтому я делаю оговорку, что метод предназначен для продуктовой разработки, потому что понимаю, что фичеориентированная работа может быть возможна только при возможности более-менее длительного планирования. Однако непосредственная цель веб-сервиса - уменьшить временные затраты на организацию эффективного взаимодействия, и думаю, что это может пригодиться в любой разработке.
9982th
Мое мнение: статья не должна быть настолько короткой, чтобы целиком вмещаться до ката. Если бы вы перевели и слегка адаптировали первые пару глав этого вашего Handbook'a, то выглядело бы гораздо лучше и можно было бы ожидать дискуссии и обратной связи, а сейчас статья вызывает ощущение рекламы из корпоблога.
aerlinn13 Автор
учту на будущее, большое спасибо!