Интересно узнать, в какое время на вашем проекте проводят ежедневный митинг: daily standup (или daily scrum)?
Например: утром, в обед или вечером? Если есть на то определенные причины, напишите плиз, почему именно в это время.
Не важливо коли, важливо проводити його саме тоді, коли програміст тільки почав роботу над чимось, щоб не дати йому можливості зосередитись і попрацювати пару годин! Якщо для цього потрібно більше одного стендупу — то треба проводити їх частіше.
В ідеалі треба робити так — як тіки тім прийшов, нехай посидять годинку, а тоді бах, стендуп! Тоді ше годинку і нехай на обід ідуть (обов’язково всіх вигнати на обід).
Після обіду не дайте тіму часу сісти за таски, як тільки побачите, що люди втягуються, скликайте мітінг, а то вони (девелопери), не дай Боже, тай щось встигнуть зробити.
І основне — не забувайте розбавляти стендупи різними «дуже важливими» мітінгами (пам’ятайте, не підряд, а тоді, коли людина сидить і починає втягуватись — тоді асап робіть мітінг, бо воно ще встигне код написати!)
«нужно больше митингов» ©
Не проводим.
завидую вам. Ни разу для себя не получил пользы от того, как кто — то расскзазывает, что он сделал или будет делать или какие у него проблемы ...
Почему бы не проводить его в чате? Синхронные коммуникации убивают продуктивность программиста.
Сейчас 10:30, уже несколько раз менялось за последний год.
Не во всех командах народ на 10 приходит. В некоторых кто-то может на 12 появляться или вообще после обеда.
Не важливо коли, важливо проводити його саме тоді, коли програміст тільки почав роботу над чимось, щоб не дати йому можливості зосередитись і попрацювати пару годин! Якщо для цього потрібно більше одного стендупу — то треба проводити їх частіше.
В ідеалі треба робити так — як тіки тім прийшов, нехай посидять годинку, а тоді бах, стендуп! Тоді ше годинку і нехай на обід ідуть (обов’язково всіх вигнати на обід).
Після обіду не дайте тіму часу сісти за таски, як тільки побачите, що люди втягуються, скликайте мітінг, а то вони (девелопери), не дай Боже, тай щось встигнуть зробити.
І основне — не забувайте розбавляти стендупи різними «дуже важливими» мітінгами (пам’ятайте, не підряд, а тоді, коли людина сидить і починає втягуватись — тоді асап робіть мітінг, бо воно ще встигне код написати!)
«нужно больше митингов» ©
Наш PM точно так и делает, у лидов митинги с 11 до 17 (с небольшими перерывами), так что я рад, что я не лид и в такой ситуации не собираюсь становиться.
ещё хорошо начинать иногда с задержкой в
чтобы дев приостановил работу и не то чтобы ждал, а подвисал как-бы.
ну и напряжёнку конечно нагнетать необходимо.
а таймшитить митинги несолидно, там же не долго.
И каждые 1,5 минуты совершенно необходимо спрашивать в общем чате про статус всяких "super-critical"- багов, которые уже полгода валяются.
Спасибо большое за коменты!
в 10:00, причина проста, перед початком робочого дня узгодити свої плани на цей день, і не перериватися пізніше.
а так команда без планов работает?)
?
Есть система управления тасками RedMine/JIRA и планирование на Sprint (прочий промежуток времени), все девелоперы видят какие таски можно взять, над какими можно работать, QA видят что можно тестить, что готово и можно закрыть. ИМХО стендупы — наследие совка (пятиминутки).
В моем понимании количество любых совещаний должно быть сведену к минимуму и на них должны присутствовать только те, кого это касается, а не все подряд, которые засыпают на митингах.
С другой стороны как любой руководитель оправдает свою «занятость» и покажет видимость деятельности без совещаний?
Планування, борди і т.д. — це все окей, але, скажімо, ти не встиг виконати запланований-проестімейчиний таск на вчора, від виконання твоєї роботи, залежиить робота твоїх тіммейтів. Як донести до всієї команди і тімліда, що ти не встигаєш, і пізніше можливо завалиться спрінт через тебе, без ранкових стендапів ? Додати «remaining estimate» в Jiri, і хай інші моніторять за твоїми тасками, поки ти не закриєш їх? ІМХО не можна абсолютно все автоматизовувати, десь треба залишити трошки «людського» =)) Я сам противник частих мітингів протягом цілого дня, але перед початком роботи сказати пару слів: «В мене все ок, я зробив то, то і то, або в мене не все ок, поможіть мені хтось», я вважаю більш ніж виправданим.
Як донести до всієї команди і тімліда, що ти не встигаєш, і пізніше можливо завалиться спрінт через тебе, без ранкових стендапів ?Визуализация прогресса рулит. Допилить индикатор по часам и %сделанного.
Для тех кто в танке есть еще обсуждения в skype между членами команды, какие таски выполены, какие в работе какие critical и т.д. Это гораздо полезнее этих искусственных совещаний. Если надо что-то помочь неужели надо ждать начала следующего дня? Подошел — попросил и т.д.
Никакого оправдания у стендап-ов нет за исключением ИБД у тех, кто их проводит.
А печенюшки поесть? А шутки пошутить?
А асоциальных у нас запирают в одиночках — и там они кодят, прикованные к батарее, за еду.
А асоциальных у нас запирают в одиночках — и там они кодят, прикованные к батарее, за еду.В вашу фирму я не пойду.
Вы хоть понимаете разницу между социальным общением по интересам и обязаловам типа бесполезных митингов? Или вы категоричны во всем?
Работа в одиночной камере, где ни менеджеры, ни вино с женщинами не отвлекают от компа...
Pазве это не мечта любителя работать без тиммитингов?
Мне не нравится «одиночная камера», давайте переименуем ее в личный кабинет со строгим режимом доступа (только тех, кто приносит еду), в скайпе мне тоже всякие олухи не нужны. К батарее приковывать не надо.
Тогда пожалуй полученная меня ситуация устраивает: я делаю качественно свою работу, меня никто и ничто не отвлекает, руководство довольно.
А любители поболтать и делать ИБД вроде совещаний, «командного духа» целыми днями пусть продолжают в том же духе.
у стендапа есть две причины:
1. Интровертность большинства разрабов (хрен он сам скажет, что зарылся). На стендапе это психологически проще.
2. Лучше дернуть человека один раз, чем каждые 10 минут узнавать нет ли у него проблем.
1. Интровертность большинства разрабов (хрен он сам скажет, что зарылся). На стендапе это психологически проще.Адекватный человек сам обратится за помощью к кому надо, если у него проблемы. Опять же это относится не к интернам, а чувакам по-опытнее.
2. Лучше дернуть человека один раз, чем каждые 10 минут узнавать нет ли у него проблем.А если чувак пришел на работу, вник в таск и ему 2 часа ему осталось доделать, а тут стендап с опозданием, который выбивает из колеи. Не будь стендапа, он бы закончил.
Почитайте на досуге про асинхронный режим. В данном случае чувак сообщит как закончит: через 0,5 часа / 2 часа / под вечер, а если капать на мозги каждые 10 минут, то он хрен знает когда закончит.
Адекватный человек сам обратится за помощью к кому надо, если у него проблемы.Так в том то и проблема, что если всех «неадекватных» уволить — это половину программистов разогнать надо. Не самых худших, притом.
Вообще, мне как менеджеру — стендап нафиг не нужен был бы, если б каждый программист всегда логировал бы время в джире, работал по приоритетам, не забывал двигать таски и синхронизироваться с сотоварищами. Но пока этого нет — стендап меньшее зло.
Так в том то и проблема, что если всех «неадекватных» уволить — это половину программистов разогнать надо.А теперь уже ваш кристальный шар дал сбой. Я нигде про увольнение не писал. Я писал, что интровертов нужно оставить в покое и дать им делать свою работу.
В нашей команде синхронизация идет по скайп и RedMine, стендапы и всякие сборища нам не нужны и мы чаще 2 раз в неделю не собираемся.
Адекватный человек сам обратится за помощью к кому надо, если у него проблемы.
Я нигде про увольнение не писал. Я писал, что интровертов нужно оставить в покое и дать им делать свою работу.Т.е. зарылись на месяц на простой ерунде — и фиг с ними?
стендапы и всякие сборища нам не нужныОни всем не нужны. Но есть проблемы, которые решаются только стендапами/планерками. Если у вас таких проблем нет — то и отлично.
Т.е. зарылись на месяц на простой ерунде — и фиг с ними?Вы или не читаете весь коммент или упорно выдергиваете только то, что выгодно вам и впадаете в крайности.
В нормальном режиме вся команда, в т.ч. исполнитель и лид прекрасно знают redline и deadline каждого таска и если redline еще не наступил, то задержка на
Если у вас таких проблем нет — то и отлично.Спасибо.
Экстремальный случай, приведенный вами, имеет отношение только к интернам и самым младшим джунам,Если бы. Не увидел высокоприоритетный таск, юзает не тот модуль/библиотеку и так далее.
ИМХО — надо искать и вычленять корень проблемы, а именно — помочь или «пнуть» человека.Ну вот стандап это и есть способ поиска проблемы. Тут же ещё психологический момент: никого не дергаешь, а «пасешь» одного человека — он начинает обижаться (да, и такие есть).
Если бы. Не увидел высокоприоритетный таскДля этого у тасков есть специальные значки и label-ы, оговоренные командой.
не тот модуль/библиотеку и так далее.Наша команда набрала 12 баллов из 12 по тесту Джоэла Так что, то, что вы пишете исключено. Есть 2 системы контроля версий, ветки для разных версий, система сборки/деплоя в одно действие.
Тут же ещё психологический момент: никого не дергаешь, а «пасешь» одного человека — он начинает обижаться (да, и такие есть).
Если в других командах где я работал раньше (не моей) было: 1 тимлид, 1 «ледокол» и 4 «клоуна» (3 из них по знакомству), то пинать получится только одного «клоуна», поскольку за пинание других могут пнуть вас. Нет никакого смысла пинать «клоуна» при всех, поскольку он будет обижаться даже если накосячил.
Слава богу в моей текущей команде: 1 тимлид, 4 «ледокола» и 2 «клоуна» (1 из них по-знакомству). При таком раскладе мы втроем (1 ледокол на dev-opsе) успеваем сделать больше, чем другие команды в 3 раза большие по размерам, но отличающиеся по соотношению ледоколы/клоуны.
Так что, то, что вы пишете исключено.Я же говорю — проблем нет, стендап не нужен.
Нет никакого смысла пинать «клоуна» при всех, поскольку он будет обижаться даже если накосячил.Если тимлид не может убрать человека из команды — то он козел отпущения, а не тимлид.
С точки зрения разраба — да, нафиг стендапы/отчеты, берём только классных людей, и все будет ок.
А вот с точки зрения манагера — далеко не всегда возможен вариант «уволить всех и нанять реальных спецов». Поэтому нужно вырабатывать варианты взаимодействия с неидеальной командой (что не исключает того, что некоторых людей нужно увольнять при любом раскладе)
Если тимлид не может убрать человека из команды — то он козел отпущения, а не тимлид.Второй раз полностью согласен с вами.
А вот с точки зрения манагер
Менеджер — это человек, управляющий чем либо. Если тимлид не направляет команду — то да, он не менеджер (ну и будем честны — не тимлид).
Менеджер — это человек, управляющий чем либоЯ управляю своим компьютером и сервером CI, я — менеджер?
Если бы ваш компьютер был рабочим — то да
А вот с точки зрения манагера — далеко не всегда возможен вариант «уволить всех и нанять реальных спецов».С точки зрения манагера — далеко не всегда возможен вариант «уволить нах. манагера как совершенно лишнее в процессе звено». Приходится:
вырабатывать варианты взаимодействия с неидеальной командой (что не исключает того, что некоторых людей нужно увольнять при любом раскладе)
С точки зрения манагера — далеко не всегда возможен вариант «уволить нах. манагера как совершенно лишнее в процессе звено».как раз манагера убрать проще всего.
как раз манагера убрать проще всего.Ни разу не наблюдал такого за свои уже 4 года в IT. Чаще всего приносили в жертву QA и иногда developer-ов, навешивая на них косяки «задним числом», но менеджер всегда выходил в белом костюме, когда публика была в *овне.
4 года в бодишопах?Да, 1 — подаван на front-end в сайтостроительной конторе.
ну так в бодишопе — манагер это человек компании, а разраб — это товар.
И естественно, заказчику (особенно «постоянному») будут говорить что «извините, плохой программист», а не «у вас тупые запросы» (именно запросы заказчика транслирует манагер).
В продуктовых же компаниях все несколько иначе — там важен результат(заезжено, но что сделаешь?). Поэтому манагер, который не генерирует «полезность» — довольно быстро идет нафиг.
Да, думаю со временем переходить в продуктовые компании или даже стабильные стартапы. Надо успеть соскочить с галеры, пока не успел отупеть и стать таким же.
стабильный стартап — это и есть продуктовая компания :)
Ни в коем случае не хочу сказать, что продуктовые намного круче бодишопов. Тут уже — кому что. Если вам (как мне) для работы нужно: стол, стул, ноутбук и имеющая смысл работа — то да, продуктовые лучше. Если же плюшки, качество кофе, спортзал и страховка важнее — то лучше все таки работать в бодишопе.
В нормальных продуктовых с печеньками все ок. В бодишопе как раз эта статья может быть и урезана. С другой стороны в продуктовой «с экономией на печеньках» важно понимать, за что ты е... как не по-матерному будет «много работаешь»? ))
Попробуй на годик — сильно прочищает мозги и выравнивает картину мира на предмет: «хм, да вообще-то они везде одинаковые...» ;)
6 лет в продуктовых. Состав разрабов начал меняться еще при мне. Сам я давно ушел — о чем не жалею, хотя на момент ухода всегда было очень обидно — и на сегодня везде состав простых рабочих сменился по нескольку раз. Манагеры — те же.
ЗЫ: к бодишопам примерно то же, но там есть ньюанс: манагеры могут и скачут между «большой тройкой-пятеркой» в ходе своей карьеры. Правда тут снова есть ньюанс: из «скачущих» которых я знаю — как раз достойные. Но «я лид 6 лет работаю» — практически диагноз. По фотографии.
ЗЫ: тут меня поправляют: таки больше 6 лет.
по-знакомствуПризнак того, что в компании не все ок. А также риск того, что «ледоколы» будут сваливать.
А также риск того, что «ледоколы» будут сваливать.«Клоуны» и «клоуны по знакомству» есть в каждой компании. Вопрос только в пропорциях. И для «ледокола» свалить это не вопрос вероятности, это вопрос времени.
Извините, это что, я должен писать код 365-24-праздники дней в году?
И что бы не было такого что я пришел на работу и нету рабочего настроения — значится я ни строчки кода не напишу сегодня и пох на скрам и за это меня уволить?
Нет уж, лучше увольте.
Понимаете какая фишка — я ведь тоже программист. И все комиты приходят ко мне на почту (команда не большая). Так что если у вас уж слишком часто «не рабочее» настроение — уволить вас смогу и без всяких стендапов.
А, ну и да — мыж знаем, что было бы желание, а рассказать чем ты «занят» всегда можно.
Саша, комить по 1 файлу, даже если пак из
Вы не умеете связывать джиру с свн или делать свновские хуки?
P.S. Ну и кто тут о ИБД заикался? :)
И все комиты приходят ко мне на почту (команда не большая). Так что если у вас уж слишком часто «не рабочее» настроение — уволить вас смогу и без всяких стендапов.Вы же пишете, что количество коммитов для вас — признак того, что человек занят делом. Хотите коммитов — ваши подчиненные вам их организуют с соответствующим качеством. В нашей команде здоровая атмосфера и делать такую видимость, как и меряться миллиметрами, абсолютно не нужно.
Я привел коммиты как пример того, что и без стендапа лентяй будет «выделятся». Коммитами(отсутствием), зависшими тикетами и так далее.
Т.е. для выполнения задачи «найти и покарать» мне митинги не нужны. Проблема в том, что «поиск и наказание» — это то, что вообще никому не нужно.
А стендап — это инструмент решения проблем разработчиков (скажем, если нет нужных материалов от заказчика — то я помогу их достать)
P.S. Ну и мое личное мнение: не важно где когда и как ты работаешь, если это не срывает сроки и не создает дискомфорта другим.
Я год пинал команду чтобы они комментарии писали в свн и коммитили вообще что-то более или менее разумное доброе светлое. Две практикуемые крайности: либо коммит чуть ли не каждого измененного символа (всё равно без комментариев, так что понять что идет можно только заглянув в изменения), либо коммит всего вообще огромным куском (обратно без комментариев) с докоммичиванием потом «интеграции» (банально пропущенного, упущенного, несмерженного, убитого насмерть чужого кода — целыми фичами! — и куча вариантов).
Не выпинал. Какие при этом творились «хитроумные хуки по свн» — страшно описать. В конце «насяльника» пришел к выводу, что свн — г. — гит — круто! — и «запланировал переезд» на гит. Благо, в этом я уже не участвовал...
Реальность много суровее. И все равно настроенный процесс не требует или хотя бы минимизирует оперативное «общение». Результат которого — чаще всего ноль. Но сам процесс очень важен для ЧСВ.
не так пинали. Вот когда таска не будет закрываться без правильно привязанных коммитов и полностью пройденного код ревью — вот тогда народ начнет менятся. А «гавканье» в след паравозу ещё ни кого не меняло.
А «гавканье» в след паравозу ещё ни кого не меняло.Это разумное замечание, но девелоперы находятся под давлением со стороны PM, которому важны сроки и у них не всегда получается отстоять всю процедуру как положено с ревью, тестами, доп. билдами и т.д.
А смысл ругаться с PM, если он начальник? Хочешь малокачественный продукт? давишь на девелоперов — ПОЛУЧИ. xD
ну вот мы и подходим к вопросу ответственности. Если у разрабов два начальника (тимлид+ PM) то ничего хорошего из этого ни когда не получалось.
На мой взгляд, лучшая политика, которую может вести тимлид по отношению к PM — это «заткнись или увольняй». Т.е. именно тимлид несет ответственность за скорость/качество разработки, и ПМ на это никак не может влиять (только сменив тимлида)
На мой взгляд, лучшая политика, которую может вести тимлид по отношению к PM — это «зат*кнись или увольняй».Хотелось бы побывать в такой команде.
В нашем случае PM+TL — «спитый коллектив». И TL совершенно до лампочки проект, ему нужно до
Зато он показывает свою лояльность PM-у по 20 раз в день, а с командой почти не взаимодействует.
И крайними всегда выставляются Dev+QA.
Так сказать дуалистическая монархия в действии.
Было время — я хотел пойти PM-ом в один из крупных бодишопов. Но на собеседовании, мои рассказы о построении команды и «вытягивании» проекта — были не интересны. Куда важнее было то, насколько я смог бы вести переговоры с заказчиком и решать конфликты в пользу компании (не команды!). Довольно очевидно, но я об этом сразу не подумал.
Тогда я и понял, что бодишопы — это не моё.
решать конфликты в пользу компании (не команды!)С этого места поподробнее пожалуйста)
Для меня важнее продукт, а не человеческие отношения. И логично, что для PM это минус.
Павел, попробуйте подробно написать в чем суть дела. Пока это отдельные фразы.
Я же описал выше. В бодишопе для манагера, ключевая вещь — это отношения между заказчиком и конторой. Т.е. не важно, сделаем проект или нет, лишь бы заказчик был нами доволен.
Построение человеческих отношений — явно не мой конек. У меня куда лучше получается просто собирать работающий механизм (команду).
В команде тоже важны отношения — да и заказчику важны не только слова, проект сделать тоже надо.
Но в целом выбор понятен, PM vs CTO, ok.
Построение человеческих отношенийХе-хе-хе. Я бы не назвал это «человеческими отношениями». Это скорее «отношения между человеками». Человеками здесь всегда выступает заказчик. А подрядчик — в лучшем случае это: «Эй, человек!» (к)
А работающий механизм действительно никому не нужен. Тоже очень удивило.
Было время — я хотел пойти PM-ом в один из крупных бодишопов.Павел, думаю эта тема заслуживает топика.
В этом есть ньюанс. Лид, как и всякий руководитель, должен «лидить», а не «пинать и контролировать». ПМ — вообще чисто техническая должность по ведению отчетности сродни бухгалтеру. Вопрос в том, что «лидить» — быть «лидом: я — насяльника!» — хотят многие и во многом тот самый фактор «хороший человек (я его знаю)» — это не профессия. А мочь именно лидить — мягко говоря, мало.
А описанная структура иерархии «вассал моего вассала» — уже сама по себе зло. Тут либо люди понимают общее дело и место каждого в этом общем деле и его роль и его обязанности и как это вливается в общее дело, либо начинают строиться «крутые иерархии с лычками и погонами». Вопрос обратно таки в том, что «клеить лычки» — это насяльника умеют, а вот строить процесс — уже нет. Подмена понятий происходит незаметно как бы, но техническому человеку видна. Хотя, признаюсь, бывает не сразу.
Есть один момент: вышестоящий человек может быть вообще не технарем, и не шарить, что такое тех долг, спринт, и чем вообще программисты целый день занимаются. Влезание такого человека в процесс — большая проблема. Поэтому у руководителя (называйте его как хотите) должна быть возможность защитить команду от таких действий.
А рассуждение про «понимают общее дело» и прочая фигня — несколько диссонирует с вашим «в-job-ывать за плюшки».
Я считаю в процессе должно быть понимание процесса. Иначе особо смысла работать именно с этими людьми нет.
Конечно. Но не всегда понимание приходит сразу. И ко всем.
К слову, когда один мой знакомый увольнялся из одной конторы по причине «всё достало», последней каплей стало то, что тим-лидом назначили одного дебила, который выдавал на гора кучу мелких комитов прямо в продакшн. На верху посчитали число комитов и решили что чувак больше всех работает :D
Я когда впервые столкнулся с непониманием базовых принципов/практик работы свн со стороны «тимлида назначенного дебилом» — был в шоке дня 3 не меньше. Это вообще мое слабое место — воспринимать людей как такого же уровня или выше твоего. Постоянно на этом попадаюсь. Но я знаю об этом недостатке и борю его.
ЗЫ: а ведь интересно — на собеседованиях на тех.должности за свн не спрашивают. И еще интересно и уже относится к особенностям «своё дело против работы на дядю» — на собеседовании ты «собеседуешься», но среди прочего еще и очень нужная вещь — прособеседовать самому своего будущего непосредственного лида/начальника на предмет адекватности. Теоретически, на это предполагается испытательный срок (хотя почем же?), но какой смысл начинать, если заранее можно определить кто есть кто? Вот в бизнесе уже с этим много проще и если говорить о заказной разработке — ты заказчика видишь как на тарелочке и «простреливается» он «наводящими вопросами» с большей легкостью, чем в соседних ветках эйчары «прикладной психологией по программистам» занимаются.
В принципе, для тимлида и не обязательно быть самым знающим программистом в команде, но и дебилом он тоже не должен быть. Хороший тимлид прежде всего должен понимать, что он далеко не во всем разбирается лучше всех остальных программистов, должен уметь раздавать задачи в команде тем, кто лучше способен их сделать и должен удерживаться от соблазна подгребать под себя самое интересное напротив закрывая собой то, что тупо надо сделать. Скорее софт-скилз, а не технические, если разобраться.
Что касается собеседований, то когда искал работу в последний раз сразу же минусом были собеседующие с которыми разгорался спор по технической части (само по себе это нормально) <b>И</b> в качестве аргумента пусть и неявно привлекалось «кто тут начальник?»
Не совсем так. Т.е. во многом так, но есть огромная куча ньюансов. Что совершенно точно — дебилом быть не должен.
в качестве аргумента пусть и неявно привлекалось «кто тут начальник?»Именно. Очень четкий критерий состояния «сливай воду — забирай документы».
На стендапе это психологически проще.Наоборот.
Ответить на прямой вопрос, для интроверта вроде проще, чем самому разговор начать.
Нет. Это будет не «прямой вопрос» — это будет «допрос». Интроверту не нужен «вопрос с пристрастием» — ему нужно пальцем показать. Это сложно. Но это просто. Такая вот хитрость.
показать пальцем на таску и угукнуть?
Ну вроде того. Дословно описывать что есть «показать пальцем» — тема отдельной статьи и не одной. Рождество же ж, бро! ))
У нас 2 раза в день, минут по 25, утром и вечером. И ещё пару раз в течении дня. И «маленькие фичи» (tm) такие, что по полгода работы требуют, но эстимейт на них, где эти будущие полгода расписаны на 4х часовые таски желательно дать до конца дня (вчерашнего). :) Почему так — мне пока трудно судить, после 20 лет обычной итеративной разработки без использования баззвордов я всё ещё новичок в скраме.
а он у вас называется стендап или ауфштейн? ))
ситуацию, когда «пахнет жареным» мы называем =ахтунг=.
dp.ua))
Неплохо standup проводил Джоржи Карлин. Срам и прочие стундупы — полное фуфло :)
Лучше всего — конечно с утра, как все соберутся — у нас 15мин с 9 до
10:15 утра, для русских это 12:15 соответственно. Длительность 15 минут.
Почему — чтобы все добрались до работы.
В основном между 12 и 13, продолжительность около
Толку особого нет, т.к. в RedMine + Git + скайп видно всю картину в реальном времени.
Но разве кто-то может лишить руководство (тимлида) его законного права «надувать щеки».
Жирные клиенты, нонче, тоже по скраму работают. :)
Клиенты — да. А для девов — «никогда» ;)
если бы просто у нас вечер совпадает с утром в США поэтому и поздние stand up meeting
Если West сoast, то все сходится;)
Коли всі зберуться. Домовились на 10:45 до 11:00
Интересна именно статистика
Традиционно на предприятиях летучки/5минутки были скорее с утра. Уточнение планов работ на весь день.
Есть общее правило — когда всем удобно. Точные цифры — уточняйте в команде.
anonymous
Нестор Иванович
Artur Rakytskyi
devv
Max Ischenko
Sergii Kudriavtsev
Viktor Kryvyziuk
Gabriel Angelos
Gremlin
Андрей Кушнарев
Roman Labish
Eugene
Roman Labish
John Doe
Max Dzyubenko
Pavel Kruchina
Alex Fogol
Сашко
Artem Komisarenko
Alexander Fedorov
Uliana Kravchuk
Anton P
Andriy Bondarev
Sasha Eskin
Nikolay Sereb
Włodzimierz Rożkow
Gabriel Angelos
Viktor Kryvyziuk
Oleksandr K
Sergii Surskykh
Oleksandr K
Дмитро
Nazarii Bardiuk
Pavel Kruchina
Найкращі коментарі пропустити