Рубрика «agile»

О пользе лаконичности - 1

С одной стороны, программисты – мягко говоря не самые общительные люди на свете. Это нормально, ведь если разработчики вдруг станут разговорчивыми кто будет писать код? С другой – время одиночек прошло. Современное ПО разрабатывается командами и даже самые консервативные компании, вроде Сбербанка внедряют Agile. Agile manifest пропагандирует определенные ценности, в том числе: «Люди и взаимодействие важнее процессов и инструментов». Так что общение с коллегами – не прихоть, а потребность. Эта статья ориентирована на гибкие команды разработки: разработчиков, тим-лидов, аналитиков, тестировщиков и т.д.

Профессиональные PM вряд ли найдут здесь что-то новое. Если вы – «технарь» и хотите, чтобы вас как можно меньше отвлекали от основного вида деятельности и вам интересно при чем здесь Спарта, добро пожаловать под кат.
Читать полностью »

image

Пару лет назад я встретился с родственником. Мой бедный двоюродный брат (генеральный директор страховой компании) продался Agile Silver Bullet и сильно пожалел. Он сказал что-то вроде:

Это надувательство! Мы изменили весь рабочий процесс. Мы пригласили консультантов. Мы наняли этих мастер-PMов. И ничего не работает! Нет никакого результата. Нет никакой ответственности. Все, что я получаю — это отмазки.

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

«Можно обманывать некоторых людей все время, всех людей некоторое время, но невозможно обманывать всех людей все время». Авраам Линкольн

Самое недооцененное, на чем может заработать каждая компании — это Сервис. Раза в два можно увеличить оборот, но придется быть честным до конца. Хитрить со всеми все время все равно не получится.

Свежая история, где клиент чувствует, что остался в дураках:
Заказал три ящика минералки.
Ошиблись и привезли три бутылки вместо трех ящиков.
Развели руками, увезли три бутылки, сказали, что на складе что-то пошло не так.
Никаких действий от магазина.
Позвонил, в поддержку. Удивились, посмеялись, сообщили, что составили запрос, специалист изучит и вынесет решение.
Через день пришло письмо с извинениями и скидкой 100 руб. на следующий заказ.
Написал в ответ “А может доставите мне мой заказ?”
Без реакций.

А экономика сервиса работает так:
Заказал три ящика минералки.
Ошиблись и привезли три бутылки.
Извинились. И через два часа привезли четыре ящика. Один подарили.
Делать заказы тут стал чаще.
Рассказал в течении месяца историю еще пяти знакомым, трое попробовали, один стал клиентом.
Потратили на меня меньше 600 руб., за год заработали от 30 000 руб.

Мы стартап, делающий систему управления проектами. Рынок очень непростой, много чего уже сделано до нас. Однако это не первая наша компания и текущий опыт говорит, что работать надо там, где есть рынок и внимательно следить за тем, что думают и чувствуют клиенты.
В этой статье несколько ключевых подходов к сервису при разработке софта. Опыт каждого достался нам очень дорого. Самый дорогой — второй после ката.
Читать полностью »

Совместное использование Scrum и DevOps — перевод статьи The Convergence of Scrum and DevOps

Перевод статьи, написанной Scrum.org и DevOps Institute. Ссылка на оригинальный файл

От переводчика

Статья показалась мне очень полезной, хотя и сложной для перевода, не смотря на то, что часть терминов, которая относится к Agile, мне известна. Очень старался не исказить смысл оригинала и надеюсь, что мне это удалось. В любом случае, всем, кто владеет английским, очень советую читать оригинал. Это моя первая работа в области публичного перевода, потому прошу не судить строго.

По сути статья — это практически руководство пользователя (хотя и крайне верхне уровневое). Единственное, что советы из него нельзя просто взять и внедрить (что, наверное, относится к любой методологии), и, с моей точки зрения, стоит придерживаться главного принципа — изменения должны быть плавными и не следует ломать то, что работает. Любые изменения должны вытекать из боли (большой или малой), тогда коллектив к ним готов, не нужно создавать эту боль искусственно.

Ссылки, которые были в основном документе, я поместил сразу в текст, они отделяются скобками и курсивом. Если были сомнения в корректности перевода термина, то я дублировал его в скобках на английском.

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

