По Scrum все же считается, что каждый член команды может быть взаимозаменяем.
На практике такое бывает редко, поэтому лучше всего на уровне планирования предусмотреть риски и подумать как их можно избежать В любом случае стоит на ретро обсудить причины, почему не успел сделать и как в будущем можно не допустить таких ошибок
Доска - это все таки про канбан. И на самом деле в разработке to do, in progress, done мало, по крайней мере по моей практике
На счет эффективности и как она считается. Приведу картинку из SAFe, в которой они как раз пытаются объяснить в чем плюс гибкой методологии
Т.е. при обычной (справа) waterfall модели, ты будешь разрабатывать долго и не факт, что это то, что нужно пользователю (plan)
А вот за счет Agile и постоянных проверок, ты сможешь не отходить сильно от того, что нужно пользователю и за счет этого быть эффективнее.
Я писал пример в статье на эту тему, что за счет иттераций и взаимодействий с PO мы смогли сократить время разработки за счет того, что не стали делать лишние вещи, а быстро проверили гипотезу
Поэтому обычно, когда говорят о повышении скорости, то смотрят через эту призму.
--
А ретро, как сказали выше, есть не только в Scrum. И оно просто позволяет учится на своих ошибках, а не закапывать их в стол, как часто происходит в разработке
На самом деле Вы правы. Поэтому команды часто делят на "продуктовые" и "сервисные".
В "продуктовых" часто есть смысл в Scrum и Agile, просто потому что это либо разработка нового, либо задает темп разработки
А вот в "сервисных" (то что ты говорил экслуатация и поставка) лучше использовать канбан. Сделать доску, поставить WIP лимиты и просто наглядно смотреть за тем, как идут задачи.
Задача данной статьи помочь разобраться в Scrum Guid и она на самом деле достаточно сильно на нем базируется. Потому что порой ты приходишь в команду и хочешь быстро погрузить их в материал и удобно, когда есть статья, в которой есть базовые моменты с иллюстрациями.
Про релизы в статье я написал только один раз
Важно помнить, что Increment - не значит релиз. Scrum не обязует каждый спринт выпускать новый релиз.
Больше в статье я не упоминал данный вопрос, так как Scrum и не предполагает его. Вы сами можете решить в какой момент требуется проводить релиз Поэтому у меня нет цели сравнивать его с другими фрэимворками и методологиями.
Задача данной статьи помочь разобраться в Scrum Guid и она на самом деле достаточно сильно на нем базируется. Потому что порой ты приходишь в команду и хочешь быстро погрузить их в материал и удобно, когда есть статья, в которой есть базовые моменты с иллюстрациями.
Про релизы в статье я написал только один раз
Важно помнить, что Increment - не значит релиз. Scrum не обязует каждый спринт выпускать новый релиз.
Больше в статье я не упоминал данный вопрос, так как Scrum и не предполагает его. Вы сами можете решить в какой момент требуется проводить релиз Поэтому у меня нет цели сравнивать его с другими фрэимворками и методологиями.
Со своей стороны могу только добавить, что мой пример из комментария основан из практики разработки. И тут как раз вопрос в том, что SCRUM это только фундамент для работы, а дальше каждая компания адаптирует его под себя. Мне, видимо, повезло и я попадал в команды, в которых не вставал вопрос, что такое дэйлики и зачем они нужны. Мы синхронизировали работу и понимали на каком мы этапе и кому с чем можно помочь. Но Ваши материалы почитаю, звучит интересно
вы всегда работаете по методике. В любой компании есть бизнес процесс выстроенные годами
Поэтому это просто одна из идей как можно выстроить процессы так, чтобы разработчик мог принимать решения и при этом компания шла к своей цели постепенно и проверяла все идеи
Agile наоборот говорит о том, что нужны амбиции. Потому что если в обычных компаниях все за разработчика решают менеджеры, то в Agile разработчик является ключевым человеком. (Но да, я часто приходил в компании и слышал «а мне удобно, задачу дали, а я работаю. А как там планируют, это их проблемы»
Ценность инкремета определяется на Sprint Review Product Owner и стэйкхолдерами, что указано в статье
В скрам не сказано, что не нужна цель. Просто ее нужно всегда проверять. Скрам нужен, когда вы понимаете что хотите, но не понимаете как достичь. И тут с помощью инкремента вы ищите свой путь
Но если посмотреть с другой стороны, а как разрабатывалась машина? Она же появилась не сразу
В начале сделали Ford T. Отличный автомобиль. мотор заводится в ручную, кабина деревянная. Усилитель? Не, не нужен. Начали продавать. Продали какое-то количество. Дальше внедрили стартер, чтоб руками не заводить и таким образом открыли доступ женщинам водить. Потом поставили усилители, чтобы улучшить комфорт.
Поэтому тут вопрос задачи. Если вы хотите сделать машину с усилителем, стартером и т.п., то вы делаете ее целиком. (Если смотреть по матрце стэйси, то это можно отнести к простой системе)
Но вот если ваша задача выйти с новым, инновационным продуктом, то без проб и ошибок не сделать хороший продукт. Продолжая пример с автомобилями. Вот Wolkswagen вложил несколько миллиардов в электромобили. Зачем? Чтобы разработать платформу, проработать эргономику и т.п. Прошло немного времени и оказалось, что все же электромобили не факт, что будущее. И вот вопрос: а можно ли сделать прототип, без платформы и проверить, а нужно ли вообще это делать. А только после этого тратить миллиард на платформу?! И вот тут Agile помог бы потратить меньше денег, чтобы в начале проверить, а потом уже вкладываться в понятный маршрут
Если смотреть по Scrum Guid, то там говорится, что Daily нужны только разработчикам для того, чтобы понимать как идете к цели спринта. Может кто-то встал в тупик и на дэйлике об этом скажет и кто-то сможет помочь.
Меня он на самом деле много раз выручал. Всегда в голову приходит случай, когда увидел, что функционал не корректно работает. Хотел его поправить и сказал об этом на дэйли. Оказалось, что другой разработчик делает связанный функционал и поправит этот баг во время ее решения. И за счет этого я не потратил время на решения данного функционала.
Ещё один плюс регулярных встреч (хотя это и не совсем соответствует принципам Scrum, но всё же) заключается в том, что в небольшой компании бизнес может часто запрашивать сроки и статусы. И в таких случаях можно предложить им: «Давайте не будем назначать лишних встреч. Если у вас есть вопросы, приходите на ежедневное собрание и задавайте их там». Таким образом, разработчиков будут беспокоить реже в течение дня.
Но так, я с тобой согласен. Когда готовился к PSM был удивлен, когда в тестировании был вопрос на эту тему. Этот момент на самом деле был один из решающих в том, чтобы написать эту статью
Да, нам видно повезло и мы смогли внедрить такую практику. Потому что со временем мы видели изменения в лучшую сторону
Но куда больше вы бы могли получить если бы условно добавиви "козла" в стадо "баранов". :)
Вот тут даже спорить не буду - полностью согласен. Мне грустно, что не было такого человека и согласен с тем, что с ним все бы развивалось стремительнее.
Но в этой статье как раз и хотел дать небольшую надежду командам, которые сейчас работают в таких же условиях.
По Scrum все же считается, что каждый член команды может быть взаимозаменяем.
На практике такое бывает редко, поэтому лучше всего на уровне планирования предусмотреть риски и подумать как их можно избежать
В любом случае стоит на ретро обсудить причины, почему не успел сделать и как в будущем можно не допустить таких ошибок
Доска - это все таки про канбан. И на самом деле в разработке to do, in progress, done мало, по крайней мере по моей практике
На счет эффективности и как она считается. Приведу картинку из SAFe, в которой они как раз пытаются объяснить в чем плюс гибкой методологии
Т.е. при обычной (справа) waterfall модели, ты будешь разрабатывать долго и не факт, что это то, что нужно пользователю (plan)
А вот за счет Agile и постоянных проверок, ты сможешь не отходить сильно от того, что нужно пользователю и за счет этого быть эффективнее.
Я писал пример в статье на эту тему, что за счет иттераций и взаимодействий с PO мы смогли сократить время разработки за счет того, что не стали делать лишние вещи, а быстро проверили гипотезу
Поэтому обычно, когда говорят о повышении скорости, то смотрят через эту призму.
--
А ретро, как сказали выше, есть не только в Scrum. И оно просто позволяет учится на своих ошибках, а не закапывать их в стол, как часто происходит в разработке
На самом деле Вы правы. Поэтому команды часто делят на "продуктовые" и "сервисные".
В "продуктовых" часто есть смысл в Scrum и Agile, просто потому что это либо разработка нового, либо задает темп разработки
А вот в "сервисных" (то что ты говорил экслуатация и поставка) лучше использовать канбан. Сделать доску, поставить WIP лимиты и просто наглядно смотреть за тем, как идут задачи.
Задача данной статьи помочь разобраться в Scrum Guid и она на самом деле достаточно сильно на нем базируется. Потому что порой ты приходишь в команду и хочешь быстро погрузить их в материал и удобно, когда есть статья, в которой есть базовые моменты с иллюстрациями.
Про релизы в статье я написал только один раз
Больше в статье я не упоминал данный вопрос, так как Scrum и не предполагает его. Вы сами можете решить в какой момент требуется проводить релиз
Поэтому у меня нет цели сравнивать его с другими фрэимворками и методологиями.
Задача данной статьи помочь разобраться в Scrum Guid и она на самом деле достаточно сильно на нем базируется. Потому что порой ты приходишь в команду и хочешь быстро погрузить их в материал и удобно, когда есть статья, в которой есть базовые моменты с иллюстрациями.
Про релизы в статье я написал только один раз
Больше в статье я не упоминал данный вопрос, так как Scrum и не предполагает его. Вы сами можете решить в какой момент требуется проводить релиз
Поэтому у меня нет цели сравнивать его с другими фрэимворками и методологиями.
Спасибо за замечание и за материалы!
Со своей стороны могу только добавить, что мой пример из комментария основан из практики разработки. И тут как раз вопрос в том, что SCRUM это только фундамент для работы, а дальше каждая компания адаптирует его под себя. Мне, видимо, повезло и я попадал в команды, в которых не вставал вопрос, что такое дэйлики и зачем они нужны. Мы синхронизировали работу и понимали на каком мы этапе и кому с чем можно помочь.
Но Ваши материалы почитаю, звучит интересно
Да, согласен, ты прав
Да, согласен, поэтому написал "если будут вопросы". Подразумевая, чтобы скрам мастер следил за тем, чтобы бизнес не "прописался" на дэйликах
Не совсем понимаю понимаю почему я сказал что то другое
Я описал пример, когда разработчик говорит о статусе своей задачи, который явно отображает статус выполнения цели
вы всегда работаете по методике. В любой компании есть бизнес процесс выстроенные годами
Поэтому это просто одна из идей как можно выстроить процессы так, чтобы разработчик мог принимать решения и при этом компания шла к своей цели постепенно и проверяла все идеи
Agile наоборот говорит о том, что нужны амбиции. Потому что если в обычных компаниях все за разработчика решают менеджеры, то в Agile разработчик является ключевым человеком. (Но да, я часто приходил в компании и слышал «а мне удобно, задачу дали, а я работаю. А как там планируют, это их проблемы»
Ценность инкремета определяется на Sprint Review Product Owner и стэйкхолдерами, что указано в статье
В скрам не сказано, что не нужна цель. Просто ее нужно всегда проверять. Скрам нужен, когда вы понимаете что хотите, но не понимаете как достичь. И тут с помощью инкремента вы ищите свой путь
Да, я с вами согласен на счет релизов.
Но в статье я нигде не писал про релиз. Наоборот я подчеркнул, что инкремент - не значит релиз
Тут скорее вопрос в том, что порой ты можешь не понять, что завис
И придя на Дэйли ты скажешь «я продолжаю трудится над этой фичой»
В этот момент команда может спросить «а почему так долго?»
И ты уже расскажешь и в этот момент может кто нибудь помочь
—
Можно сказать, что за этим должен следить проджект, но в скрам командах считается, что его нет и команда сама следит за статусами
В тот момент сильно ничего не рассматривали. У компании был путь к scrum, поэтому мы спорить не стали
Внедрили больше scrum. Из канбана ничего не брали кроме доски)
на самом деле у меня есть ровно зеркальный пример. Мы внедрили скрам и смогли в 3 раза сократить lead time)
Но в любом случае, фрэимворк - решение команды. Если он ей мешает, то он ей не нужен
Но если посмотреть с другой стороны, а как разрабатывалась машина? Она же появилась не сразу
В начале сделали Ford T. Отличный автомобиль. мотор заводится в ручную, кабина деревянная. Усилитель? Не, не нужен.
Начали продавать. Продали какое-то количество.
Дальше внедрили стартер, чтоб руками не заводить и таким образом открыли доступ женщинам водить.
Потом поставили усилители, чтобы улучшить комфорт.
Поэтому тут вопрос задачи. Если вы хотите сделать машину с усилителем, стартером и т.п., то вы делаете ее целиком. (Если смотреть по матрце стэйси, то это можно отнести к простой системе)
Но вот если ваша задача выйти с новым, инновационным продуктом, то без проб и ошибок не сделать хороший продукт.
Продолжая пример с автомобилями. Вот Wolkswagen вложил несколько миллиардов в электромобили. Зачем? Чтобы разработать платформу, проработать эргономику и т.п. Прошло немного времени и оказалось, что все же электромобили не факт, что будущее. И вот вопрос: а можно ли сделать прототип, без платформы и проверить, а нужно ли вообще это делать. А только после этого тратить миллиард на платформу?! И вот тут Agile помог бы потратить меньше денег, чтобы в начале проверить, а потом уже вкладываться в понятный маршрут
Спасибо за комментарий!
Если смотреть по Scrum Guid, то там говорится, что Daily нужны только разработчикам для того, чтобы понимать как идете к цели спринта. Может кто-то встал в тупик и на дэйлике об этом скажет и кто-то сможет помочь.
Меня он на самом деле много раз выручал. Всегда в голову приходит случай, когда увидел, что функционал не корректно работает. Хотел его поправить и сказал об этом на дэйли. Оказалось, что другой разработчик делает связанный функционал и поправит этот баг во время ее решения. И за счет этого я не потратил время на решения данного функционала.
Ещё один плюс регулярных встреч (хотя это и не совсем соответствует принципам Scrum, но всё же) заключается в том, что в небольшой компании бизнес может часто запрашивать сроки и статусы. И в таких случаях можно предложить им: «Давайте не будем назначать лишних встреч. Если у вас есть вопросы, приходите на ежедневное собрание и задавайте их там». Таким образом, разработчиков будут беспокоить реже в течение дня.
Ссылка на скрам гайд: https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-US.pdf#zoom=100
--
Но так, я с тобой согласен. Когда готовился к PSM был удивлен, когда в тестировании был вопрос на эту тему. Этот момент на самом деле был один из решающих в том, чтобы написать эту статью
Спасибо за замечание! Учту в следующей статье
Да, нам видно повезло и мы смогли внедрить такую практику. Потому что со временем мы видели изменения в лучшую сторону
Вот тут даже спорить не буду - полностью согласен. Мне грустно, что не было такого человека и согласен с тем, что с ним все бы развивалось стремительнее.
Но в этой статье как раз и хотел дать небольшую надежду командам, которые сейчас работают в таких же условиях.
Спасибо за комментарий!