понедельник, 11 декабря 2023 г.

Хоккейная амуниция

          Хотел бы поделится своим опытом в выборе/эксплуатации хоккейной амуниции. Мои дети довольно давно играют в хоккей и за это время я опытном путем выяснил:

  • Коньки и клюшки должны быть только Bauer/CCM.  Эти две детали хоккейной экипировки на топовом уровне никто еще не научился делать. 
    • Клюшки True - красивые, легки - но хрупкие.
    • Клюшки vikkela - в принципе не плохой вариант для маленьких детей, до 8-9лет так как являются одними из самых легких. Но опять же хрупкие.  На подростковом возрасте они будут быстро ломаться
    • Наши клюшки Заряд прям порадовали - за свои деньги оказались прям очень достойным вариантом. Но дизайн не обновляется, по сравнению с другими выглядит убого. Они почему-то не понимают что для детей это важно. 
  • Шорты - в принципе любые можно брать, тут главное чтобы удобно сидели на поясе. Но самые удобные Bauer серии Ultrasonic
  • Нагрудник - марка тоже не принципиально, у всех есть хорошие модели. Нужно смотреть чтобы наплечные чашечки не болтались, нормально были закреплены. У Bauer есть неудачная серия, где эти чашечки из "сверхлегкой пены" плохо закреплены и болтаются постоянно. 
  • Налокотники, наколенники, краги - тоже без разницы какой фирмы.  Все что там пишут про ультрасовременные технологии на 99% брехня. Все эти граммы ни на что особа не влияют.  Главное чтобы ребенку в этом удобно было. 
  • Защита шеи - только Ice Armor. Для меня остается загадкой почему никто не додумался кроме Ice Armor сделать нормальную защиту шеи. 
  • Баулы - лучше брать НЕ Bauer/CCM. Они переоценены. Ничем в лучшую сторону не отличаются. Я экспериментировал с разными формами. Стоячие чуть удобнее если в раздевалке мало место, но сильно дороже. Сейчас остановился на классических прямоугольных баулах. У тех же Ice Armor очень не плохие баулы получились.
  • Шлемы - вообще никакой разницы между брендами нет. Главное подобрать его по форме/размеру головы, чтобы не мотался на голове туда-сюда, и не жал (даже чуть-чуть не должен жать). Иначе он во время тренировки намокает, и еще больше жать начинает.  
  • Термобелье - тоже всякого перепробовал. 
    • Самые топ конечно Bauer, но неоправданно дорогой. Но у меня есть комплект который четвертый год уже носят каждый день. Надписи постирались уже, затяжка в одно месте - но в общем и целом почти как новый. Никаких тебе катышков, липучки тоже работают как новые.  В общем если денег не жалко - прям рекомендую
    • Mad guy - тоже ок, но катышки появляются и оно на ощуп холодное. Когда еще в раздевалке холодно - прям совсем не очень. Дети ныли от него постоянно
    • Goal& Pass - самое лучшее по отношению цена-качество. 
  • Носки - Bauer конечно самые лучшие, но они довольно тугие. Особенно когда ноги влажные - прям тяжко одеваются. Ну и они пипец какие дорогие. За эти же деньги можно 3 пары Goal&pass купить. Или 5 пар noname носков. В общем я сейчас высокие гольфы от noname продавцов покупаю - норм заходит

пятница, 8 декабря 2023 г.

SDLC models/Software development methods/Software development models

            Я решил освежить и систематизировать свои знания по SDLC models/Software development methods/Software development models. Я признаюсь честно, будучи программистом я с отвращением относился ко всем этим методологиям и тем кто их продвигает.  У меня всю жизнь была предельно простая методология разработки: Нормально делай, нормально будет!  Ну а сейчас думаю - негоже мне быть невеждой до старости, надо просветится. 

           Вы знаете - почитав весь вечер про все эти Agile/Scrum/Lean/Kanban у меня ощущение как будто я методичек от Лайк Центра начитался. Успешный успех повсюду. По сути все эти "методы" - маркетинг чистой воды. Бородатые мужики в 1960-х придумали предельно простые вещи - чтобы написать какой-то софт тебе нужно:

  1. Собрать требования к софту
  2. Спроектировать его
  3. Спланировать разработку
  4. Разработать
  5. Протестировать что ты понаписал
  6. Задеплоить в прод
  7. Поддерживать
