Натолкнулся на отличную статью, которая, базируясь на понятии пропускной способности коммуникации (communication bandwidth), кратко и емко объясняет, чем StandUp-митинги и другие формы face-to-face коммуникации лучше электронной почты, звонков, ежедневных письменных отчетов и т. д.
У нас в компании периодически проходили споры на этот счет и, думаю, фраза communication bandwidth поможет мне победить в следующем холиваре :)
6 комментариев:
Задавать вопросы лично лучше, чем по почте!
Аффтар по ссылке открыл омерику.
Ну а низкая полезность(с моей точки зрения) стэнд-апов в нашем конкретном случае - вовсе не в том, что я считаю face-to-face неэффективной коммуникацией. Причина - в отсутствии командных задач.
Еженедельные ретры, с моей точки зрения, вывезли бы решение действительно общих вопросов куда лучше (мы и так то и дело пытаемся свалиться к таким дискуссиям). А консультации по тех. вопросам у нас замечательно проходят вне стенд-апов (это, собственно, и не тема для стендапа).
То есть ты клонишь к тому, что при всей эффективности face2face-коммуникации, в случае отсутствия командных задач нам просто не о чем коммуницировать, а при наличии командных задач активная коммуникация происходит в течении всего дня, и в отдельном митинге смысла нет? Пожалуй, в этом я с тобой соглашусь.
Но вот нюанс. Есть высокая вероятность, что в любой момент времени в команде есть человек, который занимается задачей в области/модуле, где у тебя высокий уровень компетенции. И вот здесь комммуникация на standup-митинге прийдется кстати.
Кроме того, нельзя забывать и о других положительных сторонах standup-митингов вроде дополнительной мотивации сделать к следующему митингу то, что ты обещал на предыдущем.
Вероятность, что кто-то в другой команде что-то делает в модуле, по которому у нас есть знания точно такая же. Почему же мы не ходим к ним на митинги? :)
В идеальном мире такие вопросы должна решать самоорганизация. Человек понимает, что застрял или близок к этому, или понимает, что что-то делает не так. Соответственно, задает вопросы. Тем более, что на стендапе проблемы не должны _решаться_, решаются они уже после - в консультациях между заинтересованными людьми. Так и в чем смысл - в контексте конкретно этой проблемы - в обозначении "у меня проблема" на скраме?
По поводу мотивации. Это причина, да. По этому поводу я доформулирую и напишу :)
По поводу мотивации будет много букв.
Мотивирует "обещание что-то сделать". Но понять значимость того, что ты сделал, может только человек, который в курсе.
То есть люди, которые работают над другими задачами - они за твоими вообще не следят. Соответственно, это и не мотивирует (по крайней мере с моей точки зрения).
Именно поэтому у нас часто скрам и вырождается в "двиганье бумажек" без особого анонсирования того, что же именно сделано (единственное, что понятно всем - "я что-то сделал"). Собственно, человек, который в задаче разбирается - скрам-мастер - он и смотрит, что за бумажка сдвинута и что-то понимает.
Мотивирует коммит перед людьми, которые понимают задачу. Эти люди - начальник и те, кто работает над той же проблемой. Соответственно, динамическое формирование мини-команд (два разработчика, или даже один разработчик) и ежедневный митинг с начальником дадут ту же мотивацию + платформу для дискуссий и обсуждений по теме (потому что все в теме и никто не "лишний" и не теряет время слушая неинтересную болтовню).
Скрам - в нашей форме - очень простая форма отчетности. менеджер теряет минимум времени и узнает, что все заняты делом.
Однако для разных задач и разных исполнителей нужен разный уровень контроля. У нас это выглядит как отсутствие дискуссий на тему фасти - мы исключительно репортим прогресс; и активное обсуждение тем сомноменеджера - задачи другой "мини-команды". Два мини-митинга выглядят, с моей точки зрения, более удачными в данном случае.
Число таких мини-команд и разбиение на них, естественно, нефиксированное.
Касательно самоорганизации. В идеальном случае действительно инициатива должна исходить от того, у кого проблемы. Но 1. человек может не понимать, что у него проблемы, что он пошел по неоптимальному пути и т. д. 2. не стоит забывать о социальных факторах: человек может стесняться спросить или просто быть интровертом. В случае ежедневного стендап-митинга есть гарантия, что хотя бы раз в день адекватность твоей деятельности будет проверена (хоть и поверхностно) командой.
У нас регулярно после скрама люди разбиваются на группы и обсуждают какие-то нюансы. Тот факт, что дейли-митинг регулярно провоцирует конструктивные обсуждения, я считаю довольно существенным.
Насчет других команд. Действительно, можно довести эту идею до абсурда и ходить на дейли-митинги друг к другу. Но если говорить о вероятности того, что твои знания пригодятся, то она как раз максимальна внутри твоей команды, а уровень твоей компетенции в области задач другой команды в общем случае будет гораздо ниже.
Насчет миникоманд. У нас в скрам-команде и так 4 разработчика и 2 тестера. Не думаю, что имеет смысл заморачиваться и динамически разбивать команду над подкоманды. Тем более в результате этого перестали бы возникать дискуссии, о которых я говорил выше.
Твоя точка зрения тоже верна, да.
Собственно, в предмете спора осталось очень мало объективных вещей, и субъективные относительно них становятся важнее.
А субъективные - это matter of taste. Идеального и чтобы нравилось всем не придумаешь, да.
Отправить комментарий