Kanban vs. SCRUM

Запись встречи: http://team.custis.ru/2009/07/kanban-vs-scrum.html (видео)

Просмотрел запись, просто супер! Согласно Core Protocol: 6 баллов из 10
+ 3 балла за классные обсуждения
+ 2 балла что используется принципов Study Group - когда заранее было сказано подготовиться к встрече.
+ 1 балл за запись отличную и отчёт

Чтобы поставить 10 баллов, я бы добавил следующее
+ 2 использовать паттерны StudyGroup, тогда и встреча интересней будет
+ 1 попросить участников потом (так как есть е-мыл) написать отзыв в митинг- статью
+ 1 включить вещание в инет, хотябы через скайп или rutube!!!! (это делается за 5 минут, зато аудитория будет в тыщи раз больше!!!)

Мои мысли по теме:
1. Чтобы понять одну из методологий, нужно понимать скоуп её использование. Это продукт, проект, или только одна разработка. Другой нюанс срез в даже в скоупе. И даже в рамках могут быть разные срезы. Поэтому определив какие области покрываются предлагаемой практикой облегчело бы обсуждение.
2. Был график, когда каждая последующая методология уменьшает количество включенных практик. SCRUM исключил технические, отдав на усмотрение команде, Kanban исключил множество других практик. Каждая следующая методология даёт выбор, чем мы покроим свои активности. Поэтому я бы ввёл следующую методологию - Agile. В которой не одной практики вообще, а другие практики выбираем по усмотрению.
3. По поводу менеджера и улучшения процесса. Кайдзен-команды это альтернатива ретроспективам. То есть Just-in-time по отношению к улучшению процесса, и не нужно ждать ретроспективы.
4. По поводу цепочки задач, и почему хорошо не ложиться вытягивание от маркетинга, через тестирование, к разработке. То тут лучше к Lean в построении цепочки создания ценностей. А тестирование по определению Lean должно быть убито как явление. Так как любые ошибки добавляют потраченное время, поэтому здесь практики Unit Testing для разработчиков, и Acceptence (Fitness) тестирование для тестировщиков. Цель уменьшить время фидбека после каждого чекина. Сюда же идут - ScoreCards, Testable Units, разделение кода и дизайна. Что позволяет работу QA вплести в разработку.
5. И вообще мне усматривается, что менеджмент, как средство управления процессом (придумать документы, поставить практики, мотивировать людей в разборках тет на тет), а не продуктом, исчезает. То есть практика Канбан и Лин делает так, чтобы менеджмент процесса убрать за счет способности команды стопорнуть процесс и его улучшить, как только обнаруживается дырка. Что очень хорошо в канбан видно. Просто форсируются изменения как только обнаружены дырки процесса.

В общем все супер! А можно вебвещание сделать, я хотел бы в следующий раз через скайп поучаствовать тоже :)