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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я уже пытался лечить «механический» scrum (часть 1, часть 2, часть 3), а в этой статье постараюсь выписать универсальное лекарство от «подгорания». Само по себе «подгорание», «бурление» и т.п. — это хорошо, это значит вам не все равно (а ведь безразличие — это шаг к унынию, или, как принято в IT — к выгоранию). На тему вреда выгорания написано и снято много материалов, например: вот, вот, вот или вот.

Одна распространенная мудрость гласит: «Баттхёрты — двигатель прогресса». Но часто бывает так: пригорело => быстро принимается поверхностное решение, маскирующее проблему => решение воплощается в жизнь => пригорать продолжает. Другими словами, вместо того, чтобы разобраться и поставить диагноз, мы сразу приступаем к лечению. Попытаюсь это проиллюстрировать примерами.
Прозрачность — панацея от баттхёртов - 1
Читать полностью »

В этом посте я расскажу о тех проблемах с которыми в течении года сталкивалась наша Scrum Front End команда при работе над приличным проектом. Мы начинали разрабатывать проект с нуля используя стек технологий React + Typescript. Оглядываясь назад я вижу многие миллионы выброшенные впустую просто из-за того, что процесс разработки не был поставлен с самого начала правильно. Но на это есть свои причины.
Читать полностью »

image

Изначально Agile ассоциировался исключительно с ИТ-сферой и стартапами. Для ИТ продуктов идеально подходит гибкая методология разработки и она легко ложиться в основу молодых проектов, которые только выходят на рынок.

А что делать большим традиционным компаниям, которые годами жили в WATERFALL проектах и чтобы согласовать новую кнопку на сайте проходят семь кругов бюрократического ада?

Сейчас мы наблюдаем распространение Agile в новых сферах: банковские структуры (и речь далеко не только о финтехах), транспортные услуги и пр.
Часть компаний применяют новую методологию к отдельным продуктам, некоторые, переводят целые подразделения в такой формат.
Читать полностью »

image

В 2001 году группа технологов и программистов, разделявших небанальные теории о том, как следует управлять разработкой ПО, встретились на горнолыжном курорте Сноубёрд, чтобы письменно изложить некоторые из этих концепций. Так родился «манифест Agile» — обманчиво простой документ, призванный пересмотреть догмы разработки ПО. Разработка ПО в стиле Agile превратилась в новый стандарт организации труда программистов в организации. Такие компании как Facebook, Amazon, Apple, Google и Netflix выстроили свои внутренние процессы разработки в соответствии с базовыми положениями этого манифеста. Учитывая абсолютные масштабы Agile и его общественный резонанс среди сторонников, легко убедиться, что Agile — самая влиятельная из всех когда-либо формализованных трактовок разработки ПО. Однако, Agile — это идеология. Нормативная система ценностей и убеждений, практически до основания впитавшихся в дело разработки ПО. Таким образом, софтверная индустрия сегодня дает интересную возможность оценить, как номинальные цели некоторой идеологии согласуются с ее воплощением на практике.
Читать полностью »

Девушка в IT, или 5 советов для амбициозных - 1В этом посте я специально не буду говорить отдельно о «рецепте для женщин», т.к. считаю, что схема успеха одна и та же, независимо от пола. Об отличиях и специфике «женского пути» будет в конце. Если кто-то интересуется только этой частью, смело скрольте до последнего раздела.

В конце прошлого года меня пригласили выступить на мероприятии Worldwide Conversation on Women’s Higher Education and Equality in the Workplace на факультете компьютерных наук ВШЭ. Это беседа о том, как в современном мире женщина может построить успешную карьеру в области науки, образования или информационных технологий, с какими сложностями она при этом сталкивается и как может их преодолеть.

Я была спикером «со стороны IT» и рассказывала, как мне кажется, вполне очевидные и сами собой разумеющиеся вещи. Но, делясь впечатлениями о мероприятии с друзьями и коллегами, обнаружила, что тема очень многим интересна и относятся к ней очень по-разному. Именно после этого и родилась статья. В ней я расскажу о моем опыте развития карьеры в IT-компании и том, что считаю важным делать, а чего, наоборот, избегать, чтобы стать успешным в своем деле.
Читать полностью »

Вводная часть


В предыдущем посте я писал как организовать процесс “грумминга” задач в системе JIra так чтобы “Менеджеру продукта” было удобно осуществлять навигацию по всему Беклогу продукта. Продолжая продуктовую тему напишу о том как я долго шел к пониманию того — что такое типы задач в Jira.

Важно тут сказать что дальше структуру которую я буду предлагать подойдет именно для процесса развития продукта(ов), но врятли будет корректной для управления проектами. Кстати если Вас волнует вопрос почему Agile это в большей степени фреймворк для управления продуктами но почитайте об этом вот тут.

Структура задач


В системе Jira на уровне проекта есть три уровня задач, это: Epics, Stories/Tasks, Sub-task. Оригинал статьи тут. Jira позволяет достаточно сильно кастомизировать эти сущности — можно менять названия, картинки, настраивать под эти задачи свои workflow. В этом то и кроется корень зла! Чем больше ты “кастомизируешь” систему под свои потребности не имею согласованного понимания что есть что, тем больше это вызывает вопросов и в конечном счете отторжение от работы в данном приложении.
Читать полностью »


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