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

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

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     промышленное программирование · скрам     Оставить комментарий

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

Представьте, что вы едете с Войковской на Речной вокзал. Это на север, дальше от центра. Спускаетесь по лестнице в потоке других пассажиров. На платформу прибывает поезд. Нужно ли на него поспешить? Или вам в другую сторону?

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

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

Старые указатели не имели таких проблем. Сразу ясно, что в центр — 1 путь, направо.

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

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

18 декабря 2018 года, 23:22     дизайн · фото     Оставить комментарий

Связь с водителем о выходе

17 октября 2018 года, 23:30     идиотека     Оставить комментарий

Пятиминутка паранойи

Только что ходил в хроме по сайтам и заметил, как мелькнул индикатор работы камеры. Может телеметрия Windows 10. Может еще что.

Пришлось заклеить.

А вы знали, что опсосы (сотовые операторы) из смс составляют ваш профиль и продают посторонним компаниям? Например, вам приходит смс о переведенной на карту зарплате. Вы радуетесь. А в это время опсос распарсил сообщение и обновил в профиле величину доходов. Это делается элементарно, потому что у опсоса есть шаблон сообщения. Стоимость отправки сообщения по согласованному шаблону ниже, чем стоимость отправки произвольного сообщения. Банки согласовывают и платят меньше.

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

15 сентября 2018 года, 00:29     lytdybr · опсосы     Оставить комментарий

Популярные песни сегодня и 20 лет назад

Рик Беато сделал два микса из 20 песен, популярных сегодня и в 1998 году.

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

30 июня 2018 года, 00:57     музыка     Комментарии (2)

Серебристые облака

Давно мечтал увидеть серебристые облака. Один раз вроде как видел и сфотографировал. Но облака были не очень хорошо видны. И фотоаппарат был так себе. А теперь получилось. Вот они:

Москва, прошлая ночь, после 1:00.

28 июня 2018 года, 22:44     фото · lytdybr     Оставить комментарий

туда →

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

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