Настольная книга тимлида разработки ПО. Книга тимлида разработки по Издательские решения
 Скачать 0.67 Mb.
|
|
Контроль качества Вход процесса: Выполненная задача Цели процесса: – Оценка сложности и времени тестирования задач – Соответствие нового функционала заданным требованиям и ожиданиям заказчика – Отсутствие дефектов в связи с внедрением нового функционала Метрики: – Оценка сложности и времени тестирования задач – Среднее время ожидания тестирования – Скорость тестирования задач – % пропущенных ошибок – % автоматизированных тест-кейсов Качество можно рассматривать шире, например в рамках теории Total Quality Management. В. Большаков. «Настольная книга тимлида разработки ПО» 66 Публикация новых версий Вход процесса: Готовая к публикации новая версия Цели процесса: – Опубликованная новая версия – Минимальный ущерб в связи с публикацией новой версии (простой, ошибки) – Минимальная стоимость процесса сборки и публикации Метрики: – Среднее время ожидания публикации задачи после успешного тестирования – Сумма простоя в процессе публикации – Количество инцидентов во время публикации – Количество публикаций в целом В. Большаков. «Настольная книга тимлида разработки ПО» 67 Обслуживание и поддержка Вход процесса: Система, с которой работают пользователи Цели процесса: – Минимизация времени обслуживания заявок пользователей – Минимизация отказов и времени даунтайма системы – Минимизация стоимости процесса Метрики: – Метрики SLA – Uptime – Количество специалистов, необходимых для поддержки функционирования систем Используйте post-mortem отчеты для анализа инцидентов доступности продукта. Они помогут команде исправить причины, которые привели к инциденту или деградации. В. Большаков. «Настольная книга тимлида разработки ПО» 68 Прием, распределение и контроль задач в подразделении Качество постановки задач Какие задачи у вашей команды, кто их и как ставит? Ощущение вас как руководителя складывается в первую очередь из поставленных задач и того, как вы их принимаете. Все это делают по-разному. Одним достаточно контролировать техническую часть, поручая кон- троль закрытия другим сотрудникам. Другие же ограничиваются только распределением задач. На самом деле вы должны отстаивать интересы заказчика внутри вашей команды, а значит ставить задачи и контролировать процесс их выполнения в полной мере. Многие начинающие руководители недооценивают необходимость грамотной поста- новки задач, хотя это напрямую влияет на качество их выполнения. По этой причине в совре- менных методологиях вышеупомянутой проблеме уделяется больше внимание. Мы будем рас- сматривать постановку задач в процессе разработки ПО. Методики постановки задач: – S.M.A.R.T. является аббревиатурой, где каждая буква означает критерий эффективно- сти поставленных целей или задач. – Specific – (конкретный) – нацельте на конкретную область для улучшения – Measurable – (измеримый) – дайте количественную оценку или предложите показатель прогресса – Assignable/Attainable – (назначаемый/достижимый) – укажите конкретного исполни- теля – Realistic – (реалистичный) – опишите, какие результаты могут быть реально достигнуты при наличии ресурсов – Time related/Tangible – (связанный со временем/осязаемый) – укажите, когда может или должен быть достигнут результат – User story (пользовательские истории). Если говорить про Agile разработку, то поль- зовательские истории рекомендованы как наиболее простой и понятный заказчику способ. Но вместе с простотой появляются проблемы с невыявленными требованиями. Предложено несколько формул пользовательских историй: – Я как <Роль> могу <Функционал>, чтобы <Получить ценность> – Для того чтобы мне <Получить ценность> как <Роль>, я могу <цель/возможность> – Как <Кто> <Когда> <Где> я <Хочу>, потому что <Причина> – К пользовательским историям и не только часто применяется I.N.V.E.S.T. метод – Independent (независимость) – Старайтесь избегать создания задач, которые зависят друг от друга – Negotiable (обсуждаемость) – задачи не являются формальным контрактным обязатель- ством или требованиями – Valuable – ценность для пользователя и покупателя – Estimable (оцениваемость) – разработчики должны иметь возможность оценить размер задачи – Small (компактность) – от размера задачи зависит очень многое, слишком большие и слишком маленькие задачи сложно оценивать – Testable (тестируемость) – подтверждением того, что задача разработана успешно, слу- жит удачное прохождение тестов В. Большаков. «Настольная книга тимлида разработки ПО» 69 – DoD (Definition of Done) – критерий готовности, некий формальный набор работ/меро- приятий, свидетельствующий о законченности задачи. В этот список могут попасть авто-тесты, документация и проведено ревью. Набор необходимых условий для решения задачи. – Acceptance Criteria – критерии приемки, конечный набор свойств системы, говорящий о том, что задача выполнена. Набор достаточных условий для решения задачи. – Технические задания по ГОСТу или нет – ёмкие опросники со множеством вопросов, которые раскрывают перечень различных требований. – Есть еще некоторый набор интересных подходов CLEAR, PURE, CPQQRT Какой же метод выбрать? В чем компромисс? Вам необходимо находить баланс между стоимостью процессов аналитики и качеством реализации ожиданий. Можно долго и дорого собирать, формализовывать и выполнять требо- вания, а можно использовать более простые модели формализации. Так или иначе за более простую модель придется заплатить исправлением неправильно сделанной работы в некоторых отдельных случаях. Для начала давайте решим, за какие задачи бизнес готов платить больше – обычно это более ценные для него самого задачи. Иногда для бизнеса ошибка даже в незначительном вопросе может привести к катастрофическим последствиям. Таким образом вырабатываются критерии задач, требующие более детального описания: – Задачи, имеющие высокую ценность для бизнеса – Задачи, ошибка в которых будет дорого стоить для бизнеса В. Большаков. «Настольная книга тимлида разработки ПО» 70 Методы оценки задач, риски Зачем оценивать задачи? – Для планирования и понимание того, когда и какой функционал может появиться – Для оценки экономической целесообразности реализации этой задачи – Для оценки эффективности работы команды Оценить можно только ту задачу, в которой можно провести правильный аналитический анализ. Это означает, что требования были собраны полностью, они не противоречивы и выра- жены понятным недвусмысленным языком. Как происходит оценка: – Ознакомление с требованиями задачи, уточнение вопросов. – Проектирование решения, валидация спроектированного решения. – Декомпозиция спроектированного решения. – Оценка сложности и объема исполнения, а также рисков, связанных с реализацией и процессом. Точность оценки напрямую влияет на трудозатраты. Она зависит от знания командой кодовой базы проекта, умения проектировать в уме решения, способности оценивать риски и размера задачи. Качественный и вдумчивый подход к описанию задачи, предварительному анализу кодовой базы, точному проектному решению и детальному рассмотрению рисков – залог более точной оценки. Обычно этот критерий не придается особому значению и зря – он напрямую связан с планированием, которое определяет выполнение или невыполнение ожи- даний бизнеса. Оценка НЕ РАВНО (≠) срок реализации. Оценка – это длительность выполнения задачи. Срок реализации – это результат процесса планирования оцененных задач. Единицы измерения оценки задач: – Человеко-часы или человеко-дни, реже недели или месяцы – Понятная для заказчика единица измерения. С помощью нее удобнее планировать и легче оперировать в обсуждении команды. Минусы при такой оценке сложно закладывать риски, их нужно заблаговременно выявлять и иногда обосновывать. – Story points – измеряют усилия, которые нужны, чтобы выполнить элемент Бэклога Про- дукта или любой другой отрезок работы. Сами по себе эти количественные оценки не важны. Важно то, как оценки разных элементов соотносятся друг с другом. История, которой присво- ено значение 2, должна быть вдвое больше истории со значением 1 и соответствовать двум третям истории со значением 3. – Менее понятная для заказчика единица измерения, но более удобная для команды, поскольку не требует обоснования рисков. Команда уходит от проектного решения и опирается на субъективное мнение объема и сложности задачи. Оценка заведомо менее точная, поэтому применяют числа Фибоначчи, закладывающие пропорциональные риски. – У разных команд будет разный размер Story point. Не стоит приводить их в соответствие без особой необходимости. – Для ориентации команды на смежные величины, можно делать отсылку к конкретной задаче, которая была оценена в 1sp. – Без оценок – В некоторых процессах подход к планированию, оценке экономической целесообраз- ности и оценке эффективности команды может решаться другим способом – в этом случае оценка не нужна. Например, в процессе ServiceDesk (поддержка пользователей) есть норма- тивы по решению задач (SLA), в которые необходимо укладываться. Другой пример, в Kanban непрерывная ручная приоритезация задач обеспечивает их выполнение в срок. В. Большаков. «Настольная книга тимлида разработки ПО» 71 Существуют различные техники оценки задач: – Покер планирование (с вариациями оценки Фибоначчи, размерами футболок, выкиды- ванием значения на пальцах) – игра с принятием индивидуальных решений по оценке и груп- повым анализом индивидуальных оценок. – Диаграмма сходства (Affinity Mapping) – объединения схожих по трудности/объ- ему/рискам задач в группы. – Дерево декомпозиции – классическое разбиение задачи на части и их оценка. – Сортировка задач – упорядочивание задач по шкале времени. В. Большаков. «Настольная книга тимлида разработки ПО» 72 Планирование и декомпозиция задач Планирование – это оптимальное распределение ресурсов для достижения поставлен- ных целей, а также деятельность (совокупность процессов), связанная с постановкой целей (задач) и действий в будущем. «Любой план – это ложь!», сказал мне как-то топ-менеджер Zara в процессе автоматиза- ции их склада. Но зачем люди этим занимаются? Выстраивание планов – это поиск, попытка привести действия команды к наиболее оптимальному получению результата. В зависимости от глубины планирования (час, день, месяц, год и т.д.). Планирование может определять, какой объем работ/задач будет выполнен в установленный промежуток вре- мени или может отвечать на вопрос, когда будет закончен тот или иной этап работ. Обычно необходимо ответить на вопросы – какие задачи будут решены за следующую итерацию (спринт) или когда будет завершен проект? Планирование проектов – это отдельная область, описанная в PMBOK, Prince2 и других гибких методологиях. В основном такое планирование опирается на: – выявление задач – нахождение и выстраивание параллельной работы – нахождение зависимых задач и решение задач критической цепи Планирование проектов производится с помощью Диаграммы Ганта. Для планирования итераций (спринтов) можно также применить принципы планирова- ния проектов, но в упрощенном варианте. Однако будет полезным не только выявлять зави- симости и критический путь, но и распараллелить работы. В повседневном планировании вы занимаетесь распределением задач между исполнителями или установкой определенных пра- вил распределения задач. Декомпозиция нужна для задач, которые велики по размеру (и это несет бóльшие риски для планирования). Работы задачи можно распараллелить или синхронизировать их испол- нение и ожидания бизнеса. Задачу можно разбить на бизнес-ценные части (что рекомендует Scrum) или технические подзадачи. Обычно разделение на бизнес-ценные части нужно для промежуточной валидации с бизнесом, чьи ожидания мы выполняем. Техническая декомпо- зиция задач зачастую нужна для точного планирования, она упрощает работу с зависимостями и позволяет распараллелить некоторые задачи. Для избегания психологических блоков и улучшения производительности, команда в повседневной работе должна видеть только часть бэклога продукта – ту, над которой рабо- тает сейчас и ее ближайшую перспективу. В. Большаков. «Настольная книга тимлида разработки ПО» 73 Делегирование и эскалация Делегирование – процесс передачи части функций другим членам команды. Принципы делегирования: – ожидаемые результаты – обозначить ответственность – наделить необходимыми правами (всестороннее делегирование, но без избыточных прав) – делегирование лицу, имеющему необходимые компетенции – своевременность делегирования – отсутствие конфликтов по части ответственности – поддержка при выполнении функций – возврат полномочий (обозначить время/событие и процесс) Отчасти делегирование схоже с постановкой задачи, только в этом процессе передаются не конкретные задачи, а зона ответственности за определенный процесс. Эскалация – передача ответственности за решение проблемы на уровень руководителя. Необходимо понимать полномочия, в рамках которых вы действуете в организации, и вопросы, которые вы не можете решить в силу своих компетенций. В случае, если вы объ- ективно оцениваете свои возможности и то, что вы не справляетесь с рядом вопросов – пере- дайте их на уровень выше. Не затягивайте с эскалаций, время, потраченное на попытки решить непосильную проблему самостоятельно, может быть сэкономлено своевременной эскалацией. Эскалация применяется в проектном управлении с точки зрения работы с рисками. Также данный термин можно встретить в работе служб поддержки, так называется переход заявки на более старшую линию поддержки. Шаги эскалации в проектном управлении: – Проинформировать вышестоящее лицо, имеющее полномочия решить проблему – Проанализировать причины проблемы и ее потенциальное влияние – Разработать несколько альтернативных решений проблемы и оценить их достоинства и недостатки – Описать ситуацию вышестоящему лицу, с вариантами решения и собственными реко- мендациями – Объяснить последствия несвоевременного решения проблемы – Задокументировать результаты эскалации и зафиксировать извлеченные уроки В. Большаков. «Настольная книга тимлида разработки ПО» 74 Повседневный контроль задач Для разных процессов повседневный контроль задач будет отличаться. Так или иначе он сводится к: – получению сводной информации по прогрессу задач – выявлению задач, где необходимы управленческие решения – решению проблем и задач Что может дать сводную информацию по прогрессу? – Для всех процессов полезными будут встречи (ежедневные, еженедельные), частота зависит от среднего показателя размеров задач. – Для итерационных процессов применяется диаграмма сгорания – Для Kanban используется скорость потока задач за вчерашний день, скорость прохож- дения через каждую из колонок и весь процесс в целом. – Для ServiceDesk необходима поддержка показателей SLA, а также количество посту- пивших и решенных задач. Старайтесь не использовать микроменеджмент и делать работу сотрудников более про- зрачной за счет логирования работы, актуализации статусов задач и оставшегося времени. Те, кто пропустил плановую встречу, могут поделиться информацией в чате, ответив на те же вопросы, что задавались бы на встрече. Автоматизируйте повседневную работу с помощью ботов, которые напомнят сотрудни- кам о: – Зависших задачах – Актуализации статусов, оставшемся времени по задачам и логировании затраченного времени на задачи – Текущих метриках спринта, показателях эффективности В. Большаков. «Настольная книга тимлида разработки ПО» 75 Прием результатов Важная процедура с точки зрения контроля качества выполненной работы. Если не кон- тролировать качество – оно будет со временем ухудшаться. Для разработки контроль качества складывается из принятия технического решения и приемочного тестирования. Также важный аспект – осознание своей ответственности как тимлида, за прохождение приемочных тестов. Даже если в вашей команде есть тестировщик, и он проверил качество выпускаемого продукта, вся команда несет ответственность за итого- вый результат и окончательное решение заказчика. Вы, как представитель этой команды, при- мите на себя весь негатив заказчика, если он найдет то, что тестировщик мог упустить из виду. Переделывать задачу всегда дороже чем на раннем этапе потратить больше времени на определение правильного вектора действий. Хотя, если мы вспомним про компромисс на этапе постановки задач, то придем к неизбежности переделывания некоторых из них, ведь подобные ошибки способствуют поиску компромисса. Для улучшения модели поиска компромисса, умений и знаний сотрудников проекта/про- цессов и инструментов необходимо проводить Review выполняемости задач. Постепенно улуч- шая процессы и подходы к работе, вы сможете повысить результативность команды и реали- зацию ожиданий бизнеса. В. Большаков. «Настольная книга тимлида разработки ПО» 76 Технический лидер Компетенция в разработке важна для понимания проблем команды, возможности помочь с выполнением задач, а также для контроля выполнения задач. Поскольку тимлид ответственен за результаты команды, он уделяет много внимания про- цессам и качеству выполнения всех задач. Для улучшения отдельных видов работ и результа- тов в целом вводятся регламенты, средства технического контроля и автоматизация. Существует 2 варианта технического надзора в команде: – Первый – нет технического лидера, команда самостоятельно решает, что и как сделать по каждому виду работ. Возможно использование cross-review. – Второй – техническим лидером команды является тимлид. Он организовывает процесс технического контроля над результатами отдельных работ и общих итогов. Иерархия технического надзора может быть сложной. Например, в компании могут быть технические лидеры по отдельным видам компетенций. Такие лидеры будут задавать стан- дарты и определять вектор развития технологии в компании. Помимо этого, может быть роль Архитектора, которая совмещает техническое лидерство по множеству компетенций. За что отвечает технический лидер: – План будущего использования технологии – Стандарты, регламенты, ограничивающие способ использования технологии в компа- нии и отдельных проектах – Контроль технологических стандартов и регламентов в отдельных частях работ или итоговых результатах В данном случае роль может включать подроли Владельца и Менеджера процесса управ- ления технологией. Эти подроли могут быть делегированы. Например, тимлид определил стан- дарты и регламенты, а за счет code cross-review делегировал роль менеджера, контролирующего соблюдение стандартов. Встречаются и случаи, когда компетенция в разработке у тимлида ниже, чем у чле- нов команды. Фокус тимлида будет строиться на итоговых результатах и командной работе. Вопросы принятия технических решений необходимо делегировать более компетентным кол- легам, в целом опираясь в принятии решений на мнение других. В противном случае тимлид может прослыть самодуром. В. Большаков. «Настольная книга тимлида разработки ПО» |