Сайт Романа ПарпалакаБлог

Лебедев всё

Слушал тут Лебедева и услышал о Беслане такое, чего от любого нормального человека услышать нельзя в принципе.

Лебедев: Это безумно ужасная трагедия, это страшно, этого никогда нельзя забыть, но при этом бегать вот как эти бесконечные создающиеся и спекулирующие на трагедии в последствии комитеты, все эти матери Беслана и какие-то там еще голосы Беслана, то есть они множатся, чтобы привлекать к себе внимание и получать как можно больше политических пирогов после этого вместо того, чтобы просто, блядь, похоронить своих детей и просто жить дальше, потому что это просто трагедия, которая случилась. Они не могут влиять на эту ситуацию никак, эта ситуация называется пиздец в стране.

А перед этим он сказал следующее:

Лебедев: В Беслане, я думаю, что к Путину в первый раз в жизни приехали нормальные консультанты. Я думаю, что они приехали из Израиля, потому что это та самая страна, где вообще с террористами не церемонятся. Если есть террорист, с ним просто не рагзоваривают, не важно, что он хочет сказать.

Я как раз до Лебедева слушал Латынину. Она посвятила всю передачу Беслану.

Латынина: Вот израильтяне такие сопляки, такие мягкотелые, не то что крутой Путин, они вели переговоры с террористами или нет? Ответ: вели всё время. Они пользовались любой возможностью вести переговоры любым способом. У них, например, был израильский офицер, который знал Иди Амина, диктатора Уганды, был его приятель. Он в эти дни постоянно говорил с ним по телефону. Они обратились к Садату. Садат, президент Египта, как вы понимаете, не был большой любитель Израиля в это время. Он попытался вести переговоры с Организацией освобождения Палестины и с Угандой. Даже Ясир Арафат отправил террористам своего личного посланца. Более того, террористы поставили дедлайн, он 1 июля. Израильский кабинет министров специально начал переговоры, чтобы перенести дедлайн на 4 июля, и вот эта пролонгация дедлайна была ключевой для спасения заложников. Она предоставила Израилю время организовать и провести спецоперацию. И если бы Израиль не вел переговоров с террористами, никакого спасения бы не было, была бы бойня.

...

Еще раз: в Беслане, на мой взгляд, было принято два решения. Первое: не повторять Буденновск и не договариваться с террористами. Оно было совершенно правильным. Второе: не говорить с террористами, организовать случайный взрыв и списать его на террористов. Я не буду оценивать моральность этого решения, но скажу, что оно было выполнено крайне непрофессионально.

Вот есть такое русское слово: «не договориться» и «не договариваться». Вот такое впечатление, что был отдан приказ, и люди не удосужились уточнить грамматику: совершенный или несовершенный вид у этого глагола. И понятно, что силовики были в безвыходном положении. Но это и есть их профессия — находить выход из безвыходного положения. Из простого положения люди находят выход сами.

Также нужно отметить, что раньше в той же записи Лебедев говорит, как важно проверять факты популярному блогеру, хотя сам же этого не сделал:

Надо сказать, что любой блогер, особенно тот, у которого много подписчиков, он должен думать своей головой, перед тем как что-то пиздеть, и особенно, если чувак комментирует новости и факты, он должен перед тем как их прокомментировать, хотя бы немножко ознакомиться с фактурой.

Меня не интересуют мотивы этого человека, я не собираюсь думать, чего здесь больше — невежества или продажности. Я просто больше не буду читать или слушать Лебедева, для меня этот человек перестал существовать.

8 сентября 2019 года, 14:50     Лебедев     Оставить комментарий

Протесты и выборы

На удивление, предстоящие бессмысленные выборы в бесполезную Мосгордуму стали предметом внимания и обсуждения, и благодаря этому обрели некоторый смысл.

Несмотря на недавний 50-тысячный митинг, независимых кандидатов не зарегистрировали. Из оставшихся вариантов только «умное голосование» Навального может хоть как-то повлиять на результат выборов. Ведь если вы испортите бюллетень или вообще не придете, результат будут определять другие избиратели.

