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

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

Казалось бы сиди работай, раз платят, какая тебе разница используется результат твоей работы или нет? Тем более студенту? Деньги же ну очень нужны. Оказалось все сложнее, деньги нас, конечно, мотивируют, но этого не достаточно, нужно больше. Если твоя работа никому не нужна то мотивация падает, человек перестает работать. Даже если ему платят все также.

Те кто работал в условиях когда результат был бесполезен и тут же уничтожался, они соглашались работать меньше, отказываясь от работы гораздо раньше. В условиях Сизифова труда студенты сделали на 30% меньше. Что еще интересней, примерно те же цифры получаились и в случае если не уничтожать результат работы, а просто не обращали внимания, показавая что результат не особо важен.

Если интересно то об этом можно прочитать в книге «A Taste of Irrationality» Дэна Ариэли, она бесплатная, для iBooks и Kindle. Ну и, на самом деле, это лишь пара статей из других книг того же автора.

1. Команда рано или поздно приходит к моменту когда проект «уже сделан на 90%» — что-то уже запускается (в идеалистичном use case) , есть какая-то система, казалось бы осталось лишь допилить чуть чуть.
2. Но на самом деле это лишь начало. Дальше еще столько же до того момента когда продуктом можно будет реально пользоваться, когда он станет работать у другого человека, перестанет падать в ситуации отличающейся от идеальной и т.д. Вот тут да, снова дошли до стадии «готово на 90%».
3. И это оказывается не все... Теперь нужно допилить чтобы все было «красиво», удобно, чтобы это поддерживалось, запускалось из коробки, были написаны инструкции. И после уже снова «готов на 90%», тут уже и правда почти готово.

Ну в общем это все понятно, интересно другое: если в первом этапе у нас рулят матерые программисты, самоорганизующаяся команда, правильная архитектура и всякие хитрые технологии, то во втором уже больше качество собранных требований (заранее собранных), ну а в третьем вообще лишь процессы. Причем в третьем, в противоположность первому, иногда важнее даже начинающие программисты, потому что они согласны заниматься «не интересными задачами», точнее они еще не выросли из них. А те матерые разработчики которые начинали уже выросли, им это не интересно, и даже уволятся если им дать такую задачу. Если рисовать графики важности то получится примерно такая иллюстрация:

Отличный пример всему этому имхо весь опенсурс, часто застрявший на первом этапе. Вот, например, популярный линуксовый десктоп: в нем огромное количество крутых штук, которых нет в коммерческих конкурентах. Это все благодаря матерым программистам. Но в тоже время в нем не сделаны банальнейшие вещи, естественные у конкурентов, и естественные для пользователя. Пример: уже 6 лет висит задачка «показывать превью картинок в диалоге выбора файлов». Казалось бы самая естественная вещь, но висеть будет еще столько же времени, потому что матерому программисту заниматься такимим вещами не fun, это ниже его уровня, а вот процессов, менеджеров и стажеров там очень мало. И о сборе требований, анализе пользователя тоже никто пока не думает. Я не говорю что опенсурс весь такой, есть масса совсем противоположных примеров, но тут изначально условия существования проекта такие, поэтому много примеров.

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

Стахановец vs Бюрократ

Допустим один программист пишет код, просто пишет код, потому что JIRA полная задач. Ему нужно их сделать, кровь из носу.

А другой донимает его проблемами того что в ТЗ бардак, заказчик толком не понимает что хочет, код у нас не протестирован, не описан толком, в коммитах svn непонятно что, библиотеки используются не правильные, и вообще в проекте разруха, а никому до этого нет дела.

На самом деле не то чтобы дела совсем нет, но некогда с этим разбираться, тут работы 3 вагона. И первый программист выполняет эти задачи. Оба правы, но конфликт есть. Если принять одну сторону, то задачи сделаем, но рано или поздно проект придет в такое ужасное состояние что проще будет махнуть рукой и уйти в другой проект. Это всем знакомо, каждый разработчик наверное успел поучаствовать в проекте, в котором все было плохо поставлено.

А если заняться улучшением процесса, то все будет внешне очень правильно, но задачи останутся не решенными, и в конце концов проект тоже провалится. Если вспомнить Кента Бека, который на Крайслере воплощал свою идею правильной разработки, методологию XP, то проект вынуждены были закрыть, не смотря на то что по нему было написано столько книг восхваляющих то как правильно его вели.

Стахановец vs Изобретатель

