"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 ответов на этот тест существенно повышают шансы разработки хорошего продукта.

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

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

Что значит быть праведным agile-коучем?

Наткнулся только что на статью-дискуссию на infoq: "А есть ли у agile коучей код этики?"

"Искушение Святого Антония", С. Дали

Давно у меня на уме - что значит "быть праведным agile коучем"? Известно, что личный коучинг базируется на тех же методах, что и НЛП, у коготоро репутация чуть подпорчена... Да и встречаются клиенты, которые жалуются на коучей, которые дословно "messed around with our processes".

Так кто же такой праведный коуч? Каким принципам он следует? Что ставит во главу своей практики? Что ставит превыше всего?

У медиков есть свой: "не навреди".
У google - свой "do no evil".
А что есть у agile-коучей?

Набросок моих принципов - что для меня значит быть праведным коучем:

• раскрывать потенциал людей, работающих в компаниях 
• привести компанию на более высокую ступеть развития или как минимум показать потенциал и путь
• работать с клиентами, уровень ценностей которых совпадает с моим
• не чувствовать эмоционального фона к людям, а работать с процессами - помнить о том, что все хотят счастья и делают то, что делают, потому что думают, что это верный путь
• не вести двойных игр, не быть политкорректным - открыто говорить то, что на уме
• внердять практики (kanban, scrum, what-so-ever), только в случае, когда я интуитивно верю, что они смогут показать дальнейший путь развития компании, раскрыв потенциал
• во время работы помнить о том, что я хочу научить компанию поддерживать свой процесс без моего участия и как можно скорее научиться обходиться без меня

Как-то так.
Готов рассмотреть предложение о внесении изменений в список, цена договорная :)