Среди критиков умного голосования звучит аргумент: если Навальный предложит голосовать за сталиниста, как я смогу это сделать? Как переступить через свои моральные принципы?

Но рассуждать о моральных принципах на таких выборах — всё равно что задумываться об этических проблемах, столкнувшись с хулиганским поведением. На хулиганство единственным адекватным ответом будет угроза дать в морду и готовность ее выполнить. Нет смысла анализировать такой ответ на предмет невежливости. Получится невежливо, но эффективно.

Власть применяет все политические технологии, которые только может придумать. Путинги с бюджетниками. Концерты какой-то Бузовой. Выдуманные праздники в Парке Горького. Повышение явки. Сушка явки. А история с флагом особенно циничная. Когда Немцов нес флаг в день флага, его задержали. А когда нужно придумать повод для отказа в проведении митинга, в честь того же дня флага организовывают концерт.

Ладно, предположим, что в думу пройдут сталинисты. 2-3 человека из 45. Может именно они и отправят какие-нибудь депутатские запросы о полицейском произволе в июле-августе.

И еще можно порассуждать о коммунистах более глобально. Есть мнение, что на выборах 1996 года должен был победить Зюганов, но ему не дали, опасаясь реакционной политики. А сейчас, когда прошло больше 20 лет, как вы думаете, какая реакция лучше, путинская или зюгановская? Можно обратиться и к практическому опыту. В Молдавии коммунисты правили с 2001 по 2009 год. И результаты не сильно отличались от либералов и демократов.

Я, собственно, никого не уговариваю. Поступайте как хотите.

1 сентября 2019 года, 12:08     политика     Оставить комментарий

Радиационное загрязнение больницы в Северодвинске

На Медузе статья о том, как в больницу в Северодвинск привезли зараженных радиацией больных и даже не предупредили врачей:

В больнице имени Семашко, куда отвезли еще троих пострадавших, были детекторы и дозиметры. Врачи поняли, что идет заражение, хотя им тоже изначально было сказано, что его нет. Они их сами дезактивировали, надели защитные костюмы, респираторы, и только удостоверившись, что все безопасно, стали оказывать помощь. Так и должно быть. Так и было бы сделано у нас, если бы и нас предупредили.

На следующий день, когда больница уже была, по-русски говоря, загажена цезием-137, военные начали проводить дезактивацию в операционных и приемном покое, выкосили всю траву вокруг, все радиоактивные предметы, которые они не могли обеззаразить, они демонтировали и увезли с собой — в том числе ванну в приемном покое, в которой мы мыли пострадавших.

Я закрываю лицо ладонями. Массирую себе глаза. И задаю немой вопрос: как такое могло произойти? Как? И у меня нет ответа. Где тот человек, который принял это решение?

И еще более невероятным кажется происшедшее, когда все посмотрели и обсудили сериал «Чернобыль».

Сначала врешь об украденных миллиардах. Потом о результатах выборов. И вот уже врешь о радиационном загрязнении: «Они не опасны для вас, работайте».

22 августа 2019 года, 00:05     по жизни     Оставить комментарий

Не храните бизнес-логику в базе данных

Современные базы данных не только хранят эти самые данные, но и обрабатывают их с помощью пользовательских функций, хранимых процедур, триггеров. После знакомства с этими инструментами у разработчика возникает мысль перенести часть бизнес-логики из кода приложения в базу. Сторонники такого подхода утверждают, что это повышает быстродействие, так как для обработки данных не требуется передавать их с сервера БД в приложение.

Я расскажу, почему в промышленном программировании так делать не надо.

Масштабирование производительности. У приложений и базы данных различные возможности масштабирования при росте нагрузки на систему. Для масштабирования обычных приложений на современных фреймворках достаточно запустить несколько копий на разных серверах. А база остается одна. Чтобы снизить нагрузку на чтение, применяют репликацию master-slave. Снизить нагрузку на запись не так просто. Но, возможно, к этим методам не придется прибегать, если облегчить нагрузку на базу данных и держать бизнес-логику в приложении.

