Строгая типизация: Typescript, Flow, Javascript — быть или не быть?
Согласно опросу Global Developer Hiring Landscape Survey report 2017, проведенному Stack Overflow, JavaScript является самым востребованным языком программирования среди веб-разработчиков по всему миру. С момента своего создания в 1995 году JavaScript зарекомендовал себя как оптимальный язык работы с интерфейсами для браузеров и веб-страниц. Благодаря богатому набору библиотек он также обеспечил новые возможности для визуализации. Angular[.js], Ember.js и другие подобные фреймворки предоставили JS необходимую гибкость и возможности.
Следует помнить, что JavaScript разрабатывался как клиентский язык для масс, поэтому его функциональность не такая разнообразная, как у других языков. В нем не хватает множества важных функций, необходимых для адекватного написания и поддержки массивных приложений. Чтобы справиться с этой проблемой, веб-разработчики создавали такие инструменты, как eslint для сканирования кода.
Статистика GitHub за последние три года также показала убедительный рост числа проектов, в которых используется статическая типизация JavaScript. Даже в других языках разработчики предпочитают использовать статическую типизацию вместо динамической.
Рекомендуем курс по теме
Java Enterprise advanced
История JavaScript
Mosaic от NCSA был первым общепризнанным веб-браузером еще в 1993 году. А в 1994 Netscape представила свой популярный запатентованный браузер, получивший название Netscape Navigator, который считался единственным надежным вариантом в 90-х годах. Netscape наняла Брендана Эйха в 1995 году, и в том же году им был основан JavaScript. По словам Эйха:
Допустим. Мы находимся в сложном положении, когда большинство продвинутых языков переходят к функциональному программированию, к строгой и статической типизации.
JavaScript динамически типизированный язык и позволяет объявлять функции, объекты и переменные без объявления типа. Хотя эта возможность и упрощает использование языка, это не всегда удобно. Чтобы помочь справиться с такими проблемами типизации языков программирования, и появлялись TypeScript и Flow.
Цель статьи – выделить плюсы и минусы статической типизации в контексте разработки на Javascript. В дополнение к этому мы рассмотрим TypeScript и Flow, а также сравним их, чтобы в конце этой статьи вы могли бы решить: стоит ли переносить свои проекты на строгую типизацию вместо того, чтобы полагаться на «ванильный JavaScript».
Зачем это нужно
Вспомните Coffeescript, который был чрезвычайно популярен. Но, хотя я очень уважаю его изобретателя, факт заключается в том, что у этого языка были некоторые серьезные проблемы (почитайте соответствующую ветку переписки на ycombinator). Затем появился ES6.
Из-за необходимости поддерживать старые браузеры и для интерактивного выхода функционала ES6 у нас стали появляться транспайлеры, такие как Babel. Coffeescript имеет много общего с ним и тоже является транспайлером.
Инструментов CoffeeScript и Babel было недостаточно, что подтолкнуло сообщество в строну TypeScript и Flow. Взгляните на тренды (за Flow не ручаюсь, думаю, что возникла контекстуальная ошибка, он должен быть в несколько раз меньше).
Статистика Google Trends
TypeScript – это язык программирования с открытым исходным кодом, разработанный Microsoft, является суперсетом JS. По другую сторону – Flow, который разработан Facebook.
На практике Flow сравнительно проще, чем TypeScript, и его можно постепенно включить в файл проекта, настроить проверку типа в нем, просто добавив // @flow в начале файла. Все расширения основываются на комментариях.
Конечно, и TypeScript, и Flow полезны. Мы, в свою очередь, развернем сравнение с точки зрения разработчика.
TypeScript
TypeScript, как видно по названию, умеет проверять типизацию. Он принимает на вход (.ts) и генерирует (.js) на выходе. Существует флаг компилятора nolmplicitAny, который, если включен, потребует от вас указать типы и возвращаемые значения для всех используемых аргументов и функций.
Активация noImplicitAny может иметь серьезные последствия для вашей работы, особенно при работе с малоизвестными сторонними модулями. Помимо того, я обратил внимание, что при использовании noImplicitAny я стал писать часть кода специально, чтобы сделать довольным компилятор TypeScript.
В дополнение ко встроенной демонстрации ошибок до компиляции, при использовании TypeScript с IDE на подобии WebStorm перед вами откроется перекрестная навигация и более точное автозаполнение.
Flow
Если пользуетесь Flow, то обратите внимание на пакет для Atom Nuclide.
Все же, кто на вершине?
Независимо от того, кто является вашим фаворитом: TypeScript или Flow, проверка типов – это будущее JS. Примечательным различием между Flow и TypeScript является то, насколько плавно они могут быть интегрированы в текущие проекты. В то время как TypeScript значительно сложнее, Flow относительно легко внедряем, предупреждая по ходу базовой интеграции, что проверяет меньше вашего кода, как и ожидается. Если вы пишете на Angular, то выбор у вас небольшой.
В дополнение ко всему, есть множество других аспектов, о которых стоит задуматься. В сочетании со статической типизацией, TypeScript также нацелен на предоставление гибкого набора инструментов, языковой поддержки рефакторинга и автокомплита.
Преимущества использования статической типизации
Обнаружение ошибок на лету
С помощью тестирования типов легко проверить работоспособность кода еще до его выполнения.
Следующие операции действительны в JavaScript, но вы получите бонус в typescript, например:
static.ts hosted with ❤ by GitHub
Более точная передача смысла функции
Типы действуют как активная, живая документация для автора и его тим-мейтов. Благодаря статической типизации вам легче понять цель функции, тип данных, которые он принимает в качестве входных, или что ожидать взамен.
Упрощение отладки ошибок
Нам лучше проверить, что s – строка, а y – регулярное выражение. Без статических типов вам понадобится дополнительный код. А без него нас могут ждать сюрпризы во время выполнения.
Различие между данными и поведением
Поскольку статические типы четко различают данные и поведение, это позволяет разработчикам более уверенно прогнозировать свои ожидания и более точно объяснять цель. Это не только смягчит давление и двусмысленность, но также добавит ясности и прозрачности во время кодинга.
pressure.ts hosted with ❤ by GitHub
Сокращение вероятности возникновения ошибок во время выполнения
Ошибки типа во время выполнения становятся катастрофическими, на чем и живут такие сервисы как Sentry.
Например, приведенный ниже код будет работать в JavaScript, но будет отмечать ошибку компиляции: строка не существует.
helloworld.js hosted with ❤ by GitHub
Инструмент доменного моделирования (если использовать IDE)
Одна из лучших особенностей статических типов. Если вы работали в Visual Studio на языке подобном C#, вы поймете, о чем я. Это реально уменьшает административную сложность. Пример (у вас реально получится работать с субдоменами):
Недостатки использования статических типов
Проверка статического типа не лишена недостатков. Мы пройдемся по некоторым недостаткам, которые заслуживают внимания, прежде чем вы сделаете выбор в пользу статической типизации для своих проектов.
Одна из проблем – дополнительная стоимость обучения инженеров и затраты на сопровождение типизированного кода.
Одна из причин, по которой JavaScript настолько популярен среди веб-разработчиков, заключается в его простоте и в том, что им не нужно добираться до полной системы типов перед началом работы. Это особенно важно для начинающих программистов. Включение типов в процесс скорее запутает их и сделает процесс обучения более сложным, чем ожидалось.
С использованием TypeScript или Flow общий размер кода увеличится на 30% как минимум. Плотность кода снижается. Это как Ruby или Java 
Использование статических типов в JavaScript — Да или Нет?
Выбор сводится к личным предпочтениям и типу проекта, над которым вы работаете. В заключение вы можете выбрать проверку статического типа, если:
Если ваша команда работает над проектом с большой базой кода, TypeScript поможет обойти множество ошибок. А лучше, чтобы эта база кода сейчас была маленькой или вообще равнялась нулю, тогда вы сможете сократить затраты на интеграцию.
Чем больше людей, тем сложнее контролировать, что они пишут. Вам легче переложить часть боли машине.
Используйте TypeScript, если вы считаете, что в будущем потребуется большой рефакторинг. Не взваливайте на себя ненужное бремя, если имеете дело с краткосрочным заданием.
Строго типизированные языки, такие как TypeScript, – это прекрасный выбор, если вы или ваши товарищи по команде уже знакомы с типизированными языками, такими как Java или
C# обучением. Так как TypeScript был разработан тем же разработчиком, который изобрел C#, оба эти языка имеют похожие элементы.
TS+ES6 возможно перевести на ES5 с помощью TS-транспайлера. Вы сможете отказаться от babel.
Для тех, кто использует Angular 2+ или любой другой фреймворк, предлагающий TypeScript, следует попробовать статическую типизацию.
В заключение
Как только вы полноценно перейдете к статической типизации, то вряд ли вернетесь назад. Однако все это зависит от требований и объема проекта, над которым ведется работа. Не стесняйтесь поделиться своими мыслями, оставляйте комментарии. Мы будем рады услышать ваше мнение :).
Олександр Книга, Software Engineer в Weblab Technology
Дмитрий Дмитриенко, Brand Specialist в Weblab Technology
Шармин Хаят, Data Specialist в Weblab Technology
User flow: как создаются популярные приложения и сайты
Я – Максим Скворцов, UX/UI-дизайнер Omega-R, международной компании по разработке и интеграции IT-решений. Я занимаюсь проектированием и визуализацией интерфейсов мобильных и веб-приложений.
На базе своего опыта в сфере информационных технологий и экспертизы компании хочу поделиться своим видением и подходом к применению одного из инструментов проектирования дизайна – user flow. Почему его используют и почему он является ценным помощником для дизайнера? Как может выглядеть user flow и как его создать?
Что такое user flow?
Ситуация: Вы нашли новое приложение, которое обещает делать именно то, что вы хотите, и вы нетерпеливо нажимаете кнопку загрузки. Через мгновение приложение запускается, и вы готовы приступить к работе. Но сначала вам приходится зарегистрировать учетную запись, затем дать приложению разрешение на доступ к вашему местоположению и отправлять вам push-уведомления, после этого необходимо пролистать весь туториал, соглашение об использовании персональных данных и т.д. Горькая правда заключается в том, что пользователь при таком взаимодействии скорее закроет и удалит приложение, каким бы функциональным оно ни было. Вот почему так важно оптимизировать путь пользователя в приложении с помощью user flow.
User flow – это визуальное представление последовательности действий, которые пользователь выполняет для достижения своей цели. Может охватывать как какую-то отдельную функцию, так и полностью весь продукт.
Чтобы составить последовательность, необходимо провести исследование и ответить на три базовых вопроса:
User flow – это история о пользователе
User flow позволяет взглянуть на взаимодействие пользователя и приложения глазами пользователя.
Если полноценные сайты предоставляют достаточно места для творчества, то разработка мобильных приложений всегда заставляет искать баланс между функциональностью и удобством использования. С одной стороны, пользователи должны легко получать доступ к наиболее важным функциям с главного экрана приложения без множества дополнительных шагов, легко нажимая на большие кнопки. С другой стороны, когда мы говорим о приложениях, речь идет не только о кнопках.
Допустим, вы создаете приложение для музыкального плеера. С одной стороны, вы хотите, чтобы пользователь мог воспроизводить свои любимые песни одним касанием. С другой стороны, им нужен способ определять избранные треки, искать новую музыку (возможно, в нескольких местах), контролировать громкость и настраивать эквалайзер, сортировать музыку, шаффлить список, читать биографию исполнителя, делать покупки и иметь под рукой все остальные функции плеера. Пользователю захочется делиться рекомендациями и плейлистами в соцсетях и видеть, что слушают их друзья.
Если пользователь сёрфит в интернет-магазине во время прослушивания плейлиста и решает пропустить текущий трек, ему не нужно закрывать магазин и переходить обратно через несколько шагов меню — доступ к этой кнопке пропуска должен находиться на том же экране.
Создать максимально функциональное приложение не так сложно, но собрать все это в наиболее привлекательном и комфортном для пользователя виде – гораздо более сложная задача. Если компания-разработчик не справилась с ней и не создала приложение интуитивным, то оно так и останется лежать невостребованным в сторах. Пользователю всегда легче загрузить более понятное приложение, чем тратить время на чтение мануалов и туториалов или без конца бродить по нему в поисках смысла.
Роль дизайнера
Представьте, что вы работаете над продуктом в одной команде, где есть Project Manager, Backend- и Web-разработчики. Предположим, есть даже какое-то техническое задание от заказчика, которое написано достаточно подробно и добротно. Осталось просто взять и сделать продукт.
Что же должен сделать дизайнер? Если судить по ожидаемому результату – нарисовать все нужные экраны так, чтобы конечный продукт был удобным и красивым, и отдать разработчикам.
В целом – да. Но есть подводная часть айсберга. Там скрыто множество вещей, о которых мало кто задумывается. Все мы любим удобные и интуитивно понятные интерфейсы, любим, когда все работает логично и результат любого взаимодействия предсказуем. И чтобы все это было, нужно тщательно проработать каждую деталь.
Как раз для этого нужен user flow – он поможет определить пути достижения пользователями цели, вычислить позитивные и негативные сценарии на выбранном пути достижения цели наших потенциальных пользователей. Он дает возможность понять, все ли процессы в продукте имеют логическое завершение и выстроены эффективно, так, чтобы пользователь тратил минимум времени для достижения цели.
Важно: чем больше проблема и чем больше функций, тем больше сценариев необходимо проработать.
Таким образом, user flow помогает исключить распространенную ошибку, когда создают список требуемых функций и на основе них просто проектируют интерфейсы. Такой подход, разумеется, возможен. Но это может привести к тому, что сценарии взаимодействия с интерфейсом заставят пользователя проходить слишком много шагов для выполнения простых операций.
Ценность для продуктовой команды
User flow помогает на верхнем уровне согласовывать с заказчиком сценарии для работы продукта или функционала. Особенно тогда, когда у заказчиков нет конкретных и детализированных требований (когда они сами плохо понимают, чего они хотят). В этом случае user flow может дать какое-то направление для заказчиков, и они уже подскажут, в каких местах они хотели бы изменить логику, предоставив свою обратную связь – либо в виде комментария, либо самостоятельно скорректировав текущую схему. Несмотря на то что создание user flow кажется сложным и длительным по времени процессом, он помогает исключить множества ошибок при разработке продукта. С его помощью, как говорится, «медленно запрягают, но быстро едут».
Для PM на основании user flow удобно заводить задачи для разработчиков – достаточно очевидно и прозрачно, какие изменения необходимо внести в текущую логику или какие новые функции будут добавлены.
Тестировщики могут готовить use cases (тесты) и чек-листы, поскольку они в удобном формате демонстрируют пользовательские сценарии.
User flow очень полезен для команды, особенно когда состав команды достаточно большой – не нужно каждому отдельно объяснять логику работы. Таким образом, user flow вовлекает в процесс проектирования заказчика, мотивирует команду, направляет весь рабочие процессы в единое русло, поскольку каждый член команды видит картинку в целом.
Ценность для заказчика
Пользователь – это почти всегда тот, кто покупает или пользуется продуктом или услугой или потенциально готов это сделать. От того, насколько комфортно выстроен этот процесс, зависит его лояльность пользователя. Каким бы способом он ни приобретал продукт или услугу – в офисе, по звонку, с выездом специалиста на дом, через сайт, через приложение – путь приобретения и пользования должен быть максимально простым.
Что касается сайтов и мобильных приложений, user flow – это то, как пользователь будет перемещаться по контенту (тексту, картинкам, аудио, видео). User flow включает в себя определение приоритетов в требованиях к контенту, барьеров в навигации и поиск наиболее быстрых и безболезненных маршрутов к целевому действию. По сути user flow непосредственно связан с воронкой конверсии, и IT-компания, использующая user flow, автоматически разрабатывает эффективную воронку конверсии или оптимизирует существующую воронку.
Итогом оказанной ему помощи в достижению цели, воплощенной в дизайне благодаря user flow, является счастливый и заинтересованный пользователь. А счастливый и заинтересованный пользователь означает большее количество проведенного времени в приложении или на сайте, более низкие показатели отказов, повышенные коэффициенты конверсии и улучшенный пользовательский опыт работы.
Таким образом, user flow напрямую влияет на успех сайта или мобильного приложения и прибыль заказчика. В центре дизайна становится пользователь, и это полностью совпадает с принципом клиентоориентированности бизнеса.
Как всё выглядит?
Я нигде не видел четко прописанного стандарта, в соответствии с которым происходит проектирование user flow. Представление user flow может быть разным и зависит от того, насколько детально надо все проработать. Важно достичь вашей цели как дизайнера – чтобы заказчик и продуктовая команда понимали, каким образом пользователь получит доступ к той или иной функции, где они будут находиться и как они будут работать.
User flow может быть представлен в виде комбинаций из:
Пусть нашим пользователем будет молодая мама, цель которой – купить многофункциональный кухонный комбайн. Один из сценариев последовательности шагов может выглядеть следующим образом:
Task flow
Task flow – это простое представление того, что пользователь делает на каждом шаге для выполнения цели или задачи. По сути это классическая блок-схема, определяющая эту последовательность.
В данной схеме не отражены условности и прочие вопросы, которые необходимо проработать. А что будет, если по результатам поиска ничего не нашлось? А что будет, если оплата не прошла? Здесь представлены лишь общие этапы, которые могут предполагать множество действий: например, поиск может быть расширенным с множеством фильтров, путь оплаты зависит от выбора инструмента оплаты и т.д.
Для составления схемы можно пользоваться списком необходимых и достаточных элементов из классических блок-схем, представленных на картинке, или использовать стандарт BPMN – он ориентирован как на технических специалистов, так и на бизнес-пользователей.
Wire flow (lo-fi)
Wire flow – это объединение блок-схемы и wireframes. Wireframe – это низкодетализированный набросок дизайна экрана, упор в котором делается не на визуальную составляющую, а на расположение элементов, структуру и содержание экрана.
В wire flow вместо элементов блок-схемы представлены схематичные макеты экранов, с которыми взаимодействует пользователь на пути достижения цели. Не нужно зацикливаться на визуальных деталях и отрисовывать каждую кнопку и иконку. Чаще всего акцент делается на элементах навигации в дизайне каждой отдельной страницы.
Wire flows особенно удобны при создании мобильных экранов: относительно небольшие размеры мобильных экранов легко используются для замены более абстрактных элементов блок-схем. Wire flows комфортны для формирования и уточнения технического задания, но едва ли подходят для этапа тестирования.
Пример такой схемы:
Screen flow (hi-fi)
Здесь речь идет о детально проработанных экранах, которые понятны как пользователям, так и разработчикам. Обычно делается акцент на элементах навигации и некоторых нюансах поведения. Его можно использовать как регламентирующий документ для утверждения дизайна макетов.
Screen flow можно по сути назвать прототипом, если ему добавить интерактивность. Его особенностью является высокая точность или идеальное пиксельное соответствие: в нем учитывается физический размер экрана и представляются все визуальные и типографические детали продукта. Элементы screen flow – это фактически макеты экранов готового приложения.
Заказчик приложения может быть приятно удивлен скоростью разработки, когда вы покажете ему screen flow, и может подумать, что разработка близка к завершению. Мы, как правило, заранее сообщаем заказчику, что за screen flow не стоит никакого кода, но наличие screen flow дает заказчику гарантию, что за отлично подготовленными UX и UI последует не менее идеальный код.
Пример screen flow:
Ниже представлен вариант, как может в совокупности выглядеть гибрид классических блок-схем, схематичных изображений и финальных макетов.
Как вы понимаете, самым затратным по времени является самый проработанный – screen flow. Именно он выглядит как рабочее приложение и готов к интерактивному прототипированию, тестированию, новым итерациям, утверждению и передаче разработчикам. Для командного проектирования user flow существует множество инструментов автоматизации, среди которых Overflow, Miro, Flowmapp и другие.
Таким образом, user flow, охватывая весь продукт, систематизирует и структурирует процесс его создания, максимально ориентирует продуктовую команду на потребности пользователя и на их единое понимание, позволяет создать предельно понятный и интуитивный продукт с помощью анализа пользовательских сценариев. Всё это не только существенно ускоряет скорость разработки, но и углубляет взаимодействие с заказчиком. User flow заставляет IT-компанию всегда думать о бизнес-требованиях заказчика, чтобы создавать приложение более эффективным и успешным, чем это возможно в рамках выделенного бюджета и времени без применения user flow.
Дерзкая птица структур: development flow
Если вы на пальцах не можете описать структуру вашей организации, отдела, вообще работы — значит, вы делаете это неэффективно.
Эффективность и прозрачность это никогда не одно и то же. Можно прозрачно делать неэффективные вещи, а эффективно делать вещи непрозрачные.
Построение структуры работы это сложный, индивидуальный процесс, с налётом дерзости. Потому что нужна не только смелость и рефлексия («мы работаем неэффективно, почему?»), но и умение делать изящные нагромождения.
Изящные нагромождения — залог создания структур. Кажется «нам не надо, работаем и ладно, зачем нам лишние слои», но на деле — один продуманный слой поднимет вашу работу на новый уровень. Это нагромождение, но оно изящно. Что-то вроде dependency injection или использование фотошопа вместо рисования красками.
Если сейчас вы подумали «нет, у нас всё эффективно» — даже не надейтесь. Неэффективно. Даже если у вас абсолютно, совершенно, никогда вообще не создаётся заторов в работе — то вы просто живёте в иллюзиях. Это невозможно. Эффективность это грёбанный процесс, а не данность. И конкретный человек должен этот процесс обеспечивать. А другие — поддерживать. Не потому, что «так сказали», а потому что всем будет хорошо — все будут работать так, как им комфортно, и быть эффективными.
Короче, наше детище изящных нагромождений мы называем «дерзкой птицей структур» или «development flow». Сейчас мы его опишем, и еще съедим пару ваших собак в спорах.
Зачем он нужен
Development Flow призван для исполнения 4 обязательств:
Система
Система состоит из элементов, элементы разные, и по ним идёт «ток» — рабочий процесс. В ИТ «ток» это код, дизайн, документы и прочие штуки, с которыми и над которыми мы работаем.
Системы бывают отсутствующими
Если вы не знаете, на каком этапе вашего Частного флоу сейчас находитесь (например, «разработка фичи»), и не знаете, каким этапом вы являетесь в Общем флоу (например, четвёртым, после Владельца продукта, Скрам мастера и Дизайнера), и какой этап должен пойти за вами, какие у него критерии возврата, и много всяких мелочей еще…
Или если вы знаете, но для вашей работы с вами рядом должен сидеть Проектный менеджер, и напоминать, чем именно в эту самую секунду вам следует заниматься (не отрывайся от монитора, тут же следящие программы)…
Или если вы просто чувствуете, что вы неэффективны…
… то скорее всего, у вас нет Системы.
Система бывают неработающими правильно
Не всё золото, что блестит. Не всё V12, что под капотом. И главное — не каждый двигатель работает правильно, даже если едет (привет, любимый автопром).
Важно иметь правильно работающую систему, потому что это наша уверенность. В своей работе, в работе всей системы. Вы сразу будете находить проблемы, большинство которых сможете решить.
У работающего двигателя есть звук. Он ритмичный, приятный. Если там есть проблема, это слышно чуткому уху мастера. Скрип, чихания, нарушение ритма, стук. Это медленно или быстро уничтожает двигатель, и «машина бизнеса» ломается именно тогда, когда ты взял долларовую ипотеку на трёшку внутри кольца.
В системе работы людей эти шумы — нарушение сроков, недовольства, утечка кадров, пониженный тонус сотрудников, перекидывание проблем на соседний отдел — и много всего другого. Хороший управленец ходит по офису с растопыренными сверхчувственными локаторами вместо ушей. Ему известен надвигающийся шторм, он чувствует, что упало давление. Он слышит все короткие вздохи, и замечает отведённые глаза. Он и есть Система.
Development flow: система
Система DF подразумевает два раздела — Общий флоу (функционирование системы в целом), и Частный флоу (функционирование отдельных её частей).
Общий флоу
Система состоит из элементов, объединенных в структуру для достижения намеченной цели.
Цель в ИТ — выпуск продукта в нужное время, нужного качества. Элементы системы — участники процесса: Владелец продукта, Проектный менеджер, Скрам мастер, Разработчик, Дизайнер, Тестировщик, Техписатель… Всё это элементы, и не все они присутствуют постоянно. Иногда роли объединяются. Нужно выделить свои элементы.
Нужно выделить свои элементы. Записать их, и стрелочкой нарисовать свой первый флоу. Это называется Общий флоу.
Владелец → СМ → Дизайнер, Разработчик → Тестировщик → Техписатель
Задача — объединить элементы в структуру и показать, какие профессиональные взаимодействия возможны. Непрофессиональные — о том, что дизайнер и владелец продукта живут вместе, не надо. Надо только роли. Владелец не должен взаимодействовать с Дизайнером или Разработчиком. Только Скрам мастер. Только. Скрам мастер.
Когда мы выделяем взаимодействия, эти стрелочки, мы должны показать, что даёт Первый, и что в качестве обратной связи возвращает ему Второй. Так система начинает жить.
Владелец → даёт описание задачи → СМ
СМ её переформулирует и для Владельца, и для остальных. Оценка задачи — приблизительная — выстроится сама собой. Но задача СМ — из простого описания, применив изящное нагромождение, сделать ДОСТАТОЧНОЕ_ОПИСАНИЕ. Части этого ДО он и будет обсуждать и распределять с командой.
СМ → даёт части ДО → Дизайнеру и Разработчику
ДО включает в себя схему, все возможные её состояния, и много другого (не хочу пока нагромождать). Каждый получает свою часть. Не всегда одновременно. Обычно Дизайнер опережает Разработчика на один спринт.
Дизайнер и Разработчик на ежедневном митинге в качестве обратной связи с СМ возвращает ему своё видение задачи. Убеждаемся, что всё понимаем одинаково. Это занимает 25-28 секунд. А спасает часы и недели.
Разработчик → после своего частного флоу (об этом позже), передаёт код → Тестировщику
Разработчик отдаёт код, Тестировщик смотрит в свою часть ДО, и отрабатывает своё флоу. Обратная связь Тестировщика — для СМ → «позитивная», то есть то, как он понимает задачу, а для Разработчика → «негативная» — только в том случае, если сломано.
Разработчик не имеет представления, что его код тестируют, до тех пор, пока не появляется проблем.
Думаю, что Общий флоу правильно формулировать так. Первый отдаёт Второму, Второй обрабатывает, возвращает «позитивную» или «негативную» Обратную связь, двигает дальше в Общем флоу. Позитивная обратная связь — убеждённость, что всё работает как задумано; негативная обратная связь — показывает, где и что пошло не так.
Частный флоу
В этой статье я в общих чертах разберу частные флоу Владельца, СМ и Разработчика, в качестве примера. Если вам будет интересно, потом выложу остальные наработки.
Владелец
Главная цель
Формулировка задачи (backlog ← описание), читать обратную связь
Что дальше
Когда задачи сформулированы Владельцем, СМ их описывает → приводит к Достаточному_Описанию.
Обратная связь от
СМ переописывает задачу и обсуждает с быстро Владельцем ключевые вехи, в тч сроки.
Взаимодействует с
СМ
Главная цель
Принять задачу, привести её в вид Достаточного_Описания, оценить задачи, распределить, читать обратную связь
Что дальше
Распределяет задачи сотрудникам
Обратная связь от
Дизайнер, Разработчик, Тестировщик, Техписатель
Взаимодействует с
Владелец, Дизайнер, Разработчик, Тестировщик, Техписатель
Разработчик
Главная цель
Разработка фичей и исправление багов. В Общем флоу ему приходят задачи от СМ, и при помощи своей профессиональной деятельности, он их реализует (git flow, rebase flow, feature flow и др).
Что дальше
Он может вносить предложения по модификации, обсуждая их с СМ и Дизайнером.
Обратная связь от
СМ, Дизайнера, Тестировщика
Взаимодействует с
СМ, Дизайнером, (важно — он не может порождать взаимодействие с Тестировщиком)
(В таком описании схема мне не очень нравится, вот эта моя презентация с другим описанием, и мне с ним приятнее работать. Но я же исследую варианты, пробую, оттачиваю, и тут получилось так. )
В сухом остатке
Development Flow решает такие задачи:
Очень много работы у Скрам Мастера (Тимлид, CTO). Но так и должно быть, он — главный тягач в этом подходе.
Оставайтесь в неведении или создавайте дерзкие структур. Мы предлагает свою птицу, но она большая и это только часть, в первом приближении. Нам нужно больше всяких кейсов. Потому я прошу вас — вешайте на меня всех собак, хочется разгрызть тему получше.
(Многое пришлось вырезать, чтобы хоть немного ужать размер статьи. Из-за этого что-то мог упустить, но буду оперативно исправляться, пишите.)