Все эти безчисленные методы строятся на том чтобы выполнять отдельные операции / группы операций из этого списка либо паралельно, либо инкрементально + в цикле. Ну и конечно навалить сверху кучу маркетинга, так чтобы на книжку хватило, переназвать все понятия и потом до самой пенсии колесить по миру - выступать на конференциях объясняя что значат новые термины которые ты ввел. 
Специально для тех бедолаг кому больше нечем заняться кроме чтения моего недоблога, спецкурс - история развития software development methods за 5 минут. Не благодарите.
  1. Waterfall - вот как раньше мосты разрабатывали, так и софт будем писать. Собрали требования, спроектировали, построили, сдали в эксплуатацию. Все по порядку, никакого agile. Ну что вы хотели, мосты ведь не agile ни разу. 
  2. Prototyping - эту методологию тоже из традиционной инженерии взяли. Прежде чем огромный мост бабахать, может маленький сделать из говна и палок ? Так быстрее будет гораздо, и заодно поймем какой нам мост нужен прежде чем все в полный рост делать 
  3. Iterative and incremental development - ну это первый метод разработки который придумали именно для софта. Додумались что в отличии от моста, софт можно писать по частям. То есть выкатил первую версию с одной фичей, потом собрал требования для второй фичи, разработал и выкатил вторую фичу. В общем мы все до сих пор примерно так и работаем
  4. Spirital development - вот первая ласточка технического маркетинга, буллшита по нашему. Из 1986 года напомню. Чувак(Barry Boehm) подумал - а что если мы будем задачу решать в цикле, и на каждой итерации этого цикла, будем проводить оценку рисков и выбирать наиболее подходящую методологию разработки для данной итерации. В общем чувак добавил бюрократии в виде оценки рисков, ну и все остальное как в iterative and incremental development. Но главное его изобретение я считаю - он изобрел технический маркетинг в методологиях разработки. Ибо после него маркетингового буллшита стало в разы больше
  5. Rapid Application Development (RAD) - в 1991 году James Martin понял невероятное - клиентам гораздо проще пальцем показывать чем читать/писать огромный толмуды с требованиями. Напомним что в классическом waterfall - тебе нужно на первом этапе выдать разработчикам все требования ко всем фичам в формализованном виде(в виде текста), а потом подписать их своей кровью и не менять их после этого. Какая-то немыслимая херня по нашим временам. А James Martin понял что если сначала, на этапе сбора требований быстро сделать на коленке что-то, что выглядит примерно как тот софт который тебе нужно написать (прототип), и заставить клиента расписаться кровью на прототипе - то вероятность того что в итоге клиент получит именно то что он хочет, сильно повышается по сравнению с 500-страницами требований в виде текста. Ну и еще он понял что потом этот прототип не обязательно выкидывать после, его можно улучшать итеративно, и даже давать клиенту им пользоваться. В общем prototype + iterative and incremental development+marketing = RAD. Причем этот маркетинг я уже застал в своей программистской карьере. Borland  Delphi, Borland C - это все было уже RAD-остным.
  6. Extreme programming -  вот где маркетинговый буллшит развернулся в полную силу. Kent Beck решил, а что если мы возьмем все хорошее, что есть в существующих методологиях разработки ПО и сделаем это на максималках(extreme)? Чем не новая методология ? К примеру code review на максималках - это pair programming. Что, до него pair programming никто не занимался ? Неужели чтобы сесть вместе с джуном и показать ему как писать код, тебе нужна новая методология ?  Что самое интересное, Kent Beck разработал эту методологию когда работал в Chrysler над их бухгалтерской системой. Начал он там работать в 1996, в 1999 написал книгу про extreme programming, а в феврале 2000-го этот проект закрыли.  Прям успешный успех, не правда ли ? В это же время саму Chrysler купила Mercedes Benz. Наверное потому что в Mercedes набирали программистов которые по одному умели работать, а в Chrysler все по двое сидели.
  7. Scrum - а дальше ребята подумали, iterative and incremental development звучит слишком понятно, по этому книжку не напишешь. А что если мы это все пере-назовем своими словами и добавим ритуалов по вкусу ? Чем не новая религия для программистов ? Сказано -сделано, так и появился scrum.  Ребята отличились тем что изобрели новую профессию - scrum-master. Типа как scrum-священник. Ведь у каждой религии должен быть священник который бы следил чтобы все ритуальные митинги соблюдались ?
  8. Lean software development - а дальше Mary Poppendieck and Tom Poppendieck прочитали книжку про Toyota и ее  систему управления производством. И тут они подумали - что если взять все хорошее из существующих методологий, переназвать терминами из книг по TPS, то получится вполне себе новая методология. Поэтому не долго думая в 2003 году они выпустили книгу Lean Softwware Development и подружились с тусовкой agile-балоболов и счастливо колесят по миру продавая свое "изобретение". 
  9. Kanban development - а дальше случилось мое любимое изобретение, Kanban. Ребята "изобрели" kanban доску и построили вокруг этого не хухры-мухры а целую методологию. Цитата из википедии - "Kanban approach aims to manage work by balancing demands with available capacity, and by improving the handling of system-level bottlenecks". А то до вас никто не балансировал запросы на IT capacity с ее фактической доступностью. Вы первые такое придумали. Увидели что на kanban доске куча задачь в QA зависла. Собрали совещание - что же нам делать ? Наверное нужно количество тестировщиков увеличить! Бинго! 