Масштабирование разработки. Когда вы разрабатываете систему сами, вы используете любые инструменты на свое усмотрение. Когда вы нанимаете разработчиков, лучше применять стандартные общепринятые инструменты. И баги с боевой системы проще воспроизводить локально, когда бизнес-логика располагается только в коде.

Автоматизация разработки. БД как хранилище данных — стандартная практика. Для упрощения разработки в такой парадигме есть развитые инструменты — библиотеки ORM, которые умеют, в частности, автоматически генерировать скрипты миграции структуры БД. Изменение бизнес-логики в коде облегчается средствами среды разработки: автодополнением, автоматическим рефакторингом. Пользовательские функции в БД придется изменять полностью вручную.

Версионирование. Все разработчики научились работать с системами контроля версий кода. Git — стандарт де-факто, используется и для разработки, и для выкладки на сервер. Выкладка кода для каждого серверного языка — понятная и отработанная процедура. Одновременное весрионирование структуры данных в базе, хранимых процедур и скриптов миграции как минимум вызывает вопросы.

Тестирование. Бизнес-логика в коде покрывается стандартными юнит-тестами и функциональными тестами. Написать юнит-тест на функцию в базе данных если и не невозможно, то весьма сложно.

Отладка и профилирование. Для отладки и мониторинга серверных приложений существуют инструменты: логирование, отладчики, профилировщики, мониторинг. Искать баги в триггерах и хранимых процедурах вам придется вслепую.

Я помню, как на прошлой работе в CityAds в проекте была одна InnoDB-табличка на несколько сотен записей. Она пополнялась из триггера при изменении записей в другой таблице. Но иногда вставки по непонятным причинам не происходило.

Я долго не мог докопаться до настоящей причины, пока не сделал добавление записей из кода, а не из триггера. Оказалось, что вставка иногда не срабатывает из-за ошибки типа unique constraint violation на автоинкрементном первичном ключе. Стандартный механизм исключений и логирование помогли отследить эту ошибку.

Админы подтвердили, что это известная проблема в MySQL 5.6, но быстро перевести production на 5.7 они не могли. Пришлось переключить тип таблицы с InnoDB на MyISAM. Проблема исчезла.

Не храните бизнес-логику в базе данных.

6 августа 2019 года, 11:46     промышленное программирование     Оставить комментарий

Дизайн указателей в московском метро — 2

Продолжим разбирать достоинства и недостатки указателей в московском метро. Вот указатель в подземном переходе на Пушкинской площади.

Здесь теория близости работает против задумки дизайнера. Стрелка оказывается сильно связанной с Тверской, и гораздо слабее с Пушкинской и Чеховской. При беглом взгляде может сложиться впечатление, что к Тверской надо идти налево, а к Пушкинской — правее указателя и прямо. Однако это впечатление ложное: прямо находится выход на поверхность.

Дизайнер попытался компенсировать этот эффект пустотой справа от Чеховской, которая говорит: «справа ничего нет». Но близость при беглом взгляде всё равно выигрывает.

Дефект исправляется расположением названий станций не по горизонтали, а по вертикали. Либо в правой части указателя нужно написать «выход в город». Я не знаю, как сделать лучше, если нельзя менять размер указателя.

20 июля 2019 года, 21:39     дизайн · фото     Оставить комментарий

Этикет пешехода

xxx: Кажется, я постигла одну из величайших (для меня) тайн мироздания.
xxx: А именно — почему женщины чаще, чем мужчины, загораживают проход и, даже если идут вдвоем, умудряются равномерно распределиться по тротуару так, что обойти их не представляется возможным.
xxx: Женщины ближе к природе. А природа не терпит пустоты... =_=

Баш

