Outsouricng 3.0: продуктовая разработка в офшоре

Выступил на agilebasecamp с докладом, разрывающим шаблоны мышления, офшоре, продуктовой разработке и ответственному отношению к работе.

Outsourcing3.0 - продуктовая разработка в офшоре

"Scrum is a diet, Kanban is a mirror"

Мой полуночный твит бьёт рекорды.

Что же я на самом деле имел в виду?

Скрам - известный всем каркас управления проектами, который реализует Agile ценности и принципы, состоит из набора несложных правил. Следуя этим правилам, вы гарантировано устраните самые часто встречаемые проектные проблемы.

Это вам что-то напоминает?

Мне это напоминает комплексную витаминную диету, совмещенную с режимом, которые лечат массу заболеваний.

ЧТО ЖЕ ЛЕЧИТ СКРАМ?

• нехватка обратной связи (витамины)
• нехватка обмена информацией внутри команды (витамины)
• нехватка доверия (минералы)
• избыточное количество незавершенной работы "work-in-progress" (ожирение)
• вынуждает делать такие практики как интеграционное и приемочное тестирование, автобилды и автодеплоймент регулярными (упражнения)

НО ЧТО ЕСЛИ ВЫ ЗДОРОВЫ?

Если вы здоровы - на что вам диета и режим ? У вас и так отличный обмен веществ и активный образ жизни.

Но что вам может быть полезно - так это ЗЕРКАЛО В ТРЕНАЖЕРНОМ ЗАЛЕ.

 

Зачем? Для того, чтобы вы видели себяи смогли равномерно и сбалансировано развиваться.

Аналогия проста: канбан-доска - это такое же зеркало. Что с ним делать - решаете вы. Оно лишь показывает вам что и где не так. Никаких правил. Никаких догм. 

Читайте вдохновляющий пример использования визуализации процесса в последней книге Хенрика Книберга "Lean from the trenches", где канбан-доски сыграли ключевую фукнцию в становлении процессов и успехе продукта.

Slides Open Source Boot Camp

Делюсь слайдами двухдневного воркшопа, проведенного для сообщества Open Source Молдовы.  Объясненные концепции:

• lean startup,
• user personas,
• business model, 
• story mapping, 
• kano weighting, 
• paper protyping, 
• etc.

Open Source Boot Camp

View more presentations from krivitsky

AgileBaseCamp - from idea to product

Вау, СкрамГайдз опять делает крутую конференцию.

На этот раз мы будем плавать (или летать - кому нравится) выше гибкой разработки!

Мы живем в пору "ренессанса предпринимательства" (слова Эрика Риза, автора концепции Lean Startup). Сегодня даже Манифест уже выглядит чуть устаревшим:

Кого удивишь работающим продуктом?
Кого покоришь адаптивностью к изменениям?

Что же это значит?

Это значит, что сегодня как никогда важны процессы, которые позволяют эмпирически проверять бизнес идеи: "deliver value over working software" и дающие свободу поменять стратегию и курс продукта на 90 а то и на все 120 градусов: "pivot or persevere over responding to change".

И наш кемп как раз об этом.

Лично я хочу донести на своем докладе мысль о том, что даже будучи в аутсорсинге (которого у нас в стране много больше локальной разработки) - можно делать продукты, а не просто оказывать coding&testing услуги.

Как? Узнаете на моем докладе.

Ваша Кри :)

"Метрики и сантиметрики". Или в поисках agile метрик.

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

"Метрики - это зло", - так всегда открывает тему метрик Сережа Дмитриев, когда на тренингах всплывает вопрос метрик в Скраме.

Почему они зло? Да потому что, люди будут подсознательно вести себя так, чтобы повысить метрики, которыми вы их будете мереть: "Show me how you’ll measure me, I’ll tell you how I’ll perform" - гласит народная мудрость. В результате - метрики улучшаться, а ситуация - нет.

Что же делать? Держать метрики в секрете и никому не показывать!

Но как же прозрачность, самоорганизация и отсутствие единой точки менеджмента в Agile? Хм... Что-то здесь не так.

Может быть мы просто не то меряем?

ЧИТАТЬ ДАЛЬШЕ >>>

КОД РЕТРИТ!

Как еще лучше разработчик может провести субботу?
Открыта пререгистрация! >>>


Друзья, присоединяйтесь к инициативе - мы хотим проводить СУГУБО ПРАКТИЧЕСКИЕ встречи для разработчиков. Что мы там будем делать? Писать код! Не продукты, а именно код.

Цель ретрита - вместе освоить одну из новых технологий на выбор.

Что такое code retreat?

coderetreat.com - подобный формат был придуман Corey Haines (@coreyhaines).

Мы из идеи берем основу - программисты, работающие в сменяющихся парах над интересными задачами, могут многому научиться друг у друга. Благословние от Кори на наш ретрит мы уже получили!

Кто организаторы?

Первая встреча будет проведена: @alexeykri + @vir.
Помещение предоставляет SCRUMguides.

Наше расписание

Начало в 11:00

Вход и что иметь с собой?

Вход, конечно же, бесплатный. С участников - свои ноутбуки с блоками зарядки + любимый IDE.

Размер группы

Для первой встречи и обкатки формата нам нужно 3-5 пар участников. 

Что мы будем писать? 

Мы запустили голосование за идеи на facebook, присоединяйтесь: 

Голосуем за тематику встречи 24го декабря:
Scala, Akka.io, NOSQL или что-то поинтереснее?

Регистрация

Открыта пререгистрация! >>>

----
Ваш Кри.

The Krivitsky Test - минимальный процесс разработки

Всем известен Тест Джоеля (Спольски): 12 шагов к лучшему софту.

Вот мой тест из 8 шагов:

1. Есть ли удобный и единый source control с правами на чтение-запись у всех членов команды?
2. Налажен ли процесс автосборок (он же continuous integration), который собирает продукт минимум раз в день, разворачивая сборки на тестовой среде?
3. Есть ли у команды своя комната?
4. Есть ли у команды физическая доска для планирования либо ее удобный электронный аналог?
5. Есть ли в команде процесс краткосрочного планирования c горизонтом в одну, две или максимум три недели?
6. Вовлечен ли заказчик в процесс приемки и раннего тестирования фич на ежедневной основе?
7. Обсуждает ли команда свой процесс разработки как минимум раз в месяц для его наладки?
8. Ограничивает ли команда размер своего баг листа, чиня дефекты регулярно?

По-моему опыту - утвердительные 8 ответов на этот тест существенно повышают шансы разработки хорошего продукта.

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

Как вы можете заметить - как минимум пять пунктов, а то и более, перекрываются с виденим Джоеля. Что не может не радовать :) Хорошего вам софта!