Программист опять пишет код, просто пишет код, потому что 3 вагона еще не закончились (на самом деле он просто не видит сколько там дальше вагонов в этом составе).

А сосед придумывает какие-то хитрые схемы развития, пусть не Канзас Шафл, но на пару лет тоже хватит. С начала утверждает что вот этот метод делающий «2 + 2» никуда не годится, его нужно разбиться распределенные сервиса (для стабильности, конечно). Проходит 1 час и новая идея: надо складывать все в очередь на вычисление, периодически поднимать кластер на Amazon EC2, и там Hadoop'ом считать сумму. Потом еще подумает и скажет что Hadoop это фигня, надо на Erlang, потому что mapreduce это прошлый век, и что тут есть огромный потенциал к тому чтобы еще лучше распараллелить, но нужны особые возможности.

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

Вот так 5 минутная задача превращает в большой подпроект на пару месяцев. С одной стороны нужно попроще делать чтобы быстрее закончить, и, с другой стороны, учитывать то что продукт должен прожить долго. Мир меняется с огромной скоростью, и не вариант когда сразу после запуска он тут же выходит на максимум своих возможностей, и дальше не выдерживает роста нагрузок, сложно расширяем новыми возможностями и вообще уже устарел. Хотя устареет он скорее всего как раз от того что писали слишком долго, придумывая слишком много новых фишек.

Бюрократ vs Изобретатель

А что если у нас столкнутся наш борец за правильность процесса и изобретатель? Для первого все идеи второго это просто саботаж. Ведь план работ уже утвержден, ТЗ написано, сроки зафиксированы. Между прочим за каждую строку ТЗ он бился часами, там все выверено. Ну какие еще новые идеи? Какие изменения на ходу? Один раз придумали, зафиксировали, и больше никаких идей! И вообще это все непроверенные технологии, их нельзя на живом проекте начинать использовать. Вот пройдет пару лет, заслужат они уважения, вот тогда можно думать. И только после того как в ТЗ внесем, до старта проекта! А сейчас все это ужасно ненадежно, все библиотеки написано черт знает кем, они не протестированы, API не задокументирован, и наверняка криво написаны. Прежде чем предлагать возьми и посчитай что это даст, подходи только с цифрами, где точной цифрой будет указан какой будет прирост производительности, или что там оптимизируем.

Да это же задушит все идеи нашего изобретателя. Вписывать в ТЗ? Писать отчеты? Проверять качество кода? Ну и что что пока не стабильно, будем перезапускать периодически. Ждать пару лет? Да так ничего не успеть, и отстать навсегда. В результате он плюнет и скажет что до него докапываются, до каких то мелочей, и нет больше изобретателя.

Конфликт

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

В команде должны быть все люди с противоположными взглядами, и они должны отстаивать свое мнение, конфликт должен быть, именно благодаря ему проект не уйдет ни в одну из крайностей, а будет держатся оптимальной середины, вырастет вовремя хорошим и качественным, а не уродцем, которого тут же хочется забыть.

Он выделил 4 роли: Producer — Administrator — Enterpreneur — Integrator — сокращенно PAEI. Адизес описал все в общем случае, мне же это интересно на примере команды разработки ПО. Только я позволю себе перевести названия ролей не дословно.

Стахановец — Producer

Делает работу, здесь и сейчас. Поставь ему задачу и он ею тут же займется. И у него всегда много задач, всегда есть что делать, даже поздно вечером и даже ночью. Почти идеальный работник, большинство хороших разработчиков именно такие.

Ему важно что он делает, и как. С презрением смотрит на все что не помогает в его работе. Ну например багтрекер, отчеты о проделанной работе, письма и тем более все эти совещания. Зачем они ему? Он и так знает что он делает, что сделал и что дальше ему делать. И каждая минуты потраченная на эти, казалось бы, бесполезные вещи отнимает время от выполнения своей основной работы, что он очень не любит.

Бюрократ — Administrator

Этому уже важен не столько результат как процесс. Главное чтобы все было сделано правильно, оптимально, с использованием наилучшей технологии, чтобы все потенциальны ошибки были учтены в документации, все требования собраны, а весь код протестирован и задокументирован, и т.д. И он все сделает для того что бы так и было.

Он потратит неделю на вылизывание небольшого скрипта, пусть и одноразового. Для него просто унизительно сделать что-то неправильно, даже если цена правильности в сотни раз выше цены задачи. Но задачу доведет до конца, сделает все как положено, в этом можно на него положиться. Если задача правильная, конечно, за неправильную задачу вообще не возьмется.