Хоть я давно наблюдаю за этим явлением, наблюдениями не торопился делиться. Напишешь, что умудренная опытом женщина идет навстречу по середине узкой дорожки и не думает сдвигаться, и вроде как жалуешься. Сложно отойти в сторонку? Ты же мужчина! Солдат! Женщин надо уважать. А тем более старших. Ей тяжело. Она же мать, вырастила детей.

Недавно я стал свидетелем случая, когда от такого поведения пострадала третья сторона. Так что теперь можно разобрать явление непредвзято.

Тротуар шириной метра полтора, на нем спокойно расходятся два человека. Иду по правой стороне. Впереди по левой стороне бодро идет старшая женщина. Я постепенно ее догоняю. Навстречу по своей правой стороне идет мужчина с тележкой. Тоже бодро и тоже старший.

От меня до женщины остается несколько метров. Мы обходим обледенелое место, я по правильной стороне, она по неправильной. Мужчина видит, что женщина не собирается освобождать неправильно занятую сторону, и, не сбавляя скорости, резко поворачивает левее и проходит между нами. Через секунду я слышу звук падения мужчины и тележки. Возвращаюсь и спрашиваю, всё ли в порядке. Моя помощь не понадобилась. Иду дальше, обгоняю старшую женщину. Была мысль сказать ей что-то вроде «что же вы делаете, мужчина из-за вас упал, а вы даже не оглянулись». Но я ничего не сказал, потому что это не моя проблема.

Я вряд ли когда-то пойму, что происходит в голове у таких людей, и чего здесь больше — хамства или невоспитанности. Но это и не так интересно.

Из этой истории надо извлечь другой урок. Мужчина мог бы избежать падения, если бы не психанул и не изменил резко траекторию. Лет 10 назад я выработал шаблон поведения в таких ситуациях. Когда на тротуаре двое могут спокойно разойтись, я подхожу вплотную с правой стороны и останавливаюсь. Занявший чужую сторону человек всё прекрасно понимает и без лишних слов обходит с нужной стороны.

9 февраля 2019 года, 22:44     по жизни · lytdybr     Комментарии (1)

Работа над задачами в скраме

В прошлый раз я рассказал о скрам-команде и событиях спринта. Перейдем к вопросу о том, как организовать работу с задачами. Я буду опираться уже не на руководство, а на собственный опыт. Дело в том, что скрам не исчерпывающий набор инструкций. Он задает рамки, внутри которых команда действует на свое усмотрение. Работа с задачами как раз не регламентирована.

Бэклоги продукта и спринта

По скраму задачи на разработку образуют бэклог продукта. Бэклог содержит все требования к продукту и эволюционирует по мере развития бизнеса. За ведение бэклога отвечает владелец продукта, даже если ему в этом помогают другие участники команды. На планировании владелец продукта и команда разработки совместно формируют бэклог спринта, то есть определяют, какие задачи будут взяты в спринт.

На практике бэклог ведется в трекере (редмайн, жира, таргет процесс и пр.). Несмотря на богатство возможностей этих инструментов, запланированные задачи лучше представлять на доске в материальном виде. Когда перевешиваешь настоящую бумажку в колонку «сделано», чувство удовлетворенности от выполненной задачи усиливается.

У доски проходят ежедневные 15-минутные встречи команды — стендапы. Разработчики обязаны присутствовать на этой встрече, они по очереди рассказывают о прогрессе в достижении цели спринта. Остальные участники процесса могут посещать стендапы без права голоса.

Предыдущие версии руководства предписывали каждому разработчику команды ответить на стендапе на 3 вопроса:

  • Что я сделал вчера, что помогло команде разработки приблизиться к цели спринта?
  • Что я сделаю сегодня, чтобы помочь команде разработки достичь цели спринта?
  • Вижу ли я какие-либо препятствия, которые могут помешать мне или команде разработки достичь цели спринта?

В 2017 году в руководство внесли изменение, по которому команда сама определяет формат встречи. Я объясняю это изменение расширением области применения скрама.

