Привет, Хабр! Меня зовут Максим Лютцау, в Промсвязьбанке я работаю product owner’ом. Почти год разработка нового интернет-банка «Мой бизнес» у нас идет по фреймворку Scrum, и в связи с этим я уже успел набить шишек. В этом посте я хотел бы рассказать о самых болезненных из них, а также о том, какие средства нам в итоге помогли. Чтобы вы смогли избежать подобных неприятностей.
Фреймворк Scrum был принят в нашем банке, чтобы ускорить развитие и уменьшить TTM. Когда началось внедрение, выяснилось, что некоторые сотрудники оказались к этому не готовы. Они не понимали, зачем это надо и что это даст.
«Мы и раньше нормально работали, зачем нам это?», «А почему не будем делать иначе?», «Кто это пришел меня учить, откуда он знает, что так лучше?» — подобные вопросы постоянно сыпались с их стороны. И даже когда эти сотрудники получали ответы, через некоторое время все снова повторялось.
Самое разумное решение в этом случае — перевести людей на другие проекты. Это нужно сделать обязательно, поскольку человек, излучающий негатив, способен повлиять на всех. В нашей истории именно это исцелило наш коллектив — исчезло всеобщее напряжение, и все настроились на восприятие новой информации.
Негативная реакция на изменения не зависит от возраста. Разработчикам, о которых мы говорили выше, было немногим больше 30 лет. При этом у нас в команде отлично работает человек, которому уже за 50, — никаких проблем со Scrum у него не возникло.
В любой организации приходится сотрудничать с людьми, которые просто не работают по Scrum. В нашем случае это команды с других проектов и отделов. У них обычно гораздо более длинные этапы реализации проектов. Честно говоря, у нас по Scrum пока что работают только разработчики ДБО.
Мы решили ничего с этой проблемой не делать — не лезть со своим скрамом в работу других людей. Мы просто просим их сделать то, что нужно нам. Когда они возвращаются с решением, мы начинаем связывать свои задачи. Не стоит усложнять взаимодействие, если корпоративная культура еще не созрела сама собой. Конечно, после скрам-тренингов возникает желание поменять абсолютно все, но лучше вовремя остановиться.
Хоть мы и не поторапливаем другие подразделения, в сотрудничестве с нами они начинают работать быстрее. Мы приглашаем безопасников на наши встречи и демо, и теперь согласование полностью готового релиза занимает всего один день. До этого уходило от недели до двух.
Внедрив Scrum, мы перешли с месячных отчетных периодов на двухнедельные спринты. Вначале из-за масштабности задач сжимать сроки не хотели. Но подгонять размер спринта под то, что надо сделать — это большая ошибка. Наоборот, нужно подгонять планы под длительность спринта. Сделать это довольно просто — достаточно декомпозировать задачи. Когда они уменьшаются в размерах, их проще расставить по плану, задать им приоритет. Меньшие партии кода быстрее тестировать, проверять, согласовывать с безопасниками. Вообще, я бы даже рекомендовал по возможности уменьшать длительность спринта с двух недель до одной.
Когда кто-нибудь из команды не успевает сделать все запланированное к концу спринта, возникает естественное желание отложить демо — чтобы прийти на него во всеоружии. Но в таком случае нужно все равно придерживаться графика. В любом случае стоит рассказывать о результатах работы: что успели, что и почему не успели, что предприняли, чтобы успеть. Так мы не убегаем от проблем, а выступаем с ними лицом к лицу и потом можем совместно найти решения.
Такой подход повышает мотивацию, после неудачных плановых демо вырастает ответственность за работу. Если раньше стенд для демо разработчики готовили за пять минут, то сейчас они делают это за день до демо, а потом уже шлифуют оставшиеся неровности, чтобы все было супер.
Поначалу коллеги скептически относились к тому, чтобы каждый день отвлекаться от привычной работы на стендап-встречи. Даже если они проводятся онлайн и требуют всего 10 минут.
В решении этой проблемы помогает символическое поощрение от человека, который находит общий язык с командой. Однажды забавы ради я сказал, что буду отмечать в календаре тех, кто приходит на стендапы, и начал ставить плюсики. Результат получился неожиданным, и эффект был заметен уже после одного спринта. Не желая быть заминусованными, разработчики сами приходили на стендапы. Это даже переросло в нашу общую шутку: теперь уже они грозятся поставить мне минус, когда я не могу прийти на какое-нибудь собрание.
Многие думают, что скрам-встречи занимают очень много времени. Здесь достаточно посчитать, так ли это на самом деле. У нас получилось два часа в неделю из 40. Это не так много для того, чтобы организовать работу и оставаться в курсе всех дел.
Если на стендап-встречи не хочет идти вся команда, да и сами встречи получаются не слишком активными, это сигнал к тому, что работа идет не так. Как и если встреча затягивается больше чем на 15-20 минут. Рассказ о своих занятиях и планах у человека не должен занимать больше одной-двух минут.
С тайм-менеджментом у нас связано еще одно правило. Если обсуждение задачи занимает больше 30 минут, мы его прекращаем. Это значит, что мы не успели разработать задачу, что она плохо декомпозирована и требует еще времени. На это стоит обратить внимание. Ограничение в 30 минут мы установили для себя — в каждой компании нужно устанавливать собственный барьер.
Успешность Scrum зависит, в первую очередь, от четкого планирования. Нужно определить, какое количество задач должно быть оценено и описано, а какое пока можно просто отложить. Не стоит пытаться охватить сразу все. Разработчику нужно понимать, что он будет делать в ближайшие два спринта. На более отдаленные сроки достаточно примерного представления — чем позднее, тем меньше деталей.
Что разработчики делают сегодня? А что будут завтра? Бывает, руководители задают такие вопросы регулярно. Мы смогли объяснить своему руководству, что все интересующие моменты можно узнать на нашей скрам-доске или придя на ежедневный стендап. Никаких специальных отчетов с таблицами и мониторинга по задачам в Jira. Нам удалось сжать этот микроменеджмент до еженедельных встреч с руководством, где я отчитываюсь по конкретным выполненным задачам команды.
Напоследок — явная проблема, упоминания которой я почти нигде не нашел. Не нужно пытаться объединить скрам-мастера и product owner’а. Последний строит бизнес-подразделение, прорабатывает бэклог, выполняет KPI. Он заинтересован в успехе продукта и старается вникнуть во все — поэтому начинает назначать встречи, обсуждать какие-то детали. В общем, нагружает себя кучей функций, из-за которых на бэклог просто не остается времени.
Такое случалось и со мной. Я организовывал встречи, стендапы, решал проблемы членов команд. Из-за этого бэклог оставался не проработан, то есть на основную деятельность просто не было времени. Сейчас мы нашли руководителя разработки, который имеет авторитет у команды и стал также выполнять функции скрам-мастера, поскольку имеет больший опыт работы по этому фреймворку. Теперь я смог отойти от Scrum и полноценно сконцентрироваться на задачах product owner’а, который, в свою очередь, должен думать над требованиями. Без хороших требований не будет хорошего продукта. В результате бэклог стал улучшаться, к коллегам пришло понимание, как мы будем двигаться дальше.
На первый взгляд Scrum кажется очень простым, но все-таки имеет много подводных камней. Мы работаем по этому фреймворку почти год, но только сейчас мы начали более-менее четко оценивать свои способности, начали наращивать скорость развития.
Некоторые сотрудники принципиально против изменений
Фреймворк Scrum был принят в нашем банке, чтобы ускорить развитие и уменьшить TTM. Когда началось внедрение, выяснилось, что некоторые сотрудники оказались к этому не готовы. Они не понимали, зачем это надо и что это даст.
«Мы и раньше нормально работали, зачем нам это?», «А почему не будем делать иначе?», «Кто это пришел меня учить, откуда он знает, что так лучше?» — подобные вопросы постоянно сыпались с их стороны. И даже когда эти сотрудники получали ответы, через некоторое время все снова повторялось.
Самое разумное решение в этом случае — перевести людей на другие проекты. Это нужно сделать обязательно, поскольку человек, излучающий негатив, способен повлиять на всех. В нашей истории именно это исцелило наш коллектив — исчезло всеобщее напряжение, и все настроились на восприятие новой информации.
Негативная реакция на изменения не зависит от возраста. Разработчикам, о которых мы говорили выше, было немногим больше 30 лет. При этом у нас в команде отлично работает человек, которому уже за 50, — никаких проблем со Scrum у него не возникло.
Сложно взаимодействовать с теми, кто живет не по Scrum
В любой организации приходится сотрудничать с людьми, которые просто не работают по Scrum. В нашем случае это команды с других проектов и отделов. У них обычно гораздо более длинные этапы реализации проектов. Честно говоря, у нас по Scrum пока что работают только разработчики ДБО.
Мы решили ничего с этой проблемой не делать — не лезть со своим скрамом в работу других людей. Мы просто просим их сделать то, что нужно нам. Когда они возвращаются с решением, мы начинаем связывать свои задачи. Не стоит усложнять взаимодействие, если корпоративная культура еще не созрела сама собой. Конечно, после скрам-тренингов возникает желание поменять абсолютно все, но лучше вовремя остановиться.
Хоть мы и не поторапливаем другие подразделения, в сотрудничестве с нами они начинают работать быстрее. Мы приглашаем безопасников на наши встречи и демо, и теперь согласование полностью готового релиза занимает всего один день. До этого уходило от недели до двух.
«Мы ничего не успеем за спринт!»
Внедрив Scrum, мы перешли с месячных отчетных периодов на двухнедельные спринты. Вначале из-за масштабности задач сжимать сроки не хотели. Но подгонять размер спринта под то, что надо сделать — это большая ошибка. Наоборот, нужно подгонять планы под длительность спринта. Сделать это довольно просто — достаточно декомпозировать задачи. Когда они уменьшаются в размерах, их проще расставить по плану, задать им приоритет. Меньшие партии кода быстрее тестировать, проверять, согласовывать с безопасниками. Вообще, я бы даже рекомендовал по возможности уменьшать длительность спринта с двух недель до одной.
Когда кто-нибудь из команды не успевает сделать все запланированное к концу спринта, возникает естественное желание отложить демо — чтобы прийти на него во всеоружии. Но в таком случае нужно все равно придерживаться графика. В любом случае стоит рассказывать о результатах работы: что успели, что и почему не успели, что предприняли, чтобы успеть. Так мы не убегаем от проблем, а выступаем с ними лицом к лицу и потом можем совместно найти решения.
Такой подход повышает мотивацию, после неудачных плановых демо вырастает ответственность за работу. Если раньше стенд для демо разработчики готовили за пять минут, то сейчас они делают это за день до демо, а потом уже шлифуют оставшиеся неровности, чтобы все было супер.
«Зачем нужны ежедневные стендапы?»
Поначалу коллеги скептически относились к тому, чтобы каждый день отвлекаться от привычной работы на стендап-встречи. Даже если они проводятся онлайн и требуют всего 10 минут.
В решении этой проблемы помогает символическое поощрение от человека, который находит общий язык с командой. Однажды забавы ради я сказал, что буду отмечать в календаре тех, кто приходит на стендапы, и начал ставить плюсики. Результат получился неожиданным, и эффект был заметен уже после одного спринта. Не желая быть заминусованными, разработчики сами приходили на стендапы. Это даже переросло в нашу общую шутку: теперь уже они грозятся поставить мне минус, когда я не могу прийти на какое-нибудь собрание.
Многие думают, что скрам-встречи занимают очень много времени. Здесь достаточно посчитать, так ли это на самом деле. У нас получилось два часа в неделю из 40. Это не так много для того, чтобы организовать работу и оставаться в курсе всех дел.
Если на стендап-встречи не хочет идти вся команда, да и сами встречи получаются не слишком активными, это сигнал к тому, что работа идет не так. Как и если встреча затягивается больше чем на 15-20 минут. Рассказ о своих занятиях и планах у человека не должен занимать больше одной-двух минут.
С тайм-менеджментом у нас связано еще одно правило. Если обсуждение задачи занимает больше 30 минут, мы его прекращаем. Это значит, что мы не успели разработать задачу, что она плохо декомпозирована и требует еще времени. На это стоит обратить внимание. Ограничение в 30 минут мы установили для себя — в каждой компании нужно устанавливать собственный барьер.
Непонятный бэклог
Успешность Scrum зависит, в первую очередь, от четкого планирования. Нужно определить, какое количество задач должно быть оценено и описано, а какое пока можно просто отложить. Не стоит пытаться охватить сразу все. Разработчику нужно понимать, что он будет делать в ближайшие два спринта. На более отдаленные сроки достаточно примерного представления — чем позднее, тем меньше деталей.
Неуместный микроменеджмент
Что разработчики делают сегодня? А что будут завтра? Бывает, руководители задают такие вопросы регулярно. Мы смогли объяснить своему руководству, что все интересующие моменты можно узнать на нашей скрам-доске или придя на ежедневный стендап. Никаких специальных отчетов с таблицами и мониторинга по задачам в Jira. Нам удалось сжать этот микроменеджмент до еженедельных встреч с руководством, где я отчитываюсь по конкретным выполненным задачам команды.
То, о чем почти не пишут
Напоследок — явная проблема, упоминания которой я почти нигде не нашел. Не нужно пытаться объединить скрам-мастера и product owner’а. Последний строит бизнес-подразделение, прорабатывает бэклог, выполняет KPI. Он заинтересован в успехе продукта и старается вникнуть во все — поэтому начинает назначать встречи, обсуждать какие-то детали. В общем, нагружает себя кучей функций, из-за которых на бэклог просто не остается времени.
Такое случалось и со мной. Я организовывал встречи, стендапы, решал проблемы членов команд. Из-за этого бэклог оставался не проработан, то есть на основную деятельность просто не было времени. Сейчас мы нашли руководителя разработки, который имеет авторитет у команды и стал также выполнять функции скрам-мастера, поскольку имеет больший опыт работы по этому фреймворку. Теперь я смог отойти от Scrum и полноценно сконцентрироваться на задачах product owner’а, который, в свою очередь, должен думать над требованиями. Без хороших требований не будет хорошего продукта. В результате бэклог стал улучшаться, к коллегам пришло понимание, как мы будем двигаться дальше.
На первый взгляд Scrum кажется очень простым, но все-таки имеет много подводных камней. Мы работаем по этому фреймворку почти год, но только сейчас мы начали более-менее четко оценивать свои способности, начали наращивать скорость развития.
sw0rl0k
Серьезно, зачем они нужны? К счастью у нас на работе их нет. И я правда не понимаю, зачем они нужны. То есть, в 1986 году, когда не было ни жиры, ни гита, в этих митингах был смысл. Но сейчас-то они зачем?
Что я сделал с последнего собрания? — смотрите в гите
Что я буду делать сегодня? — смотрите в жире
Какие сложности нужно будет решить? — смотрите в жире
Многие говорят, что на митингах можно решить проблемы взаимодействия. Те которые «Не могу выполнить свою задачу, пока Вася не запилит бэк/Коля не скинет макет/Саша не скинет контент» ну и тому подобные. ИМХО, при возникновении таких проблем, их надо сразу говорить менеджеру, чтоб это становилось его головной болью и он пинал всех причастных.
jia3ep
Суть в том, чтобы при возникновении проблем, они оперативно решались внутри команды, а не становились головной болью менеджера.
Кстати, именно поэтому в Scrum отсутствует такая роль (менеджер). Человек, у которого постоянно болит голова, никак не помогает выпуску продукта.
sw0rl0k
В скраме же есть product owner — я лишь обобщил всех не it-специалистов словом менеджер.
ApeCoder
И чем же занимается PO?
Lofer
Выбирает, что делать в первую очередь для бизнеса/Клиента
ApeCoder
Следовательно он решает не все проблемы, а только те, которые связаны с определением приоритетов, да?
Lofer
Да. Проблемы… шерифа не волнуют.
Фактически он использует сервис «Scrum Team» для создания продукта. Какая магия работает внутри команды — его волновать не должно.
maksitron Автор
Его задача создать ценный для клиента продукт. Поэтому ПО занят созданием задач и их приоритетом.
maksitron Автор
Спасибо за вопрос :)
Стендапы нужны, чтобы синхронизировать работу команды, не все изменения видны в гите, и не все заводится в джире, созвониться проще и быстрее. И не надо забывать о ламповости таких мероприятий, живое общение тоже нужно, оно помогает поддерживать командный дух, тем более если не вся команда работает в одном офисе / городе.
«при возникновении таких проблем, их надо сразу говорить менеджеру, чтоб это становилось его головной болью и он пинал всех причастных.» — у нас другой подход, стараемся все вопросы решать сами, без привлечения руководителей.
sw0rl0k
Как я уже писал выше, под менеджером я подразумеваю product owner'a / project manager'a / хоть горшком назови, только в печь не клади
maksitron Автор
Как-то обидно из владельца продукта превратиться в менеджера.
Тогда ответ такой, если команда взяла задачу в спринт — ее реализация является «головной болью» всей команды, в т.ч. и продукт оунера.
Если что-то не готово по задаче, то зачем брать ее в спринт?
VolCh
А кто владелец продукта как не менеджер? Причём основной его ресурс — человеческий :)
otchgol
Да с какое это стороны? Он не может руководить командой. Его дело проталкивать задачи. Это все, что он может. Команда решит что, когда и как будет делать. PO может что-то себе планировать исходя из опыта и капасити/велосити, но решать-то не моежт. Это отличие от менеджера, как мне видится.
VolCh
Что значит «проталкивать» в вашем понимании? Убеждать команду «ну сделайте, пожалуйста, вот такую фичу, мы без неё деньги терям?»
otchgol
Проталкивать и есть. Добиться попадания задачи в продукт. Приоритезация задачь не влияет напрямую на их попадание в спринт. Она может быть недостаточно описала или сложна в раелизации и может находиться в топе очень долго. Как PO добъется ее исполнения неизвестно. Вполне возможно он может поти на поводу у команды и отказаться от задачи. У нас такое бывает очень часто.
kadestro73
Не совсем так, владелец продукта только расставляет приоритеты и ожидает выполнения задачи. Менеджер же следит за выполнением задач в момент ее реализации и пытается держать под контролем разработку, что в скраме лежит на команде
sw0rl0k
Ну смотрите. Допустим мне надо запилить какую-то фичу на фронте. Эта фича завязана на бэк. Задача и по фронту и по бэку в этом спринте(по крайней мере везде где я работал, задачи по фронту и бэку делались в одном спринте, если это касалось одной фичи). Так вот я как фронт разработчик не должен ходить и тыкать палочкой бэка, мол давай сделай мне пожалуйста эндпоинт. Я должен просто прийти к тому, кто отвечает за выпуск продукта(неважно, как называется его должность) и сказать «смотри, я замокал данные и сделал свою часть, но бэк не готов и мне потребуется еще какое-то время, чтоб заменить мок на реальные данные и проверить, что все работает. у нас там на горизонте фичефриз, и если бэк будет готов вечером перед днем фичефриза, то я не успею подогнать фронт». И вот тогда этот человек должен сам ходить и пинать бэк, чтоб они поскорее сделали свою часть. И это я имел в виду, когда говорил, что это должно быть головной болью менеджера, а не разработчика. А смысл моего первоначального сообщения был в том, что о таких проблемах, когда они возникают, надо сразу говорить человеку, отвечающему за выпуск продукта, а не ждать митингов.
otchgol
Я же говорю, что параллельно работаете. Делаете mock service. Все у вас есть бэкэнд. Делаете свою задачу спокойно. А бэк делается параллельно. Все в одном спринте. Никто никого не держит.
VolCh
> мне потребуется еще какое-то время, чтоб заменить мок на реальные данные и проверить, что все работает. у нас там на горизонте фичефриз, и если бэк будет готов вечером перед днем фичефриза, то я не успею подогнать фронт»
otchgol
Фронт на две недели? Очевидно, что нет, иначе неправильная разбивка. То есть задача закончилась в первую неделю и все можно было успеть.
Фичефриз не то, чтобы кодефриз?
Можно сколько угодно спорить. В спринт можно уложить и разработку и проверку. Бывают исключения. В 80% случаев можно все сделать.
sw0rl0k
В идеальном мире все было бы идеально. Ну или взаимодействие с бэком сводится к «утянуть гетом какой-нибудь объект», то тоже оно потом просто меняется с мока на реальные данные и норм. Ну или если на бэке сидят все супер-крутые программисты, а джунов и мидлов нет совсем. В реальности нередко сталкиваюсь с тем, что после замены мока на реальные данные, что-то отваливается и надо ждать пока бэк поправит. И бывает всё это делается не в одну итерацию.
Но вообще мы сейчас спорим не о том)) Изначально разговор был про то, что при возникновении любых проблем их надо решать сразу, а не ждать митингов.
otchgol
Да спор бестолков. Кадый останется при своем опыте. Просто у меня полно примеров с успешным тестированием продукта внутри спринта. Есть и примеры с задачами переходящими из спринта в спринт. Ничего такого в этом нет. Для этого есть ретроспективы. Главное принимать их во внимание.
VolCh
А если стендапы сводятся именно к статусам задач в джире или, в лучшем случае, к сделанным коммитам/PR?
bayarsaikhan
На практике достаточно часто проблема, которая бы ушла в бекграунд, всплывает во время стендапа. Так как присутствует и внимательно слушает вся команда, то проблему можно оперативно купировать еще рано утром.
Lofer
Самый тупой карандаш заменяет самую острую память.
Не записали (в Jira/TFS/) Task/Bug/Issue — сами себе злые мудаки-буратины.
ApeCoder
Это если только вы делаете код. Бывают также вещи типа "обяснил Пете и Саше структуру модуля X" — т.е. если команда работает как одно целое часто есть вклад в чужие коммиты и вообще в какие-то вещи, которые коммитами не являются.
Какие сложности возникли — в принципе можно добавлять в жиру организационные баги, типа "петрович из соседнего отдела опять продолбал сроки" но я не видел, чтобы так делали. У вас так?
У менеджера нет запланированных дел. Вместо того, чтобы послушать 10 минут статусы он должен весь день быть готовым к асинхронному вызову от других кодеров. Да, кодеры занимаются только коммитами, один кодер не может другому помочь узнать, кому написать, чтобы пропинали Васю.
time2rfc
Привет, scrum не панацея для всех отраслей разработки. Простой и жизненый пример зачем нам нужен утренний стендап — мы планировали катиться в прод, но пока распланированные задачи решались всплыли новые технические задачи критичные для выхода(их нет в бэклоге, жире, гите), после стендапа мы потратили еще 10 минут, распределили задачи и пошли работать. У каждого были свои технические проблемы, но понять что они каскадом накладываются у нас мы смогли только пообщавшись с утра, и как результат переиграть дальнейшие действия.
Для продуктов с дооолгими релизами это не так критично, ну так серебрянной пули то и не существует.
otchgol
У нас команда сидит в одной комнате. Почти все слышно. Проблемы озвучиваются на всю комнату обычно. Стендап почти всегда избыточен.
arbox
Простите, а когда вы работаете, если вы целый день озвучиваете свои и прислушиваетесь к чужим проблемам?
arbox
Если признать, что информированность всех членов команды важна, то ежедневный «стендап» реализует достижение этой цели. Во время такой встречи происходит обмен информацией.
Если команда обменивается информацией иначе, то ежедневные встречи могут быть избыточными.
А возможность «посмотреть в гите» была и остается, только ведь разница в том, посмотрю ли я или буду иметь возможность посмотреть. В нашей практике всегда было проще проактивно рассказать, что важного произошло за прошлый день, чем ожидать правильного самостоятельного понимания изменений от других членов команды и отвечать всем десять раз на один и тот же вопрос.
VolCh
Тут вон в 90 секунд и даже меньше предлагают ограничивать доклад одного человека. Такие доклады, имхо, выливаются в видимость информированности.
arbox
Прощу прощения, а в чем вопрос по существу? Мы говорим о цели подобного ежедневнного собрания. А подобные предложения пытаются заменить цель формой. Каждый член команды в своей работе прекрасно ощущает, хватает ли ему информации для его работы. Если такое состояние достигается за 90 секунд, то все сэкономили время.
VolCh
Ну может цель обмен информацией, а может цель у большинства участников — исполнение ритуала ради «плюсиков», а информацию они добывают менее формализованными способами, чем заслушивание скороговорки из списка закрытых и ещё открытых тикетов от десятка человек.
ApeCoder
А почему это должна быть именно скороговорка и именно по закрытым тикетам?
VolCh
Потому что за 90 секунд описания тикетов иначе не прочитать. По закрытым и открытм, которые вчера закрыл и которые сегодня будешь пилить,
ApeCoder
Почему нужно именно описание тикетов? Если их много, можно обобщить.
The Daily Scrum is a 15-minute time-boxed event for the Development Team. The Daily Scrum is held every day of the Sprint. At it, the Development Team plans work for the next 24 hours. This optimizes team collaboration and performance by inspecting the work since the last Daily Scrum and forecasting upcoming Sprint work. The Daily Scrum is held at the same time and place each day to reduce complexity.
The Development Team uses the Daily Scrum to inspect progress toward the Sprint Goal and to inspect how progress is trending toward completing the work in the Sprint Backlog. The Daily Scrum optimizes the probability that the Development Team will meet the Sprint Goal. Every day, the Development Team should understand how it intends to work together as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment by the end of the Sprint.
The structure of the meeting is set by the Development Team and can be conducted in different ways if it focuses on progress toward the Sprint Goal. Some Development Teams will use questions, some will be more discussion based. Here is an example of what might be used:
— What did I do yesterday that helped the Development Team meet the Sprint Goal?
— What will I do today to help the Development Team meet the Sprint Goal?
Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?
— The Development Team or team members often meet immediately after the Daily Scrum for detailed discussions, or to adapt, or replan, the rest of the Sprint’s work.
The Scrum Master ensures that the Development Team has the meeting, but the Development Team is responsible for conducting the Daily Scrum. The Scrum Master teaches the Development Team to keep the Daily Scrum within the 15-minute time-box.
The Daily Scrum is an internal meeting for the Development Team. If others are present, the Scrum Master ensures that they do not disrupt the meeting.
Daily Scrums improve communications, eliminate other meetings, identify impediments to development for removal, highlight and promote quick decision-making, and improve the Development Team’s level of knowledge. This is a key inspect and adapt meeting.
VolCh
Вот и обобщают: я закрыл вчера 5 тасок, чем приблизил команду к цели спринта на 1%. сегодня планирую 3, но это будет 1,5%
eugenvz
Очередной антипаттерн в Scrum.
Daily Scrum не про то, что вы пишете.
Большинство так и пребывают в счастливом (хотя нет, скорее, в несчастном, раз так всё бесит) неведении, для чего эта встреча.
Много писать не буду, так как обычно это всё равно что "метать бисер...", скажу только, что три вопроса, которые вы привели — это про обычный, как правило бессмысленный, ежедневный отчёт. С таким же успехом туда же можно про количество "чаёв и походов в туалет" добавить.
Daily Scrum — это про статус в части движения к цели спринта. А теперь спросите вокруг, кто понял о чём это. Кстати, в Scrum Guide и про цель спринта тоже написано.
Беда в том, что множество "Scrum-команд" (именно в кавычках) понятия не имеют, что такое Scrum Guide. А если и имеют понятие, то не поняли, или поняли, но не осознали написанного.
VolCh
Пришёл сертифицированный скрам-мастер, сказал нам что надо делать и нарёк нас скрам- командой. Что не так? Он мошенник?
Ну я вот прочитал по его совету, чтобы лишних вопросов о том, что делать надо, не задавать. Объяснения «зачем» стал опускать быстро, поскольку реально ответ на него у меня есть: «начальнки сказал, что делаем скрам». А цель спринта у нас всегда одна была: выполнить все таски из лога спринта.
time2rfc
хороший пример "механического" скрама
Tiendil
Это поощрение?
klauss_z
Ключевое слово — «символическое».
maksitron Автор
Да, это скорее манипуляция :)
Mishiko
Стендап — это уже манипуляция
VolCh
В чём манипуляция? Кого и через что стендапы заставляют менять обычное поведение?
Mishiko
Не прикидывайтесь. Разработчику приходится думать что он скажет на завтрашнем стендапе. Это тонкое психологическое давление с целью заставить людей работать. Если бы это было не так, разрабы охотно бы бежали на стендапы без всякого напоминания — разве плохо пятнадцать минут языком потрепать вместо работы?
Скрам манипулятивен по своему духу — с одной стороны изобразить заказчику что работа идет, с другой стороны подстегнуть разрабов.
VolCh
Обычно достаточно за 5 минут до него распечатать по фильтра из джиры. Главное чтобы очереди не было на один принтер на 200 девов, у которых митинг в 11 :)/
VolCh
упс, с телефона пишу. А в чём подстегивание-то?
Mishiko
Читаю статью (заодно вспоминаю своих коллег):
— часто разработчик считает что сделал меньше чем должен (результат неверной оценки задачи) и недоволен собой, а учитывая что разрабы люди обычно самолюбивые, необходимость публичного признания (хотя остальным до лампады его проблемы) рождает либо нежелание идти на стендап, либо переработки у особо ответственных.
otchgol
Частично так. Но по нашему опыту людям не стыдно сказать я вчера, сегодня и завтра буду делать то-то. И так три дня подряд, хотя всем ясно, что работы там на день. Скрам для стыдливых японцев из тойоты работать может.
kolkoni
В «Scrum: Революционный метод управления проектами» есть все ответы.
Если решили внедрять скрам, то книжка обязательна к прочтению.
maksitron Автор
Спасибо за совет. Читали, и не только ее.
WizardryIB
Короткий спринт — это понижение КПД команды, скрам ради скрама. Три недели — оптимальный спринт. А если объединить скрам-мастера с тим-лидом?
maksitron Автор
Про скрам ради скрама — не соглашусь, если правильно выстроены процессы CI/CD вполне себе рабочая схема. Сами пока не пробовали, но у коллег из Альфа-банка неплохо получается.
Про объединение, тут надо понимать, что у тим лида тоже есть свои интересы, kpi и т.п. а скрам-мастер в первую очередь слуга самого процесса.
speshuric
А почему понижение КПД? Накладные расходы на спринт — это время для демо, ретроспективы и планирования. Время планирования и демо зависит от количества задач и поэтому при длинном спринте также увеличатся. Ретроспектива — зависит от сыгранности команды и вообще может пройти за 20 минут, когда у команды уже было 10-20 ретроспектив.
В любом случае — оптимальная длина спринта зависит от огромного количества факторов. По моему опыту, чаще командам комфортнее работать в спринте 2 недели. Но видел команды со спринтом и в 1 неделю, и в 3, и в 4. Если 4 и больше, то надо приглядеться, но вполне может быть, что так надо.
Примерно в 70-80% случаев первым скрам-мастером становится экс-тим-лид. Ну или его правая рука, если сам тим-лид становится PO.
Busla
об этом чёрным по белому написано в Scrum guide
maksitron Автор
На сколько я помню, как основной минус объединения ролей там приводиться в пример, что продукт оунер более заинтересован в качестве, а скрам-мастер в сроках. У меня же физически не хватало времени (и/или опыта). Конфликта интересов не было.
napa3um
Но отсутсвие времени на одно в связи занятостью другим — это и есть проявление конфликта интересов.
ggo
Канонический скрам-мастер отвечает за практики (скрам-практики) и рост команды (самоуправление).
Канонический продукт-оунер отвечает за успешность продукта. А что для этого нужно, качество, скорость, надежность, или что-то еще, в каждом конкретном случае по разному. Т.к. продукты разные и жизнь переменчива.
otchgol
Скрам, вероятно, есть противопожность семье в толстовской репрезентации: бОльшая часть проблем скрама идентична, и лишь счастье от него приводит компании к разным финансовым результатам.
У нас тоже вызывает недоумение необходимость стэндапов. В опенспейсе их необходимость мала. Но, подневольным нам, приходится ходить на них. Очень редко мы можем уложиться в пол-часа. И это бесит. Я думаю, что основная и единственная цель стэндапа — самоорганизация на основе совестливости команды, недостижима. Кому работать тот работает. Не скажу, что стэндапы не поднимают каких-то важных проблем или не дают быстрого решения тому, кто попал в тупик мысли, однако это редкость. Мне лично проще повернуться и громогласно попросить помощи, если надо. Может быть тут важно, что я не стесняюсь этого, но тут ведь персональное дело.
Вопрос необходимости скрама как стиля работы актуален для всех. Ведь это решение для бизнеса, а не для людей. Развитие и карьерные перспективы тут убиваются самим принципол полной и мгновенной заменимости любого члена команды.
Скрам сосвсем не способен решить вопрос контроля качества. Сазерленд прямо говорит о необходимости отсутствия команды QA. Наш очень долгий опыт показывает, что команда QA поднимает качество продукта на недостижимую юниттестами и code review высоту. То есть это преднамеренная потеря качества.
Как это ни глупо, но скрам рождает гораздо больше менеджмента, чем иерархическая структура. Возможно, это актуально только для интернациональных распределенных команд, но для нас это актуально.
Есть еще беда неприспособленности скрама к внешнему воздействию. Проблемы пользователей не укладываются в него напрямую. Решать проблему, возникшую у пользователя в текущем спринте нельзя, а неделя для кого-то может быть безумно долгим сроком.
Беды борьбы и управления бэклогом у всех, очевидно, одинаковы и набили аскомину. Исторически у нас сложилось игнорирование эпиков и формирования карманов из неактивных спринтов, что отвратительно, но есть. Возможно кто-то решает это эффективнее. Возможно для небольших проектов вроде клиент-банка такой беды и нет, но для большого прокукта с историей она остра.
Ну и самое смешное, что в конце спринта мы никогда не имеем рабочег продукта. Нам надобится дополнительный спринт на тестирование и залатывание програмных дыр в конце релизного цикла.
Ретроспектива еще одна забытая и бесполезная штука. Я не видел улучшений независящих от команды, наверное, никогда. По идее скрам-мастер должен решать остальное, но у нас его нет. Видимо, в этом=то вся беда и кроется.
Если подытожить, то я никак не вижу радости от внедрения скрама.
ApeCoder
Из-за чего? Нет ли какого-то несоответствия размера команды или повестки митинга Гайду?
Вы можете процитировать гайд на эту тему?
otchgol
У нас нескрамовская команда в 13 человек. Животрепещущие темы обсуждаются сразу же.
Гайдов у нас нет. Причина проста — берндаун чарт полезет вверх. Скоуп спринта не должен меняться для нас посулат. Менеджерский постулат, выведенный из слушания Сазерленда. Так уж получилось, что все его слушали как-то особенно и услышали совершенно разное. Каких-то материальных потверждений этого выслушивания они не привезли. Ну колоды карт не в счет.
ApeCoder
Вы интересовались, что написано в гайде по этому поводу?
maksitron Автор
Я думал больше проблем чем у нас не бывает :)
Подскажите, пожалуйста, зачем и как у вас началось внедрение Скрама?
Кажется, что основная проблема в том, что это было решение сверху, сотрудники его не приняли, а внедрение проходило без соответствующего сопровождения, в связи с чем накопилось много проблем, которые никто не решает и решать не хочет.
Я могу ошибаться, но сейчас картина выглядит именно так.
VolCh
А зачем сотрудникам (читай — разработчикам) скрам или ещё что другое? Моральное удовлетворение от уменьшения тайм-ту-маркет?
otchgol
Я просто не могу себе представить сложившейся команды, которая в один день проснулась и попросила скрама. Людям не нужен скрам — он обесценивает их и препятствует карьерному росту. Скрам нужен компании и это разные вещи. Можно было бы коротко ответить да сверху, но это слишком банально.
Сопровождение скрама в наших реалиях невозможно просто теоретически: нас и PO разделяют континеты. Раньше были страны, но теперь решили улучшить ситуацию, по аналогии увеличения любви к теще с увеличением расстояния до нее, видимо. Скрам у нас песня очень забавная. Он нам с проектом в наследство достался. А проблемы для скрама решать никто и не должен. Основная идея в том, что скрам саморешающая затея. У нас скрам мастера-то нет. А тут проблемы внедрения… Ну главное отрапортовать, что скрамим со всей силы и демы. А там хоть не рассветай. Интересно, что за последние два года количество посещающих демы уменьшилось в несколько раз. Маркетинг с них просто исчез. При этом продажи выросли и довольно значительно. Что-то не так с этим скрамом в наших реалиях…
speshuric
Что сказали или предложили остальные участники команды на ретроспективе? Если вас 13 человек (это многовато, но терпимо), то пробовали просто взять и договориться о лимите в 90 секунд на каждого?
Стендап не про совесть. А про то, что если условный Петя делает задачу третий день, а она оценена в 1 день, то на невыполненный спринт попадает не Петя, а команда. Стендам помогает не превратить эти 3 дня в 5 или 7. Тут вопрос не в том, стесняется Петя или нет. Может он и правда верит, что сегодня всё доделает (и так второй месяц :) ), тут вопрос, чтобы команда увидела риск до провала.
Ну так договоритесь с PO о правилах, как он может emergency в текущий спринт вставлять. Какие критерии, что задача emergency, а не просто приоритетная. Как договориться о том, какие задачи эта emergency пододвигает. Договоритесь о том, что "цена" впихивания в спринт — это рефакторинг или устранение техдолга в следующем с нижней границей оценки 30-50%.
Что-то сильно не то вы делаете, судя по симптомам.
sopov
Не только :)
А вы ставите релиз после каждого спринта?
maksitron Автор
У нас в Банке только ДБО. Хотя может кто-то скрывает :)
Пока нет, но мы стараемся.
sopov
Мы не скрываемся, привет от системы Е.О.
ApeCoder
del
Hanno4ka
Почитав комменты выше, складывается впечатление, что скрам зло и вообще… Так никто и не говорит, что скрам — это панацея от всех бед и проблем.
Наша команда работает по чистому скраму и вполне успешно. Соседние команды на этом же проекте работают кто на чистом канбане, кто исползует смесь канбана и скрама. Кому как удобно и кому как лучше подходит.
У вас от использования скрама одни проблемы? Тут важно понять, что это за проблемы и решаются ли они в рамках скрама. Может, вам лучше от него отказаться и тспользовать другой подход? Такое возможно.
Если у вас очень долгие стендапы — это то, что можно решить не отказываясь от скрама. У нас такое было тоже, но сейчас укладываемся в 15 минут. То, что помогло нам — небольшая подготовка к стендапу, просто вспомни, что ты делал, что планируешь. Можно просто открыть свой рабочий to-do лист и по нему быстро сориентроваться. Если надо что-то обсудить — просим остаться кому надо на дополнительные 10 минут, а остальные могут расходиться работать.
Я не защищаю скрам, я не знаю, какая именно у вас там ситуация (это к тем, кто негативно отзывался). Просто не стоит категорически делить на чёрное и белое. Отладить процесс, тем более новый и незнакомый — это дело времени и упорства. Сразу никогда не получится получить хорошие результаты. Но проанализировать, что не так и как можно это решить — вот это более правильный подход, как по мне.
VolCh
Какую ценность даёт скрам для обычных разработчиков? Максимум, в теории, — посылать всех с «тут быстро и срочно» к по и см. Так тот же водопад ещё больше возможностей для этого даёт. Скрам и прочий формальный аджайл — это, прежде всего, про минимизацию зря выполненой работы.
otchgol
Как итеративный процесс может привести к минимуму лишней работы? У вас должен быть законченный продкут каждый спринт. Вы выполните работу под доделке каждый раз переделывая неудачные с точки зрения PO реализации. Я действительно не вижу как тут можно получить выгоду.
Корпоративные выгоды я вижу легко, но мне это безразлично.
ggo
Предполагается, что доставляя готовый продукт короткими итерациями, и получая обратную связь, можно лучше и точнее понимать, а что нужно сделать для улучшения и это улучшение будет реально полезно.
В противоположность тому, когда итерации длинные, и обратной связи нет, соответственно прогноз полезности будущих улучшений хуже.
otchgol
Накладные расходы на доделку до готового продукта это никак не уменьшает. По сути скрам предполагает прототипирование на готовом продукте.
ggo
Продукты бывают разные.
Есть те, которые можно регулярно улучшать, и эти улучшения сразу становятся доступны пользователям. Слушая пользователей, можно понимать куда дальше двигаться в улучшении продукта.
И есть другие продукты, которые сложно регулярно улучшать, и сложно доставлять эти изменения до пользователей.
Очевидно во втором случае, выгоды от agile-подходов не очевидны.
otchgol
Не знаю как у кого. У нас PO должен повертеть продукт с заказанной функциональностью. Потом потребует поменять. И каждое требование нельзя предтставить в виде полуработающего прототипа или слепить на коленке — протукт должен быть готовым. Вот те накладные расходы скрама про которые я говорю. Пользователь тут безразличен. Это дело PO слушать его или нет и чаще всего нет в виду отсутствия прямой связи PO-пользователь. PO-маркетинг или PO-support вполне работающий диалог, а конечный пользователь недоступен… Ну у нас так.
ggo
Agile-подходы не универсальны. Запустить ракету на Луну по agile не получится. Да даже не ракету, гаджет какой-нибудь изготовить в товарных количествах и продать.
Если есть регулярная обратная связь от конечных пользователей, то слушая ее, можно попробовать не делать лишнего. Это «про минимизацию зря выполненой работы».
Если у вас конечный пользователь недоступен, то регулярная доставка улучшений становится несколько выхолощенной. А если уж совсем формализоваться, то ее (регулярной доставки) и нету.
зы
это не означает, что у вас все плохо, и вы не умеете работать.
разные продукты — разные практики.
poxvuibr
Да, они хороши для небольших команд и немастабных задач.
И египетские пирамиды тоже не соберёшь. Но каждая из команд, которая участвует в процессе вполне может работать по гибким методологиям.
Hanno4ka
Вот мне очень понравилась книга «Scram. Революционный метод управления проектами». Само название, конечно очень кричащее, но книга хорошая. Из неё я сделала такой вывод. Джеф Сазерленд в своей работе сталкивался с определёнными проблемами (организации проекта и процессов). Чтобы их решить, он применил определённые методики. Собрав эти решения воедино, он назвал это «Scrum».
Очевидно, эти решения проблем не помогут вам, если у вас другие проблемы.
Если вам надо забить гвоздь и вы берёте картонный лист для этого, то это не значит, что картон плохой. Каждой задаче свой инструмент. Вот и всё.
otchgol
Эм… Тойота как-то выпускает машины аджайлом, говорят. Может врут…
Что касается обратных связей, то это инструмент PO. Это никак не связано с процессом разработки. В далекие нулевые годы мы разрабатывали продукт исходя из запросов пользоввателей без аджайла. Очень редко мы переделывали что-то в те далеки благодатные времена. А с аджайлом делать одно и тоже несколько раз приходилось. Дурные понятия UX и дизайн в целом портят кровь…
Что касается умения работать, то меряться тут нет смысла. Продукт наш общеизвестен и приносит очень хорошую прибыль хозяевам. Это единственный важный критерий, думается. Мне безразлична оценка эффективности аджайла в компании. Я против него.
speshuric
Lean production != Agile.
У них есть общие моменты, но это сильно разные штуки.
VolCh
Как раз потому что итеративный. Быстрая обратная связь на неудачные решения. Не пилим фичу из 50 экранов 2 года, а потом оказывается что никому она не нужна, а быстро делаем 5 экранов, запускаем и смотрим результаты, может и не надо остальные 45 делать.
ggo
Ну конкретно в скраме еще много внимания уделяется команде, которая непрерывно качественно растет (во всех аспектах — люди, процессы, инструменты, культура и т.д.)
otchgol
Я не могу себе представить чистого скрама в жизни живущего продукта. Эскалейшены и прочие срочные беды всегда его нарушают. Возможно, что в среде аутсорса или подобных независимых команд, он может существовать. Но в жизни продукта после 1.2 я его представить не могу.
Скрам хорош для экстравертов. Я мало видел программистов экстравертов. Скрам нужен менеджменту как средство уменьшения рисков. А зачем он человеку я представить не могу.
ggo
Предполагается, что вам (разработчику) он (скрам) нужен, потому что вы получаете кайф не от написания крутого кода, а от того что сделали мир чуточку лучше вместе с чуваками из вашей команды. «Сделали мир чуточку лучше» — в смысле есть реальные люди, которые реально тащатся от того, что пользуются вашим продуктом. И эта польза не какая-то виртуальная польза (типа была красная кнопочка, а стала синяя, ненавижу красный цвет), а реальная (типа экономлю свое время, трачу меньше денег, стал больше зарабатывать, и т.д.)
VolCh
А как быть с позицией «чем тратить время на все эти ритуалы, я лучше фичу запилю или баг пофикшу, чтобы людям жить стало легче»?
ggo
Типичный ит-шный подход.
Вы мне скажите чо залабать, а я залабаю. Зачем, почему, меня не волнует.
Он, этот подход, не хороший и не плохой.
Но иногда приходит осознание, что чем меньше между конечным пользователем и реальным реализатором промежуточных звеньев, тем лучше. (быстрее, точнее, дешевле и т.д.) Собственно скрам про то, как это (продуктовую направленность всех активностей команды) прошить в ДНК членов команды. Чтобы в принципе не было фраз «Вы мне скажите чо залабать, а я залабаю».
VolCh
От скрама количество звеньев не меняется, а может даже увеличивается (стейкхолдеры напрямую к разработчикам не обращаются, если надо что-то срочно запилить).
И дело не в «Вы мне скажите чо залабать, а я залабаю», а в «чтоя сделал, что я собираюсь делать и какие проблемы — можете в джире прочитать, а я пилить буду»
ggo
Не единым стейкхолдером жив человек.
Некоторое время назад канонический процесс разработки выглядел как-то так. Хотелки в том или ином виде прилетают к Аналитикам. Аналитики рождают ТЗ. Разработчики на основании ТЗ ваяют поделку. Тестировщики на основании ТЗ и поделки, проводят тестирование. Админы на основании инструкции к накату и поделки, выкатывают в прод. Каждый из этапов формализован, расчерчен SLA-ем, создается и сохраняется куча артефактов. На любом из этапов можно вернуться назад на любой предыдущий.
Скрам же утверждает, что ни Аналитиков, ни Разработчиков, и т.д. нет. Есть только команда, саморазвивающаяся и кроссфункциональная, которая отвечает за продукт от начала до конца. В рамках процесса делаем только то, что реально кому-то приносит пользу. В общем это «про минимизацию зря выполненой работы». Количество звеньев существенно уменьшается.
Про «можете в джире прочитать». Это всего лишь индикатор зрелости спеца (и в какой-то мере его окружения). Раз так говорит, значит еще не понимает что такое команда и почему 1 + 1 > 2.
VolCh
Или просто не понимает, чем ежедневные митинги, сильно ограниченные по времени и содержанию, лучше других способов информирования, шаринга знаний. Я вот только что тест прошёл на свои каналы восприятия, который показал, что лучше всего мне читать, потом смотреть "картинки" типа графиков и диаграмм, а только потом слушать.
otchgol
Это для студентов хорошо. В качестве самореализации. Для меня это не важно. Я делал продкуты, которыми пользовались и их закрывали. И писал дрянь, которая успешно продается по сию пору.
Вид процесса производства продукта в любом случае никак не изменяет удовольствие/стыд от произведенного.
Наш цикл выдачи продукта конечному пользователю — квартал. Разные команды выпускают разные продукты разными процессами примерно в эти сроки.
То есть не вижу никакой радости аджайла опять…
ggo
Еще один типично ит-шный подход.
Я сделал коричневую субстанцию, но она отлично продается. Мне за это стыдно.
И я сделал конфетку, но она не продается. Реально классная штука.
Опять же, это не хорошо, не плохо.
Так устроены ит-шники
Просто в реальном мире, если твоей гениальной поделкой никто не пользуется, то это поделка бесполезна. Если согласиться с этим тезисом, то жизнь сильно упроститься.
otchgol
Мне не нужно повышение самооценки. У меня лично на пятерых хватит. Продукт, надо которым я работаю очень хорошо продается. Сделки большие и вполне решулярные. Я в любую минут пому увидеть ненулевое количество пользователей использующих то, что я пишу.
И меня бесит скрам.
Mishiko
Никак не могу понять — какое место занимает тестирование в спринте?
Если спринт завершен без тестирования, то не факт что функциональность рабочая, т е фактически спринт не может считаться завершенным без тестирования. Если включить тестирование в спринт, то сроки почти наверняка погорят из выявленных ошибок (допустим уровня critical).
poxvuibr
То, что задача протестирована — один из критериев Definition of done. Не протестированная задача не считается закрытой.
Mishiko
— ну и сколько отводится на тестирование и устранение дефектов? Дефект вещь не предсказуемая способная легко поломать спринт. А разработчик норовит тянуть завершение задачи до конца спринта. Из Вашего ответа я не сумел понять сколько времени закладывать в каждую задачу на тестирование. Может есть какие то рекомендации, практики?
VolCh
Так же как на разработку. В смысле не столько же, а сначала от балды, с последующим анализом выявленных багов. Багов в оценке и качестве тестирования.
Mishiko
И что, тестировщики присутствуют на планировании спринта? Ни разу не видел. И насчет «балды» поражен. А как же «покер планирования»?
В итоге хочу узнать: в Вашей версии планирования итерации какой процент времени отводится на тестирование и за сколько дней до конца итерации разработчики должны закончить работу, чтобы тестировщики могли протестировать задачи?
napa3um
Тестировщики присутсвуют на планировании спринта, конечно, если являются частью скрам-команды. Но возможна и организация тестирования в виде «внешнего сервиса» скрам-команды. В обоих случаях нет никаких принципиальных проблем в планировании (и постепенном уточнении в последующих спринтах) затрат на тестирование.
Mishiko
— а если не являются, то команда пишет код без ошибок?
— что позволяет разработчикам закрывать спринты с нетестированным кодом, т е кодом который возможно вообще не работает или работает неверно.
— пожалуйста, подскажите: какой процент времени итерации в Вашей команде отводится на тестирование и за сколько дней до конца итерации разработчики должны закончить работу, чтобы тестировщики могли протестировать задачи?
napa3um
Если не являются, то роль тестирования на себя берут либо сами программисты, либо внешний сервис, как я и сказал.
У каждой истории утверждается т.н. definition of down («условия приёмки»), в некоторых случаях это действительно бывают условия, не включающие тестирование напрограммированного, но чаще всего, конечно, кейсы тестирования являются частью содержимого задачи (и рождаются на «груминге» в ходе уточнения требований к пользовтаельским историям и декомпозирования их на технические таски).
Определяется для каждой задачи отедельно.
Тестировщикам и программистам по возможности должно быть всегда, чем заняться на спринте. Включая задачи «разогрева» пользовательских историй для следующих спринтов (декомпозиции или даже намёток кода). Считать спринт забегом, подготовка к которому не является его частью или после которого хоть трава не расти — не совсем о скраме, скрам — это про итеративный, повторяющийся процесс, и на каждой следующей итерации всегда есть наработки из прошлого. И тестеры, конечно, не сидят и не ждут, пока программисты закончат свою работу, чтобы начинать тестировать, у них уже хватает и без этого тестирования (недоисправленные и недодеплоенные задачи из прошлого спринта, превратившиеся в новые задачи текущего, например, или другие «короткие» для кодирования задачи).
Mishiko
— похоже речь идет о теории, а не о практике (верный симптом наличие общих фраз и отсутствие каких то чисел). Как практик я знаю, что слабое место скрама — это сдача в конце итерации не протестированных фич (самотестирование разработчиком это чепуха), которые потом возвращаются в следующую итерацию. Заказчику при этом бывает сложно объяснить, почему мы опять делаем то, что ему уже показывали как сделанное.
— по моему опыту необходимость и глубина тестирования, в первую очередь связаны с личностью разработчика пилившего фичу. Про кого то я знаю что его код не потребуется править, про кого то могу сказать что почти наверняка функционал не реализован так как надо. Конечно что то зависит и от сложности задачи, но основной фактор это личность разработчика. Опытный тимлид учитывает это в разработке. Но в любом случае это плохо вписывается в теорию скрама. Во всяком случае я ясного ответа о том как планировать тестирование в итерацию не получил.
napa3um
Думаю, что наши с вами команды, задачи, ограничения спринтов, а так же участие в скрам-группах тестеров (и других некроссфункциональных единиц — например, Java Developer + PHP developer) будут превращать любые данные мной цифры для вас в случайный шум, у вас всё естественно будет совсем иначе. (Да, я тоже считаю нашу практику не совсем скрамной, и у нас и без этого хватает отличий от «настоящего» скрама. И, уверен, у вас тоже не «идеальный сферический» скрам, ибо идеальные сферы на практике обречены превращаться в катышки опыта).
Вот и у вас не скрам, похоже, который слегка против перекосов компетенций в команде (у вас, видимо, джуны с сеньорами). Вообще, тестирование, зависимое от личности разработчика — очень плохая практика безотносительно скрама.
Думаю, в режиме «ага, удивите меня» вы вряд ли сможете найти такое решение. Оно вытекает из личной практики и организации процессов (скрам не освобождает от необходимости применять когнитивные усилия по ведению проекта).
Mishiko
Зачем писать общие фразы? Вопрос о том как планировать тестирование в итерацию. Скрамомерством заниматься не интересно.
napa3um
«Какие юзерсториесы должны быть воспроизводимы на демо в этой задаче? Какие аспекты, какие критерии качества выполнения этой задачи важны стекхолдерам, что именно в этой юзерстории создаёт вэлью, ценность для пользователей, добавляет конкурентное преимущество продукту? Какие шаги нужны для воспроизведения юзерстории от начала до конца? Какое поведение тестируемого продукта ожидается, как его залогировать/идентифицировать/измерить?» — причём, все эти вопросы задаются и уточняются на всём жизненном цикле задачи, сначала при грумминге со стороны бизнеса продуктовнером для продуктового бэклога, потом груммингом программистами и тестировщиками для бэклога спринта. Да, сами тестировщики ещё при планировании реализации могут в силу своего проф-опыта видеть «уязвимые» места в пользовательских сценариях, корректировать их, предлагать свои варианты, в этом их польза на грумминге ровно такая же, как остальных участников — вложить в описание задачи до её взятия в работу максимально экспертной инфы о потенциальных подводных камнях и рисках со стороны каждого этапа реализации (в том числе и прохождения тестирования). И точно так же каждый участник помогает оценить задачу со своей стороны, а решение расхождений в оценках сложности задачи в ходе скрам-покера помогает каждому узнать о сложностях «чужих» (не своей специализации) этапов реализации «своей» (в скраме всё — «наше» :)) задачи.
Да, перечитал всё написанное мной выше — читается как анекдот. Идеальные процессы, идеальные люди, и всё это обмазано смузи и коворкингами. А на самом деле — да, просто собирается толпа людей, спорят о процессах и ролях, апеллируя ко всем заветам скрама, забывая про спринт, продуктовнера и свои профессии, несогласованно между собой создают в ишью-трекере кучу противоречивых задач (оформляя их кто во что горазд), назначают кучу встреч и кучей других способов играют в офис. При этом скрам-коучи обещают, что вот-вот шит-шторминг стихнет, и мы (в пике Балмера, видимо) сразу покажем 100500% эффективности. Это версия для любителей депрессивных интерпретаций.
Busla
Если у вас есть тестировщики (и прочие выделенные «части скрам-команды»), то у вас не скрам. Под-команды явно запрещены в скрам-гайде. Тестированием должны заниматься сами разработчики, либо внешние сервисы.
otchgol
Я не говорил, что они часть команды. Мы тестируем саму в рамках спринта. И это бесит.
VolCh
Если в критерии завершенности задачи входит тестирование, а на планировании тестировщиков нет, то это что угодно, но не скрам, имхо.
Mishiko
Вы говорите максимы, но не отвечаете на вопросы. Речь идет о каком то теоретическом скраме? Ведь не трудно ответить на вопрос, вспомнив как прошло прошлое планирование: «в Вашей версии планирования итерации какой процент времени отводится на тестирование и за сколько дней до конца итерации разработчики должны закончить работу, чтобы тестировщики могли протестировать задачи?»
poxvuibr
У меня о практическом.
Какой-то процент времени не выделяется. Тестировщики вместе со всеми участвуют в планировании и повышают сторипойнты на задачу если её сложно протестировать.
Спринты двухнедельные, как правило задачу надо сдать в начале второй недели, чтобы её протестировали, вернули дефекты, поправили их и закрыли. Пока ведётся разработка, тестировщики как правило пишут план тестирования.
Mishiko
— это понятно и звучит логично, но возникает вопрос: чем занимаются разработчики вторую неделю, пока тестировщики тестируют фичу? Допустим все получилось сразу и дефектов нет. Получится что разрабы пинают балду до конца итерации или в итерацию начинается подброс не запланированных задач.
poxvuibr
У разработчика всегда есть чем заняться. Чаще всего это решение всякого технического долга, или задачи из следующего спринта.
VolCh
Там где был скрам в моей практике или что-то к нему близкое, единственное время было — это время спринта. Ни сколько времени займёт решение задачи, ни сколько процентов в этом решении займёт тестировании мы не оценивали. Два основных подхода: задачу оценивают (в сторипоинтах) разработчик(и) и тестировщик вместе и на тестирование отдельная задача. Так что вопросов «сколько процентов» или «за сколько дней до конца» не возникает.
otchgol
Никак не могу согласиться. Зачем разработчику тянуть с задачей до конца спринта? Если задача нестолько долгая, что занимает почти весь спринт, то она должна быть побита на подзадачи. А задача на три дня не должна породить багов на спринт. Мне так кажется. Бывает все, но нетривиальные задачи довольно редки. По моему очень богатому опыту.
Mishiko
Пример: Спринт двухнедельный. Фича — очень длинное древовидное меню, чтобы не положить фронт использовать автоподсос, для реализации нужно сделать что то на бэке, что то на фронте. Задействуем двух разработчиков — один на фронт, второй на бэк, каждому задача на неделю. Оба начинают одновременно и в какой то момент должны объединить свои усилия. По плану остается неделя на тестирование и устранение дефектов.
Дальше все идет не так как планировали) Фронт готов, бэк оказался сложнее чем думалось и затянулся, потом пытаемся соединить — оказалось что фронт и бэк не стыкуются в некоторых местах, фронт дорабатываем, бэк дорабатываем, стыкуем, ловим кучу ошибок (без всякого тестирования). Как результат — вроде сделано, но уперлись в конец спринта и получили фичу без тестирования. Ну а в следующем спринте соответственно получаем тестирование фичи, еще ошибки (уже не тривиальные) и тратим еще неделю на их устранение.
ggo
Классическая ИТ-проблема. Скрам на нее никакого ответа не дает. Скрам про другое.
Как синхронно внести изменения и выкатить в две и более тесно взаимодействующие системы? Решается ИТ-средствами — версионирование API, управляющие флаги, выкатка в прод в несколько этапов, и т.д.
Mishiko
— не усложняйте, это типичная фича размером в 2 человеко недели, разбитая на двух разработчиков. Если тут начать «версионировать API» — заказчик этого не поймет.
ggo
Вы только что говорили, что реальная доставка будет только через 2,5 спринта (исходя из опыта). А сейчас говорите что заказчику обещаете доставить за 1 спринт. Один из топов проблем, знаем что не сделаем в обещанный срок, но все равно обещаем данный срок.
И версионирование API не единственное и не обязательное решение. Подойдет любой подход, который снимет известные риски за приемлемую цену.
Mishiko
— ничего такого не говорил. Спринт двухнедельный, фича на 2 человека недели пилится одновременно двумя разрабами. Есть еще неделя на тестирование и устранение дефектов. Ничто не предвещало) Но это все чепуха, это был лишь пример того как в конце спринта можно получить запиленную (?), но не протестированную фичу. Наверняка можно и другие случаи из жизни вспомнить. Вопрос в том что с этим дальше делать? Вот тут люди пишут — «Задача является выполненной, если она протестирована» (правда формулировка тоже наводит на мысли, похоже автор не уверен в том что то что не протестировано, то не выполнено). Правильно пишут.
otchgol
У нас не вебовый продукт. Все, что вы говорите неактуально для разработки. Однако наш продукт предназначен для решения этой ситуации. Прототипируем бэкэнд за пару часов. Делаем его макет с ограниченным количеством ответов. Пишем фронтэнд на этом прототипе и закрываетм протестированный таск. Делаем бэк и видим, что параметры не подходят. Дальше или останавливаем и перепланируем спринт или делаем бэк как договорились. Задачи совершенно параллельны и объеденения не требуют. Тестирование в спринте в любом случае.
Вроде ничего не упустил.
Mishiko
— не вежливо прозвучало
— это был пример ситуации, когда запланированная фича оказалась не протестирована, а не исследование Вашего гениального продукта. Могу слова «фронтэнд/бэкенд» заменить на что то иное, если Вам сложно абстрагироваться.
— это было сделано, как и другие необходимые телодвижения. Все это можно обсудить на ретроспективе и понять что пошло не так (как всегда виноваты люди). Проблема не в этом конкретном случае, а в ситуации когда фича вроде бы запилена, а времени на тестирование в спринте не осталось.
otchgol
Уж простите, если вдруг обидел. У каждого свое видение. Ваш пример взаимозависимых задач не актуален для десктопных приложений. Собственно все, что я хотел сказать.
Если прототип был вначале спринта, то как бэкэнд держал фронт задачу?
Тут просто неправильно оценена задача бэкэнда. Такое бывает. Это исключение. В неисключительных случаях все можно успеть за спринт.
Словом никаких проблем закончить задачу в спринте нет. Это если хотеть.
VolCh
Бэкенд не держал фронт задачу, он держал подзадачу интеграции готовых фронта и бэка. Задача из трёх подзадач: фронт, бэк и их интеграция.
otchgol
Не знаю как у кого. Мы включает тестирование в спринт. Сроки на него закладываются изначально. При большом количестве серьезных багов можно говорить о неправильной оценке задачи. Что делать с ней дальше дело десятое. При правильной оценке сроки не горят.
Mishiko
— допустим, теперь вопрос: разработчики у вас заканчивают пилить фичи за сколько дней до конца итерации?
otchgol
Почему вы думаете, что это должно как-то регламентироваться? Кто как закончит, так и будет. В последний день итерации подходит вполне. И, ктсати, тестируют у нас тоже разработчики. Сазерленд требует тестировщиков увольнять. Команда должна быть универсальна и равномерна. Это требование скрама от апологета.
Mishiko
— идиотское требование: у тестировщика и разработчика разная психология, разное отношение к тому что существенно, а что нет, разный набор знаний. Даже обсуждать не интересно. По такой логике и техписы не нужны — разработчик сам все задокументирует)))
otchgol
Техписателей у нас тоже заменяли. Качество без QA значетельно ухудшается это проверенный временем факт. Я говорю о технологии. Апологет скрама Джефф Сазерленд в ответ на вопрос нашего PO о судьбе QA сказал буквально «get rid of them». Не о чем спорить.
Кстати я работаю на компанию, которая производит известные утилиты для QA. Можете на слово поверить, что я знаю очень много о QA и разработчиках. Можете и не верить.
Busla
Если требование не устраивает, значит скрам вам не подходит — используйте другую методику. Пусть она похожая, но это не скрам.
otchgol
В некоторых случаях это значит меняйте место работы. В небольших городах это не всегда возможно.
В общем, мыши будут плакать и колоться пожирая кактусы…
Mishiko
— а можно скрам оставить, а Сазерленда, который как то обходится без профессионального тестирования, в игнор? Или Вы скрамонаци?
otchgol
Ну это как оставить ленинизм отрекшись от вождя мирового пролетариата. Проще сделать новую ветку и назвать это все рускрамом или нашакомпаниярамом. Это просто другое.
Я не защищаю скрам. Я его ненавижу. Все, что происходит навязывается мне. Возможно потому я и негативен. Все что я пишу это просто попытка разобраться в потенциальной применимости скрама к разработке.
Mishiko
Как раз мне Scram нравится, как ко всему отношусь к нему не как к догме с авторитетными вождями. Единственный вопрос который меня смущает, это то что тестирование способно разрушить любую итерацию, а отсутствие тестирования лишает смысла рапорт заказчику о готовности фичи.
otchgol
Это просто получается одна из аджайл технологий. Не скрам, не канбан, а что-то там. От меня же требуют скрама и следования ему. В качестве иконы поднимают его над моей головой и толкают. И я никогда не видел ни одной команды, которая бы могла ему следовать идеально. Меня бесит, что следовать всему неприятному в нем должен я, но все приятное в нем может быть убрано.
time2rfc
мир изменчив и странно ожидать что все будет идти по плану, но у меня есть опыт скрама в разных командах, однажды мы прожили пол-года без ПО благодаря тому что довольно хорошо жили по скраму до этого
beezy92
Потому в scrum рекомендуется автоматизировать большую часть кода/функционала. Чтобы CI/CD pipeline работал и выявлял ошибки. Чтобы можно было делать как можно больше итерации. А держать QA дорого и долго.
Mishiko
— Ваше замечание только подтверждает мысль, что в Scrum тема качества и тестирования плохо продумана
napa3um
Строго наоборот, она продумана и именно вокруг этой продуманности и построена. Скрам — для быстрого вывода на рынок продукта, быстрого получения фидбэка и быстрой коррекции курса развития. Сначала занять место под солнцем, привлечь бабло, и лишь потом уже закрепляться качеством и построением «взрослых» процессов вместо скрама. Т.е., скрам именно про «лучше хуже, но раньше», именно про снижение издержек на вывод продукта путём некритичного и контролируемого снижения качества (меньше бюрократии в процессах, меньше предположений о рынке, больше реального «прощупывания»).
Lofer
Это общая цель всех Agile методологий, а не только Scrum. Просто в Scrum ориентация на ритмичность поставок, даже в ущерб «результату» (давайте сделаем один справочник вместо двух нужных для фичи, потому что в итерацию влазит только один)
napa3um
Всё так, скрам — лишь один из аджайл-подходов. И его ритмичность присуща не только скраму, вообще говоря, это аспект любого повторяющегося процесса. Без водителя ритма никакая схема не взлетит.
Lofer
Канбан не предполагает ритмичности по времени, в отличие от Scum, хотя тоже к Agile относится. Можно выкатить одну фичу через неделю, а другую через месяц.
Mishiko
Какой может быть «вывод на рынок» у не работающего продукта?
piton-vas
У нас тестеры в команде и присутствуют на планировании. Если задача обширная для тестов, они накидывают поинтов. Также бывают задачи только на тестирование, их тоже берем в спринт и оцениваем.
Задача является выполненной, если она протестирована ( ручное + по возможности you)и все баги исправлены. ( было бы здорово ещё включать время на написание юнит -тестов и код ревью, но ещё не сделали так)
Если в ходе выполнения вылазят критиков баги, требующие много времени на исправление, то можем и на следующий спринт перенести. Либо делаем в текущем, а потом переоцениваем задачу. Все зависит от загрузки и приоритета задач.
eugenvz
Автору спасибо за то, что поделился, как трансформация идёт в его компании.
Судя по написанному работы у вас ещё очень много и вы на пути к Scrum.
Понимаю, что бесплатный совет обычно не обладает высокой ценностью :-), но рекомендовал бы больше внимания уделить Scrum Guide'у, как основному документу про Scrum (обратите внимание на End Note).
Не соглашусь с тезисом про то, что мало где пишут про то, что нельзя совмещать роли PO и SM. На самом деле это одна из самых часто упоминаемых тем, суть которой в ярком конфликте интересов у этих двух ролей.
Можете на схожие темы погуглить: PO vs. PM, SM vs. PM и т.д. найдёте очень много интересного и полезного для себя и своих коллег.
Для всех непонимающих (обычно это касается событий в Scrum, например Daily Scrum): вы, скорее всего, не знаете и не понимаете фреймворка и его сути. Здесь я ничего никому доказывать не буду, потому что комментарий разрастётся до размера статьи и даже больше :-) Обратите лишь внимание на следующие определения в Scrum и попробуйте осознать их глубину, особенно последнего, третьего:
Scrum is:
• Lightweight
• Simple to understand
• Difficult to master
В заключение хочу сказать, что в служении "карго-культу Scrum" я замечен не был :-), и основная проблема компаний и команд в том, что они Scrum'ом называют НЕ Scrum, а что-то другое, при этом страдают ни в чём невиновные команды :-)…
В Scrum'е я немного понимаю, так как практикую его уже некоторое время и являюсь сертифицированным (Scrum.org: для знающих людей ценность сертификации на этом ресурсе должна быть понятна) специалистом .
VolCh
Противоречиво немного :) А по сути, зачем простым разработчикам его понимать? Скрам-мастер должен понимать и говорить остальным членам команды что, как и когда делать, нет?
eugenvz
Покажу разницу (интерпретация на русском языке): "простой для понимания" vs. "трудный для совершенного овладения".
Что должен делать Скрам-мастер также написано в Scrum Guide. В первую очередь, несёт ответственность за продвижение и поддержку Scrum в соответствии со Scrum Guide.
Говорить остальным членам команды что и как делать идёт вразрез с понятием самоорганизующейся (self-organizing) команды и больше похоже на руководство детским садом, например.
"Простым" разработчикам, возможно, и незачем его понимать.
VolCh
Так команда вполне может самоорганизоваться, а бизнес, руководство требует именно скрам, требует соблюдения ритуалов, плюсики вон ставят выполнил или нет очередной пункт ритуала, может даже премии дают по количеству плюсиков ).
Или скрам подразумевает, что команда должна самоорганизоваться ровно так как описано в гайде, не читая его? А если читать его нужно, то это уже организация автором гайда. И зачем тогда читать всем, если один может прочитать и описать необходимые ритуалы?
Как по мне, то самоорганизующаяся команда — это, прежде всего, команда, которой не нужны начальники, чтобы работать по утвержденному и приоритезированному списку задач. В работе такой команды должно быть минимизировано количество ситуаций "нечего делать", "жду когда закончат блокер", "а я не знал, что сосед по столу мог объяснить мне эту задачу за 5 минут и я сделал бы за два часа, а не на 5 дней завис" и прочие организационные неувязки. Скрам для этого не нужен, скрам — это рамки (одно из значений "фреймворк"), в которую загоняют команду. Ну описал скрам-мастер рамки, в которых нужно работать, вздохнули, выучили и работаем. Пару раз по голове получили за выход из рамок типа взятия задачи от стейкхолдера без участия, как минимум, продактаунера — перестали так делать. Все довольны, нет? Бизнес рапортует — у нас внедрён модный скрам, разработчики выполняют ритуалы, недолюбливая их, но находя плюсы типа того, что любого стейкхолдера можно послать к скрам-мастеру или по, не вникая в детали — ничего не знаем, у нас спринт, у нас бэклог.
eugenvz
Постараюсь ответить коротко.
VolCh
1. Кому нужно? Как по мне, то обычно определенная организация процесса нужна бизнесу, менеджменту для, прежде всего, прозрачности и предсказуемости, управляемости, контроле — в их понимании. Самой команде обычно всё это не нужно, фичи и фиксы, польза пользователям доставляются по мере готовности согласно намеченному плану.
2. Я тоже не верю. Но я и не верю, что авторы какой-то книги, которую руководство воспринимает как догмат, знают как эффективно организовать команду людей, которых они никогда не видели.
3. Да может они и смогли донести понятно, но проблема организации если и стала проблемой команды, то на уровне «мы не решим нашу проблему — проблемы (увольнения, депремирования и т. п.) будут у вас». Команда радостно соглашается исполнять требуемых от них ритуалы и играть назначенные роли, производить события и артефакты, искренне надеясь, что даже если проблема бизнеса не решится, то команду виноватой не сделают и у неё проблем не будет, поскольку делала всё согласно гайду или прямым указаниям.
ApeCoder
Для того, чтобы так было нужна организация, обладающая определенными свойствами. Например, может быть организация разработки где принято делать релизы раз в год. Какие-то фичи готовы, но чтобы зарелизить, надо стабилизировать код — поэтому нельзя выкатить фичу отдельно.
ApeCoder
С учетом того, что большинство и не пытается, в этом нет противоречия.
speshuric
Первые 2-3 спринта — может быть и должен. А дальше он должен быть заменимым. Скрам-мастер не может же за команду решать на ретроспективе. Не может за команду вносить изменения в процесс.
ggo
Скрам-мастер не решает на ретро, и не реализует принятые решения.
Скрам-мастер ручками ничего не делает, а фасилитирует ;)
Другое дело, что чувак, исполняющий роль Скрам-мастера, может исполнять и другие роли. И в рамках исполнения других ролей, вполне может делать что-нибудь руками.
speshuric
del, не на то сообщение ответил
tangro
Вот в медицине есть понятие двойного слепого теста, который объективно показывает насколько лекарство правда работает. Это достаточно долгий, затратный, но всё же дающий хорошее понимание вещей процесс. Можно ли придумать что-то подобное в ИТ, например, для оценки успешности применения того же скрама? Мнение участников при этом, конечно, аргументом быть не может (ну типа как мнение разработчиков лекарства о том, что оно работает, совершенно не влияет на результат двойного слепого теста). Было бы интересно придумать методику оценки.
ApeCoder
Я думаю можно такое провести, если запретить разработку без лицензии.
В противном случае ни для кого из участников это не окупит. Есть разные исследования проессов на студентах — например TDD, кажется. Но на боевых задачах и квалифицированных специалистов это безумно дорого.