Настольная книга тимлида разработки ПО. Книга тимлида разработки по Издательские решения
 Скачать 0.67 Mb.
|
|
Нотации описания процессов Модель IDEF0 возникла в армии, точнее, в ВВС США в 1980-х годах. Схема развора- чивается одновременно слева направо, сверху вниз и по диагонали. Объекты, расположенные левее / выше, доминируют над теми, которые находятся правее / ниже. Доминирующие объ- екты могут включать в себя зависимые. Например, доставка заказа – это элемент, входящий в состав более масштабного процесса управления заказами. Также доминирующие объекты могут являться предшествующими этапами для зависимых: получение заявки – согласование заявки. Графические элементы: – Прямоугольники – действия или этапы. – Стрелки – ресурсы, исполнители, необходимые для совершения действия или прохож- дения этапа. Главное достоинство IDEF0 – крайне высокая степень детализации. Можно создать модель, которая будет учитывать на каждом этапе практически все ресурсы и сотрудников, которые потребуются даже для самых сложных алгоритмов. Недостатком является то, что гра- фическая модель занимает очень много места и её тяжело читать, не имея специальных навы- ков. Она позволяет создать модель, которая будет отражать: – Структуру системы – Функции – Потоки ресурсов, информации Ещё один минус: с помощью IDEF0 лучше всего описываются модели, где бизнес-про- цесс представляет собой одну цепочку, без развилок. Если на пути он встречает множествен- ные «или», работать с IDEF0 становится очень сложно. Базовая нотация BPMN включает не более 10 типов значков и помогает описать алго- ритм в понятной неподготовленному бизнес-пользователю форме. Расширенная BPMN содер- жит около 100 значков и позволяет сделать регламент машиночитаемым, не допуская разно- чтений. Её центром является именно бизнес-процесс, алгоритм прохождения которого она и показывает. Основные элементы BPMN: – Задача (прямоугольник) – Событие (круг) – Шлюз, развилка (ромб) – Поток, ход (стрелка) – Базы данных, документы – Сноски – Пулы Главное преимущество BPMN – описание именно бизнес-процесса, делая его понятным даже для рядовых сотрудников. Сегодня BPMN пользуется популярностью. Большинство вен- доров, предлагающих системы BPM, предусматривают работу c BPMN – схему, созданную с её помощью, можно сделать исполняемой подключив возможности информационной системы. Недостаток BPMN в том, что она зациклена на бизнес-процессах и плохо подходит для описания структуры предприятия или дерева целей. При использовании расширенной версии схема усложняется, и понять её человеку без специальных навыков будет уже сложно. EPC (Event-driven Process Chain), фокус сделан на событиях. Схема использует значительно больше элементов – разноцветных фигур: В. Большаков. «Настольная книга тимлида разработки ПО» 56 – Розовые фигуры – события – Зелёные – функции (действия) – Жёлтые – исполнители – Серые – ресурсы – Оранжевые – информационные системы Модель разворачивается сверху вниз, более высокие элементы предшествуют более низ- ким. В качестве соединительных элементов используются, помимо стрелок, разделители «и», «или», «исключающее или». Благодаря этому EPC лучше подходит для ветвящихся биз- нес-процессов. Чтобы выстроить схему, сначала определяется стартовое/финальное событие, затем – промежуточные события и необходимые для них исполнители, ресурсы. Преимущество EPC – простота восприятия. Разноцветные элементы делают модель более «живой», приятной для глаз. Это немаловажно, если требуется нарисовать схему для сотрудников или провести презентацию. В отличие от предыдущей нотации, эта позволяет выстроить сложные развилки и длин- ные параллельные ряды событий. Каждый элемент можно разложить на более мелкие эле- менты, построив для них отдельные схемы. Главный недостаток EPC в том, что её структурной единицей является событие, кото- рое приходится создавать даже для самых незначительных этапов. EPC также справедливо критикуют за обилие тавтологических элементов: задача «определить исполнителей» – собы- тие «исполнители определены», задача «согласовать договор» – событие «договор согласо- ван». Если схема длинная и сложная, подобные и многочисленные стрелки от «исполнителей» к «событиям» ее перегружают. Особенно если один исполнитель отвечает за множество дел или на одно событие назначено несколько сотрудников. При выборе нотации для описания процесса учитываются следующие факторы: – IDEF0 удобнее использовать для верхнеуровневого описания процессов – BPMN имеет протокол описания XML (BPMN 2.0) и может быть автоматизирован, например продуктом Camunda – EPC легче для чтения процесса целиком, но сложнее при выделении действия для кон- кретной роли На практике если процесс небольшой, его описывают в BPMN (для этого есть бесплатный удобный редактор https://bpmn.io/ ). Если процесс масштабный, то его дробят на более мелкие составляющие, которые описываются в BPMN, но верхнеуровнево все эти процессы связыва- ются в схемах IDEF0. В. Большаков. «Настольная книга тимлида разработки ПО» 57 Внедрение процессов или изменений Достаточно часто изменение процессов влечет за собой изменение средств автоматиза- ции процесса (программного обеспечения), создание новых бланков документов, работу новых инструментов (их закупку и настройку) и др. К внедрению процессов необходимо относится как к Управленческому проекту. То есть составьте перечень мероприятий и запланируйте их выполнение на диаграмме Ганта. Незави- симо от масштаба изменения процессов, вам как минимум потребуется проинформировать сотрудников, скоординировать запуск процесса и проконтролировать его выполнение. Запуск процесса состоит и следующих шагов: – Информирование о начале работы согласно новому процессу (со сносками на докумен- тацию) – Выборочный контроль исполнения шагов – Общий контроль исполнения процесса – Получение обратной связи от участников процесса – Оценка эффективности нового процесса Что может пойти не так: – Сотрудники не следуют новому процессу умышленно (саботаж). Для начала необхо- димо выслушать доводы сотрудников, с чем они не согласны. Вероятно, вы не вовлекли сотруд- ников в этап проектирования процесса, что породило их несогласие. – если доводы разумные, можно включить их в следующую итерацию изменения про- цесса. Например, исправить его через некоторое время – сообщите об этом сотрудникам и попросите работать пока в текущей версии процесса. – если их доводы не разумные, объясните почему. – если это личная неприязнь к вам и саботаж просто способ выражения этой неприязни, то необходимо перечитать главу Конфликтология и решать этот вопрос указанным там спосо- бом. – Сотрудники не знают, как правильно следовать новому процессу. – вы могли совершить ошибку, не описав нужные вещи в процессе, или ваши сотрудники невнимательно изучили сделанный материал. Так или иначе, это больше обычная ситуация нежели саботаж. – Новый процесс имеет критические ошибки и нуждается в пересмотре Контролируйте новый процесс первое время, как писал пластический хирург Максвелл Мальц: «Человеку нужен 21 день, чтобы привыкнуть к изменениям своего тела». Этот срок в «21 день» применяют и для других случаев, где людям необходимо привыкнуть к чему-то новому. Если это редкий процесс, то отсчитывайте 7—9 итераций этого процесса до смягчения вашего контроля. В. Большаков. «Настольная книга тимлида разработки ПО» 58 Эволюция процесса разработки Конструируя свой процесс, необходимо отталкиваться от основных параметров: – Долгосрочное или краткосрочное сотрудничество у вас с заказчиком – Насколько жестко ограничены срок и требования к продукту Процесс разработки будет меняться со временем и на то есть определенные причины: – Меняются люди в команде – Меняется количество людей в команде – Меняются требования к качеству продукта – Появляются риски, которые сыграли – Подходит плановая оптимизация процесса – Появляются жалобы и предложения Вам нужно будет достаточно часто менять и адаптировать процесс разработки к изменя- ющимся условиям. Есть лучшая практика для оптимизации процессов – Цикл Деминга. Цикл Деминга (PDCA) закладывает в управление процессом постоянное улучшение качества. Эдвард Деминг заложил два варианта для цикла управленческих действий постоянного улучшения качества: PDCA (планируй/Plan – делай/Do – проверяй/Check – корректируй/Act) и PDSA (планируй/Plan – делай/Do – изучай/Study – корректируй/Act): – Планирование: установление целей и процессов, необходимых для достижения целей, планирование работ по достижению целей процесса и удовлетворения потребителя, планиро- вание выделения и распределения необходимых ресурсов. – Выполнение: выполнение запланированных работ. – Проверка: сбор информации и контроль результата на основе ключевых показате- лей эффективности (KPI). Они получаются в ходе выполнения процесса, выявления и анализа отклонений и установления причин отклонений. – Воздействие: (управление, корректировка) принятие мер по устранению причин отклонений от запланированного результата, а также изменений в планировании и распреде- лении ресурсов. В. Большаков. «Настольная книга тимлида разработки ПО» 59 Цикл Деминга ни что иное как здравый смысл, примененный к любому происходящему во времени процессу, которому необходимо постоянное улучшение. Процесс непрерывного совершенствования поддерживается многими методологиями. Например, в Scrum есть встречи Sprint Retrospective, а в ITIL есть Continual Service Improvement. Так или иначе все приходят к реестру, процессу выявления улучшений и плано- вой работе с ними. Есть несколько способов поиска улучшений: – Анализ потерь на всех этапах решения задач. Такой анализ может происходить на встре- чах Sprint Retrospective. – Анализировать основные метрики процессов и предпринимать действия по их посто- янному улучшению. Важно обеспечить непрерывность их роста, а не большую величину роста. В. Большаков. «Настольная книга тимлида разработки ПО» 60 Лучшие практики разработки и особенности их применения Существует множество хороших практик разработки. Важно выбрать из них те, что под- ходят к конкретному случаю. Kanban (применяем при высокой неопределенности в приоритетах/размерности задач/ бэклоге) – Доска для наглядности не сможет вместить большого количества тикетов – Работать с подзадачами на доске неудобно – Приоритеты можно менять на лету – Нет издержек на оценку задач – Сложно попасть в сроки по плановым задачам Scrum (применяем если можем планировать на 3+ итерации, нет фиксированного бюд- жета или требования могут измениться) – не работает с совмещенными ресурсами (сотрудники, выполняющие задачи разных команд) – работает в условиях краткосрочного планирования – подразумевает отсутствие четкого конечного образа продукта – кросс-функциональные команды подразумевают способность подменить одного специ- алиста другим (больше подходит для Fullstack разработчиков), и производство менее сложных продуктов – подразумевает само-организованные команды, что требует найма команды с опреде- ленными soft skills – ввиду избегания конечного образа продукта страдает область архитектурного плани- рования ServiceDesk (применяем, если необходимо обеспечить единый временной норматив выполнения заявок) – отсутствует планирование – задачи могут быть большими, но они должны укладываться в временные рамки SLA – приоритет выставляет поддержка, а не бизнес. Существует еще множество различных лучших практик, подробно рассмотреть их в рам- ках данной книги невозможно. Для себя вы можете почитать про RUP, ITIL, RAD, Lean SD, Six Sigma, MSF, XP, PMBOK, Prince2. Но стоит четко отделять практики WoW (way of working) вашей команды, от практик корпоративного уровня SAFe, LeSS, Disciplined Agile. В. Большаков. «Настольная книга тимлида разработки ПО» 61 Менеджер процесса разработки Менеджер контролирует выполнение процесса, спроектированного Владельцем про- цесса. «Управляешь только тем, что можешь измерить» американский ученый и публицист Питер Друкер Менеджер на ежедневной основе выполняет аналогичный цикл PDCA, собирая инфор- мацию о результативности, выявляя проблемы процесса и устраняя их. Как собирать информацию? Для каждого процесса определена измеримая цель. Более того, измерить можно не только поток работы, но и качество результатов на каждом шаге. Обычно самый простой способ – контролировать итоговый результат, быстро привлекая менеджера к этапам более глубокого контроля. Без этого каждый раз будет затрачиваться много времени на выяснение причин пло- хих метрик итогового результата. Конечно, кроме всего прочего, необходимо быстро анализировать информацию – соби- раемые метрики должны выводится на графики. Также оперативную информацию можно получать от исполнителей на ежедневных встре- чах (или других отчетных собраниях). На основании анализа репозитория и сервиса проведения ревью можно собрать множе- ство метрик, например: – выгорания – коммиты, комменты в нерабочее время – лени – мало кода, мало коммитов, мало ревью, мало задач, мало активных дней – фокуса на задачу – простой после ревью, простой после тестирования и ожидание релиза – качество – churn, возврат из тестирования, фиксы на проде – bus-фактор – области изменения кода – качество постановки задач – частота изменений описаний, churn – технический долг – высокий complexity, низкий уровень рефакторинга legacy Как выявлять проблемы? Выявление проблем может быть построено на данных анализа и полученных путем изу- чения трендов, и пороговых значений статистических данных. На практике у вас должен быть дашборд с графиками и информацией, достаточной для понимания работы процессов и людей. На основании выявленного отклонения необходимо исследовать природу этого собы- тия. Дедуктивным методом вы докапываетесь до исходной причины, также вы можете при- менить метод «5 почему». По итогу анализа вы придете к одному типу первопричины про- блемы: внешние факторы, процесс, сотрудники. Копайте так глубоко, насколько это будет возможно/необходимо, ведь не докопавшись до сути, вы можете потратить силы на лечение симптомов, а не первопричин. Как реагировать? Есть 3 варианта реакции на выявленные проблемы: – Коммуникация с другими подразделениями и внешними контрагентами – Исправление процесса с владельцем процесса – Управленческое воздействие на сотрудников Большая часть бизнес-процессов на предприятии не изолирована, а связана с работой других подразделений. Даже, например, вход в ваш процесс обеспечивает какой-то другой. Если итоговые результаты вашей работы неудовлетворительны из-за ошибок, в поступивших к вам на начальном этапе входных данных – это повод обсудить ситуацию с руководителем В. Большаков. «Настольная книга тимлида разработки ПО» 62 другого подразделения. Поиск компромисса необходим для предотвращения дисбаланса, когда сверхэффективность одних подразделений может оборачиваться худшей результативностью других. Также ваш процесс может зависеть от работы подрядчиков, что не может снимает с вас ответственности как с менеджера процесса. Результат вашего процесса зависит не только от внешних коммуникаций. Если резуль- тат не соответствует ожиданиям, возможно, сам процесс спроектирован неверным образом. Потребители могут жаловаться на качество, скорость или стоимость процесса. Вам как мене- джеру, нужно понять, какие рекомендации владельцу процесса дадут наилучший результат. Например, входящий в разработку поток заявок от бизнеса принято классифицировать на: Инциденты, Новый функционал и другие категории. Это необходимо, чтобы наилучшим спо- собом (баланс качества, скорости и стоимости) решить каждую из заявок. Каждый этап про- цесса уникален и требует переосмысления, ведь он может иметь отклонения от общих пра- вил, адаптируясь под разные ситуации. Причины неудовлетворительного результата – описание процесса может быть либо недостаточно детализированным, либо наоборот слишком конкрет- ным, что не дает сотрудником подходить к решению задач творчески. Наконец, ваши сотрудники могут не соблюдать предписанный процесс (умышленно или неосознанно). Сами управленческие воздействия мы разбирали выше в блоке «Мотивации чле- нов команды». Одной из классических функций менеджера является Планирование. Для оптимизации собственных ресурсов остальным подразделениям важно понимать, когда вы сделаете ту или иную задачу. Прогноз результатов строится из выходных результатов процесса, понимания доступных ресурсов на прогнозируемый период и из потенциальных изменений или рисков. Проблема с метриками заключается в том, что сотрудники в погоне за видимостью результата могут предоставить вам лишь красивые цифры. Так часто происходит, когда бонусы привязываются к KPI. Не попадайте в эту ловушку, лучше, чтобы сотрудники не знали о том, какие вы хотите увидеть цифры и по каким метрикам. В. Большаков. «Настольная книга тимлида разработки ПО» 63 Аналитика Вход процесса: Заинтересованные лица, требования к системам Цели процесса: – Оценка объема аналитики по задачам – Скорректированные ожидания заказчиков – Согласованное описание требований заказчиков – Обновленная документация продукта – Обученные сотрудники, проведенное демо и др. Метрики: – Удовлетворенность работой аналитика (Заказчик/Архитектор/Разработчик/…) – Количество задач с описанными требованиями В. Большаков. «Настольная книга тимлида разработки ПО» 64 Программирование Вход процесса: Согласованные требования по задаче Цели процесса: – Оценка сложности и времени выполнения задач – Написание кода, реализующего рабочие требования – Проверка соответствия кода соглашениям/стандартам Метрики: – Соответствие времени решения задачи плановым показателям – % прохождения статического анализа кода – % прохождения автоматизированного тестирования – % прохождения ручного тестирования – Количество выполненных задач – Объем выполненных задач В. Большаков. «Настольная книга тимлида разработки ПО» |