Здорово, что у вас взлетело это правило, искренние поздравления!
Когда я только пришла в it у меня было правило самой себе - сначала загугли. И на самом деле в большинстве случаев я либо находила понятное, простое решение, либо, если оно было сложное, то шла к старшим коллегам и разбирала с ними.
И в гугл, и на форумах я натыкалась на неработающие решения, которые отбирали у меня время. Но мы же либо учимся на своих ошибках, либо продолжаем верить слепо первому найденному ответу.
Так что всегда будут сотрудники, да и начальники, которые больше верят интернету, чем коллегам. Я с этим смирилась и решила, что если таким доверчивым коллегам буду объяснять - почему найденное решение не подойдёт, сделаю добро. Правда так я стала лидом 😄
Круто, когда получается совмещать методики. Важно использовать их исходя из проблем и запросов бизнеса и компании.
Скрам был "создан" для быстрых побед продуктовой самостоятельной команды.
Канбан-метод - для анализа работы системы производства (кстати да, не конкретных инженеров).
Их можно совмещать и нужно, когда Скрам уже дал все плюшки своей методологии, а нам нужны ещё улучшения или есть проблемы, которые только Скрамом не выявляются/не решаются. Но всё-таки важно понимать для чего внедряются те или иные инструменты.
Тот же Скрам часто внедряют для сближения бизнеса и it. Тут для пользы метрик канбан надо в начале, до перехода на Скрам, провести большую работу по описанию текущего процесса, покрытию канбан метриками и накоплению исторических данных, чтобы потом было с чем сравнивать.
Подход классный. Очень хочется узнать о реальном кейсе, если есть пример - было бы очень интересно о нём почитать.
Как вариативность это хорошо. Но и совсем забывать про объемы памяти на машинах и возможности развертки приложения на имеющемся железе такое себе. Есть компании и роли, где и правда об этом думать не надо по тем или иным причинам.
Сейчас и заказчик часто скажет, что не надо оптимизировать, проверять, настраивать - кати уже код на прод. Потом правда недоволен, что во время акций и распродаж сайт падает, но никогда не признает, что нужны более продуманные решения. Отсюда всё больше решений без привязки к железу, к сожалению.
Сейчас можно встретить и более погруженных в железо инженеров, но скорее всего там, где это супер критично для бизнеса/заказчика.
Боже, какие прекрасные кейсы реальности! Мне всегда очень страшно за технику на улице, а вы экспериментируете аж с ледяным дождем!
А вот выход из приложения да - сама всегда тыкаю в интерфейсах таких всё подряд. Когда была маленькая мечтала интерфейс банкомата взломать, а так как я такая не одна, то приходится теперь, когда взрослая, тестировать самые сумасшедшие сценарии перед выводом фичи в прод.
Судя по описанию спринта и других мероприятий тут речь пыталась вестись о Скрам, только с отклонениями и без его наименования. Например "у каждого спринта есть критерий завершенности — условия, когда спринт считается выполненным не только по времени, но и по результату: задачи реализованы, код прошел тесты и готов к демонстрации" - в Скрам нет критериев завершенности спринта, есть цель спринта, которую команда срремится выполнить, как раз инкремент, о котором договорились поставить.
Есть инструмент критерии завершенности, больше известный как Definition of Done, но это про таски и отдельные задачи. И совсем не обязательно даже про итерацию, если говорить просто про итеративную разработку.
Опираясь уже на эту несостыковку у меня возникают вопросы к подходу авторов в любой теории.
Дальше видим, что автор показывает не так готовым инкремент спринта, как обычно показывают и тренеруют Agile практики. В случае примера с лего инкремент первого спринта это больше про возможность ехать хотя бы одному человеку: 1 кресло, 2 основных колеса с костыльным третьим, рулем и всё - ни крыши, ни передач, ни стекол и например без шин, просто на дисках.
В общем итерационный подход вам надо ещё раз изучить, господа авторы. Про Скрам боюсь представить)))
"Простой разработчик", который знает методологию Киневин))) Ну-ну))
У меня тоже по статье сомнения о точке отправки. Я как раз писала про применение Scrum в зрелых и не зрелых командах. И вы подмечаете про типы задач. Я была удивлена, когда мой знакомый в каком-то бородатом 2013 или 2015 году (не помню год, к сожалению), сказал, что он Коуч, который помогает Камазу по Agile проекты делать. Я прям тогда сильно не поняла - зачем заводу гибкие подходы. Теперь знаю, что в разные этапы работы компании нужны разные инструменты и если вы "завод", то при внедрении новинок можно их и по Agile внедрять/разрабатывать
С посылом согласна на 100%. Но есть грубые неточности, которые режут глаз.
Agile это не методология, это именно что набор ценностей и принципов. Можно называть философия, но не методология.
Dark Scrum автор называет именно неудавшийся Scrum. Не Agile. Ещё есть названия типа ScrumBut, или по-русски СкрамНо. Это и правда "отступление" от скрам гайда.
Тут как раз скрам мастер или другой опытный пользователь методологий, объединяющихся под Agile, скажет, что юной и неопытной в Agile подходах команде в первый раз нужно научиться работать по типовому фреймворку/методологии, по её четким правилам.
Когда команда уже понимает, что ценности и принципы у них работают и как работают - вот тут можно крутить/вертеть процессы на своём опыте, опираясь на Agile. Без стартового опыта эксперименты будут дольше и болезненнее как для команды, так и для продукта и для бизнеса.
И самое болезненное для меня, душнилы этого вечера, Scrum - продукт 2х авторов ещё 90х годов прошлого века, которые обоснованно ввели роль Scrum master в своем гайде. Они не входят сейчас в сам альянс (на сколько мне известно из открытых источников). Кен например сейчас в Scrum.org состоит. Альянс только сертифицирует людей по гайду.
Я к тому, что посыл отличный и как действующий тестировщик и практикующий Scrum master согласна. Было бы круто, если бы аргументы проверялись на точность.
Информация
В рейтинге
6 608-я
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
Здорово, что у вас взлетело это правило, искренние поздравления!
Когда я только пришла в it у меня было правило самой себе - сначала загугли. И на самом деле в большинстве случаев я либо находила понятное, простое решение, либо, если оно было сложное, то шла к старшим коллегам и разбирала с ними.
И в гугл, и на форумах я натыкалась на неработающие решения, которые отбирали у меня время. Но мы же либо учимся на своих ошибках, либо продолжаем верить слепо первому найденному ответу.
Так что всегда будут сотрудники, да и начальники, которые больше верят интернету, чем коллегам. Я с этим смирилась и решила, что если таким доверчивым коллегам буду объяснять - почему найденное решение не подойдёт, сделаю добро. Правда так я стала лидом 😄
Отличная статья, ребят <3
Круто, когда получается совмещать методики. Важно использовать их исходя из проблем и запросов бизнеса и компании.
Скрам был "создан" для быстрых побед продуктовой самостоятельной команды.
Канбан-метод - для анализа работы системы производства (кстати да, не конкретных инженеров).
Их можно совмещать и нужно, когда Скрам уже дал все плюшки своей методологии, а нам нужны ещё улучшения или есть проблемы, которые только Скрамом не выявляются/не решаются. Но всё-таки важно понимать для чего внедряются те или иные инструменты.
Тот же Скрам часто внедряют для сближения бизнеса и it. Тут для пользы метрик канбан надо в начале, до перехода на Скрам, провести большую работу по описанию текущего процесса, покрытию канбан метриками и накоплению исторических данных, чтобы потом было с чем сравнивать.
Подход классный. Очень хочется узнать о реальном кейсе, если есть пример - было бы очень интересно о нём почитать.
Как вариативность это хорошо. Но и совсем забывать про объемы памяти на машинах и возможности развертки приложения на имеющемся железе такое себе. Есть компании и роли, где и правда об этом думать не надо по тем или иным причинам.
Сейчас и заказчик часто скажет, что не надо оптимизировать, проверять, настраивать - кати уже код на прод. Потом правда недоволен, что во время акций и распродаж сайт падает, но никогда не признает, что нужны более продуманные решения. Отсюда всё больше решений без привязки к железу, к сожалению.
Сейчас можно встретить и более погруженных в железо инженеров, но скорее всего там, где это супер критично для бизнеса/заказчика.
Спасибо за пост. Немного понастольгировала <3
Боже, какие прекрасные кейсы реальности! Мне всегда очень страшно за технику на улице, а вы экспериментируете аж с ледяным дождем!
А вот выход из приложения да - сама всегда тыкаю в интерфейсах таких всё подряд. Когда была маленькая мечтала интерфейс банкомата взломать, а так как я такая не одна, то приходится теперь, когда взрослая, тестировать самые сумасшедшие сценарии перед выводом фичи в прод.
Рассказывайте ещё <3
Судя по описанию спринта и других мероприятий тут речь пыталась вестись о Скрам, только с отклонениями и без его наименования. Например "у каждого спринта есть критерий завершенности — условия, когда спринт считается выполненным не только по времени, но и по результату: задачи реализованы, код прошел тесты и готов к демонстрации" - в Скрам нет критериев завершенности спринта, есть цель спринта, которую команда срремится выполнить, как раз инкремент, о котором договорились поставить.
Есть инструмент критерии завершенности, больше известный как Definition of Done, но это про таски и отдельные задачи. И совсем не обязательно даже про итерацию, если говорить просто про итеративную разработку.
Опираясь уже на эту несостыковку у меня возникают вопросы к подходу авторов в любой теории.
Дальше видим, что автор показывает не так готовым инкремент спринта, как обычно показывают и тренеруют Agile практики. В случае примера с лего инкремент первого спринта это больше про возможность ехать хотя бы одному человеку: 1 кресло, 2 основных колеса с костыльным третьим, рулем и всё - ни крыши, ни передач, ни стекол и например без шин, просто на дисках.
В общем итерационный подход вам надо ещё раз изучить, господа авторы. Про Скрам боюсь представить)))
"Простой разработчик", который знает методологию Киневин))) Ну-ну))
У меня тоже по статье сомнения о точке отправки. Я как раз писала про применение Scrum в зрелых и не зрелых командах. И вы подмечаете про типы задач.
Я была удивлена, когда мой знакомый в каком-то бородатом 2013 или 2015 году (не помню год, к сожалению), сказал, что он Коуч, который помогает Камазу по Agile проекты делать. Я прям тогда сильно не поняла - зачем заводу гибкие подходы. Теперь знаю, что в разные этапы работы компании нужны разные инструменты и если вы "завод", то при внедрении новинок можно их и по Agile внедрять/разрабатывать
С посылом согласна на 100%. Но есть грубые неточности, которые режут глаз.
Agile это не методология, это именно что набор ценностей и принципов. Можно называть философия, но не методология.
Dark Scrum автор называет именно неудавшийся Scrum. Не Agile. Ещё есть названия типа ScrumBut, или по-русски СкрамНо. Это и правда "отступление" от скрам гайда.
Тут как раз скрам мастер или другой опытный пользователь методологий, объединяющихся под Agile, скажет, что юной и неопытной в Agile подходах команде в первый раз нужно научиться работать по типовому фреймворку/методологии, по её четким правилам.
Когда команда уже понимает, что ценности и принципы у них работают и как работают - вот тут можно крутить/вертеть процессы на своём опыте, опираясь на Agile. Без стартового опыта эксперименты будут дольше и болезненнее как для команды, так и для продукта и для бизнеса.
И самое болезненное для меня, душнилы этого вечера, Scrum - продукт 2х авторов ещё 90х годов прошлого века, которые обоснованно ввели роль Scrum master в своем гайде. Они не входят сейчас в сам альянс (на сколько мне известно из открытых источников). Кен например сейчас в Scrum.org состоит. Альянс только сертифицирует людей по гайду.
Я к тому, что посыл отличный и как действующий тестировщик и практикующий Scrum master согласна. Было бы круто, если бы аргументы проверялись на точность.