Недавно прочитал, что идеальная Agile-команда -- как повара в кафе: подберут ингредиенты, приготовят блюдо персонально для клиента. Самое вкусное для конкретного гостя.
Представляете такую команду в реальном ресторане?
Приходите на бизнес-ланч, -- меню нет, но есть на все готовая, молодая, незашоренная процессами команда. Кто-то из них вообще администратор зала, но решил попробовать себя в новой роли.
И вот вы начинаете говорить, что хотели бы: соляночку на первое, чтобы по всем правилам; ну и, раз сами спросили, на второе -- стейк и картофель с розмарином и соусом. Вроде бы не бюджет бизнес-ланча, но команда записывает, активно обсуждают, подсказывают. Кто-то уже побежал готовить -- круто!
1. Приносят первую порцию, небольшую и жидкую - MVP пока что. На тарелку решили не тратиться, ведь главное не в упаковке. Пей, значит, из ладошки!
2. Высказываете замечания: -- Вроде как картошку то стоило поварить.. -- На анчоусы (откуда?!) у вас аллергия, -- Посуду бы конечно добавить. Команда соглашается, но посуду решили добавить только в 3 спринт -- ресурсов не хватало и между идеей убрать анчоусы (да зачем вообще?!) и добавить посуду выбираете здоровье в ущерб брезгливости.
3. ...
4. ...
5. Итерации к 5 это уже будет солянка. В тарелке для супа. В чистой. Жаль только не доварили (спринта не хватило, затянули с нарезкой мяса). А как удалось объяснить, что 5 видов разного мяса в одном блюде и одинаково готового (тут промашка, обещали исправить) -- это не баг, а фича, -- это ваш, как заказчика, отдельный повод для гордости.
Но за 5 попыток наверно уже и наелся.
И ведь все как ты хотел! Что недоволен то?!
P.S. Agile — отличный подход. Но никакая методология не заменит здравого смысла и процесса, внутренней культуры. И ни одна методология не может применяться без изменений в любой сфере. Панацеи нет, придется додумывать!
Освойте инструменты креативных методологий для применения в проектах и рабочих задачах 💡
В новом бесплатном онлайн-курсе Креативное мышление в рабочих задачах рассказываем, как мыслить нестандартно, генерировать идеи и приземлять их в реальные IT-проекты.
Обучение проходит в формате интерактивной истории: в роли руководителя вы будете решать задачи команды. Пройдете путь преодоления трудностей в жизни команды от момента их выявления до решения. Приобретете навыки поиска корневой проблемы, фокусировки и использования креативных инструментов в рабочих задачах.
Кому будет полезен курс:
руководителям больших и маленьких команд, которые хотят освоить новые инструменты, чтобы улучшить рабочие процессы;
тем, кто хочет находить уникальные решения для развития проектов и получить практический опыт в их реализации;
Не умею работать с руководством: отстаивать границы впихуемости по порученным задачам.
Бизнес всегда будет желать напихать задач полную панамку.
Для такой панамки есть чёткий термин: бэклог. Этот бэклог всегда будет выше любых границ разумного, доброго и вечного. Одна из главных Твоих задач — чтобы он не был бессмысленным навалом хотелок, а стал приоритезированным и управляемым процессом.
Первым рубежом в обороне и систематизации задач будет оценка и группировка, — это Твоя ответственность. Важно понимать границу между оценкой (примерное представление о размере задачи) и декомпозицией (уже полноценная работа над ней). Процесс уточнения и детализации задач называют грумингом (или backlog refinement), а оценка задач проводится в рамках планирования или специальных встреч. Оценивают задачи в крокодилах, бананах, бутылках — или по классическим методам, например, покеру планирования с использованием последовательности Фибоначчи.
Зачем нужна такая грубая оценка? Чтобы бизнес мог сопоставить трудозатраты с потенциальной ценностью задачи. После этого он может применить фреймворки приоритезации, такие как MoSCoW, ICE, RICE и прочие, чтобы определить, что действительно нужно сделать в первую очередь.
Это позволяет избежать ситуации, когда разработчики бросаются на "огненные" задачи, которые в конечном счёте не приносят ценности, а реально важные вещи тонут в хаосе.
Держать бэклог в приоритезированном состоянии — это только полдела. Надо ещё понять, сколько задач команда может физически осилить. Надо понять широту размаха челюсти команды - velocity :) Для этого существует несколько способов оценки, включая оценку в человеко-часах, сторипоинтах, T-shirt sizes и другие.
Velocity — это не просто количество задач за спринт, а сумма их оценок (например, в сторипоинтах) за спринт, а совокупная способность команды выполнять задачи, включая багфиксы, тестирование, митинги и прочую обвязку. В реальности бОльшая часть времени может уходить на поддержку, рефакторинг и другие технические нужды. Поэтому рассчитывать, что 100% ресурсов пойдут на новые задачи, — полный фейл. Не попадись на эту удочку!
Как только команда поймёт своё реальное velocity, станет очевидно, что любая новая задача вытесняет другую. Кому станет очевидно? И команде, и бизнесу. И вот тут начинается меджик — бизнес перестаёт думать, что производительность команды резиновая.
Теперь можно чётко отстаивать границы впихуемости. Если бизнес диктует, что "завтра всё должно быть в 100 раз масштабируемо", CTO не кидается в бой с криками "сейчас запилим!", а чётко объясняет, какие ресурсы потребуются, какие риски возникнут и какие альтернативные варианты возможны. Главное — не просто говорить "нет", а предлагать реалистичные варианты решения проблемы.
Видишь? Мы отстроили процесс груминга, приоритезации, декомпозиции и оценки задач, взятие в работу только реального объёма бэклога спринта, и внезапно — у нас резко наладились отношения с бизнесом. Бизнес больше не ждёт чудес, команда работает без авралов, CTO перестаёт быть мальчиком на побегушках.
Важно с бизнесом говорить на его языке. Если разработчики постоянно в аврале, а менеджеры требуют новых фич, нужно донести, чем это обернётся:
Затраты на поддержку вырастут → Дороже обслуживать.
Продукт становится нестабильным → Клиенты уйдут к конкурентам.
Отток специалистов → Потери на найме и онбординге.
Поэтому CTO — это не просто технический управленец, а человек, который понимает, как встроить технический блок в коммерческую стратегию компании и поддерживать баланс между техническими возможностями и бизнес-целями.
Впихуемость — штука коварная, как чемодан без ручки: тащить тяжело, а бросить страшно. Отстаивай границы, управляй ожиданиями, приоритизируй с умом — и однажды бизнес сам предложит оставить пару задач в бэклоге "на потом".
П.С. объявляю конкурс на иллюстрацию к этому посту!
Если проводить аналогию с футболом, то можно сказать, что большинство крупных российских компаний играют с утяжелителями для ног. Если от них избавится – то тогда они побегут.
Agile нужно искать не Jira, а в рабочем окружении, которое не должно мешать постоянному самоусовершенствованию и экспериментам.
Нет таких проектов, которые должны собираться и тестироваться дольше часа, если только речь не идет о логическом синтезе или симуляции.
Время разработчика еще никогда не было настолько дороже, чем железо. Просто добавьте CPU и RAM. Amazon, Oracle, Google на полную катушку, используют свою же инфраструктуру для разработки. Это не «догфудинг» – скорее они пьют свое же собственное шампанское.
Быстрая итерация становится средой, в которой рождается (а не насаждается сверху) Agile.
Как повысить свою ценность в ИТ: в поиске новых компетенций. Новый выпуск Sravni Podcast
Поговорили с Левоном Гончаровым, экспертом в области Agile и построении команд. Обсудили, как разносторонность и насмотренность помогают в ИТ (и в целом в карьере), об успешном планировании, делегировании и самых ценных сегодня софт-скиллах.
Также в этом выпуске:
Как меняются требования к разработчикам
Везде ли эффективен SCRUM
Что важно знать о психологии при работе с командами
Путь от айтишника до владельца баскетбольного клуба и кинопродюсера
⚡️ 31 октября в 15:00 начнется вебинар «Нейросети без галлюцинаций: миф или реальность?». Недавно нейросети часто ошибались, создавая рисунки с аномалиями и документы с несуществующими законами. Сегодня результаты стали более корректными, однако галлюцинации продолжают встречаться. На вебинаре обсудим, как промпты могут снижать влияние галлюцинаций, добавлять качественные данные в контекст и организовывать автоматическую проверку результата.
👨🎓 Спикер:Брейман Александр— эксперт Учебного центра IBS, кандидат технических наук, доцент департамента программной инженерии ФКН ВШЭ.
⚡️ 1 ноябряв 15:00 стартует эфир«Оценка задач в Agile-проектах». Рассмотрим, как особенности Agile-проектов влияют на выбор инструментов оценки. Участники узнают о таких методах, как Story Points, Planning Poker и T-shirt Sizing, и их роли в управлении проектами.
👨🎓 Спикер: Политыко Сергей — архитектор информационных систем в IBS.
Регулярные внутренние воркшопы — важная часть непрерывного улучшения гаражистов. Так, недавно Саша Липин, лид одной из наших продуктовых команд, провел вебинар по методологии приоритезации задач WSJF (Weighted Shortest Job First — Сначала Более Ценная и Короткая Работа).
Если коротко — это модель, с помощью которой можно оценить задачи в бэклоге и расставить им приоритеты на спринт.
А если интересно разобраться и научиться, то листай карточки в посте. На них рассказали, по каким параметрам оценивать эпики/фичи/задачи и по какой формуле выявлять самые важные для бизнеса ;-)
Большая часть работы проджекта состоит в постановке задач и планировании загруженности команды. Кто-то прибегает к доске Канбан, кто-то выстраивает спринты. Но сегодня хотела бы обсудить 5S-метод по планированию задач. Этот метод помогает справиться с авралом, когда кажется, что дел навалилось куча, и за что хвататься в первую очередь – непонятно.
Sort – сортировать задачи по степени их важности для текущего проекта / спринта. Удалять (или переносить в архив) лишние задачи, оставляя только самое необходимое
Set in order – выстраивать задачи в приоритетном порядке.
Shine – прозвучит неожиданно в данном списке, хотя и очевидно: состояние рабочего места также влияет на производительность труда. Уберитесь на столе, чтобы ничто вас не отвлекало, а также разберите открытые вкладки в браузере (я точно этим грешу).
Standardize – разработайте алгоритм, который можно будет использовать для чек-листа по схожим спринтам / этапам проекта в дальнейшем.
Sustain – обсудите с командой алгоритм, отшлифуйте его. Внедрите и первое время контролируйте, что алгоритм используется всеми членами команды (включая вас).
Светская беседа в деловой переписке: вымысел или реальность?
Пока я проходила курс проджект-менеджмента от Google, сложнее всего мне давались задания по составлению деловых писем. Потому что американская деловая этика требует начинать любое письмо со Smalltalk. То есть обязательно нужно было спросить, как дела у всей команды, поздравить с тем, как продвигается проект, еще что-то про погоду. И только во втором абзаце можно было переходить к сути.
Кто вообще пишет такие письма?
Думала я и ошибалась. Поняла это, когда реально начала работать с зарубежными подрядчиками. Вот пример письма, присланного мужу перед рождественскими праздниками. Просто поздравления, уточнения, как дела.
Правда, мне все еще непривычно общаться на светские темы в то время, когда я хочу получить ответ на запрос, либо обсудить какую-то проблему. А ваше мнение: светские беседы в деловой переписке действительно создают дружелюбную и эффективную атмосферу?
Исследование показало, что процент отказов в Agile-проектах по разработке ПО на 268% выше. Оно было проведено по заказу консалтинговой компании Engprax. Неясно, откуда взялся именно такой процент.
Исследование проходило с 3 по 7 мая, в нём приняли участие 600 инженеров-программистов (250 в Великобритании и 350 в США). Выяснилось, что проекты с чёткими требованиями, задокументированными до начала разработки, имели на 97% больше шансов на успех. При этом введение спецификации до начала разработки может увеличить успешность реализации на 50%, а обеспечение точности требований — на 57%.
Авторы исследования утверждают, что исследованные ими Agile-проекты проваливались в 65% случаев. При этом они продвигают новую методологию Impact Engineering, которая якобы позволит сократить количество неудач в проектах в 6,5 раз (до 10%).
Автор книги об Impact Engineering Джунаде Али сказал: «Наше исследование показало, что, когда дело доходит до поставки высококачественного программного обеспечения вовремя и в рамках бюджета, важен надёжный процесс разработки требований и наличие психологически комфортных условий для обсуждения и решения проблем по мере их возникновения, а также нужно принять меры по предотвращению выгорания разработчиков».
Результаты исследования вызвали возмущение у сторонников Agile-подхода.
Story Map может стать более углубленной и проработанной, если добавить форматы "Jobs Story", "System Story", "Изменение", "Описание изобретения".
Jobs Story Когда <ситуация, контекст>, Я хочу <мотивация>, так что <ожидаемый результат> Пример: Когда сбоят системы отправки, выгружаю уведомление в формате XLS, чтобы отправить клиенту и регулятору вовремя
System Story Способ описания требований к разрабатываемому решению с точки зрения разработчиков. Формат напоминает User Story, только с фокусом на процессе взаимодействия пользователей с разрабатываемым решением: <Глагол действия> <Субъект>, чтобы <Кто> получил <Что> (или чтобы <Цель>). Пример: Установить уровень давления в системе в соответствии с типом пива, чтобы покупатель смог наполнил бутылку пива без пены за 30 секунд.
Изменение <вместо того, чтобы>, старый способ действия, <новый способ действия> Пример: Вместо бесконтрольных трат бюджета, выбирает на какие тематики его потратить
Описание изобретения <Полезное действие/ Отрицание нежелательного эффекта> в <контекст> за счёт <принцип работы> Пример: Быстрее нахожу какой статус выбрать в колонке-фильтре статусов за счёт вывода их в идеальном хронологической последовательности
Один из самых недооцененных компонентов в разработке это «Developer Tools» – различные инструменты и утилиты для разработки и тестирования. В каждой крупной компании есть своя «секретная формула крабсбургеров», просто некоторые компании охотнее делятся этими внутренними инструментами с сообществом. Клон AWS crosvm для ChromeOS в конечном итоге лег в основу Firecracker, который AWS использует для Lambda. Использование простой песочницы (на базе Linux KVM) позволяет сильно сэкономить время при проверке какой-то гипотезы или отладки ошибок.
Инженеры из RedHat пилят аналог crossvm для Linux и macOS.
Кстати в Boeing все хорошо: GitOps, Cloud-Native, Kubernetes, все процессы исключительно data-driven.
Есть одна общая черта, которая объединяет такие компании как Amazon, Apple, Tesla, Nvidia, Huawei – полная концентрация на клиенте и продуктах.
Эти компании не пытаются гнаться за трендами и не распыляют внимание на поиски эликсира молодости в DevRel или Agile.
У нас из крупных компаний, может быть только в Зеленом Банке понимают значение корпоративной культуры, дизайна и того что называется customer experience. И это только из-за руководства. Если там дать развернутся Товарищу Майору, то об амбициозных задачах и качестве, можно будет забыть.
OpenStack это скорее freemium нежели open-source. Идеальный вариант для вендоров и интеграторов.
Почти ничего не работает «из коробки». Просто установить, но очень «дорого» развивать и поддерживать.
Развитием проекта управляет несколько крупных компаний, а не сообщество разработчиков.
Интерес к проекту постепенно падает.
Кроме Mirantis у которых был офис в России, насколько я знаю, никто больше ничего для upstream OpenStack – не делал.
Для CoudStack нужно сделать нечто похожее на DevStack OpenStack – «shift-left» окружение и автоматизация для разработчиков, которая снизит порог вхождения в проект.
VMware – это тупик с точки зрения развития. Больше 65% компаний в Китае используют гибридное облако (в основном OpenStack). Энергетика, Финансы, Телеком и образовательная сфера в Китае почти полностью на OpenStack.
В России все еще много VMware и Microsoft – у нас было традиционно очень сильное лобби интеграторов и продажников. Потом многие из этих людей оказались на хороших должностях в корпорациях. Им не выгодных резкие изменения. В многих таких компаниях планируют мигрировать инфраструктуру из 2005 года в 2012. То есть мигрировать на технологический стек чуть-чуть менее устаревший.
Микросервисы – это антипаттерн. Для микросервисов нужны микропрограммисты.
Возможно через несколько лет ИИ освободит человечество от необходимости заниматься рутинной работой, например писать код, но в 2023 Amazon AWS это: просто Java, Linux, QEMU-KVM, внутренний тулинг и кастомное «железо» (SmartNIC, свичи, СХД); просто Сервис-ориентированная архитектура (SOA), просто несколько тысяч программистов и отлична организация труда.
Без динамической инфраструктуры (так называемое облако) не возможно представить себе широкое проникновение ИИ. Без нескольких ключевых проектов с открытым исходным кодом не возможно представить себе современную инфраструктуру on-prem и «в облаке».
Большая часть из этих проектов решает какую-то, определенную, локальную задачу, создавая при этом проблемы, для тех кому «посчастливилось» поддерживать этот стек, на годы вперед.
Вклад российских компаний в эту экосистему по сравнению с вложенным капиталом – на уровне погрешности измерения.
Накопленные годами экспертные знания и опыт вымываются с каждой новой волной хайпа.
А в это время OpenCV от которого зависит несколько десятков многомиллиардных корпораций и дроны, не может собрать 500 000$ на развитие. Мы слишком заняты – нужно внедрять GitOps и микросервисы.
В этом бизнесе мы уже не участвуем – нужно сконцентрироваться на важном.
