Пишу про разработку вообще и в частности про: JavaScript, HTML5, CSS3, AngularJS, ReactJS, Agile, Bitcoins

Как и зачем писать пользовательские истории – user stories

В предыдущем посте об оценке задач и как может имеет смысл от этого отойти, я упомянал “юзер сторис” или пользовательские истории (user stories). Давайте сегодня поговорим об этом подробнее, но без ухода в дебри.

Начнем с базового понятия – пользовательские истории пришли для того чтобы заменить список требований. А почему agile именно так подходит к решению? Чем список требований помешал, ведь в итоге именно его и нужно выполнить, разве не так? Совершенно верно, возразить тут нечего, все именно так и обстоит и проблема совершенно не в списке задач.

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

dilbert-agile-scrum

Давайте разберемся в ситуации.

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

  • Хотим начать продавать товары “бандлами”, то есть пользователь может найти товар и ему предлагается добрать в корзину товары из смежной категории
  • В стране меняется валюта (проходит деноминация) и нужно поддержать это на сайте. Нужно писать обе цены вместе: “цена до” и “цена после”
  • На сайт заходят много посетителей с мобильных телефонов, явно выделяются пользователи с андроидами, можем ли мы как-то это использовать? (Намек на PWA)
  • и т.д

Это нормальные задачи, которые может ставить бизнес. Явно, что задачи связаны с техническим решением, поэтому конечно они приходят в R&D и все они сформированы как пользовательские истории. В чем преимущество сторон в таком подходе?

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

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

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

Что должны включать в себя пользовательские истории (п.и.)?

user-stories

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

Простой шаблон п.и. будет следующим: <Кто (тип пользователя)> нужно (некое действие) <Что>, <Почему>. Несколько примеров историй с некоего сайта путешествий:

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

Первые три истории отвечают только на два вопроса: Кто и Что. Этого вполне достаточно, дополнительное пояснение не требуется. В последней же истории есть пояснение, для того чтобы было ситуация стала более понятной. Ведь программисту может быть не очевидно, например он часто не летает в одно и то же место и функция повторного заказа ему никак не поможет. Вместе с тем такое объяснение поможет ему понять задачи некоторых пользователей приложения.

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

  • Только пользователь класса “премиум” может отменять в день заезда без штрафа.
  • Любой другой пользователь при отмене в день заезда платит 10% штраф от суммы заказа.
  • После отмены пользователю должно быть отправлено эл. письмо с подтверждением.
  • Отель так же должен получить уведомление по эл. почте.

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

Ссылки по теме:

Поделиться:

Больше не назначаем сроки

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

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

Доклад на английском, но ниже я приведу свой вольный пересказ.

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

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

is-no-estimation-for-real

Agile говорит о том, что нужно выработать подход, при котором мы можем работать в равном темпе над задачами. Однако, в тот момент, когда мы начинаем ставить сроки – темп нарушается. Эти два подхода противоречат друг-другу.

Даже если мы немного “сумничаем” и скажем, что сроки такие-то, но у них есть 20% шансов исполниться – это опять ничего не значит. Если дату мы как-то попытались угадать, то что с процентами? Это же тоже некая догадка. Чем же две догадки лучше чем одна? С тем же успехом можно играть в казино.

Agile снова пришел на помощь и предложил использовать “стори” (storie). Стори – это описание некой истории (сценарий), которая описывает некое поведение пользователя, которое приводит к получению некой ценности. Неправильный подход к стори – это описание запрашиваемого функционала.

Однако, только стори это не достаточно. Менеджерам нужна хоть какая-то привязка ко времени, поэтому были введены “стори-пойнтс”, которые должны были по идее обозначать сложность той или иной задачи, однако они таки привязаны ко времени. 1 с.п. это примерно пол дня, 2 с.п. это день и так далее. Мы снова занимаемся оценкой времени.

Как альтернативу с.п. можно предложить не оценку цифрами, а использовать более общие понятия: Trivial, Easy, Normal, Hard, Herculean, Don’t Know.

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

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

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