На этом у меня все. Ждем новых методологий разработки.

четверг, 7 декабря 2023 г.

Метрики в разработке

         За те 15-20 лет что я программирую, я не раз наблюдал попытки измерить этот процесс. Как правило это было сделано максимально некомпетентно, людьми которые ничего не понимали в разработке.  Приходили какие-то "эффективные менеджеры", желающие выслужится и начинали заставлять трэкать время,  считать твои коммиты, строчки кода, или закрытые тикеты.  Я всегда пытался объяснить этим людям, что все не так просто как они думают. Но они упорно не понимали меня, потому что никогда не программировали или делали это так давно что у же забыли.  Это все равно что объяснить человеку который никогда не плавал, какого это - плавать. 

       Наконец-то я нашел адекватное исследование на эту тему - https://queue.acm.org/detail.cfm?id=3454124 Я крайне рекомендую прочитать его прежде чем внедрять эти метрики. Они предлагают метод называемый SPACE. В рамках этого метода они предлагают использовать 5 измерений: удовлетворенность, производительность, активность, коммуникативность и эффективность. В каждом измерении они предлагают ряд метрик которые можно измерить, либо измерений которые могут быть использованы как прокси-метрики для целевых метрик. К примеру удовлетворенность саму по себе измерить трудно, но можно легко замерить уровень текучки в коллективе (turnover), которая  может служить в каком-то приближении прокси-метрикой для удовлетворенности (не удовлетворен =>уходишь). Мне лень переводить все, поэтому дальше просто короткое обобщение на английском:

  • Satisfaction and well-being dimension
    • Best captured with surveys. To assess the satisfaction dimension, you might measure the following:
      • Employee satisfaction. The degree of satisfaction among employees, and whether they would recommend their team to others.
      • Developer efficiency. Whether developers have the tools and resources they need to get their work done.
      • Burnout. Exhaustion caused by excessive and prolonged workplace stress.
    • Productivity and satisfaction are correlated, and it is possible that satisfaction could serve as a leading indicator for productivity; a decline in satisfaction and engagement could signal upcoming burnout and reduced productivity
  • Performance dimension - is the outcome of a system or process.
    • Can be measured with following metrics
      • Quality. Reliability, absence of bugs, ongoing service health.
      • Impact. Customer satisfaction, customer adoption and retention, feature usage, cost reduction.
  • Activity dimension - is a count of actions or outputs completed in the course of performing work. Metrics can be:
    • Design and coding. Volume or count of design documents and specs, work items, pull requests, commits, and code reviews.
    • Continuous integration and deployment. Count of build, test, deployment/release, and infrastructure utilization.
    • Operational activity. Count or volume of incidents/issues and distribution based on their severities, on-call participation, and incident mitigation.
  • Communication and collaboration dimension - capture how people and teams communicate and work together. Following are examples of metrics that may be used as proxies to measure communication, collaboration, and coordination
    • Discoverability of documentation and expertise.
    • How quickly work is integrated.
    • Quality of reviews of work contributed by team members.
    • Network metrics that show who is connected to whom and how.
    • Onboarding time for and experience of new members
  • Efficiency and flow dimension - capture the ability to complete work or make progress on it with minimal interruptions or delays, whether individually or through a system Some example metrics to capture the efficiency and flow dimension are:
    • Number of handoffs in a process; number of handoffs across different teams in a process.
    • Perceived ability to stay in flow and complete work.
    • Interruptions: quantity, timing, how spaced, impact on development work and flow.
    • Time measures through a system: total time, value-added time, wait time.

