что такое workflow в разработке
Введение в Microsoft Workflow Foundation
Заинтересовались — читайте дальше.
Введение
Если оглянуться, то мир вокруг нас — это бесконечная череда сменяющих друг друга процессов. Мы сажаем зерно, оно прорастает, цветет, оставляет потомство, погибает. На его месте вырастает что-то новое. И так день за днем. Люди пытаются описать эти процессы, симулировать их на компьютере, придумывают что-то новое. Для этого создаются различные ментальные модели, которые упрощают описание повседневных процессов. Вводятся уровни абстракции. Например, придумали объектно-ориентированное программирование. С его помощью можно описывать объекты реального мира. Это легко и естественно. Достаточно посмотреть на вещь и в голове уже вырисовывается более или менее точная модель: какими свойствами обладает этот объект, какие действия может совершать.
Но объекты, которые никак не взаимодействуют между собой, не имеют никакого смысла. Жизнь — это движение, зачастую цикличное. С другой стороны в мире существует человек. Он вносит некоторую сумятицу своей разумностью. Многие вещи, которые он делает — непоследовательны. Мотивы не всегда ясны. Сроки не всегда соответствуют ожиданиям. Человек может о чем-то забыть, что-то сделать не так, как задумывал раньше. И в тоже время он тоже оперирует объектами. Будь то объекты реального мира, такие, как камни, цветы, вода, или виртуального: документы, информация, слова.
Именно для описания движения и взаимодействия объектов внутри программ создана технология Microsoft Workflow Foundation. Это связующее звено, которое позволяет создавать взаимодействия, связывающие объекты между собой или процессы, протекающие внутри самих объектов. Workflow Foundation (WF) разделяет все процессы на два основных типа: последовательные процессы (sequential) и процессы, основанные на состояниях (state machine).
Последовательные процессы
Последовательные процессы, в понимании WF, — это такие процессы, которые обычно происходят без вмешательства извне. Также, они занимают относительно немного времени. Хорошим примером такого процесса может послужить копирование файлов из одной папки в другую: мы задали папки в начале процесса, а потом в него не вмешиваемся до завершения. Т.е. это, по сути, отлаженный конвейер. Да, может что-то сломаться и потребовать каких-то действий, но это исключительные ситуации, которые обрабатываются отдельно.
Процессы, основанные на состояниях
Лучший пример процесса, основанного на состояниях, кроется в его переводе. State machine буквально означает государственный аппарат. Это такой процесс, который имеет множество состояний, которые в зависимости от различных событий могут переходить из одного в другое. Все это мы обычно видим в бюрократическом аппарате: государственная страховка, продажа квартиры и т.д. Требуются подписи различных чиновников, которые могут быть в отпуске или на больничном. Такой процесс может длиться очень долго: дни, недели, а то и месяцы. Именно для таких ситуаций создан state-machine workflow.
Что нам дает WF
Давайте теперь посмотрим, что нам дает WF. В первую очередь это наглядность. Все мы постоянно рисуем какие-то схемки, наброски. В более сложных случаях мы детально углубляемся в проектирование, например, рисуем временные диаграммы. Теперь мы можем перенести эти эскизы в Microsoft Visual Stuidio 2008 с помощью встроенного редактора. Вот как это выглядит:
Даже далекий от программирования человек сможет разобраться в том, что происходит на диаграмме.
Но все эти эскизы оторваны от действующей программы, никак с нею не взаимодействуют. Если нам надо изменить течение процесса, то необходимо открыть исходники, вспомнить места, в которых необходимо сделать изменения согласно новому эскизу. Эти задачи позволяет решить WF. Мы можем просто взять и перенести участок кода на другое место. Тут же его скомпилировать и сравнить с исходным вариантом.
Также использование WF помогает более наглядно представить работу системы. Выделить процессы, которые могут быть разделены на составляющие или наоборот, объединены. Также поддерживаются транзакционные системы: можно задать компенсирующий процесс для случая, когда что-то пошло не так. Этот процесс вернет систему в состояние, в котором она находилась до наступления ошибки.
Есть возможность опубликовать процесс в качестве сервиса или веб-сервиса, доступного через интернет. Более того, можно создать так называемый Durable web-service, который сохраняет идентификатор сессии и состояние сервиса в промежутках между вызовами, позволяя выполнять процесс в течение длительного времени, не поддерживая соединение. Вы даже можете остановить процесс, сохранить состояние и запустить его на другом компьютере с того же самого места.
Средства разработки
Наиболее удобным средством разработки является визуальный редактор, встроенный в Visual Studio 2008. Он позволяет быстро и гибко создавать и модифицировать процессы. При этом нет необходимости разбираться в том, как это устроено на низком уровне. Также можно создавать процессы, используя язык разметки XAML или при помощи C#.
Давайте взглянем на основные элементы интерфейса для работы с процессами в студии. Вот как выглядит окно в процессе разработки:
Рассмотрим назначение каждой панели.
Это основной документ, в котором мы моделируем процесс. Сейчас мы видим приглашение перетащить туда какие-нибудь элементы для создания последовательного процесса.
Процесс состоит из базовых элементов, называемых Activity. Они находятся в панели Toolbox под номером два. В ней находится множество элементов. Часть из них вполне понятна по их названию. Например, While или IfElse. ConditionedActivityGroup звучит более загадочно.
Естественно, понадобится панель Properties для настройки всевозможных параметров.
Также очень полезна панель Document Outline, обозначенная цифрой четыре. В ней отображается дерево элементов данного процесса, позволяющее быстро переходить от одного элемента к другому.
Заключение
WF предоставляет разработчику более высокий уровень абстракции при работе над проектом. Позволяет пробовать новые идеи, используя имеющиеся наработки. Вы можете создать библиотеку часто используемых процессов и их элементов для повторного применения в других проектах. В следующей статье мы познакомимся поближе с последовательными процессами на примере программы, осуществляющей резервное копирование файлов.
Управление проектами через workflow. Как я наладил производство в два шага
Управление задачами в плотном потоке проектов подобно жонглированию. Упал один шар из дюжины — это уже большая проблема. Пытаться поднять — увеличивать риски уронить остальные. Забыть про него — представление будет неполноценным. И при любом исходе доверие к профессионализму жонглёра подорвано.
Проджект-менеджеру ещё сложнее. Жонглёра ценят за яркое шоу, а труд пиэма должен быть максимально незаметен. Однако, часто в обойме проджекта накапливается такое количество проектов, что постоянные провалы в каждом из них становятся нормой жизни. И пиэма начинают ценить за шоу по поднятию шаров. То есть за потери ресурсов, потраченных на исправление ранее созданных проигрышных ситуаций.
Решение этой проблемы мы видим в использовании корпоративных стандартов моделей управления повторяющимися задачами. Корпоративных — потому что стандарты должны быть разработаны до момента найма пиэма. Менеджер может выбирать оптимальное решение для конкретного проекта/команды самостоятельно, исходя из заранее описанных регламентов, а не изобретать новые правила игры для каждого нового случая.
Пять проблем, с которыми сталкиваются руководители во время найма, и как их решать
Читайте колонку Марины Хадиной, директора по развитию Talantix — облачной CRM-системы для найма от hh.ru.
Основа стандартов — 2 типа документов
Воркфлоу (англ., workflow — «поток работ»)
Если новичок не сможет за 1 минуту разобраться, как устроено взаимодействие между участниками проекта и на какие этапы делится выполнение услуги, перед нами плохой воркфлоу. Хороший документ позволяет профессионалу за 5 секунд понять, на ком именно застрял процесс, если проект вдруг встал.
Регламенты
Детализируют воркфлоу, описывая, как именно происходит приемка-передача информации / данных / материалов, и какая технология стоит за выполнением каждой задачи.
Я настроил бесперебойную работу в продакшне «Кинетики» в 2 этапа:
Шаг 1. Определяем единый процесс работы
Ключевые вопросы для формирования единых коммуникационных потоков:
Какова последовательность работ?
Кто несет ответственность за каждый этап?
Какова последовательность коммуникации между сотрудниками/отделами?
Какие именно происходят коммуникации?
В каждом регулярном процессе задействованы одни и те же специалисты. В коммуникации принимают участие 4 стороны: Специалисты, PM (проект-менеджер), АМ (аккаунт-менеджер) и Клиент. Одна из задач PM: строго следить за этапами производства и последовательностью коммуникаций.
Для наглядного представления взаимодействия я разбил работу по каждой услуге на блоки:
В схеме используются следующие обозначения:
Реализация воркфлоу через блок-схемы позволяет отразить большое количество информации в сжатом объеме.
Возьмем один фрагмент:
— Проект-менеджер ставит задачу на формирование гипотез (1).
— Пиэм формирует техническое задание на внесение правок на сайт (2).
— После выполнения задания стратег информирует пиэма о готовности к запуску, пиэм проверяет, тестирует вариацию и дает добро на запуск тестирования. Это считается сдачей работ (4).
Детализацию я описал в регламенте: как именно ставить задачи, где брать шаблон для заполнения гипотез, как правильно их генерировать, как тестировать и т.д. Обычно регламентами пользуются новички или джуниоры, а опытные специалисты обращаются только к воркфлоу, т.к. правила работы и технологии им уже известны и находятся в оперативной памяти.
Шаг 2. Ретроспективы. Делаем поток более эффективным
Большой плюс такой схемы — возможность ретроспективы проектов, когда нужно разобрать сбой или какую-то проблему при ведении проекта. Руководителю отдела или директору в этом случае понятно: кто, что и когда делал, с кем общался. За несколько секунд можно определить, на каком этапе возникла проблема и где следует поправить регламент, чтобы ошибка не повторялась.
То же самое относится и к сотрудникам, принимающим участие в проекте; каждый может быстро вспомнить, где у него возникают проблемы в работе, а руководитель оперативно исправит эти моменты.
Наверняка, у многих есть талмуд (своя wiki), где написано «все то же самое». Это здорово, но ускоренное восприятие информации через схему — весомый аргумент в пользу воркфлоу. Опыт показывает, что, по сравнению с текстовыми записями или mindmap схемами, такой воркфлоу откладывается в памяти в разы быстрее.
Актуализация воркфлоу и синхронизация бизнес-процессов
Необходимость в этом возникает в двух случаях:
Добавлена или изменена услуга;
В существующем процессе найден баг (неточность / неполнота / нарушены этапы).
По последнему пункту актуализация составляет 90% работы.
Для того, чтобы это было проще реализовывать, рекомендую следить за строгостью исполнения работ в связке CRM-Воркфлоу-Регламенты-Система управления проектами:
Названия задач и название процессов должны быть строго одинаковыми во всей связке;
Вложенность задач / процедур, должна точно отражать структуру задач / хранения документов.
Названия и связи (я делаю их стрелками в xmind) помогут быстро увидеть, как изменения в одном элементе повлияли на остальные процессы. В сфере интернет-рекламы такие связи довольно сильны, изменения в составе услуги несут корректировки в бюджетировании, а это влияет на договорные обязательства, прайс и коммуникации между исполнителями.
Баги во взаимодействии будут находить и сотрудники (но лучше на них не надеяться), или вы при аудите выполнения задач и фидбеков клиента. Но стоит выделять только повторяющиеся сигналы / недовольства / пожелания, а не бросаться править процессы по первому звонку клиента, ведь обновление процедур — непростой этап, который делится на:
Внесение изменений в регламентирующие документы;
Уведомление о изменениях заинтересованных лиц;
Контроль внедрения изменений (95% времени).
Зачастую все это требует серьезных временных затрат высокооплачиваемых сотрудников.
Разрабатывая воркфлоу, не стоит забывать о том, что чрезмерная упорядоченность ведет к тому, что на ее поддержание приходится тратить слишком много времени, а значит, и денег.
Ошибки и неточности есть везде и после определенной отметки, борьба с ними обходится дороже, чем потери от них самих. В тоже время тотальный контроль удовольствие дорогое и сомнительное. Понимание того, какой именно объем процедур требует описания, приходит с опытом. Мне для этого потребовался год непрерывной практики, и теперь я постоянно вижу улучшения.
Итак, в управлении повторяющимися задачами важна согласованность работы команды и менеджера проектов. Ключевую роль в этом играют наглядное описание (бизнес-) процесcов и удобство работы с этими файлами. Я нарочно не пишу «с этими документами», т.к. люди плохо запоминают сложно структурированную информацию в тексте, будь то PDF или бумажный реферат. Зато блок-схемы воркфлоу усваиваются прекрасно. Попробуйте.
Автоматизация workflow небольшой команды разработки (Часть 1)
Практически во всех местах моей работы программистом для разработки использовали всего два продукта: багтрекинг и систему контроля версий. Чаще всего это были Atlassian Jira и SVN. В принципе, наличие этих двух систем здорово упорядочивает общение всех участников процесса разработки и положительно влияет на качество работы отдела и продукта.
Итак. Настройка ПО, сопровождающего процесс разработки
Crowd и Jira
Первым был Crowd — менеджер учетных записей. Я скрестил и синхронизировал его с Jira. Crowd втянул в себя все группы и всех пользователей Jira. В Jira работу с директорией Crowd я сделал read/write (поскольку нового пользователя добавлять через Jira удобнее чем через Crowd).
В Jira всех пользователей разбил на группы:
Если вкратце, то юзеры в группе могут только создавать задачки и наблюдать за ними, девелоперы могут их редактировать и решать, а админы управляют версиями, компонентами, могут удалять или редактировать чужие комментарии или задачи.
Confluence
Я считаю этот продукт самым удачным среди всевозможных баз знаний. После прочтения большого количества статей и сравнения разных систем, я пришел к выводу, что Confluence среди них бесспорный лидер.
В нем я создал разные Пространства:
Весь хелп у нас хранится в Confluence в виде иерархической структуры статей. В конце версии одним кликом получается пачка HTML файлов, которые ссылаются друг на друга. Все это удовольствие мы просто копируем в проект и выпускаем. И потому справка у нас постраничная (а не все в одном огромном файле), легко поддерживаемая и всегда онлайн доступна для всей команды (а не где-то у кого-то в какой-то папке).
Каждый проект Jira и пространство Confluence связаны. В статье с постановкой есть ссылка на задачу и наоборот.
Bitbucket
Для хранения исходников мы исторически использовали SVN. Влияние новых технологий не прошло мимо, и конечно же выбор пал на git (бест практик как никак).
Поскольку я программист, а не сисадмин, установку чистого гита я не осилил. Потому взял готовый пакет GitBlit… но вскоре в нём разочаровался. В результате все перевёл на GitLab.
Год работы и 12 одновременно действующих проектов дали о себе знать. Сервер стал прогибаться под тяжестью руби. К тому же сказалась очень слабая совместимость с Atlassian продуктами.
В то время я заметил Stash. В чистом виде под линукс я, к сожалению, его не нашёл, за то поставил его в составе Bitbucket. И понеслась!
Создал проекты и по репозиторию в каждом. Дал полные права каждому ПМ-у на свой проект (теперь он сам может создавать репозитории в своём проекте сколько хочет). В репозитории на мастер ветку выдал права только лиду и по умолчанию выставил ветку dev.
Скрестил Bitbucket с Jira и теперь в каждой задаче есть список всех комитов по задаче. А из комитов можно переходить на задачки.
Fisheye and Crucible
Где-то я читал, что Crucible можно встроить в Stash. Но поизучав детально уже настроенный Bitbucket, я ничего подобного не нашёл. А так как CodeReview — обязательный этап в нашем Workflow, то пришлось ставить и Fisheye. Реально очень удобная штука, но имея Bitbucket, можно было обойтись и без неё.
Когда у нас стоял GitLab, добавлять репозитории в Fisheye было реально морочно… Куча настроек, генерация ключей, левые юзеры… С Bitbucket все пошло как по маслу. Скрестил Fisheye и Bitbucket и в Fisheye появился список всех репозиториев с кнопочкой “add”.
Создал проекты, указал в них группы разработки те, что в Jira для этих проектов, указал репозиторий и скрестил каждый со своим проектом в Jira. А в Jira наоборот указал в каждом проекте линки на Fisheye и Crucible и путь к репозиторию.
Теперь в каждой задаче есть комиты по задаче не только из Bitbucket, но и из Fisheye. Безтолково, конечно….но ничего страшного. Зато в каждой задаче теперь можно сразу увидеть Review и его статус!
Jenkins
Вот вроде бы и все, но нет! Надо же это все хозяйство как то автоматизированно собирать. Очень долго хотел прикрутить Bamboo, но он выглядит ущербно по сравнению с Jenkins. В Jenkins мне удавалось настроить автосборку всего еще и с перламутровыми пуговицами. В Bamboo все не так. Сообщество слабое, плагинов мало, можно рулить только выполнением консольных команд. Перечислять недостатки не буду. В начале настраивал под сборку Delphi-проектов, но потом перешли на веб и сборки стали простыми — вытащил, залил на ftp, отметил в Jira и письма разослал. Подумаю, может и на Bamboo перейдем.
Значит скрещивать Jenkins ни с кем не стал. Вроде как нужды нет. Никому не интересно в задаче сколько раз она собиралась. Единственное что — это в самом Jenkins поставил Jira plugin, чтобы при сборке задачи автоматически перемещались на другой шаг WorkFlow.
И важно все вышеперечисленные продукты обязательно настроить на Crowd. Единые учетки во всех этих системах — это реально удобно. При найме нового члена команды, достаточно его просто занести в Jira и указать его группу-проект и он имеет доступ ко всему. Точно так же и при увольнении. В одном месте выключил и доступа нет никуда.
Уголок сисадмина
Сервер у нас стоит Xeon X3430 4CPUs x 2,4 Ghz, 8 GB, 1TB
Вначале, я поднял Windows Server и на нем все эти продукты сразу + Ubuntu для GitLab. Сервер не осилил, раз в два часа просто зависал на 10 мин.
После этого принял решение разделить по разным виртуалкам. Вот что получилось:
Gateway — для выхода в Интернет (4 ядра, 4ГБ ОЗУ) — эта виртуалка мне уже досталась от админа, который этот сервер первоначально настраивал.
Jira — 2 ядра, 2ГБ ОЗУ
Confluence — 2 ядра, 2ГБ ОЗУ
Bitbucket&Jenkins — 2 ядра, 2ГБ ОЗУ
Crowd&FishEye&FTP — 2 ядра, 2ГБ ОЗУ
Все виртуалки на Linux Debian 8.2
Теперь все эти продукты летают, и зависаний, как раньше, нет.
На виртуалке Gateway пробросил два порта чтобы снаружи были доступны Jira и Confluence. Размышляю над тем, чтобы еще пробросить порт для доступа к Git. Но чтобы было более секурно, только ssh доступ.
Итоги
Вот и готовы сервера и все необходимые продукты для полной автоматизации workflow разработки. В следующей части я постараюсь подробно описать как взаимодействуют эти все продукты ежедневно в процессе разработки.
Комплексный Workflow. Решение проблем растущей IT-компании. Часть 1
Привет, хабраобщество!
Давно не писал материалов, всё больше читал чужие. Но вот, выдалась свободная минутка (пока с трёх iMac’ов сливаются свадебные фото c дисков ввиду отсутствия у моего бука привода :) и я решил выложить материал про наш рабочий процесс. Мы — молодая компания Fruitware из солнечной Молдовы, а я сам совмещаю должности коммерческого и исполнительного директора, хотя наиболее опытен я, как ни странно, в веб-программировании.
Наша компания прошла довольно значительный путь длинной в полтора года от «гаражной» студии из 5ти человек до серьёзной организации из 40.
Я скажу вам честно — увеличиться в 8 раз — это не самый безболезненный процесс и нас не раз лихорадило. Но, учась больше на своих ошибках и немного на чужих, мы построили свой порядок работы, начиная с технического оснащения и до управления проектом.
Redmine
Основной инструмент у нас — Redmine с установленной CRM-системой. Там мы храним проекты и консолидируем информацию о каждом в его Вики. На каждого клиента заведена карточка, на организации — несколько. Каждый новый заказ фиксируется сделкой для работы воронки продаж, а каждый платёж предваряется сгенерированным счётом. Также мы используем вехи Redmine для организации работы по спринтам, в задачах проставляем планируемое время и указываем фактические трудозатраты. Эти же данные используются для проверки работы сотрудников и начисления зарплат и бонусов.
Весь код мы храним в GIT, выкладываем его на собственный выделенный сервер в Германии (Hertzner). На каждого нашего разработчика открыт отдельный ftp-аккаунт для логирования любых проблем.
Что касается интерфейса управления GIT’ом — в данный момент мы используем gitosys с интерфейсом n98-gitosis-admin, но смотрим в сторону GitLab.
IDE и стандарты
Есть корпоративные стандарты написание кода, корпоративный же IDE (PHP Storm) и набор практик для работы.
По сути это даёт нам нормальную стандартизацию работы, возможность легко подойти к любому разработчику и привычно для себя на его компьютере или ноутбуке внести правки в код, провести код-ревью или помочь с дебаггом.
Штатное расписание
Рабочий процесс
С иерархией вроде бы разобрались, теперь перейдём к самому важному — процессу работы с проектом.
Начнём с того, что мы знакомимся с новым заказом и наша задача — понять проблематику клиента и предложить решение в сфере рекламы, дизайна или it. Для этого на встречу или переговоры с клиентом обязательно попадают коммерческий директор, арт-директор, системный аналитик и аккаунт (он же менеджер). Вместе мы формируем коммерческое предложение или видение проекта с понятным описанием проблемы, того, чего ждёт от нас клиент и того, что мы готовы сделать для него. На основании этого документа начальниками соответствующих отделов определяются объёмы работы, и формируется бюджет. На этом этапе бюджет может быть примерный или окончательный (всё зависит от размера проектам и его Х-фактора).
Далее, после получения принципиального согласия, формируется постановка проекта — более полное описание функционала. На основе постановки детализируется стоимость и уже после получения аванса начинается самое главное — написание ТЗ. ТЗ пишется системным аналитиком вместе с главой соответствующего департамента, чтобы не выйти за рамки бюджета.
Затем по ТЗ составляется два документа — смета со списком больших задач (без ограничений по времени) и список задач с высокой детализацией (не больше 4х часов на задачу).
Конечные исполнители, аккаунт клиента, системный аналитик и главы задействованных департаментов (в том числе и QA) встречаются и обсуждают проект, чтобы все понимали стоящие перед ними задачи одинаково. После встречи уточняется как смета, так и список задач.
Проводится стендап планирования спринта — здесь уже только исполнители, менеджер, тимлид или заменяющий его глава отдела и при необходимости системный аналитик. Затем в редмайне устанавливается веха на первый спринт, определяются конечные проверяемые индикаторы готовности первой версии, они описываются в вики вехи, задачи из списка добавляются в редмайн и назначаются на конкретных исполнителей с ориентировочным сроком выполнения.
Дальше всё по знакомому многим сценарию — дневные стендапы до 15 минут — что делали вчера, что планируете делать сегодня, какие проблемы возникли.
Спринт заканчивается стендапом с обзором сделанного, показом менеджеру получившегося продукта. Глава департамента перед этой встречей делает обязательный код-ревью. Затем, при необходимости, следует ретроспективный взгляд на спринт и обсуждение возникших проблем.
После первого спринта всё повторяется до полной готовности проекта. При необходимости промежуточные результаты показываются клиенту.
Преимущества
Будущее
И многое другое.
Спасибо за внимание, буду рад ответить на ваши вопросы.