В период активной фазы проекта наш менеджер пытался ввести в обиход утренние собрания команды (8-10 человек). 

Планируемый регламент: 3 раза в неделю, по 20 минут. 
Стиль проведения: каждый говорит о том, чем он занимается в данный момент + обнаруженные проблемы и т.п.

В конце концов команда эту практику зарубила. Обычно собрания затягивались и длились минут 30-40, и многие были против такой потери времени. Многие, к тому же, просто не приходят на работу ко времени начала митинга (к слову, через полтора часа после официального начала рабочего дня). 
А мне, напротив, очень понравилось - когда, например, уезжает тимлид, и я его подменяю, то я автоматически оказываюсь в курсе всех дел, знаю, кто чем занимается, какие есть открытые вопросы, знаю сроки планируемых релизов и т.п. А сейчас - в аналогичной ситуации, не владея информацией, я внезапно узнаю, что завтра релиз.

Собственно, вопросы:

• Используете ли вы регулярные собрания?
• В каком формате они проходят?

Это сообщение отредактировал(а) batigoal - 11.7.2007, 08:32

думаю, что это повысит производительность команды.

Ужасно. А какова ваша роль в проекте?
Я предпочитаю такую практику: на старте проекта митинг прогеров с архитекторами, разбивка проекта на итерации в зависимости от сроков и объема. Затем по итерациям собственные митинги... Каждый день - все-таки отнимает силы. А чтобы быть в курсе - достаточно ввести ежедневную отчетность.. Но ненавязчивую только 

У нас такие собрания проходят ежедневно, обычно длятся от 10 до 30 мин. Первоначально это был SCRUM-митинг в чистом виде, т.е. с ответами на три стандартных вопроса (что делал вчера, что буду делать сегодня, с какими проблемами столкнулся) и с ограничением времени не более 15 мин. В последствии формат изменился: если возникают проблемы/вопросы требующие внимания большей части команды, то по возможности кратко обсуждаем их на митинге. Если начинается общение на темы, непосредственно касающиеся лишь 2-3 человек, то останавливаем и заинтересованные лица обсуждают свои вопросы уже вне рамок митинга. Пока такой вариант устраивает, хотя вопрос о целесообразности "чистого" митинга остаётся открытым. На одной чаше весов здесь то, что затягивание собрания (иногда до часа) отнимает время, на другой - даже если дискуссию начинают 2-3 человека, часто она перерастает в общее обсуждение и "коллективный разум" находит более быстрые и качественные решения.
Фиксированное время начала митинга для нас не подходит, т.к. в команде есть несколько студентов и их график работы зависит от занятий в институте, поэтому в конце каждого собрания оговариваем время начала следующего. Обычно получается в районе 16:00. Теоретически, утренний митинг имеет преимущество "утреннего настроя на работу", но нас вполне удовлетворяет сложившийся режим.

Для нас основные достоинства ежедневных митингов:
1. Все члены команды в курсе состояния дел в проекте в целом.
2. Каждый озвучивает проблемы, с которыми сталкивается, и пути их решения. Часто оказывается, что другие уже решали подобные задачи или где-то что-то об этом читали и т.п. В итоге не приходится изобретать велосипеды.

Иногда получается, что все и так в курсе происходящего в текущий день (например, работали весь день в плотном контакте), в этом случае митинг не проводим.

Вот здесь неплохо сказано о сабже: http://www.javenue.info/post/59

Это сообщение отредактировал(а) mindflyer - 11.7.2007, 10:23

Надо командным решением дать по жопе


Нужно контролировать. У нас как-то и на 1,5 часа растягивалось. ососбенно когда директор хотел поучаствовать..
Жёстко пресекать. "А вот у меня... если вам конечно интересно, была такая вот штука" - нахек!


По жопе. Морально. В след. момент он может влететь как и ты перед релизом. Надо втолковывать.


Вот.


Аха. Самое то 

Это сплачивает команду.
Видишь забытые рожи.
В курсе дел товарища и команды
Держишь в башке всё, что может на тебя свалиться
Вобщем, это аналог "боевого листка" онлайн
Я обеими руками всегда и везде за такие собрания

Технические митинги - отдельно. Даже сразу после планёрки. Ест ьпроблема? - закончили скрам, кто нужен - остался

ЗЫ: сейчас у нас команда ровно в 5 человек, сидящих в круг(почти в круг)
Раз 5 в день возникает стихийный краткосрочный митинг на 5-7 минут. 
Планёрок нет, но может заведём.

Разработчик. По причине того, что официальный development team lead выдвинулся в proudct manager'ы, его роль выполняем мы с архитектором (архитектор - в большей степени, но он-то сейчас и в отпуске). 


Дело в том, что эта отчётность будет отправлена конкретному человеку, а не всей команде.


Команда-то как раз против  "За" только я с менеджером.

Но в целом, как я вижу, высказывания об этом подходе (оказывается, это часть SCRUM'а?) положительные. Возьму методbre на вооружение.

Это сообщение отредактировал(а) batigoal - 11.7.2007, 10:48

mindflyer, интересная заметка, спасибо за ссылку.

Я неверно выразился.... "Командирским" 


"Я-я, их бин студебеккер" 

Порой напрягает даже манагера. Но в целом полезно.

А у вас участники команды не знают о сроках?
Это должна быть доступная информация для всех разработчиков.

Нет, не знают.

А в чём причина такого неведения, команда разработчиков работающая над проектом слишком большая, или разбросана по разным комнатам.  Просто интересно, получается, когда team lead распределяет обязанности, он не обговаривает сроки?

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

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

Это сообщение отредактировал(а) stron - 19.7.2007, 16:08

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

Даты не скрываются, но и не афишируются. Видимо, причина этого "держания в неведении" в том, что релизы нерегулярны (сейчас пора maintenance'а).


Да, именно так.



Есть такой момент. Но я и не хочу съезжаться в один угол. Вариться в собственном соку - тоже не очень хорошо.

Ужос! ИМХО, это в корне не верно. Похоже на то, что менеджмент замалачивает инфу, чтобы обделывать свои грязные делишки   

Эх, вот если бы ещё при жизни наступил коммунизм и разработка везде бы велась по уму!..
На прошлой работе, где я был, ситуация была примерно та же. Есть сроки выпуска версий, о которых все знают. А бывают и такие версии, о которых становится известно лишь за пару дней и все начинают лихорадочно выправлять (или хотя бы откатывать) код, чтобы сборка была работоспособной. В основном это было из-за банальной безответственности руководства - решили делать сборку и никому не сообщили. А потом ещё интересовались - "ну как, завтра сборку точно даёте?". Было такое несколько раз на моей памяти. Руководитель разработки филиала глубоко задумывался, определяя шансы на успех, потом звал всех и сообщал, что "завтра вот, так что сегодня и завтра Ж...".
Сборку обычно отдавали в нормальном виде, но руководство из-за таких "шалостей" никто особо не любил.