Степень детализации требований в бэклоге разная: от подробно проработанных задач на следующий спринт до задач без описания на год вперед. Деятельность по уточнению и оцениванию задач называется product backlog refinement (PBR). Она может проходить в формате регулярной встречи владельца продукта, команды и заказчиков.

Критерии готовности к разработке (DoR)

Зрелая команда берет в спринт только проработанные задачи. Команда сама вырабатывает критерии готовности к разработке (definition of ready, DoR) с учетом особенностей проекта и предметной области. Пример:

Критерии готовности

  1. Команда разработки понимает бизнес-ценность задачи.
  2. У задачи понятное описание.
  3. К задаче приложены макеты всех новых экранов.
  4. В описании задачи указаны критерии приемки.

Если на проработке задачи «сэкономили», то на выяснение требований, согласования и переделки потеряется больше времени. Скрам-мастер объясняет постановщикам задач, что критерии готовности — это не капризы разработчиков. Пример:

Почему важно прорабатывать задачи

При написании кода программист принимает десятки мелких решений. Когда он понимает бизнес-ценность задачи, эти решения согласуются друг с другом, с уже существующим кодом, с видением продукта. Когда не понимает, решения случайны, продукт не получается целостным.

При работе с дизайнером над макетами даже по простым задачам выясняются тонкие моменты еще до начала разработки, уточняется описание задачи. В противном случае вопросы возникают при разработке, на решение и дополнительное согласование тратится время, задача затягивается.

Критерии приемки проясняют, какие функции требуются заказчику. Просматривая критерии приемки, программист проверяет, всё ли он сделал. А еще критерии приемки — пошаговая инструкция тестировщику.

Команда оценивает только готовые к разработке задачи. Команда объясняет владельцу продукта или заказчику, почему задача не готова, и что надо уточнить.

Зачем оценивать задачи?

Для быстрой обратной связи владельцу продукта и заказчику о сложности задач. У нас в CityAds был образцовый иллюстрирующий случай.

В спринт попала первым приоритетом задача «сделать новую форму добавления рекламодателя». Мы начали ее делать. Как выяснилось, нормальная реализация новой формы добавления затрагивает кроме нашего приложения системы других команд: авторизацию и биллинг. У авторизации не до конца готово АПИ, протокол обмена не зафиксирован, между системами сложное асинхронное взаимодействие. В результате мы не успели сделать все требования этой задачи и часть других задач.

На демонстрации заказчик был недоволен.
— Почему вы не сделали отчет?
— Приоритет формы добавления рекламодателя был выше.
— Мы думали, что вы быстренько сделаете форму и начнете делать отчет. Если бы мы знали, что добавить форму так сложно, отложили бы. Нам нужен отчет.

Оценка задач в часах

Кажется естественным оценивать задачи по предполагаемым затратам времени. Недостаток — оценку в часах сложно дать. Программист более-менее точно оценивает работу до 4 часов. Крупные задачи приходится дробить на подзадачи не больше этого ограничения. На декомпозицию уходит много времени, которое тратится впустую, когда в итоге задачу в спринт не берут. Для решения этой проблемы придумали стори-поинты.

Оценка задач в стори-поинтах

Стори-поинт — это условная единица измерения усилий команды, потраченных на задачу. Оценка в стори-поинтах включает в себя три фактора: объем работ, сложность и риски.

Объем работ больше, если в задаче надо сделать пять экранов, а не два.

Сложность больше, если на форме требуются подсказки у полей, валидация, сложные связи и зависимости между полями.

Риски на неопределенность выше, когда приходится использовать новую технологию или дорабатывать незнакомый код.

Стори-поинты нужны, чтобы сравнивать задачи друг с другом, поэтому абсолютное значение стори-поинта не важно. Для начала использования сопоставьте 1 стори-поинт несложной типовой задаче. Затем группируете выполненные задачи по условной шкале: чем правее задача, тем сложнее.