Также авторы исследования разъясняют как этот метод можно применять для SRE команд и управления инцидентами.

Есть хорошее исследование предложенное DevOps Research and Assessment (DORA) - https://cloud.google.com/blog/products/devops-sre/using-the-four-keys-to-measure-your-devops-performance 

Они предложили простой фреймворк из метрик (изначально 4-х метрик, reliability добавили потом), которые довольно легко измерять:

  • Deployment Frequency—How often an organization successfully releases to production
  • Lead Time for Changes—The amount of time it takes a commit to get into production
  • Change Failure Rate—The percentage of deployments causing a failure in production
  • Time to Restore Service—How long it takes an organization to recover from a failure in production
  • Reliability - represent availability, latency, performance, and scalability
Это сильно проще чем SPACE фреймворк, но они сознательно убрали из рассмотрения все не техническое - мотивацию, удовлетворенность и тд. 
Ну и в завершении обзора подходов к оценки производительности команд - набор метрик для платформенных команд:
  • Platform adoption rate - Measures how many product teams or services actively use the platform against those that don't.
  • Mean time to onboard (MTTO) - mean time to unboard
  • Platform service uptime
  • Feedback loop duration - Tracks the average time from when users provide feedback to when the platform team addresses it.
Метрики довольно простые и логичные, но не все из них легко реализуемы на практике (я имею ввиду автоматизированное измерение)
       Что хотелось бы сказать в конце - никогда не стоит показывать метрики эффективным менеджерам и прочим идиотам. Метрики могут помочь в поиске проблем в процессе разработки, в улучшении подходов к разработке. То есть с их помощью можно и нужно оценивать эффективность новых подходов к разработке, удобство инструментов в разработки.  Но никогда ни при каких обстоятельствах нельзя делать метрики частью процедуры оценки производительности человека. Никакие метрики не помогут тебе заставить работать ленивого человека. Он обязательно найдет способ обмануть твои метрики, человека нужно обучить, мотивировать или уволить. Как только разработчики поймут (а они поймут это довольно быстро), что метрики собираются чтобы их измерить - они начнут эти метрики обманывать и метрики начнут врать. 
       Выход я вижу один - собирать метрики анонимизировано. Чтобы при всем желании их нельзя было использовать для измерения производительности конкретного человека, а можно было использовать только в виде статистики всей команда разработки или отдельных подкоманд.