Вполне вероятно что хакеры вообще не поняли что они потрогали. Зашли посмотреть а, там какая-то скада, они подвигали настройки, ничего с виду не случилось и они ушли.
Я правильно понимаю, что после этой доработки тест не заметит, что из шаблона случайно удалили кнопку добавления элемента в список todo? Если да, то почему такой тест можно называть «сквозным»?
А есть обоснования, почему созданная методология в каком-то конкретном классе кейсов будет лучше, чем правильно выбранная для этого кейса существующая методология? И если есть, то для каких кейсов?
Интересно узнать, из какого опыта была построена методология?
Потому моему опыту — либо инструмент заточен под какой-то класс задач и в них удобен, либо это мультитул, который может всё, но сильно неудобней, чем специальный инструмент.
Если бы вы подписали договор с Ашаном на поставку вам этой корзинки на несколько лет или с автопродлением, тогда цена не могла бы просто так поменяться без соответствующего допника или пункта в договоре. Так и тут. Если в трудовом договоре не сказано, что оклад пересматривается автоматом по такому-то правилу, то и не пересматривается.
Не для всех видов деятельности (тут речь не только про ИТ и разработку) такие коммуникации являются критически важным фактором. Я бы даже сказал, что в подавляющем большинстве вполне живых и успешных бизнесов (может конечно не так успешных, как могли бы быть) эти проблемы с коммуникацией есть. Поэтому так смело говорить, более они серьезные или нет — я бы не стал.
Да, базовый уровень коммуникаций тоже должен позволять перейти к этой схеме, нельзя из каменного века сразу в паровые машины.
Про цикличность коммуникаций — речь не только про скрам, есть, например, проектная деятельность, когда проект не строго ложится в месяцы, т.е. 15-го числа закончился один 8 недельный проект и начался другой, 5 недельный. Там проще по итогу проекта оценивать, чем поддерживать две близкие по размеру календарного шага системы оценки и сводить их.
Ну да, я примерно про это же, что предлагаемая схема по сути измений больше про коммуникации регулярного управления, чем про методики пересмотра зарплаты, и поэтому может столкнуться, например, с тем, что у компании деятельность не ложится на такую цикличность коммуникаций без потерь.
А есть примерная информация, насколько было «не всё хорошо»? Сейчас в опросе понимание ожиданий и обратная связь сейчас на 93% и 89%, а было примерно сколько, хотя-бы порядок?
Примеры — допустим вчера тимлид с командой и заказчиком общался в терминах конкретных задач, которые появляются не только в начале месяца, и не обсуждал в явном виде планы строго на месяц. И если состояние коммуникаций в компании далеко от целевого состояния (как по качеству, так и по календарной/проектной структуре), то перестройка их может оказаться дороже, чем профит от новой схемы оплаты труда.
PS: А в целом схема очень красивая и при правильном применении эффективная.
Так хотелось бы, чтобы на хабре это не работало. Чтобы негативный эффект от публикации фантазий под видом фактов перевешивал кликбейтный заголовок. Благо тут можно негатив тоже регистрировать, в отличие от Medium, где только похлопать можно.
В заголовке 600k$, в середине уже 240k$, из которых еще вернули 73k$, и это всё на преположении, что себестоимость у них ровно как случайно найденный купальник на алибабе (вообще мало похож на их продукт) и складских запасов они как будто бы не держали под свой интернет-магазин. Ну и кроме того целый ряд расходов даже не обозначен.
Потому моему опыту — либо инструмент заточен под какой-то класс задач и в них удобен, либо это мультитул, который может всё, но сильно неудобней, чем специальный инструмент.
Я не совсем понял из статьи, какие модули объединяются для тестирования в группе?
1. Кто является целевой аудиторией этой статьи?
2. Какие потребности ЦА она закрывает и каким образом?
Например, сейчас понимает ожидания руководителя 93% и 7% нет.
А было «86% да и 14% нет» или «42% да и 58% нет»?
Про цикличность коммуникаций — речь не только про скрам, есть, например, проектная деятельность, когда проект не строго ложится в месяцы, т.е. 15-го числа закончился один 8 недельный проект и начался другой, 5 недельный. Там проще по итогу проекта оценивать, чем поддерживать две близкие по размеру календарного шага системы оценки и сводить их.
Примеры — допустим вчера тимлид с командой и заказчиком общался в терминах конкретных задач, которые появляются не только в начале месяца, и не обсуждал в явном виде планы строго на месяц. И если состояние коммуникаций в компании далеко от целевого состояния (как по качеству, так и по календарной/проектной структуре), то перестройка их может оказаться дороже, чем профит от новой схемы оплаты труда.
PS: А в целом схема очень красивая и при правильном применении эффективная.
На мой взгляд основной риск такой схемы — не взлетит, если с коммуникациями проблемы.