Шкала формируется не по первоначальной оценке задач перед выполнением, а по итоговой оценке после (изменение оценок видно на картинке). По мере роста опыта команды, развития проекта шкала эволюционирует: стикеры перевешиваются между колонками, добавляются и удаляются.

В случае затруднений с оценкой команда ищет на шкале похожую по сложности задачу и определяет будущее место для оцениваемой задачи.

Важно ограничить возможные значения стори-поинтов. Обычно используют числа Фибоначчи (слегка измененные: 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100) или степени двойки: чем больше соседние числа, тем больше интервал между ними. Иногда числа вообще заменяют на обозначения размеров одежды: S, M, L, XL, XXL.

Мы пользуемся картами для покера планирования. После обсуждения задачи команда разработки кидает и вскрывает карты.

Когда оценки расходятся, команда обсуждает причину расхождения. Возможно, кто-то не до конца понял, что нужно сделать. Или кто-то знает более простой способ реализации. Затем карты кидаются заново, пока оценки не совпадут. Некоторые команды договариваются о допустимости расхождения на одну ступень в обе стороны. Например, при раскладе на картинке выше итоговая оценка команды — 5.

Бывают менее однозначные ситуации.

Здесь потребуется дополнительная проработка задачи: уточнение требований у заказчика, разбиение крупной задачи на несколько частей. Когда команда не знает, как делать сложную задачу, она берет в спринт «ресёрч» — задачу на исследование. Как и любая работа в спринте, ресёрч оценивается в стори-поинтах. На выходе ресёрча — готовая к разработке задача (удовлетворяющая DoR).

Как оценивать задачи и планировать спринт?

Если вам ближе идея оценивать в часах, выбирайте часы. Помните только, что при переходе от отдельных задач к спринту важно не планировать впритык, иначе не будет запаса времени на непредвиденные моменты: неточности планирования, поддержку и исправление багов. Запас времени описывается понятием фокус-фактора команды.

Фокус-фактор — это доля времени, которая уходит на разработку запланированных задач, от общего рабочего времени. Например, фокус-фактор 0,5 означает примерно одинаковую долю условной разработки и поддержки. Хорошим считается значение 0,7.

В начале перехода на скрам в CityAds наша команда начинала с фокус-фактора 0,3. Больше половины рабочего времени уходило на исправления багов и поддержку.

Чтобы исправить ситуацию, всю поддержку пользователей пустили через систему тикетов и первую линию поддержки. Для решения повторяющихся однотипных запросов к разработчикам стали делать автоматические инструменты. Через несколько месяцев фокус-фактор вырос до 0,5.

Если считаете, что разная производительность разработчиков сводит на нет адекватность оценки в часах, выбирайте стори-поинты. Вас не будет вызывать технический директор и спрашивать, почему оценили задачу в 4 часа, когда ее можно сделать за 10 минут.

Планировать спринт в стори-поинтах помогает понятие производительности команды (velocity). Это сумма оценок в стори-поинтах выполненных в спринте задач. Если команда не успела в течение спринта полностью выполнить задачу, стори-поинты задачи потеряны.

Производительность команды меняется от спринта к спринту. На планировании можно учитывать среднее значение за последние несколько спринтов. Чем выше производительность, тем лучше. В погоне за показателями команда может завышать оценки, возможно, даже не осознавая этого. Чтобы избежать инфляции стори-поинтов, команда сверяется со шкалой при каждом оценивании задач.

Мы в CityAds в течение года после внедрения скрама пришли к совмещению двух методов оценки. Оценивали бэклог продукта в стори-поинтах, чтобы владелец продукта и заказчики знали «вес задач» и определяли приоритеты. На планировании разбивали задачи на подзадачи, назначали на исполнителей, исполнители давали оценку в часах. Пример:

Подзадачи
Проектирование — Коля (1 час)
Бэкенд — Коля (2 часа)
Фронтенд — Леша (4 часа)
Ревью — Рома (1 час)
Тестирование — Настя (2 часа)
Документирование — Коля (2 часа)
Выкладка — Рома (1 час)

