А по сути, зачем простым разработчикам его понимать? Скрам-мастер должен понимать и говорить остальным членам команды что, как и когда делать, нет?
Первые 2-3 спринта — может быть и должен. А дальше он должен быть заменимым. Скрам-мастер не может же за команду решать на ретроспективе. Не может за команду вносить изменения в процесс.
Очень редко мы можем уложиться в пол-часа. И это бесит.
Что сказали или предложили остальные участники команды на ретроспективе? Если вас 13 человек (это многовато, но терпимо), то пробовали просто взять и договориться о лимите в 90 секунд на каждого?
Стендап не про совесть. А про то, что если условный Петя делает задачу третий день, а она оценена в 1 день, то на невыполненный спринт попадает не Петя, а команда. Стендам помогает не превратить эти 3 дня в 5 или 7. Тут вопрос не в том, стесняется Петя или нет. Может он и правда верит, что сегодня всё доделает (и так второй месяц :) ), тут вопрос, чтобы команда увидела риск до провала.
Есть еще беда неприспособленности скрама к внешнему воздействию. Проблемы пользователей не укладываются в него напрямую. Решать проблему, возникшую у пользователя в текущем спринте нельзя, а неделя для кого-то может быть безумно долгим сроком.
Ну так договоритесь с PO о правилах, как он может emergency в текущий спринт вставлять. Какие критерии, что задача emergency, а не просто приоритетная. Как договориться о том, какие задачи эта emergency пододвигает. Договоритесь о том, что "цена" впихивания в спринт — это рефакторинг или устранение техдолга в следующем с нижней границей оценки 30-50%.
Что-то сильно не то вы делаете, судя по симптомам.
Короткий спринт — это понижение КПД команды, скрам ради скрама.
А почему понижение КПД? Накладные расходы на спринт — это время для демо, ретроспективы и планирования. Время планирования и демо зависит от количества задач и поэтому при длинном спринте также увеличатся. Ретроспектива — зависит от сыгранности команды и вообще может пройти за 20 минут, когда у команды уже было 10-20 ретроспектив.
В любом случае — оптимальная длина спринта зависит от огромного количества факторов. По моему опыту, чаще командам комфортнее работать в спринте 2 недели. Но видел команды со спринтом и в 1 неделю, и в 3, и в 4. Если 4 и больше, то надо приглядеться, но вполне может быть, что так надо.
А если объединить скрам-мастера с тим-лидом?
Примерно в 70-80% случаев первым скрам-мастером становится экс-тим-лид. Ну или его правая рука, если сам тим-лид становится PO.
Добавив в системы орошения IoT-датчики, следящих за уровнем влажности почвы и состоянием растений, фермеры сделают ее практически полностью автономной. Вмешиваться в процесс потребуется лишь в случае каких-то проблем.
Если честно, то это страшная картина. Не из-за потери рабочих мест, нет. Из-за безопасности IoT. Заддосил сельхоз соседней страны и никаких танков не надо. Как stuxnet, только сильно проще сделать и сразу оставит без еды, а не без урана.
Конечно, есть. Надо же продавать IoT-датчики!
Если серьезно, то большая часть этих 7+ млрд питается мало и отвратительно. Так что если обеспеченные 10% не хотят, чтобы их съели нижние 30%, этих нижних нужно докормить.
Но это я всё за автора статьи домысливаю, реально не считал.
150 на протяжении секунд/минут или на протяжении часов/суток? Если первое, то, да ну бывает по каким-то причинам. Например, СУБД пошла read-ahead делать или что-то подобное — на этом очередь может прыгать и до 300 и до 500 и до 1000. Сервер знает, то читать и поставил в очередь. Я больше с СУБД сталкиваюсь, поэтому мне эта ситуация знакома и обычна. Для OLTP такой всплеск в целом неприятен, но если это не авария, то он «рассасывается».
Но тут такой момент, что с точки зрения разгребания между очередью 16 и очередью 256 разницы почти нет. У вас это тоже в графиках видно: посмотрите, latency просто линейно растет (там обе шкалы логарифмические, поэтому в итоге всё равно линейно). Как в супермаркете: если очередь 5 человек, то ждать 10 минут, если очередь 10 человек, то 20. Наверное есть какая-то оптимизация, объединение смежных чтений, перестановки и т.п., но в реальности картина простая: есть большая очереди и её не волшебное разгребание. Этот диапазон линеен, его не интересно смотреть.
Но найти приложение, которое это заметит, непросто
Любое критичное к дисковой производительности приложение. СУБД, например.
Когда я читаю обзоры дисков и вижу что-то очередь 256, то у меня всегда вопрос: а какие выводы можно делать из показателей очереди 8 и больше? Ну то есть если очередь 8, то всё, не имеет смысла дальше смотреть, диск уже захлебнулся. Дальше уже только вопрос, как быстро он всплывет.
Всё бы ничего, но из-за этого диапазона приходится использовать логарифмические шкалы и самое интересная часть графика (очереди 1 и 2) сравнить уже сложно. На графике задержек 1 и 1,5 мс почти в одной точке, а реально это разница в полтора раза.
Ну автокомплит ключевых слов, git и переход к определению DBA точно не помешает.
если не ошибаюсь, в utimate
Ошибаетесь: git точно есть в community. Скрипты развертывания в целом есть, кажется в любом SSDT (даже в stand-alone). А вот с тестами — только с professional.
Раз уж упомянули, а есть реальный опыт разработки не крошечных проектов с SSDT и юнит тестами SQL?
Это было вполне резонное соображение. Ключевое слово «некоторые». Мысленно дополним: «А иные, наоборот, тускнели бы весной.»
Только вот это не параллакс. Параллакс — это когда сдвинулся и видишь ту же звезду под другим углом. Так как мы на Земле, то самый большой "сдвиг" для нас рождает годичный параллакс.
А внятно инструментально фиксировать яркость объектов, я уж не знаю когда именно научились, но точно не в 17 веке.
Тут вопрос что такое "противозаконным". Если вопрос "имел ли он право пользоваться ресурсами компании для майнинга", то нет, не имел. Предприятие может подать в суд и потребовать компенсации. Правда придётся доказывать ущерб и компенсацию, а как их доказать? Стоял терминал и тратил электроэнергию? Ну так скорее всего это входит в договор аренды, если не было отдельных платежей за электроэнергию, то нифига не доказать. Можно попробовать посчитать сокращение срока эксплуатации оборудования, но тоже посчитать, провести экспертизу и обосновать суду ущерб будет непросто.
Попадает ли его деяние под УК? Очень сомнительно, причем если и попадает, то под лёгкие статьи, которыми пугать как ежа голыми ягодицами. Например, в его действиях можно усмотреть признаки преступления, попадающего под статью 274 (Нарушение правил эксплуатации средств хранения, обработки или передачи компьютерной информации и информационно-телекоммуникационных сетей), но там для состава надо доказать крупный ущерб (а его доказывать сложно).
Ну если даже предположить, что получится припаять какую-нибудь ст 201 (Злоупотребление полномочиями), то на практике это значит, что будет условный срок год или два. Судимость, сложности с устройством на работу в госорганы и в банки. Стоит ли это выигрыша? Скорее всего да. Вернуло бы это биткоины QIWI? Нет. А потратиться на доказывание вины пришлось бы.
На самом деле это в бизнесе сплошь и рядом:
— Так вот делать нельзя!
— А наказание какое?
— Адмнистративный штраф в 10000 рублей!
— А прибыль?
— Э… миллион рублей…
— Ну тогда отложить 10000 на штраф и сделать.
Тоже удивило. «Можно было ожидать, что некоторые звёзды будут гореть ярче весной, когда Земля приближалась к ним, а затем становиться тусклее осенью.» Что это было? А зима может настаёт потому что Земля отдаляется от Солнца (спойлер: наоборот, зимой мы ближе, перигелий в январе)? Это ж прям днище.
Голая SSMS хороша в основном тем, что есть везде, где есть SQL Server.
SSMS в целом неплоха и растет, например, если сравнить SSMS 2008 и 2017, то очень многое улучшено в мелочах (а уж 2005 хуже даже не в мелочах, и конечно SSMS стопудово лучше, чем Query Analyzer + Enterpise Manager, но давайте не увлекаться археологией).
Но голая SSMS многого не умеет:
с гитом всё еще не умеет работать (ха-ха, но DG с ним пока до сих пор неочевидно работает)
"перейти к определению" нет.
рефакторингов даже типа safe rename нет
автокомплит на ключевых словах отсутствует
Это только то что вот прямо сходу вспомнил, если внимательнее посмотреть, то там много недостатков. Часть недостатков (в частности все, что перечислены выше) решены в SSDT и VS, но это не SSMS! А SSMS с плагинами (Apex, RedGate, dbForge и т.п.) это по цене заметно дороже DataGrip.
Но я присоединяюсь к тому, что DG (особенно из-за упомянутого смешения) концептуально ни для DBA (которые живыми базами оперируют), ни для dev, которые оперируют репозиторием, кодом, миграцией с версии на версию.
ЗЫ: у меня DG пока ничего не отбила, я пока надеюсь, что они приведут инструмент к крутому виду.
Первые 2-3 спринта — может быть и должен. А дальше он должен быть заменимым. Скрам-мастер не может же за команду решать на ретроспективе. Не может за команду вносить изменения в процесс.
del, не на то сообщение ответил
Lean production != Agile.
У них есть общие моменты, но это сильно разные штуки.
Что сказали или предложили остальные участники команды на ретроспективе? Если вас 13 человек (это многовато, но терпимо), то пробовали просто взять и договориться о лимите в 90 секунд на каждого?
Стендап не про совесть. А про то, что если условный Петя делает задачу третий день, а она оценена в 1 день, то на невыполненный спринт попадает не Петя, а команда. Стендам помогает не превратить эти 3 дня в 5 или 7. Тут вопрос не в том, стесняется Петя или нет. Может он и правда верит, что сегодня всё доделает (и так второй месяц :) ), тут вопрос, чтобы команда увидела риск до провала.
Ну так договоритесь с PO о правилах, как он может emergency в текущий спринт вставлять. Какие критерии, что задача emergency, а не просто приоритетная. Как договориться о том, какие задачи эта emergency пододвигает. Договоритесь о том, что "цена" впихивания в спринт — это рефакторинг или устранение техдолга в следующем с нижней границей оценки 30-50%.
Что-то сильно не то вы делаете, судя по симптомам.
А почему понижение КПД? Накладные расходы на спринт — это время для демо, ретроспективы и планирования. Время планирования и демо зависит от количества задач и поэтому при длинном спринте также увеличатся. Ретроспектива — зависит от сыгранности команды и вообще может пройти за 20 минут, когда у команды уже было 10-20 ретроспектив.
В любом случае — оптимальная длина спринта зависит от огромного количества факторов. По моему опыту, чаще командам комфортнее работать в спринте 2 недели. Но видел команды со спринтом и в 1 неделю, и в 3, и в 4. Если 4 и больше, то надо приглядеться, но вполне может быть, что так надо.
Примерно в 70-80% случаев первым скрам-мастером становится экс-тим-лид. Ну или его правая рука, если сам тим-лид становится PO.
Если честно, то это страшная картина. Не из-за потери рабочих мест, нет. Из-за безопасности IoT. Заддосил сельхоз соседней страны и никаких танков не надо. Как stuxnet, только сильно проще сделать и сразу оставит без еды, а не без урана.
Если серьезно, то большая часть этих 7+ млрд питается мало и отвратительно. Так что если обеспеченные 10% не хотят, чтобы их съели нижние 30%, этих нижних нужно докормить.
Но это я всё за автора статьи домысливаю, реально не считал.
Но тут такой момент, что с точки зрения разгребания между очередью 16 и очередью 256 разницы почти нет. У вас это тоже в графиках видно: посмотрите, latency просто линейно растет (там обе шкалы логарифмические, поэтому в итоге всё равно линейно). Как в супермаркете: если очередь 5 человек, то ждать 10 минут, если очередь 10 человек, то 20. Наверное есть какая-то оптимизация, объединение смежных чтений, перестановки и т.п., но в реальности картина простая: есть большая очереди и её не волшебное разгребание. Этот диапазон линеен, его не интересно смотреть.
Любое критичное к дисковой производительности приложение. СУБД, например.
Всё бы ничего, но из-за этого диапазона приходится использовать логарифмические шкалы и самое интересная часть графика (очереди 1 и 2) сравнить уже сложно. На графике задержек 1 и 1,5 мс почти в одной точке, а реально это разница в полтора раза.
А почему в статье используется
echo %username%, а не более традиционныйwhoami? Более того%username%можно и подменить, а вотwhoamiне очень.Ну автокомплит ключевых слов, git и переход к определению DBA точно не помешает.
Ошибаетесь: git точно есть в community. Скрипты развертывания в целом есть, кажется в любом SSDT (даже в stand-alone). А вот с тестами — только с professional.
Раз уж упомянули, а есть реальный опыт разработки не крошечных проектов с SSDT и юнит тестами SQL?
Только вот это не параллакс. Параллакс — это когда сдвинулся и видишь ту же звезду под другим углом. Так как мы на Земле, то самый большой "сдвиг" для нас рождает годичный параллакс.
А внятно инструментально фиксировать яркость объектов, я уж не знаю когда именно научились, но точно не в 17 веке.
Тут вопрос что такое "противозаконным". Если вопрос "имел ли он право пользоваться ресурсами компании для майнинга", то нет, не имел. Предприятие может подать в суд и потребовать компенсации. Правда придётся доказывать ущерб и компенсацию, а как их доказать? Стоял терминал и тратил электроэнергию? Ну так скорее всего это входит в договор аренды, если не было отдельных платежей за электроэнергию, то нифига не доказать. Можно попробовать посчитать сокращение срока эксплуатации оборудования, но тоже посчитать, провести экспертизу и обосновать суду ущерб будет непросто.
Попадает ли его деяние под УК? Очень сомнительно, причем если и попадает, то под лёгкие статьи, которыми пугать как ежа голыми ягодицами. Например, в его действиях можно усмотреть признаки преступления, попадающего под статью 274 (Нарушение правил эксплуатации средств хранения, обработки или передачи компьютерной информации и информационно-телекоммуникационных сетей), но там для состава надо доказать крупный ущерб (а его доказывать сложно).
Ну если даже предположить, что получится припаять какую-нибудь ст 201 (Злоупотребление полномочиями), то на практике это значит, что будет условный срок год или два. Судимость, сложности с устройством на работу в госорганы и в банки. Стоит ли это выигрыша? Скорее всего да. Вернуло бы это биткоины QIWI? Нет. А потратиться на доказывание вины пришлось бы.
На самом деле это в бизнесе сплошь и рядом:
— Так вот делать нельзя!
— А наказание какое?
— Адмнистративный штраф в 10000 рублей!
— А прибыль?
— Э… миллион рублей…
— Ну тогда отложить 10000 на штраф и сделать.
Тоже удивило. «Можно было ожидать, что некоторые звёзды будут гореть ярче весной, когда Земля приближалась к ним, а затем становиться тусклее осенью.» Что это было? А зима может настаёт потому что Земля отдаляется от Солнца (спойлер: наоборот, зимой мы ближе, перигелий в январе)? Это ж прям днище.
А его нет из коробки. Решение только поставить сторонние плагины. По сути другого пути нет.
Из популярного можно отметить:
Все хотят денег (чаще много), у всех какие-то кусочки есть и бесплатно. Автокомплит бесплатный есть у ApexSQL, но какой-то глючноватый и тормознутый.
Голая SSMS хороша в основном тем, что есть везде, где есть SQL Server.
SSMS в целом неплоха и растет, например, если сравнить SSMS 2008 и 2017, то очень многое улучшено в мелочах (а уж 2005 хуже даже не в мелочах, и конечно SSMS стопудово лучше, чем Query Analyzer + Enterpise Manager, но давайте не увлекаться археологией).
Но голая SSMS многого не умеет:
Это только то что вот прямо сходу вспомнил, если внимательнее посмотреть, то там много недостатков. Часть недостатков (в частности все, что перечислены выше) решены в SSDT и VS, но это не SSMS! А SSMS с плагинами (Apex, RedGate, dbForge и т.п.) это по цене заметно дороже DataGrip.
Но я присоединяюсь к тому, что DG (особенно из-за упомянутого смешения) концептуально ни для DBA (которые живыми базами оперируют), ни для dev, которые оперируют репозиторием, кодом, миграцией с версии на версию.
ЗЫ: у меня DG пока ничего не отбила, я пока надеюсь, что они приведут инструмент к крутому виду.