Изобретатель — Interpreneur

У него всегда куча идей о том что еще нужно сделать, что улучшить, что вообще переписать, просто фонтан предложений. Когда у него появляется задачка, совсем маленькая, он добавит кучу дополнительных фич, и предложит большое комплексное решение, уже совсем новое. Возможно даже прорыв, не что-то серое, что было в начале, а гениальное изобретение.

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

Политик — Integrator

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

Конфликт ролей

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

Рекомендую прочитать одну из книг этого автора, например Идеальный руководитель: Почему им нельзя стать и что из этого следует или почитать в инете, если интересны подробности, и, например, то как согласовать эти роли и добиться конструктивного конфликта. Я, в свою очередь, постараюсь тоже написать об этом, чуть позже.

Ну и, бонусом к оценке сроков, идут интересные слайды про «Персики и Лимоны», как отличное дополнение к принципу Питера

В сети находите 3 варианта покупки:

• 10 тыс. руб — и как получится, может завтра, а может через месяц, может вообще не доставят, но денег в любом случае не вернут. К тому же на корпусе могут быть какие-то подозрительные царапины и непонятные люди в списке контактов. Или вообще другой телефон привезут, ну и может денег сверху попросят, лишь потому что у них там какие-то непонятные вам «проблемы возникли с товаром».
• 15 тыс. руб — может быть завтра уже доставят, но черт его знает на самом деле, есть некоторая путаница со складами, курьерами, наличием, в общем они обещают на днях позвонить и сказать точнее что как будет, может сразу доставят, может в течении недели, ну или как получится.
• 20 тыс. руб — послезавтра ровно в 14:25 курьер с товаром будет у вас в офисе. точка.

Вы какой выберете? От чего зависит решение?
Если по цене, то третий вариант в 2 раза дороже первого. С другой стороны у него гарантия доставки, или вы готовы сидеть на одном месте и ждать курьера сколько угодно?
А если вы руководитель компании и закупаете их сотрудникам, что вы им скажете? А перед своим руководителем в такой ситуации как обоснуете выбор и отчитаетесь?

На самом деле почти риторические вопросы, просто повод поразмышлять о том как думает заказчик разработки софта. Цена, предсказуемость результата и пр.

PS: а еще можно было бы это разбить на 5 вариантов, чтобы сопоставить с уровнями CMMI

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

Помимо понимания зачем все это, что у нас есть и какой смысл это несет, самое главное что я вынес из книги для себя — это то что не нужно оценивать срок как таковой, пытаться угадать дату, нужно оценивать промежуток внутри которого наиболее вероятно завершение задачи, т.е. гораздо лучше что-то типа «с вероятностью 90% это сделаю от 1 недели до 5 месяцев», значит быстрее ну явно никак, только пистолет к виску приставить, и дольше будет только если случится что-то из ряда вон. Мы здесь ставим рамки проекта. Ну и по мере анализа, разработки и пр. можно давать более точную оценку, сужая этот промежуток, и в идеале реальный срок и эта оценка должны сойтись. Я конечно очень поверхностно идею передал, нужно понимать все тонкости и их тоже много, но суть примерно такая. Ну а вообще там много других оцень полезных мыслей, это лишь пример.

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

Чаще всего такие решения принимают когда поддержка текущей программы становится слишком дорогой, т.к. со временем изменения становятся все дороже и дороже. Ну и в итоге цена изменений становится совсем высокой и компания вынуждена выкинуть текущий продукт, и переписать все заново.

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

Метафора «Design debt/Долг проектированию» объясняет эту ситуацию. Когда команда работает под давлением сроков, то в первую очередь приносится в жертву архитектура приложения. Это как брать кредит по высокий процент. Команда получает ускорение в краткосрочном периоде, но с этого момента все изменения становятся дороже, эти изменения как бы выплачивают проценты по кредиту. Единственный способ перестать платить этот высокий процент, это исправить первопричину и сделать то что не было сделано когда решили отказаться от качественного дизайна.

Большинство команд, конечно, не думаю в понятиях «долга проектированию» и не пытаются выплатить «кредит». Но если у вашего проекта очень сжатые сроки, то вы наверняка уже взяли этот кредит. И он уже начинает требовать бОльшие выплаты, которые опять же требуют взять очередной кредит, и т.д. по спирали, пока проект не задохнется от бремени долга.

