Рубрика «agile» - 12

Это — материалы, которые помогут разобраться в ITSM-трендах и инструментах.

Знакомство с ITSM: 10 хабратопиков и экспертных материалов для «быстрого погружения» в тему - 1
/ Unsplash / Headway

Знакомство с ITSM: 10 хабратопиков и экспертных материалов для «быстрого погружения» в тему - 2 Пять ключевых трендов ITSM на этот год. Наш хабрапост, который мы написали не так давно (после небольшого перерыва с публикациями в нашем блоге на Хабре). Рассказываем о решениях, поддерживающих системы вроде чат-ботов; об автоматизации разработки, информационной безопасности и облачных ITSM-инструментах. Этот материал поможет быстро погрузиться в тему и охватить основные направления, которыми занимаются ITSM-специалисты.Читать полностью »

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

Звёздная карта или как балансировать знания в команде при влиянии Soft Skill-ов - 1

Читать полностью »

Дано: Компания, использующая фреймворк Scaled Agile (SAFe) для масштабирования Agile-разработки в рамках всей организации; 10 команд разработки, объединённых в одну большую команду (Agile Release Train, согласно терминологии SAFe), доставляющую общий продукт; необходимость проведения двухдневного квартального планирования (PI Planning) для определения плана работы ИТ-команд на ближайшие 3 месяца*; три офиса разработки, расстояние между самыми удалёнными превышает 6 тысяч километров с соответствующей разницей в 5 часов рабочего времени; предыдущий опыт планирования, предусматривавший физическое присутствие ключевых коллег в одном помещении и использование аналоговых досок/вайтбордов/маркеров/липких бумажечек.

* Тяжеловесный конструкт “План работы ИТ-команд на ближайшие 3 месяца” грозит серьёзно увеличить объем текста, поэтому в дальнейшем я планирую вместо него писать просто – “коммитмент”. Соответственно, составить и принять план работы – “закоммититься”.

Зачем это понадобилось?

1) Усталость от аналоговых методов работы. В то время, как космические корабли бороздят просторы, а Илон Маск роет тоннели, мы, «айтишники», упорно пишем маркерами на липучих бумажках и лепим их на доски – есть в этом некий диссонанс. Так выглядел наш коммитмент некоторое время назад:
image
Читать полностью »

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

Прелесть в том, что живые люди сами не пытаются тебя учить. Не проводят семинаров, тренингов, не берут с тебя денег. Они просто делают свою работу, как умеют. Что-то у них получается, бывают и провалы, и срывы, и ругань с матами. Но у каждого можно чему-то научиться, даже если в целом о человеке мнение складывается негативное.

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

Несколько лет мы сидели в одном кабинете, и я имел удовольствие наблюдать за ее проектами, эволюцией методов и ростом менеджерских компетенций. Она, скорее всего, не знала, что я наблюдаю и учусь. Хотя, кто их разберет, этих женщин – может, это она была Макиавелли, а не я.

В комментариях велели картинку для привлечения внимания вставить. Исполняю.

Девушка под водопадом - 1

Сейчас она работает директором проектного департамента одного из крупнейших и известнейших предприятий Челябинска. А я сижу и пишу про нее статью.Читать полностью »

Определение DevOps очень сложное, поэтому приходится каждый раз запускать дискуссию об этом заново. Только на Хабре тысяча публикаций на эту тему. Но если вы это читаете, то наверняка знаете, что такое DevOps. Потому что я — нет. Привет, меня зовут Александр Титов (@osminog), и мы мы просто поговорим о DevOps и я поделюсь своим опытом.

image

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

Наш мир устроен очень странно. И чем дальше, тем становится страннее. И хрен поймешь, в чем дело.

Вот есть на свете инженеры и программисты. Иногда в одном лице. Люди, понимающие, что такое алгоритм. Более того – люди, создающие эти алгоритмы. Прекрасно знающие, что созданный алгоритм подходит для решения одной задачи, но не годится для другой. Понимающие, что если алгоритм чуть изменить, то он сможет решать смежные задачи. Не стесняющиеся выкинуть половину чужого алгоритма, чтобы он лучше решал текущую задачу.
Программисты создают решение под задачу, или под класс задач. В этом суть профессии. Там, где это возможно, используют готовые куски своего или чужого кода. И всё у всех хорошо.

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

Я говорю о «внедрении методик», «работе по фреймворку», «обязательном использовании всех артефактов». О сектах, короче.Читать полностью »

Руководство для чайников: создание цепочек DevOps с помощью инструментов с открытым исходным кодом - 1
Создание первой цепочки DevOps за пять шагов для новичков.

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

Мое знакомство с DevOps

Когда-то я работал с облаками в Citi Group и разрабатывал веб-приложение IaaS, чтобы управлять облачной инфраструктурой Citi, но мне всегда было интересно, как можно оптимизировать цепочку разработки и улучшить культуру среди разработчиков. Грег Лавендер, наш техдиректор по облачной архитектуре и инфраструктуре, посоветовал мне книгу Проект «Феникс». Она прекрасно объясняет принципы DevOps, при этом читается, как роман.

Читать полностью »

Традиционный способ измерения задач в нашей отрасли – часы. Давайте посчитаем, сколько метрик в часах мы используем.

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

Вторые часы – те, что назвал программист, отвечая на вопрос «сколько тебе надо времени на решение задачи?». Если мы договариваемся с клиентом заранее, то именно эти часы и выставляем для продажи. Если оплата идет по факту, то мы спрашиваем оценку у программиста для целей планирования.

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

Бывают и четвертые часы – когда мы выставляем клиенту сумму, отличную от заранее обговоренной. Разумеется, если условия нашего сотрудничества позволяют так поступать.

А теперь внимание, вопрос: где тут можно поработать над эффективностью? Или по-другому: эффективность чего мы будем повышать?Читать полностью »

Гибкая методологи разработки — отличная идея, которую слишком усложнили. Agile Lite — попытка упростить ситуацию. Вам не нужны книги или семинары, чтобы объяснить Agile Lite. Нужен только небольшой текст с несколькими пунктами. Вот этот текст.

Agile Lite довольно прост. Его можно применить к любому проекту при условии, что работа разбивается на более мелкие задачи (issue). Как и другие гибкие методологии, он использует короткие циклы разработки  — спринты. Но в отличие от них, Agile Lite явно признает распространённость выгорания в индустрии разработки программного обеспечения и пытается смягчить его напрямую путём внедрения цикла «три недели разработки/одна неделя отдыха.
Читать полностью »

Не знаю почему, но вам понравилась история про одного парня. Если помните, он ушел.

Куда ушел, чем занимается, каковы успехи – не скажу, ибо не имею от него на то разрешения. Но его история получила неожиданное продолжение.

Я, как вы поняли, с ним знаком. И не просто знаком – мы вместе учились на приборостроительном факультете. На носу День Радио, и он прилетел обратно в нашу дыру на встречу выпускников. Позвал меня выпить пива, и рассказал мне одну историю. Про одну девушку.Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js