Я собираюсь написать несколько статей про новую методологию гибкой разработки Канбан (Kanban Development) в целях подготовки к Scandinavian Agile Conference 2009, где я буду делать один из докладов (кстати, заодно приглашаю всех на конференцию).
Сегодня публикую первую из статей.
Основная задача первой статьи — это как можно проще описать основы Канбан: что это такое, в чем отличие от других гибких методологий и зачем это нужно.
Также я хотел бы собрать как можно больше вопросов и сомнений в комментариях, чтобы ответить на них в следующих статьях, так что пишите всё, что вам непонятно, или что ещё вы хотели бы узнать про Канбан.
Я не то, чтобы большой специалист по этой новой методологии, но мы внутри команды пришли к Канбану самостоятельно и последовательно прошли все этапы мутации от SCRUM до Канбан, так что практический опыт есть.

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

Миссия, видение и принципы Amazon

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

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

Привет, Хабр! Представляю вашему вниманию перевод статьи Why Development Teams are Slow: Common Software Jams and Solutions автора Эрика Эллиота.



Если вы больше любите слушать, чем читать, то в аудио формате перевод доступен на Яндекс.Музыке и в Apple Podcasts

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

• Нереалистичные ожидания
• Слишком много открытых тикетов
• Неконтролируемый объем задач
• Накопление код ревью
• Плохая подготовка
• Выгорание разработчиков
• Баги
• Текучка кадров

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

Как справедливо заметил легендарный писатель Жюль Верн: «Хорошо использованный минимум вполне достаточен». В нашу эпоху понятие хорошо использованного минимума применимо и к коду. Печально, но факт: в современном мире кода слишком много. Если быть точнее, то слишком много ненужного кода, среди которого код полезный просто задыхается.

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

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