Можно нарушить эту цепь, но это требует достаточно больших усилий. Начать нужно с того чтобы команда поняла что «кредит проектированию» неприменим в текущем проекте. Также всех нужно научить методам постепенного дизайна, рефакторинга, и пр. методам улучшения качества кода. Ну и, конечно, нужно выделить время на применения этих методов.

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

Кредит проектированию это как кредит по кредитной карте: легко получить, быстро помогает в текущей проблеме, но влечет большие проблемы, до тех пор пока все не выплатишь. Почти каждая команда сможет работать быстрее, когда расплатится с этим кредитом. Поэтому требуйте постоянного улучшения качества разрабатываемой системы. А эти «лишние» затраты времени окупятся в будущем.

Иногда сложно увидеть долг проектированию, но если вы встретите нижеуказанные проблемы, то вы уже увязли:

• Команда отзывается о программе с упоминанием оборотов «куча заплаток», «хак», «работает и не трогай», «кто это понаписал!» и т.д.
• Команда часто сталкивается с неожиданными проблемами.
• После каждого исправления появляется череда новых ошибок.
• Ошибки которые уже исправляли появляются снова, через некоторое время.

Чтобы не залезть глубоко в долги старайтесь больше внимания уделять следующему:

• Увеличивайте время на разработку, ну или по крайней мере не подгоняйте и не урезайте сроки.
• Настройте команду на постоянное улучшение качества кода проекта.
• Постоянно занимайтесь рефакторингом, редизайном, код ревью и пр.
• Возвращайте этот «кредит» постоянно и постепенно, не пытайтесь все вернуть за один подход.

На основе:
«Design Debt», Software Profitability, February 2004, by Jim Shore

Под катом более-менее подробной описание сути этого подхода, в вопросах и ответах.

Что такое standup?

Это короткая ежедневная встреча, на которой обсуждается прогресс и текущие работы. Это основа коммуникаций в компании, передачи информации между участниками, организации в команде. Можно назвать это мини отчетом/историей дел и мини планированием.

Для чего standup не подходит?

Стендапы не предназначены для принятия важных решений, решения проблем и пр. Ими не стоит заменять встречи для обсуждения проблем, которые должны обсуждаться отдельно на формальных собраниях.

Какова цель таких встреч?

• Повысить информированность о текущем прогрессе и задачах.
• Скорректировать и направить деятельность команды в единое русло.
• Выставить приоритеты и сфокусироваться на работе, до следующего стендапа.
• Увидеть текущие проблемы вовремя, а также дает возможность помочь с решением, т.к. становится известно, у кого какая проблема возникнет, и кто способен помочь.
• Улучшить командный дух и коммуникацию в команде

Что происходит во время таких встреч?

Вся команда собирается в договоренное время, один раз в день в определенном месте. Люди встают по кругу или лицом к доске с задачами и планами.

По кругу каждый из участников отвечает на следующие 3 вопроса:

1. Что я сделал с последнего собрания?
2. Что я буду делать сегодня?
3. Какие сложности нужно будет решить?

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

Кто должен присутствовать?

Присутствовать должны лишь люди участвующие в разработке текущей итерации, это разработчики, тестеры, люди, отвечающие за итерацию.

Нужны ли какието временные рамки?

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

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

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

Когда проводить встречу?

Есть 3 варианта:

1. Сразу с утра, перед работой
2. В середине дня, после или перед обедом
3. В конце дня

Первое отлично работает, когда вся команда собирается в одно время с утра, без опозданий. Стендап начинает рабочий день, помогает запланировать сегодняшние дела, сфокусироваться на задачах, распределить приоритеты. Мне так кажется это самый идеальный вариант, с утра обычно с трудом начинается сама работа, всегда есть куча задач, за которые просто страшно браться, и не хочется все это планировать. А вот обсудив в компании, все становится на свои места и, легко и непринужденно, «утро» превращается в рабочий день.
Также начальник узнает о текущих задачах и проблемах, которые будут в течении дня.

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

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

Должен ли standup быть запланирован на определенное время?

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

И не надо ждать опоздавших, встреча она для команды, а не для отдельных опаздывающих личностей!

Нужен ли кто-то, кто инициирует эти встречи?

Если команда только начинает подобную практику, то неплохо бы иметь человека который бы напоминал людям, помогал начинать разговор, предотвращал паузы. Главная функция такого человека помочь команде собраться, научится проводить встречу. Далее любой участник может начинать обсуждение.

Кто отвечает за то, чтобы эти встречи работали?

