Конечно начинать день с дэйлика это самый продуктивный вариант, но в таком случае все члены команды должны приходить вовремя к дейлику и не сильно раньше его, иначе это время просто может потеряться из рабочего дня. Это, в свою очередь, может сильно повлиять на лояльность и настроение сотрудников, т.к. не всем удобно приходить, например, к 10-ти: транспортные причины, личные причины, много их. Из-за снижения лояльности и настроения продуктивность, как показывает практика, обычно падает. Значит в сумме мы не только не повысим продуктивность, но и еще можем получить проблемы с конкретными сотрудниками.
Если в вашей компании принято приходить в одно время, то конечно лучше начинать день с дэйлика. Если же на данный момент у вашей команды гибкий график начала рабочего дня, то стоит десять раз подумать перед тем, как это отменять, опросить сотрудников, посмотреть как они к этому отнесутся, если не будет явных возражений, то попробовать и изучить результаты, если же будут явные возражения — продумать последствия и взвесить полученные результаты.
У нас как раз гибкое начало дня и поговорив с людьми я понял, что ни к чему хорошему эта перемена не приведет, поэтому решил остановиться на предобеденных дэйликах.
Вообще Scrum относительно молодое и активно развивающееся направление. В нем можно пробовать разные гипотезы, главное тестировать их по одной и смотреть на результаты, при этом заранее просчитывать все точки невозврата относительно текущих процессов. Не всегда стоит искать от добра добра )
Через пару месяцев мы ввели Daily Scrum (стендап), назначили его на 12:00, потому что к этому времени обычно все уже были на работе (у нас очень гибкий график)
У нас была похожая ситуация: часть разработчиков приходила к 10-ти, часть в 11, часть в 12, а уходили обедать в районе 13:30 +- все вместе. Сначала были дэйлики в 12 и вроде бы всем в команде удобно. Потом пришло понимание того, что мы сильно разбиваем время девелоперов, ведь те, кто пришел в 10, уже давно в работе и сейчас их лучше было бы не дергать, а те, кто пришел в 11, только полноценно в работу включились, получается рваный ритм. Т.к. все ходили в обед примерно в одно время, то мы перенесли время на 13:15 и получили другой результат. Во-первых, мы избежали этого рваного ритма и люди стали успевать больше, во-вторых, сами дэйлики начинали проходить продуктивнее, команда до всех доносила исключительно нужную информацию с минимум оффтопа и шуточек, ведь все понимали, что как закончим, так и пообедать можно будет и весь оффтоп перенести уже туда.
Если у вас девелоперы тоже ходят обедать +- в одно время, попробуйте подобную схему.
Вы меня извините, но это уже полный пипец, пока что люди терпят, но вот что будет дальше, прикрой они еще N популярных для обычных пользователей сайтов, это уже вопрос
Для начала можно почитать вики. У команды есть фиксированный спринт (итерация), например у нас это две недели. Есть бэклог, в которых лежат юзер стори (грубо говоря новые фичи или изменения существующих, далее ЮС). Каждой ЮС до начала нового спринта проставлено определенное количество стори поинтов (предварительный показатель объема или сложности выполнения данной ЮС), таким образом аналитик всегда знает, какой объем новых фич мы выполним за будущие 2 недели (по окончании каждого спринта — релиз). Есть такое понятие как фокус-фактор, по сути это показатель эффективности работы команды, варьируется он в пределах 0.3-0.6, например у нас он 0.4. количество идеальных часов на спринт рассчитывается как реальное время (количество программистов*количество дней*количество часов минус заранее известные отгулы, отпуска и пр.) умноженное на фокус-фактор. Каждому таску (ЮС может состоять из более чем одного таска) выставляется оценка (от программистов) в идеальных часах (я сделаю это за столько, аналог первого столбца Оценка в данном посте), таким образом на спринт набирается то количество ЮС, сумма времени тасков которых не превышает идеальное количество часов спринта. В итоге фоку-фактор заранее учитывает все непредвиденные обстоятельства в архитектуре, баги, какие-либо еще косяки, время на попить чай, таким образом к дедлайну (концу спринта) есть стабильная версия с заранее запланированными новыми фичами, исправленными багами и доработками, которые были осуществлены в процессе спринта (все это фокус-фактор). Бывает и такое, что по каким-либо причинам в конце спринта нет стабильной версии и версия не релизится, спринт заваливается, но такое бывает редко, у нас такое случалось 2 раза за полгода. Все описанное выше далеко не краткое изложение скрама, а всего лишь описание возможного решения или предвидения проблемы, описанной в посте
Если ко мне подойдет гендир и скажет: «Я хочу по таким-то причинам иметь у себя сертифицированный QA dep, вот вам деньги — вперед», — то я и мои подопечные пройдем ее, не проблема. Если для компании моей мечты (если будет такая) потребуется в обязательном порядке для приема сертификат, то в таком случае можно его получить. Но вот тратить на это свое время и деньги ради только того, чтоб он у тебя лежал дома в файлике никому не нужный с прочими бумажками — зачем? В нынешней реальности в большинстве случаев это будет просто ненужным сертом, потерей времени и денег, ведь если я что-то захочу узнать, то я просто найду это в инете или куплю соответствующую книгу, или обращусь за помощью к моим знакомым из сферы QA. Никогда не любил обучение ради обучения, а не ради реальной пользы.
Если в вашей компании принято приходить в одно время, то конечно лучше начинать день с дэйлика. Если же на данный момент у вашей команды гибкий график начала рабочего дня, то стоит десять раз подумать перед тем, как это отменять, опросить сотрудников, посмотреть как они к этому отнесутся, если не будет явных возражений, то попробовать и изучить результаты, если же будут явные возражения — продумать последствия и взвесить полученные результаты.
У нас как раз гибкое начало дня и поговорив с людьми я понял, что ни к чему хорошему эта перемена не приведет, поэтому решил остановиться на предобеденных дэйликах.
Вообще Scrum относительно молодое и активно развивающееся направление. В нем можно пробовать разные гипотезы, главное тестировать их по одной и смотреть на результаты, при этом заранее просчитывать все точки невозврата относительно текущих процессов. Не всегда стоит искать от добра добра )
У нас была похожая ситуация: часть разработчиков приходила к 10-ти, часть в 11, часть в 12, а уходили обедать в районе 13:30 +- все вместе. Сначала были дэйлики в 12 и вроде бы всем в команде удобно. Потом пришло понимание того, что мы сильно разбиваем время девелоперов, ведь те, кто пришел в 10, уже давно в работе и сейчас их лучше было бы не дергать, а те, кто пришел в 11, только полноценно в работу включились, получается рваный ритм. Т.к. все ходили в обед примерно в одно время, то мы перенесли время на 13:15 и получили другой результат. Во-первых, мы избежали этого рваного ритма и люди стали успевать больше, во-вторых, сами дэйлики начинали проходить продуктивнее, команда до всех доносила исключительно нужную информацию с минимум оффтопа и шуточек, ведь все понимали, что как закончим, так и пообедать можно будет и весь оффтоп перенести уже туда.
Если у вас девелоперы тоже ходят обедать +- в одно время, попробуйте подобную схему.