Предисловие

Не секрет, что правильно выстроенные бизнес-процессы нужны всем.
Отдельные граждане, отделы и целые компании с холдингами бегают кругами и воют о необходимости правильного обустройства всех и всяческих процессов. Всё должно быть посчитано, измерено, запланировано и выполнено в срок, в строгих рамках бюджета. Метрики и KPI, предсказуемость и прозрачность.
Везде должен быть “внедрён” Agile. Все должны мыслить категориями Lean. Все должны думать о Business Value.
И, будучи разбуженными ночью, — мгновенно ответить на вопрос: “каков LTV нашего пользователя?”

Отличный, рациональный подход.

В разработке программного обеспечения давно и прочно обосновался тренд “не изобретай велосипеда”.
Нужно разработать инсталлятор для нашего мега-продукта? Интегрироваться с внешней системой? Разработать кучу отчётов?
Не умничай, бери коробочное решение. Сэкономишь кучу времени, нервов, и, как результат, — денег компании.
А если помножить это на тенденцию снижения среднего уровня технической квалификации инженерных кадров, — это отдельная тема, завязанная на многолетнее превышения спроса над предложением, — то вообще получается отлично. Поминутно вейпая и попивая смузи, можно строить целые системы, просто интегрируя готовые блоки при помощи быдлокода и такой-то матери быстрого прототипирования.
Поэтому — не изобретай велосипеда и не умничай. Используй готовое, а кривые руки умную голову прикладывай там, где интеграция по какой-то причине вдруг не работает.

Отличный, рациональный подход.

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

Итак, знакомьтесь с нашими героями

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

Mars Information Services: добро пожаловать в Марс!

Мы начинаем серию публикаций о том, как устроена и работает IT-поддержка глобальной американской компании Mars Incorporated, которая ведет свою деятельность почти в 80 странах и является одним из мировых лидеров по производству продуктов питания. Добро пожаловать в блог Mars Information Services (Mars IS).

Mars Information Services: добро пожаловать в Марс - 1
Читать полностью »

Лет 8 тому назад я, начинающий менеджер проектов, начал работать в Redmine. Перед друзьями я хвалился, что все мои проекты хранятся в интернете! И это было круто!

Произошло это благодаря тому, что мой руководитель не на шутку увлекся Redmine, настроил всем доступ, раздал права, а сам принялся докручивать его всеми днями и ночами. Он постоянно спрашивал: «Чего тебе не хватает?», выслушивал, а на следующее утро презентовал «фичу» как «новый айфон» со словами «Really amazing».

Задачи, которые я решаю с помощью Redmine, характерны для многих продуктовых команд. Поэтому я хочу показать вам Redmine таким, каким вы его еще не видели!

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

Когда хочешь быстро объяснить суть какого-то процесса, то обычно рисуешь на листке бумаги несколько прямоугольников с текстом и проводишь между ними связи. Этому нехитрому принципу следуют большинство методологий описания бизнес-процессов, технологических процессов и любой другой человеческой деятельности. Можно принять как данность, что подобные схемы очень важны в современной парадигме накопления знаний.

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

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

image

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

Добрый день, уважаемые читатели. Ранее я рассказывал, что основная деятельность Банка в части ИТ процессов, была организована на ITIL. Исключением стал только процесс управления изменениями. Вторая (и заключительная) часть посвящена внедрению элементов гибких методологий в Банке в процессах управления изменениями в ИТ.

Описание проблемы

Я столкнулся со следующими проблемами при анализе существовавшего процесса:

• 80% задач поступает ad hoc
• приоритеты задач постоянно меняются
• нет возможности осуществлять планирование работ
• отсутствует гармоничность в развитии систем
• нет «установленных правил игры» при реализации изменений

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

Практики управления техническим долгом в отдельно взятой команде

Примерно год назад наша команда перешла из фазы ускоренного наращивания функциональности к более плавной разработке с упором на повышение качества. К этому моменту в наших продуктах накопилось заметное количество неоптимальных решений, некрасивого кода, устаревших библиотек. Со всем этим надо было что-то делать.

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

Что удалось получить в результате:

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

Давайте расскажу, как мы этого добились.

Ланнистеры всегда платят свои долги! (и технические тоже) - 1

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