Обсуждение

Наконец-то появится шанс тебя иногда читать. :)

small batch size - так нааамного удобнее читать. +1

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

Простите пожалуйста, я новичок в вашем журнале. Что такое - "lean-kanban-TOC"?

Это современный (по факту, после 2010 года) вариант инженерного менеджмента, базирующийся на плотно переплетённых идеях http://en.wikipedia.org/wiki/Kanban_%28development%29, http://en.wikipedia.org/wiki/Lean_software_development, http://en.wikipedia.org/wiki/Theory_of_constraints.

С тегами огромная проблема: соображения о возможной классификации в момент написания текста обычно не совпадают с соображениями в момент попытки что-то найти. Поэтому полнотекстовый поиск в разы и разы лучше тегов.

overhead'а не боитесь?

С моей стороны overhead -- это только придумать заголовки, нет?

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

Это я понимаю, разбивать на части это всегда работа (мыслительная в плане выделения правильного модуля -- в том числе правильного размера и с правильными интерфейсами, а не произвольной части. И механическая -- модуль нужно таки оформить как модуль). Вся эта механика lean-kanban-TOC она антипсихологична, она контринтуитивна. И эффект проявляется только на уровне всей системы, а не одиночной операции работы с модулем.

В архитектуре то понятно. Я скорее про всякие user stories / epics и иже с ними. Их всех нужно раздельно оформлять и документировать. А потом их в результате исполняет один и тот же человек. Получается классический конфликт интересов: менеджер требует минимизировать размер задач, а разработчик хочет максимум одну задачу в день (а лучше в неделю) -- поскольку производительность на длинных задачах существенно выше, чем на коротких. Приходится искать золотую середину. Классический лин/канбан, как нам его рассказывали, предполагает взаимозаменяемость исполнителей и однородность операций. А в софтостроении оно совсем не так.

Дык "производительность одного производителя на длинных задачах выше" -- это и есть "эффективность загрузки", которая является ложным критерием оптимизации. Что хорошо станку, то плохо цеху (с точки зрения логистики. Про связь инженерного качества и организации работ это нужно обсуждать отдельно и это сильно зависит от задачи, участников проекта, опыта в выполнении подобного сорта проектов, наличия других проектов, принятой технологии инженерной работы и т.д.). В принципе, размер batch не минимизируется, а оптимизируется (там U-образная функция зависимости полезности от размеров batch). Но подчёркивается, что оптимум обычно находится контринтуитивно: он мельче того, что ожидают найти люди. А оверхед оказывается меньше (и с ним понятно как бороться и как его минимизировать), чем эффекты от малого размера порции. Эффекты же не все чисто логистические. Например, быстрая обратная связь от следующих по цепочке людей (тестеров, например, или ревьюеров, или даже пользователей) это один из таких эффектов.

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