Agile *

В википедиях, читаю:

ITSM (IT Service Management, управление ИТ-услугами) — подход к управлению и организации ИТ-услуг, направленный на удовлетворение потребностей бизнеса. Управление ИТ-услугами реализуется поставщиками ИТ-услуг путём использования оптимального сочетания людей, процессов и информационных технологий.

CI/CD (CICD) — методология разработки программного обеспечения, представляющая собой комбинацию непрерывной интеграции (continuous integration) и непрерывного развертывания (continuous delivery, или continuous deployment)

Если рассматривать "IT" как набор услуг (под управлением ITSM), не вступает ли это в противоречие с "CI/CD" (а может и с devops в целом)?

Здесь, я не имею в виду ситуацию "если родина прикажет" или "бизнес так решил", а в принципе.

Допустим, клиент заказывает услугу. Услуга имеет описание, а также, возможно, набор регламентов по использованию. Таким образом, клиент точно знает, за что платит, предполагая, что услуга имеет законченный вид и изменениям не подлежит, иначе, на каждом шаге, потребуется перерасчет, а это дополнительные временные и, возможно, финансовые издержки.

С точки зрения клиентоориентированности, в первом приближении, ITSM выглядит привлекательнее.

Но, у поставщика услуг, внезапно, CI/CD и другие "гибкие методологии разработки" (ну, допустим), а это означает постоянные изменения, как в наборе функционала (в составе предоставляемой услуги), так и в инфраструктуре проектов. Кроме того, по причине применяемых принципов, возможны разнообразные сдвиги сроков, что тоже не добавляет клиенту уверенности в завтрашнем дне.

Как потребителю услуг (клиенту), в этой ситуации, когда "всё течёт - всё меняется", быть уверенным, что он оплачивает и получает именно то, что требуется, да ещё и в полном объёме?

Выглядит так, что всё должно сойтись где-то на стыке одного и другого, но остается вопрос: а можно ли всё это красиво подружить?

По этой теме, я уже прочёл одну-две статьи, где-то на просторах интернета, но ссылки на них оставлять здесь как-то стыдно: они не отвечают на поставленные вопросы, просто постулируя - "да, можно"/"нет, не противоречит" или повествуют о том, как с одного перейти на другое, что, мягко говоря, обескураживает.

Здесь кто-нибудь есть?

Давненько не было постов! Теперь посты будут выходить намного чаще, поэтому ждите интересный контент! Сегодня хочу с Вами поделиться своими наблюдениями по самым распространенным страхам при входе или же в начале карьеры в IT, а также конечно же расскажу, как с ними бороться!

Поехали!

Большие деньги - большая ответственность, я еще немного поучусь и можно ходить на собеседования

Самое частое заблуждение и страх - это то, что я не до конца изучил материал и мне рано идти на собеседования. IT действительно кажется сложной сферой, особенно на старте. Куча непонятных терминов, новые технологии, быстрая смена трендов. Главное — не пытаться сразу охватить всё. Дроби путь на маленькие шаги: сначала разберись в основах, потом усложняй задачи.

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

Убейте в себе внутреннего "отличника", который хочет всё идеально знать. Начните действовать как можно раньше, ведь главный наш ресурс - это время. Если не начнете ходить по собеседованиям сейчас, то потом может стать поздно!

Я слишком стар/молод/у меня нет профильного образования

Это миф. В IT реально можно войти в любом возрасте и с любым бэкграундом. Большинство компаний смотрит на твои навыки и то, как ты решаешь задачи, а не на диплом. Например у меня еще ни разу не спрашивали про мой диплом и про моё образование, но при этом огромное кол-во людей верит в то, что реально нужен крутой бэкграунд, а не опыт. Важно показывать интерес к профессии, прокачивать навык прохождения собеседований, учиться продавать себя на рынке труда и тогда у Вас всё получится! Как говорил Олег Тинькофф: "Продай свои мозги дорого". Это очень хорошо описывает в целом текущее состояние рынка.

Я буду выглядеть глупо среди опытных коллег Это нормально — не знать и ошибаться, особенно в начале. Важно не бояться задавать вопросы. В IT очень развита культура поддержки: тебе скорее помогут, чем осудят. Воспринимай каждую ошибку как точку роста, а не как провал. Ведь наш опыт - это сумма всех наших ошибок. Думаете, что какой-то сеньор никогда не допускал ошибок?

Я не найду работу без опыта От каждого второго человека слышу это. Мол я не могу найти работу без опыта, всё дело в опыте! А потом я открываю его резюме и вижу, что там полная каша и оказывается, что дело не в опыте, а в резюме или же в чём-то другом. Не бойтесь искать любую возможность попробовать реальные проекты. На старте важно показывать свою мотивацию и учиться командной работе. Не стесняйся писать в компании напрямую, предлагать свою помощь за отзыв или за опыт — так много кто стартует.

Теперь дам общие советы, которые подойдут под любой Ваш страх. Но помните, что я Вам даю всего лишь отмычки, а Вы их уже сами подбираете под Ваши "проблемные" двери:

• Разделяй путь на маленькие задачи и радуйся каждому шагу.

• Найди ментора, чтобы не оставаться один на один с вопросами.

• Веди дневник успехов — записывай даже маленькие победы.

• Не сравнивай свой путь с другими, особенно в соцсетях — у каждого свой старт и темп.