После этого трекер рисовал диаграмму загруженности каждого участника. Мы понимали, как перераспределить работу, и успеем ли всё сделать:

Диаграмма сгорания, впихинг и скрам

На стендапах полезно визуализировать оставшийся объем работ в спринте на диаграмме сгорания («бёрндаун-чарт»). В идеале объем равномерно уменьшается каждый день. На практике, когда команда успевает выполнить все задачи, в конце спринта объем работы уменьшается быстрее, и график получается примерно таким:

Иногда получается, что график на диаграмме сгорания растет:

Объем работы вырастает, если команда неправильно оценила одну из задач. Или если произошел впихинг — неприятная история, когда приходит заказчик со срочной задачей. На переключение между задачами тратятся ресурсы, из-за откладывания задач нарушаются договоренности с другими заказчиками.

По скраму в течение спринта никто не может поставить команде разработки какие-либо задачи без ведома владельца продукта. По согласованию с владельцем продукта в спринт допустимо взять новую задачу, если выкинуть равноценную запланированную задачу, к которой команда не приступала.

Существует еще одна возможность, о которой любят говорить — остановка спринта. Решение об остановке принимает владелец продукта, если выясняется, что цель определена неверно, а новая цель не может ждать следующего спринта. Команда прекращает любую деятельность в останавливаемом спринте, как будто его и не было, и начинает планирование нового спринта.

Я работал с одно- и двухнедельными спринтами, и в таком режиме остановка была раз в год или два. Наверно, со спринтами длиною в месяц остановка бывает чаще.

Мы подробно рассмотрели две обязательных встречи по скраму — планирование и стендапы. В следующий раз поговорим об оставшихся двух — демо и ретроспективе.

26 января 2019 года, 18:03     промышленное программирование · скрам     Оставить комментарий

Есть другое гражданство, кроме российского

В последней передаче «Будем наблюдать» на Эхе смешной эпизод:

К. Ларина
— Вот я хочу добиться, что с Песковым случилось? Что у него якобы кто-то где-то опубликовал, что у Пескова есть другое гражданство, кроме российского. Французское гражданство.

А. Венедиктов
— [...] Нет у него французского гражданства.

К. Ларина
— Вот! Вот! У него в твиттере выложено фото с французским паспортом.

А. Венедиктов
— Нет у Пескова французского гражданства. Рассказываю. Нет.

К. Ларина
— А у тебя?

А. Венедиктов
— Нету. У меня вообще никакого гражданства, кроме российского нет.

Впомнился анекдот:

— Дед, люди говорят, у вас винтовка есть?
— Врут.
— Дед, люди говорят, у вас пулемет есть.
— Врут.
— Дед, люди говорят, у вас пушка есть.
— Врут.
— Дед, люди говорят, у вас танк есть.
— Врут.
— Дед, люди говорят, у вас атомная бомба есть.
— А вот чего нет, того нет.

16 января 2019 года, 22:32     цитаты · анекдот     Оставить комментарий

Фортепиано

Позавчера улетел из Кишинева. В зале вылета опять поставили рояль. Не очень хотелось кому попало давать мобильник для съемки ролика. Вместо этого записал игру на своем инструменте. Это хорошо известная композиция:

А это новая композиция. С помарками, но зато сейчас, а не еще через три года:

9 января 2019 года, 21:38     музыка · lytdybr     Комментарии (1)

Введение в скрам

— Проверено. Дать гению пять человек в подчинение, поставить четкую задачу и попросить организовать работу. Через неделю гений сам всё про себя поймет.
— Гений не поймет, он объяснит, какой народец некондиционный, читайте всё в блоге гения.

Баш

В прошлый раз я уже упоминал четыре принципа аджайл-манифеста по гибкой разработке. Скрам — один из многих вариантов гибкой методологии. За полным описанием скрама обращайтесь к двадцатистраничному руководству. Но это не учебник, а справочник. Он не очень подходит для начального знакомства. Я кратко перескажу основные принципы и поделюсь практическими соображениями о работе по скраму.