А теперь самое главное – что же делать, если не оценивать? Ведь ты должен объявить сроки клиенту, есть выставки, конференции, к которым нужно успеть иначе в следующем году у компании может не быть заказчиков. Да, безусловно следовать срокам необходимо, только назначать их нужно не в момент расписывания стори, тут можно только примерно понять направление, а на 3-й, 4-й итерации. При таком подходе достаточно только считать количество стори, не назначая им стори-пойнтс вообще. В итоге дата релиза будет видна вот из такого графика:

no-estimates-flow-diagram

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

Тут может возникнуть вопрос – а как же поступать с большими задачами? Стори-пойнтс как раз и говорят о том, что задачу нужно разбить. Однако, дело же не в том сколько очков мы дали той или иной задаче, дело в том можем ли мы сами себя честно спросить “Нужно ли разбить эту задачу?” и так же честно ответить.

Тут стоит добавить, что однозначно сказать – что это единственно правильный путь не получится. Вместе с тем, мне подход нравится и точно хочется его протестировать.

Ссылки по теме:

Поделиться:

Необязательный запрос к свойствам объекта

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

Предположим у вас есть некий объект, к свойствам которого вы обращаетесь. Если свойства нет, то мы получим “undefined”, однако, если мы запросим по цепочке еще одно свойство, то словим ошибку. Стандартная ситуация, ничего нового. Нужно каждый раз проверять есть ли искомое свойство.

Кстати, в качестве альтернативного решения можно использовать proxy, я об этом уже писал – Магический метод для всех “get” обращений к объекту. Только proxy нельзя написать средствами ES5, а это уже существенное ограничение.

Сегодня есть другое предложение, которую, кстати можно начать использовать: “?.”

js-optional-chaining

Звучит интересно и само предложение уже перешло на первую стадию принятия в стандарт языка.

Ссылки по теме:

Поделиться:

О профессии в IT – вас нанимают для решения проблем

Я уже публиковал видео Илая – Самообразование для начала IT карьеры, сегодня продолжим. Да, видео у него получаются длинные и (обожемой) на английском, но он выдает много интересных и (как следствие) циничных мыслей об IT индустрии и о карьерном пути в этой индустрии.

Вам платят за решение проблем.
Ваши навыки интересны только в контексте проблем, которые есть у компании. Не важно сколько сертификатов у вас есть, не важно есть у вас высшее образование или нет. Если у компании нет проблемы, которую ваши знания и навыки могут решить, то вы не будете наняты.

Интересный ответ начинается на 38 минуте: How can I get a networking job with a CCIA? Any additional skills required?

Как мне получить работу в области сетевых коммуникации с CCIA (сертификация в области компьютеров и коммуникации)? Нужны ли дополнительные навыки?

Краткое содержание ответа в свободном изложении:
Профессионалы решают проблемы. Если вы хотите зарабатывать своими IT навыками, вам нужно найти компании, у которых есть проблемы и прийти к ним со свои решением. Если у вас нет нужных навыков для решения, то их вам и нужно подучить и, возможно, получить на это сертификаты. Собственно, в этом и есть вся суть решения.

Друг Илая приехал из Индии учиться в Штаты. Паренек явно не из бедной семьи, потому что в Штатах нет бесплатного образования. Он выучился, у него все в порядке – работает, зарабатывает достойно. Достаточно долго к этому шел, но теперь все хорошо. Однако, интересный момент заключается в том, что у его друзей ситуации лучше. То есть он выучился, получил ученые степени, работает по профессии инженером, годы опыта, а ситуация его друзей лучше, хотя у них нет никакого образования.

Чем они таким занимаются? Они держат сендвич-бары. Дело в том, что они приехали в США не для того чтобы учиться, они приехали чтобы работать на любой работе, которая платить больше всего денег, готовые начать с чего угодно. Если им предлагали быть уборщиком – никаких проблем. Уборщиком в офисах? – Там платят больше? – Да! Тогда я буду уборщиком в офисах. И так далее.

Разумеется вначале друг Илая зарабатывал больше, однако потом все изменилось. Его знакомые постепенно продвигались и открывали небольшие фирмы по уборке, маленькие отели, сендвич бары – все это зачастую в не самых благополучных районах. Однако, в этих районах тоже живут люди, которые после трудового дня хотят купить поесть и пойти домой спать. И никого не волнует откуда у них деньги – кражи, наркотики, вымогательство. Его купюры такие же зеленые.