Как и другие «гибкие» процессы, стендапы созданы командой для самой себя. Поэтому команда сама должна отслеживать эффективность этих встреч. Если команде самой кажется, что что-то не получается, то нужно совместно решить что нужно исправить. Со стороны может быть только некий инициатор, который научит команду проводить такие встречи.

Могут ли некоторые члены команды не посещать эти встречи?

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

Являются ли стендапы аналогом остальных формальных встреч?

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

Вообще, если думать о стендапе как об «ответе на три вопроса», то мы недалеко уходим от простого отчета перед начальством. В таком случае «ответ» и «вопрос» ассоциируются с допросом, а не с общением.
А стендап не должен выглядеть как отчет перед начальством. Это должно быть ответами на вопросы как в обычной беседе, т.е. просто собрались командой, обсудили положение дел и вернулись к самой работе.

Для чего нужен мячик, или какой либо иной указатель при общении?

Указателем/маркером/пр. может быть небольшой резиновый мячик, или другой предмет, который передается друг другу, чтобы показывать статус держащего. Только тот, у кого этот предмет, говорит в это время. Это помогает не уходить далеко при длинных разговорах, хотя в таких случаях, когда с кем-то может начаться длительная дискуссия, можно передать ему мячик, но лучше договорится обсудить это после собрания, т.к. здесь нужно лишь общее обсуждение, а не решений конкретных задач.

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

Могу ли я говорить если у меня нет мячика? Это будет нормально, если я кого-то прерву?

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

Как детально углубляться в задачи?

Это один из самых сложных вопросов, и уровень детальности зависит от команды. Стендапы помогают изо дня в день сообщать статус проекта, и любой пришедший на стендап должен понимать кто чем занимается, и с какими проблемами сталкивается.
Размер команды в данном случае сильно влияет на детальность. Чем меньше команда, тем легче передать информацию, и в ней можно видеть более живую и понятную всем дискуссию(и не только на стендапе), чем в большой команде.

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

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

Конечно же, нет. Цель стендапа это передаче информации, и если ваш партнер уже все рассказал, вам лишь нужно сказать что вы планируете на сегодня. Если партнер что-то пропустил, можно добавить пару своих слов, но не повторять все с начала.

Если какие-то требования для ведения стендапа?

• Члены команды должны свободно себя чувствовать во время общения
• Все члены команды должны иметь возможность беседовать друг с другом, поэтому у распределенных команд с этим есть небольшая проблема
• Доска с задачами и планом очень полезна для таких собраний, но не является совсем обязательной частью
• Для стендап митинга также вовсе не обязательно соблюдать прочие «гибкие» методики разработки

Можем ли мы проводить более одного стендапа в день?

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

Может ли стендап быть распределенным?

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

Стоит ли делать какие-то заметки во время стендапа?

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

Нужно ли как-то подготавливаться к собранию?

Стендапы проходят у доски с текущими задачами и графиком работ. И будет полезным перед собранием приводить все это в порядок, относительно текущего состояния дел.
Если команда работает с небольшими задачами, на 4-8 часов, тогда участники смогут просто указывать на сами задачи, не тратя время на описание самой задачи.
В начале, когда команда или отдельные участники начинают практиковать стендапы, будет полезно собраться за несколько минут и продумать свои ответы на «3 вопроса». Это поможет в дальнейшем четче и быстрее рассказать о них на самом собрании. После небольшой практики от этого можно отказаться.

Нужно ли обновлять список текущих задач (на доске) и планы во время собрания?

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

Надо ли определяться с партнерами для парного программирования во время стендапа?

В идеале, сразу после стендапа, все собираются возле плана на день и решают с кем быть в паре, основываясь на текущих планах. И иногда полезно побеседовать перед стендапом, чтобы определиться с парной работой.

Заменяет ли стендап полноценное собрание?

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

Нужно ли вести какой-то учет присутствующих? Что если кто-то пропустил?

Стендап это контрольная точка, они дают знать о том, что происходит изо дня в день, это основа для обсуждения информации касающейся вчера, сегодня и, может быть, завтра. Поэтому учет не нужен и посещение требуется если вы присутствовали/будете присутствовать в обсуждаемые дни. Если кто-то уходит в отпуск, он может придти на стендап по возвращению. По возвращению он обычно не будет знать чем ему конкретно заняться, и как раз на стендапе он сможет или обсудить это, или ему могут подсказать какие задачи ему стоит планировать.

Вольный перевод статьи Naresh Jain: FAQs on Standup, с некоторыми личными дополнениями.