• Признай: страх — это нормально. Его испытывали все, кто сегодня работает в IT.

Понравился пост? Тогда переходите ко мне в телеграмм канал, там находится много полезного материала, для входа в IT!

🔥 Agile умирает - и его убийца уже здесь. Имя ему - искусственный интеллект!
Заметили ли вы что многие Agile визионеры активно перетекают в сторону AI-консалтинга?

Agile обещал гибкость и гуманистический фокус. Однако новые роли, жесткий спуск сверху, трансформации и бесконечный встречи превратили его в бюрократию новой волны Теперь же “искусственный интеллект” врывается в менеджмент и ставит жирную точку: куда интереснее цифровые следы людей и возможности автоматизации и прогнозирования, а не работа в ценностной модели и адаптивности. Аджайл перестал справляться с изменениями и запросами на больший контроль поставляемого результата

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

Может, Agile - это как Nokia в мире проектного менеджмента? Собственно у Nokia был замечательный Agile

Теперь думаю: это трагедия или естественный отбор? Agile ещё жив или уже пора хоронить?

Недавно прочитал, что идеальная 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 — это не просто технический управленец, а человек, который понимает, как встроить технический блок в коммерческую стратегию компании и поддерживать баланс между техническими возможностями и бизнес-целями.

Впихуемость — штука коварная, как чемодан без ручки: тащить тяжело, а бросить страшно. Отстаивай границы, управляй ожиданиями, приоритизируй с умом — и однажды бизнес сам предложит оставить пару задач в бэклоге "на потом".

П.С. объявляю конкурс на иллюстрацию к этому посту!

Не хотелось бы попасть в зону стресса. А в зону паники - тем более. Поэтому закладывайте время достаточно на случай, если всё пойдёт не по плану.

Как повысить свою ценность в ИТ: в поиске новых компетенций. Новый выпуск Sravni Podcast

Поговорили с Левоном Гончаровым, экспертом в области Agile и построении команд. Обсудили, как разносторонность и насмотренность помогают в ИТ (и в целом в карьере), об успешном планировании, делегировании и самых ценных сегодня софт-скиллах.

Также в этом выпуске:

• Как меняются требования к разработчикам

• Везде ли эффективен SCRUM

• Что важно знать о психологии при работе с командами

• Путь от айтишника до владельца баскетбольного клуба и кинопродюсера

Подкаст доступен здесь:

• YouTube

• RUTUBE

• Яндекс Музыка

Оперативно узнавать о наших новых подкастах, докладах, лекциях и других полезных ИТ-материалах можно в тг-канале Sravni Tech.

На этой неделе у нас два отличных вебинара:

⚡️ 31 октября в 15:00 начнется вебинар «Нейросети без галлюцинаций: миф или реальность?». Недавно нейросети часто ошибались, создавая рисунки с аномалиями и  документы с несуществующими законами. Сегодня результаты стали более корректными, однако галлюцинации продолжают встречаться. На вебинаре обсудим, как промпты могут снижать влияние галлюцинаций, добавлять качественные данные в контекст и организовывать автоматическую проверку результата.

👨‍🎓 Спикер: Брейман Александр — эксперт Учебного центра IBS, кандидат технических наук, доцент департамента программной инженерии ФКН ВШЭ.

✍️ Записаться

⚡️ 1 ноября в 15:00 стартует эфир «Оценка задач в Agile-проектах». Рассмотрим, как особенности Agile-проектов влияют на выбор инструментов оценки. Участники узнают о таких методах, как Story Points, Planning Poker и T-shirt Sizing, и их роли в управлении проектами.

👨‍🎓 Спикер: Политыко Сергей — архитектор информационных систем в IBS.

✍️ Записаться

Приоритезируем бэклог по методу WSJF 

Регулярные внутренние воркшопы — важная часть непрерывного улучшения гаражистов. Так, недавно Саша Липин, лид одной из наших продуктовых команд, провел вебинар по методологии приоритезации задач WSJF (Weighted Shortest Job First — Сначала Более Ценная и Короткая Работа). 

Если коротко — это модель, с помощью которой можно оценить задачи в бэклоге и расставить им приоритеты на спринт. 

А если интересно разобраться и научиться, то листай карточки в посте. На них рассказали, по каким параметрам оценивать эпики/фичи/задачи и по какой формуле выявлять самые важные для бизнеса ;-)

Метод 5S для планирования задач по проекту

 Большая часть работы проджекта состоит в постановке задач и планировании загруженности команды. Кто-то прибегает к доске Канбан, кто-то выстраивает спринты. Но сегодня хотела бы обсудить 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 секунд.

Изменение
<вместо того, чтобы>, старый способ действия, <новый способ действия>
Пример:
Вместо бесконтрольных трат бюджета, выбирает на какие тематики его потратить

Описание изобретения
<Полезное действие/ Отрицание нежелательного эффекта> в <контекст> за счёт <принцип работы>
Пример:
Быстрее нахожу какой статус выбрать в колонке-фильтре статусов за счёт вывода их в идеальном хронологической последовательности

Подсмотрено тут:
https://medium.com/serious-scrum/unheralded-alternatives-to-user-stories-f1d787fc2278
https://speakerdeck.com/ashapiro/mastier-klass-po-user-story-mapping?slide=17