Зачем нужен скрам

Скрам нужен, чтобы не получилось как в эпиграфе :-) Скрам — это набор правил для итеративной разработки программного обеспечения. Скрам направлен на повышение прозрачности рабочего процесса, выявление и устранение его недостатков. Существуют и другие способы достижения того же. Но скрам превращает искусство управления проектами в доступное ремесло.

Команда и спринты

Рабочая единица по скраму — скрам-команда. Она состоит из трех частей:
  • команда разработки — профессионалы, совместных умений которых достаточно, чтобы делать продукт;
  • владелец продукта — представитель бизнеса, знает текущее направление развития продукта, определяет приоритеты разработки;
  • скрам-мастер — проводит встречи, следит за соблюдением процесса, напоминает правила участникам, помогает улучшить рабочий процесс.

В команде разработки у всех одинаковая роль — «разработчик». У каждого разный опыт и уровень экспертизы, и это влияет на конкретный вид выполняемой работы. Но ответственность за результат у команды общая.

В идеале в команде разработки собраны все специалисты, необходимые для работы над продуктом: аналитики, дизайнеры, программисты, тестировщики. Взаимодействие в команде плоское. Размер команды не должен быть слишком большой, скажем, 5 — 9 человек, чтобы избежать излишних накладных расходов на взаимодействие.

В скраме нет менеджеров. Традиционные обязанности менеджера частично выполняет скрам-мастер, частично — сама команда разработки. Каждый участник достаточно взрослый, чтобы работать без напоминаний со стороны. Команда самостоятельно координирует свою работу.

Рабочий процесс по скраму делится на итерации — спринты. Команда разработки создает и в конце спринта поставляет заказчику некоторую завершенную функциональность — инкремент продукта.

Вот обязательные встречи в течение спринта, без которых у вас не будет скрама:
  • планирование,
  • ежедневный скрам («стендапы»),
  • демонстрация новой функциональности заказчикам и пользователям
  • ретроспектива.

Планирование

На планировании присутствует команда разработки и владелец продукта. Владелец продукта описывает потребности бизнеса на следующий спринт. Команда разработки определяет, успеет ли выполнить соответствующие задачи, и выбирает способ реализации. Также владелец продукта и команда разработки выбирают цель спринта.

Вот что написано о цели в руководстве:

Цель Спринта – это установленный для Спринта ориентир, который достигается посредством выполнения части Бэклога Продукта. Цель Спринта формулируется во время его Планирования и объясняет Команде Разработки, для чего создается Инкремент.

Цель Спринта обеспечивает Команде Разработки достаточную гибкость касательно объема функциональности, разрабатываемой в рамках Спринта. Цель Спринта воплощает важную смысловую нить, которая не только связывает выбранные элементы Бэклога Продукта, но и служит основанием для командной работы.

Цель связана с наиболее приоритетной задачей, но не тождественна ей. Польза выбора цели в дополнительной синхронизации ожиданий. Например, на планировании выясняется, что команда разработки скорее всего не может «сделать фичу и выложить в бой», потому что другая команда должна доработать АПИ, админы — запустить новый сервис и т. д. Но по-другому сформулированная цель — «сделать фичу и продемонстрировать на тестовом окружении» — достижима, и на текущий спринт устраивает заказчика, который сам хочет всё посмотреть в действии до выкладки.

У спринта должна быть только одна цель. Иногда после начала спринта возрастает оценка объема работ. В таких обстоятельствах команда разработки по согласованию с владельцем продукта жертвует менее приоритетными задачами, чтобы достичь цели. Если у спринта несколько целей, команде разработки непонятно, ради чего и чем жертвовать.

В следующий раз я расскажу о стендапах и о работе с задачами по скраму.

5 января 2019 года, 22:35     промышленное программирование · скрам     Оставить комментарий

туда →

Поделиться
Записи

Подписка на RSS (?)