Ну это вы просто риски на себя перекладываете вместо того, чтобы сделать их публичными и прозрачными для заказчика. Он то потом будет думать, что всегда можно с такой скоростью двигаться. Идеи то далеко не все не нравятся в итоге…
Как же? Все как раз проще. Берете определенный класс задач по оценкам команды и смотрите на cycle time при их выполнении у каждого члена команды. Если отличается сильно у одного, то это повод разобраться. Возможно он всем помогает и благодаря ему вообще движется разработка. Что такое «человек не выполняет спринты» я вообще понять не могу. В Scrum как раз вся командная активность прячется за спринтом и разобраться кто хороший кто плохой потом не так просто.
Расчет наверное делался с учетом наличия машины, квартиры и других стабильных ценностей. Потому что при цене на квартиру $200000 с зарплатой в $6000 собирать нужно будет долго. А за вычетом текущих расходов на аренду жилья, питание, одежду и т.д. еще дольше. Абсолютная сумма начинает меньше значить, например +$500. А повышение зарплаты на 20-30% остается таким же весомым фактором. :)
Нельзя рассуждать о не случившемся. Возможно и забрала, никто никогда не узнает. У каждого свой путь. Несколько раз я благодаря формуле принимал решения, которые оказывались в последствии очень правильными. Может быть это фарт, а может правильно выбранные веса для разных факторов…
Вы же знаете натуру человека — с растущими возможностями растут потребности. И весь мир продаж, товаров и услуг заточен именно на это. Вам хватило на покупку машины? На очереди квартира! И это уже есть? На очереди загородный дом! А потом путешествия подороже, машина поинтереснее и т.д. Но хорошая зарплата сеньор разработчика даже трехкомнатную квартиру в хорошем районе не может быстро обеспечить. Поэтому хватать не будет никогда… :)
По поводу кому что надо от жизни — тут я полностью с вами согласен. Поэтому и веса в формуле могут сильно зависеть от человека. Кому-то плевать на деньги (таких мало), кому-то плевать на время в пути на работу, кто-то не видит смысла в соцпакете. Мы все разные и для каждого своя формула. Я всего лишь предложил идею как из расплывчатого «it depends» перейти к более осознанной расстановке приоритетов и выбору на их основании.
Формула позволяет быстро отбросить «недостойные предложения» наподобие «мы дадим вам +$1000, но...», «у нас очень интересный проект, но...», «у нас отличная перспективная позиция, но...». Я для себя определяю приоритеты в виде весов и доверяю дальше решению, выданному формулой. Присматриваюсь к вакансии только если отклонение от текущей работы приближается к минимально допустимому значению. Это позволяет мне не мучиться в раздумьях, по много раз проходясь по разным пунктам и взвешивая за и против.
Задайте себе вопрос: «а для чего мне новые знания? как они мне помогут в будущем?». Ответ может быть разным:
— желание разнообразить работу новыми технологиями и сделать ее более приятной
— возможность вырасти из текущей позиции и начать больше зарабатывать
— начало карьеры на новой платформе разработки
Любой ответ можно разбирать дальше и потом перенести на «баллы счастья» или деньги.
Еще раз повторю — используйте «баллы счастья», если они вам больше нравятся. Возможность поработать с технологией должна выливаться в удовлетворенность от работы или же в перспективы будущей карьеры. Возможность поучиться у опытных спецов тоже влияет на рост ваших навыков и знаний, которые влияют на зарплату и возможность заниматься интересными для вас вещами. Вопрос лишь расстановки весов. Если прошло время и для вас зарплата стала не так важна, понижайте ее вес и новая формула будет отражать текущие реалии.
Каждому из этих аргументов можно задать вес, иначе будет очень тяжело получить оценку, даже на уровне просто размышлений и взвешивания за и против. Не нравятся деньги, можно считать в абстрактных «баллах счастья». Потому что оплата конференций и литературы может оказаться в среднем $30 в месяц, при этом дорога в офис займет дополнительный час, который будет тратиться каждый день ($10+ в день). Вот и становится легко сравнивать плюшки новой вакансии.
Оценить реально такие вещи очень сложно. Понятное дело, проект когда-то станет не так интересен. Вы можете поинтересоваться количеством проектов в компании, вариантами перехода в новый проект. Ну и в конце концов, вам никто не запрещает сменить работу, когда проект станет неинтересным.
Я совершенно не понял ход ваших мыслей. Тренер уже заработал, если вы пришли на тренинг, причем вне зависимости от того с каким набором знаний вы с него уйдете. А участники приходят с понятной мотивацией — узнать новое, разобраться в теме, получить знания и опыт тренера, ответы на свои вопросы. Тут тоже с мотивацией все понятно. Если вам кажется все просто, то почему многие собираются на совещания, тратят кучу времени и никакой пользы? А некоторые достаточно быстро решают вопросы на совещаниях. Мотивация и там и там есть, но разница в подготовке. Вот я и расписал советы по этой самой подготовке к тренингу.
Некоторые пункты слишком теоретические и притянуты за уши:
В команде недостаточно усердия для следования принятым изменениям
В команде недостаточно смелости для качественного изменения процесса
Таких можно написать штук 100. Не хватает знаний, понимания, опыта, умения общаться и т.д. Это очень тяжело увидеть, а еще тяжелее измерить и убедиться в исправлении ситуации.
При зафиксированном объеме задач на спринт, регулярно вбрасываются новые задачи
У некоторых это жизненная необходимость, а перебраться на Kanban они еще не готовы. Главное чтобы эти новые задачи вытесняли старые и команда вкладывалась в сроки итерации.
Не используются инструменты работы над видением и бизнес-ценностью (продуктовые техники, такие как BMC, Personas, Effect Maping, Story Mapping, etc.)
Только наверху было про то, что не стоит привязываться к инструментам, а тут уже все наоборот. Если Владелец Продукта имеет четкое понимание продукта и расписанные фичи хоть в блокноте, будет это работать замечательно и без других техник.
Беклог продукта не отображает ценность элементов в нем
Это одна из самых противоречивых вещей. Часто для определения ценности надо знать столько составляющих, включая затраты времени и ресурсов, что лучше просто отказаться от определения ценности в числовой шкале.
Владельца Продукта не приглашают на ретроспективу
И очень правильно делают. Тогда можно спокойно поговорить, иногда даже поругаться конструктивно, пожаловаться на Владельца Продукта. А еще, его участие в аутсорсинговых командах почти нереально. Не садиться же всем из-за этого в Skype.
Нет выделенного Скрам-Мастера или он меняется каждый спринт
Если толковая команда, то можно и ротировать эту роль среди ее членов. Ужасного в этом ничего нет.
У Скрам-Мастера недостаточно смелости, что бы противостоять решениям команды, противоречащим ценностям Agile
Опять про смелость… В основном, этот пункт превращается на практике в отстаивание идеалов по библии Agile без вникания в контекст проекта и команды.
Один Скрам-Мастер работает более чем на 3-4 команды
Ну и отлично. Если переходить на Scrum при полном хаосе, но это работать не будет. Если уже почти все наладилось, то без проблем.
Дейли-митинг проводится сидя, за рабочими местами
В сидении большой беды нет, если никто не начинает отвлекаться. А если вы сидите в одной небольшой комнате, то можно и не вставать из-за рабочих мест. Это больше вопрос сознательности.
В распределенной команде проходят отдельные Дейли по локациям
А нет, надо в распределенной команде человек на 30 всем собраться в Skype на часок-другой…
Нет предварительной работы с беклогом по подготовки к Планированию (Grooming, Refinement, etc.)
Опять же, если у Владельца Продукта нет проблем с выбором и приоритезацией требований, то можно замечательно жить и без этих практик.
Команда договаривается кто над какими задачами будет работать в ходе спринта
Часто это просто необходимо на высоком уровне, потому что иначе получится затык в работе одного из специализированных членов команды. Понятное дело, что не стоит задачи разбирать, но иногда прикинуть что кто будет делать очень помогает.
Регулярно есть незавершенная работа в конце спринта
Это конечно плохо, но зависит от модели планирования. Если команда разрешает вкидывать новые задачи, то есть «гарантированный» объем работы и «рискованный». И вот рискованный может вылезть за рамки итерации. В этом нет большой беды.
Спринт оценивается как “не успешный”, если беклог не выполнен полностью, не принимается в учет достижение цели спринта
Цели — это хорошо на бумаге. Чаще всего Владельца Продукта интересует именно выполнение задач на итерацию, а не достижение мифической надуманной цели спринта, сделанной только для того, чтобы удовлетворить эго Скрам-Мастера с библией Agile.
Ретроспективы всегда проходят по одному сценарию, по одним и тем же шаблонам встреч
Если команда попробовала разные шаблоны и выбрала самый интересный и эффективный для нее, то что в этом плохого? Другое дело, если она вообще не пробовала ничего и собралась «на поговорить».
Интересно глянуть конкретный пример, где это не срабатывало (упрощенный код страницы и тест). Можно в личку. Просто я очень много раз видел такое, что локатор написан неверно или же постоянно обновляется DOM и элемент устаревает. Обсуждать абстрактного коня в вакууме очень тяжело. Пауза в секунду — не выход в любом случае, потому что завтра секунды может не хватить и что тогда? Ставить 5 секунд? :) Если такая беда случается, то лучше уже кликнуть на элемент из JavaScript или написать кусочек JavaScript, который убедится, что элемент уже доступен. Просто как-то догадка с «прорисовыванием» звучит странно. Другой вопрос, что этот элемент может появляться «с хаками», когда он сначала добавляется в DOM, а потом на него навешивают кучу всего. Надо смотреть.
Тоже самое и с clear(). Выделение с замещением — это известный обходной маневр. Мне не приходилось видеть чтобы clear() не работал. Если примеры будут, то я могу обратиться к разработчикам WebDriver знакомым и показать им.
Нельзя рассуждать о не случившемся. Возможно и забрала, никто никогда не узнает. У каждого свой путь. Несколько раз я благодаря формуле принимал решения, которые оказывались в последствии очень правильными. Может быть это фарт, а может правильно выбранные веса для разных факторов…
По поводу кому что надо от жизни — тут я полностью с вами согласен. Поэтому и веса в формуле могут сильно зависеть от человека. Кому-то плевать на деньги (таких мало), кому-то плевать на время в пути на работу, кто-то не видит смысла в соцпакете. Мы все разные и для каждого своя формула. Я всего лишь предложил идею как из расплывчатого «it depends» перейти к более осознанной расстановке приоритетов и выбору на их основании.
— желание разнообразить работу новыми технологиями и сделать ее более приятной
— возможность вырасти из текущей позиции и начать больше зарабатывать
— начало карьеры на новой платформе разработки
Любой ответ можно разбирать дальше и потом перенести на «баллы счастья» или деньги.
Таких можно написать штук 100. Не хватает знаний, понимания, опыта, умения общаться и т.д. Это очень тяжело увидеть, а еще тяжелее измерить и убедиться в исправлении ситуации.
У некоторых это жизненная необходимость, а перебраться на Kanban они еще не готовы. Главное чтобы эти новые задачи вытесняли старые и команда вкладывалась в сроки итерации.
Только наверху было про то, что не стоит привязываться к инструментам, а тут уже все наоборот. Если Владелец Продукта имеет четкое понимание продукта и расписанные фичи хоть в блокноте, будет это работать замечательно и без других техник.
Это одна из самых противоречивых вещей. Часто для определения ценности надо знать столько составляющих, включая затраты времени и ресурсов, что лучше просто отказаться от определения ценности в числовой шкале.
И очень правильно делают. Тогда можно спокойно поговорить, иногда даже поругаться конструктивно, пожаловаться на Владельца Продукта. А еще, его участие в аутсорсинговых командах почти нереально. Не садиться же всем из-за этого в Skype.
Если толковая команда, то можно и ротировать эту роль среди ее членов. Ужасного в этом ничего нет.
Опять про смелость… В основном, этот пункт превращается на практике в отстаивание идеалов по библии Agile без вникания в контекст проекта и команды.
Ну и отлично. Если переходить на Scrum при полном хаосе, но это работать не будет. Если уже почти все наладилось, то без проблем.
В сидении большой беды нет, если никто не начинает отвлекаться. А если вы сидите в одной небольшой комнате, то можно и не вставать из-за рабочих мест. Это больше вопрос сознательности.
А нет, надо в распределенной команде человек на 30 всем собраться в Skype на часок-другой…
Опять же, если у Владельца Продукта нет проблем с выбором и приоритезацией требований, то можно замечательно жить и без этих практик.
Часто это просто необходимо на высоком уровне, потому что иначе получится затык в работе одного из специализированных членов команды. Понятное дело, что не стоит задачи разбирать, но иногда прикинуть что кто будет делать очень помогает.
Это конечно плохо, но зависит от модели планирования. Если команда разрешает вкидывать новые задачи, то есть «гарантированный» объем работы и «рискованный». И вот рискованный может вылезть за рамки итерации. В этом нет большой беды.
Цели — это хорошо на бумаге. Чаще всего Владельца Продукта интересует именно выполнение задач на итерацию, а не достижение мифической надуманной цели спринта, сделанной только для того, чтобы удовлетворить эго Скрам-Мастера с библией Agile.
Если команда попробовала разные шаблоны и выбрала самый интересный и эффективный для нее, то что в этом плохого? Другое дело, если она вообще не пробовала ничего и собралась «на поговорить».
Тоже самое и с clear(). Выделение с замещением — это известный обходной маневр. Мне не приходилось видеть чтобы clear() не работал. Если примеры будут, то я могу обратиться к разработчикам WebDriver знакомым и показать им.