Путь к успеху – это найти то, что нужно людям и решить их проблему за них. В этом суть любой профессии.

Поделиться:

Firefox работает над инструментами для разработчика

Интересный список инструментов для разработчика от Firefox.

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

Итак, что же у нас есть в Firefox’е:

  • CSS Grid Inspector
  • CSS Animation Inspector
  • Developer Toolbar
  • Responsive Design Mode
  • Rulers
  • Eyedropper
  • Screenshot Tool
  • Measure Tool
  • Dark, Light or Firebug Theme

Что тут сказать – список весьма радует. Можно пробовать 😉

Ссылки по теме:

Поделиться:

Создаем массивы в js

Разумеется мы все в крусе, что массив в js создается вот так:

Какие могу быть вопросы к этому синтаксису, все просто и доступно для каждого. Однако, это не всегда самый удобный синтаксис. Нам, например может понадобиться создавать массив “на лету”, с определенным количеством элементов. Понятно что можно сделать ровно тоже самое:

И пожалуйста – у вас в руках массив 10 элементов. Хм-м-м, круто конечно, но разве это самый “красивый” подход? js очень похож на функциональный язык программирования. Почему очень похож, потому что в некоторых местах, все-таки не дотягивает 🙂 Ну а раз похож, то хотелось бы и с массивами работать функциональными методами, а для этого нам нужно создавать массив с нужным количеством элементов без цикла. И вроде бы даже есть такая возможность еще с давних пор:

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

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

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

Аллилуя, мы стали на шаг ближе к функциональному программированию!

Поделиться:

Давайте наймем дизайнера

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

Давайте разбираться.

looking-for-designer

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

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

При таком раскладе не может быть чтобы все данные были доступны сразу. Значит нужно это передать в интерфейсе. То есть не может быть “ползунка”, который бы легко (и моментально) менял бы резолюцию. При таком подходе при каждом сдвиге придется все блокировать и ждать ответа от сервера, чтобы отобразить изменения. Имеет смысл поступить как гугл аналитикс – добавить кнопку apply в выборе дат для графика.

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

Это только одна достаточно узкая проблема, их на самом деле значительно больше. И решения для них приходят только с опытом, потому что все это ни разу не очевидно “при первом подходе к снаряду”. Если дизайнер не сделает свою работу как надо, то потом программистам придется доделывать за него.

А теперь небольшое послесловие.

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

Поделиться:

Тест-драйв библиотеки vue.js

При всех плюсах и популярности библиотек React и Angular, у них есть определенный минус для небольших проектах. Это этап сборки. Разумеется его можно обойти и не использовать webpack или любой другой таск-менеджер. Например, компоненты реакта можно описывать объектами и не использовать jsx. Но это как бы не так удобно. С тем же успехом код на тайпскрипте для ангулара можно транспалировать прямо в браузере, но наверное не стоит так делать.

В общем я о чем – пришла пора копнуть чуть глубже в библиотеку vue.js. Ее очень просто запускать прямо в браузере, что удобно. Ну и популярность все больше и больше – пора посмотреть что там такого интересного. Проект будет очень простой – только для того чтобы протестировать базовый функционал. Будем использовать открытый API гитхаба.

github-api-vue

Весь код будет в одном файле – index.html – компактно и сурово. Основной костяк файла:

Как видите – все библиотеки из CDN, ничего локально не держим.

Теперь основной код:

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

Поделиться:

Просто используй кнопки

Отличный совет! Don’t mess with native elements. Браться фронтендеры, давайте быть проще и использовать то что уже и так работает 🙂

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

Поделиться:

Как определить насколько верить

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

Ноги растут вот от этой небольшой заметки, с которой я чрезвычайно согласен How do you determine how much you can trust a person in business?. Абсолютно такая же проблема стоит и в техдепе – Как нанять программиста, которому можно доверять. А то ведь программисты же могут так напрограммировать, что потом никто не разберет.

gears

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

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

А вот как уже заниматься распределением информации – уже другой вопрос. Лично я верю в Agile, стендапы и скрамбоард. Об этом поговорим в другой раз.

Поделиться: