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

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

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

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

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

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

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

Баш

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для быстрой обратной связи владельцу продукта и заказчику о сложности задач. У нас в 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Фортепиано ★

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

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

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

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

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

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

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

Рабочая единица по скраму — скрам-команда. Она состоит из трех частей:

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

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

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

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

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

Вот обязательные встречи в течение спринта, без которых у вас не будет скрама:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

← сюда туда →