Inject Agile practices for project health
Записи с метками метрики
Outstaffing. Критерии приемки.
15 Ноябрь
Продолжая начатую ранее тему о сервисной природе разработки ПО (см. Делаем проекты или предоставляем сервис?) хочу ее продолжить. Сразу скажу, к чему относится и к чему не относится данный материал.
ОТНОСИТСЯ к моделям бизнеса типа outstaffing, т.е. когда заказчик покупает команду на продолжительный период и в бОльшей мере сам управляет ее деятельностью, а также выдачей и приоритезацией требований. Причем здесь может и не быть четко определенных заранее сроков, объемов работ, бюджетов. В качестве примеров могут быть: поддержка пользователей, поддержка и развитие продукта, аутсорс какой-либо функции – например тестирования, просто долгосрочная разработка продукта, перетекающая в развитие и т.п. В этом случае предоставляется сервис.
НЕ ОТНОСИТСЯ к ярко выраженной проектной деятельности (определены начало и конец проекта, требования, бюджет) и-или присутствует контракт типа Fixed Price. А в этом случае делается проект.
Речь пойдет о критериях приемки такого сервиса (aka SLA), точнее о количественном определении так называемого performance (качество и количество работы). Количественное определение – использование данных, метрик, KPI, фактов и т.п. Или, другими словами, как объективно понять, что работа делается хорошо.
Основной вопрос – а зачем это надо? Тут может быть несколько вариантов, причем и по «и» и по «или» принципам:
- Есть договоренности с заказчиком (в том числе контрактные) об ожидаемых параметрах performance-а
- Есть внутренние корпоративные ожидания об ожидаемых параметрах performance-а
- Есть конкуренты, делающие подобную работу, т.е. надо понимать, что мы не хуже, стремиться к лучшему
- Есть, как ни странно
, желание выявлять и устранять проблемы до их возникновения, а не заниматься пожаротушением - Есть необходимость адекватной аттестации персонала, т.е. основанной в т.ч. на показателях performance-а, а не на субъективных ощущениях. Таким образом думающие, ответственные, производительные сотрудники оцениваются по заслугам и имеют больше перспектив
- Есть система премирования, которая в отсутствии объективных показателей становится деморализатором
- Есть (а вот это уже совсем странно ) потребность улучшать рабочие процессы, например, уменьшить стоимость, увеличить «отдачу», улучшить качество и т.п.
Теперь собственно, какие критерии приемки сервиса могут быть. Их можно напридумывать много, но важно выбрать именно те, которые помогут объективно оценивать и управлять вариантами, описанными выше, и именно для вашей специфики.
Собственно примеры критериев:
- Среднее количество закрытых запросов (задач) на человека (на команду) за период времени
- Допустимый % простоя (использования) ресурсов
- Количество или % возврата запросов (задач) по отношению к сделанным
- Количество или % дефектов, обнаруженных заказчиком, в т.ч. по отношению к обнаруженным при внутреннем контроле качества
- Доля затрат на устранение дефектов и переделки
- Плотность дефектов на единицу объема работ
- И др.
Пример из реальной жизни. Для работ по поддержке продукта, где в команду поступают запросы на мелкие улучшения и на устранение дефектов были выбраны и настроены следующие метрики: среднее количество закрытых запросов на человека в месяц, % возвращенных (т.е. дефектных) запросов, загрузка команды. Для каждой метрики были определены допустимые пределы, основанные на ожиданиях заказчика и performance-е конкурирующих команд. Метрики регулярно собираются, анализируются, и по результатам принимаются решения.
Для того, чтобы сбор метрик не стал ночным кошмаром его нужно делать в следующих условиях:
- Соответствующие люди понимают зачем эти метрики нужны и способны ими пользоваться, т.е. анализировать и принимать решения на их основе
- Сбор «сырых» данных для метрик автоматизирован, это достигается несложной разовой настройкой инструментария – тайм-, таск, дефект- трекеры.
- Процессы работы настроены, люди обучены, иначе метрики будут показывать совершенно разнородные результаты
Позволю себе в контексте данной темы еще раз сослаться на справочный источник из предыдущей статьи, но теперь уже на конкретные разделы – «Quantitative Work Management» и «Measurement and Analysis», Модель «CMMI for Services, Version 1.3» (http://www.sei.cmu.edu/library/abstracts/reports/10tr034.cfm).
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
Выступаю с докладом на SPM Conf – “Почему размер имеет значение?”
4 Ноябрь
Выступаю (Сергей Поволяшко) с докладом “Почему размер имеет значение?” на конференции SPM Conf в Минске. Доклад посвящен такой основополагающей, но мало раскрытой теме как размер ПО. «Что-что?» – спросит большинство читателей, хотя многие из нас на самом деле уже сталкивались с этим самым размером, или решали вопросы адекватного определения качества и количества работы.
Ну вот, например:
- Как понять, что 100 дефектов обнаруженные в очередном релизе это много, мало или допустимо?
- Как оценить так часто упоминаемый «performance» команды или человека? Что это в цифрах и фактах?
- Как конкретизировать ожидания по качеству и количеству работы?
В основе ответов на эти вопросы лежит понятие размера. Понятие размера также просто необходимо для применения в метриках разработки ПО и предоставления сервисов. Размер – это реальный объем работ, не зависящий от квалификации исполнителей, и собственно за который заказчик платит деньги.
Наиболее древний и справедливо критикуемый способ определения размера – это строки кода – LOC. Наиболее «свежий», широко применяемый, но зачастую некорректно – это Story Points. Как еще определять размер, зачем, и какая от этого польза – в моем докладе на конференции. Презентацию доклада опубликую после выступления.
Кстати, тема размера, как основополагающая для применения в метриках, будет рассмотрена в составе запланированного тренинга:
- «Метрики: команды, проекты, процессы и код», Киев, 23-24 ноября
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
Кому же нужны метрики?
24 Июль
Проведя много тренингов и семинаров по измерениям в разработке ПО сделал некоторые наблюдения. Наблюдения связаны с реакцией слушателей на излагаемый материал. Причем реакции разнятся – от полного безразличия до восторга. Ниже попытаюсь порассуждать, кому же и когда метрики таки нужны, а кому еще рановато о них думать. Надеюсь мои рассуждения будут полезны еще и в преддверии запланированного тренинга по метрикам.
Уважаемые слушатели прошедших тренингов, если вы это читаете, то примите глубокое уважение и благодарность с моей стороны. Без вас я бы не смог совершенствовать материалы, да и эта статья не появилась бы.
Попробую категоризировать реакции слушателей и собственно проанализировать, почему они именно такие. Причем в определенную категорию попадали как отдельные слушатели из какой-то группы, так и почти целиком вся группа.
- Безразличие, или мне(нам) это не надо, и вообще о чем это. Встречается там, где и так все нормально, т.е. заказчик и руководство довольны (или думают что все хорошо , и поэтому довольны), существенных проблем нет, или к ним относятся очень снисходительно. Хорошо настроенных рабочих процессов тоже нет, но т.к. компания молодая, или небольшая, то все на виду и все вопросы можно преспокойно решать ручным управлением. Или же все настолько благоденствуют (я без сарказма, такое тоже бывает), что напрягаться по поводу метрик и не надо. И действительно, зачем (опять же без сарказма )? Но это обычно долго не длиться, рано или поздно возникают вопросы типа: Почему вы так медленно работаете? Почему у вас столько дефектов? Да у вас же на устранение дефектов уходит больше времени, чем на разработку! Почему вы никогда не можете более-менее точно спрогнозировать, когда же вы закончите? И тому подобное. А возразить-то особо нечего, т.к. непонятно как это все объяснить.
- Мягкий отпор, или мы тут работу работаем, нам не до метрик. Это следующая ступень после первой. Итак, посыпались вопросы, проблемы. Их надо решать, а то заказчик платить перестанет. К сожалению, обычно мы боремся с последствиями, а не с причинами, и в таком состоянии зависаем. И боремся экстенсивными методами, такими как внеурочная работа, выкидывание «ненужных» видов работ (тестирование, ревью кода, специфицирование и т.п.). Просто педалим. Тут действительно не до метрик. Но вот здесь уже 100% нужно задумываться если не о метриках как таковых, то о базовых шагах по решению проблем. Рецепт прост как тот факт, что солнце каждый день всходит и заходит (исключая полярные дни и ночи J). И по счастливой случайности он совпадает с основными условиями внедрения метрик. А именно, для наведения порядка нужны 3 вещи:
- Процессы. Они вообще-то должны быть, формализованные в удобном для использования виде. Повторяемые, независимо от того, кто делает. Взаимосвязанные друг с другом, например, на выходе кодирования должен быть чистый работающий код, который расположен в оговоренном месте, снабженный релизной запиской, и обо всем этом должны узнать тестировщики. Соответственно, у тестировщиков должно быть понимание как этот код запустить, по отношению к какой версии требований тестировать и т.п. Видите, сразу идет связка таких инженерных практик и специальностей как бизнес анализ, кодирование, ревью кода, юнит тесты, тестирование, создание тестовой документации, и т.п.
- Инструментарий. Тут все просто, это поддерживающие вашу работу таск-тайм-баг трекеры и прочий автоматизирующий инструментарий. При правильной настройке полей и workflow данные собираются и отображаются без особых усилий.
- Люди. Должны быть достаточно профессиональны, чтобы в правильном порядке и виде использовать инженерные и управленческие практики, подточить их под нужды проекта. А также выбрать и настроить инструментарий, или хотя бы грамотно использовать существующий. При определенной инициативе можно переходить к метрикам, т.е. к следующему уровню.
- Осторожная заинтересованность, или вот ведь как еще можно делать. Тут, и в следующих уровнях работать со слушателями одно удовольствие, т.к. мы настраиваемся на одну волну, и в процессе тренинга приходим к решению конкретных задач слушателей. Пусть и не сразу речь заходит о метриках, но вырисовываются причины проблем. Чаще всего ими бывают или ненастроенные процессы, или инструментарий, или просто не хватает подготовки у людей в области процессов, измерений и улучшений.
- Одобрение и продуктивное обсуждение. Вот тут уже хорошо чувствуется профессиональная зрелость слушателей. Или же явно видно, что есть какие-то проблемы, для решения которых недостаточно просто капать на руководство, заказчика или кого-то еще. А требуются именно цифры и факты, на основании которых могут приниматься качественные управленческие решения. Т.е. тренинг является именно тем катализатором, который побуждает к внедрению измерений и, как следствие количественному управлению. Так, в одном из случаев, элементарный сбор статистики о причинах возникновения дефектов (defect origin), побудил к совершенствованию работы именно проблемного подразделения (наконец-то), и отставил претензии к подразделению-пользователю этих проблем.
- Полная поддержка и обмен опытом по внедрению измерений. В этом случае слушатели или уже внедрили и пользуются метриками или тут же на тренинге обсуждаем, как именно улучшить уже работающую систему измерений. В этом случае идет продуктивный обмен опытом использования метрик. Люди убеждаются на опыте коллег и материала, что идут в правильном направлении. И мне тоже практически всегда есть чему поучиться у слушателей такого уровня.
Все вышеперечисленные категории ни в коем случае не есть сугубо негативным или позитивным явлением, просто каждый человек или компания находится на определенном уровне развития или в определенных условиях, что опять же не есть хорошо или плохо.
Ах да, зачем же нам вообще нужны метрики? А чтобы принимать качественные управленческие решения и разговаривать с заказчиками и руководством на языке цифр и фактов, а не на языке ощущений своего живота или другой части тела.
Оригинал статьи здесь.
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
Неправильный эстимейт готов!
14 Июль
Около года или более назад мы с коллегами обсуждали какие инженерные и управленческие практики в разработке софта нужно явно улучшать. Естественно с великой целью сделать нашим заказчикам еще лучше. Их оказалось не так уж много, и среди них мы определили проблему неточных оценок трудозатрат, не то чтобы это было мега критично, но захотелось что-то с этим сделать. И там же придумали метрику Effort Variance, которая бы показывала насколько мы улучшаемся, и которая была рекомендована для применения. Но эта проблема вместе с метрикой были подвешенными в воздухе вплоть до недавнего времени. Т.е. в силу не_мега_критичности мы ничего с этим не делали и метрику не применяли, и тем лучше. И вот, на днях некоторое стечение обстоятельств заставило посмотреть на неправильные эстимейты по другому.
В одном из обсуждений как-то все сразу согласились, что большая точность самих по себе эстимейтов нам не важна, т.к. практически все команды работают по контрактной модели «Выделенная команда». Где нет цели любой ценой выдержать плановые эстимейты, или же понижать затраты в угоду получения бОльшей прибыли. Не то чтобы такая модель расслабляла, но в силу возникновения определенного доверия между заказчиком и командой, на неточные эстимейты смотрят сквозь пальцы. Тут важнее желаемый результат, требования к которому могут постоянно меняться, а также уровень коммуникаций. Т.е. контрактная модель или же наличие внешних требований к точности эстимейта имеют значение.
С другой стороны согласились, что проблемы с эстимейтами на самом деле возникают несколько раньше. А именно из-за неполного и-или некорректного списка работ (WBS – Work Breakdown Structure). Ведь если что-то забыли в него включить, то естественно и оценивать нечего, и, как следствие, суммарный эстимейт получается неполным. Причем, проблема неполного WBS одна из самых распространенных. Что обычно забываем: ревью кода и документации, приобретения (люди, материалы, оборудование, визы, билеты и т.п.), юнит тестирование, разворачивание системы у заказчика, настройка continuous integration, совещания, исследование и т.п. Таким образом, неправильный эстимейт даже не успевает по настоящему сделать свое черное дело, за него это делает неправильный WBS.
Правила WBS довольно простые:
- Полнота – т.е. должны быть включены ВСЕ работы
- Разумная декомпозиция – не должно оставаться объемных и-или неясных работ
- Вовлечение основных участников для определения полного вида работ
- Применение шаблонов WBS и ревью WBS.
Ну и высшим пилотажем на пути к правильным эстимейтам (хотя не такой уж он и высший, не было бы лени) является использование каких-то еще моделей оценок, помимо экспертной. Наиболее доступные это аналоговая и параметрическая (модель размера). Их описания есть в других источниках, поэтому позвольте мне их опустить. Напомню лишь, что аналоговая использует данные (эстимейты, WBS и т.п.) аналогичных проектов (фаз), а параметрическая – определяет типичные объекты работ (форма контакта, интерфейс с платежной системой, добавление новости на портал и т.п.) и относительное взаимоотношение их размера между собой. Яркий пример – story points в SCRUM.
Несколько соображений о том, зачем они нужны:
- Там, где важен точный эстимейт – рекомендуется применять больше одной модели, чтобы можно было сравнить полученные эстимейты, и при большой разбежности – пересмотреть. Плюс рекомендуется делать ревью, и эстимейтов, и WBS.
- Там, где важен быстрый эстимейт, или же возможность обходиться без эскперта (без индивидуальных оценок). Т.е. в модель можно «забить» определенные входные данные и быстро получить результат. Пример – story points в SCRUM
- Аналоговая еще может быть полезна и для предсказаний разнообразных характеристик проекта. Например, если в аналогичном проекте было найдено 200 дефектов, то в планируемом в два раза бОльшего масштаба (масштаб – человеко-часы, story points и т.п.) их будет примерно в два раза больше. Такие же аналогии можно проводить и по рискам, и по проблемам, и по метрикам, и по точности эстимейтов. И принимать соответствующие меры. Только с предсказаниями надо поаккуратней – они информация к размышлению, а не руководство к действию . Если интересно про предсказания, то есть очень научная методика COQUALMO. Сможете ли (нужно ли) ее применить – вопрос, но для общего развития рекомендую почитать.
Автор: Сергей Поволяшко, оригинал статьи здесь.
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
Метрики против диагностик
29 Июнь
Прочитал на днях критическую статью на тему применения метрик менеджерами и захотел оставить комментарий. Но он получился достаточно большой и вырос в небольшую статью.
На мой взгляд все просто – автор путает понятия метрики и диагностики. Метрика служит для прямого отображения действия, а диагностика – всего лишь для отображения следствий. Например, если я рублю дрова для заказчика, то количество нарубленных дров является отличной метрикой. И ее можно успешно использовать для поощрений, наказаний, анализа производительности. Похожим образом обстоят дела и у рабочего за станком. Метрикой в данном случае является количество готовых качественных деталей. Никого не волнует как и почему их получилось столько.
У нас в IT индустрии настоящих метрик достаточно немного. К ним можно отнести количество нарушений при статическом анализе кода, сложность кода, плотность покрытия модульными тестами (с большими оговорками), Running Tested Features, Cycle Time, Lead Time и некорые другие. Большая же часть повсеместно используемых измерений, включая приведенное автором статьи количество найденных багов заказчиком или пользователями, являются диагностиками.
Диагностика является лишь способом понять, что где-то могут быть проблемы, но никак не выявить их. Например, врач измеряет мне температуру. Если температура высокая, то есть повод разбираться детальнее – сдать анализы, пройти другие диагностики, показаться другим врачам. Но врач не ставит диагноз по одной только температуре. Так же как и не говорит, что у вас все отлично, если температуры нет. У вас могут по-прежнему быть проблемы с сердцем, печенью, глазами и прочими органами.
Теперь вернемся к примеру из статьи. Количество найденных багов конечными пользователями – очень важная диагностика для меня. Если их много, то явно где-то есть проблема и надо разбираться. Если мало, то не стоит думать, что все хорошо. Но для начала стоит проверить не мешает ли что-то правильному сбору диагностики (список возможных препятствий приведен в статье). Метрикой же она являться не может, потому что найденный баг может иметь десятки разных причин и не характеризует работу команды напрямую.
Иногда между метрикой и диагностикой очень тонкая грань. Но не осознав истинной сути измерения, можно «наделать дел». О неправильном применении метрик уже рассказано и написано много смешных историй. А что вы думаете по этому поводу? Какие еще примеры ошибочного применения вы встречали? Какие еще настоящие метрики в IT вы знаете? Буду рад услышать ваше мнение в комментариях.
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
Метрики в Scrum и Kanban
7 Февраль
По разным причинам Scrum получил очень широкое распространение среди IT компаний. Многие компании и отдельные команды начали внедрять Scrum в своих проектах. У одних это получается, у других не очень. Грамотный и опытный специалист перед внедрением чего-то нового всегда задумывается о метриках. Как убедиться, что внедрение Scrum идет по плану? Улучшается ли производительность команды? Нет ли каких-то проблем?
И тут в Scrum очень мало ответов. Кроме сугубо бизнес-метрик, которые можно применять практически в любом процессе (ROI, Earned Business Value, Running Tested Features и т.д.), в Scrum предлагается метрика Velocity. Но уже писано переписано, что использовать Velocity в качестве метрики не стоит. Это может привести к неожиданным неприятным последствиям.
Получается, что хороших метрик на первый взгляд нет. В конце статьи я упомяну некоторые неявные метрики в Scrum, но пока давайте поговорим о причине проблем. Самая главная причина – это время. Бизнес практически все измеряет временем (даже деньги – это время). А в Scrum это самое время фиксируется (быстренько все вспоминаем «железный треугольник» 
) и разработка ведется итерациями. Но внутри итерации происходит много всего интересного: мы делаем задачи, пользовательские истории, тестрируем, собираем продукт, устанавливаем и т.д. И вся эта информация теряется на фоне итерации. Происходит так называемое «сглаживание шумов». Если мы затянули с одной активностью, то можем нагнать в другой. Ведь итерация целиком принадлежит команде и команда может «придумывать» внутри итерации что угодно, лишь бы в конце все было готово. Этот подход очень хорош для планирования, но отвратителен для метрик.
Во-первых, мы очень редко можем снимать показатели метрик – в конце итерации. А это в лучшем случае раз в неделю. В основном, все таки раз в две недели. Во-вторых, мы уже упоминали «сглаживание» и оно тоже вносит свои коррективы. Всю итерацию ситуация была из рук вон плохая, а в конце все сделали нечеловеческое усилие и вуаля – все готово и метрики в порядке. Хорошо это или нет? Нет! Мы теряем полезную информацию и не учимся на своих ошибках.
Совсем по-другому дела обстоят в Kanban. Тут внимание уделяется каждой задаче. Метрики снимаются со всего потока задач, который проходит через команду разработки. Вот краткий список метрик:
- Cycle Time – время, которое задача находилась в разработке от момента, когда ей начали заниматься, до момента, когда она прошла фазу конечной поставки.
- WIP – количество задач одновременно находящихся в работе. Разделяется по разным стадиям работы над задачей.
- Lead Time – время от появления задачи до ее конечной поставки. Включает Cycle Time и время ожидания в очереди на реализацию.
- Wasted Time – время, которое задача проводит в различных очередях, а не непосредственно в работе.
- Effectiveness – процент времени, которое тратится непосредственно на работу с задачей, а не на ожидания в различных очередях.
- Throughput – количество задач, которое может выполнять команда в единицу времени (день, неделя, месяц).
Этот простой список метрик позволяет полностью понимать и контролировать процесс разработки, постоянно анализируя и улучшая его. В идеале данные метрики считаются в разрезе категорий задач (по размеру, по типу, по срочности), чтобы еще улучшить понимание происходящего и позволить точнее прогнозировать результаты работы команды.
Я обещал упомянуть о неявных метриках в Scrum. Эти метрики можно собирать, используя Burndown Chart. Вы можете анализировать его с целью определения шаблонов работы команды, рассматривая ежедневный прогресс и гладкость графика. Вы можете усилить анализ. Для этого нужно ввести категоризацию задач и строить Burndown Chart по каждой категории. Некоторые команды ведут отслеживание метрик задач внутри итерации, но на мой взгляд это несколько противоречит принципам Scrum – внутри итерации команда может работать над задачами в произвольном порядке.
Подведу итог. В Kanban метрики гораздо сильнее, чем в Scrum, но это не делает Kanban более простым в реализации подходом. Наоборот, Kanban требует от команды гораздо больше ответственности, контроля и анализа с постоянным усовершенствованием. Зато с точки зрения бизнеса Kanban гораздо более прозрачный и контролируемый.
А какие метрики применяете вы? Какие метрики хорошо работали для вас в Scrum?
10-11 февраля мы с Сергеем Поволяшко проводим тренинг «Метрики: команды, проекты, процессы и код», где моя часть будет как раз посвящена метрикам и работе с ними в Agile проектах. Я буду рассказывать о метриках на различных уровнях в разных методологиях, методике их сбора и анализа.
Новый тренинг по метрикам пройдет 10-11 февраля в Киеве
26 Декабрь
Мы подготовили совершенно новый тренинг «Метрики: команды, проекты, процессы и код», который впервые пройдет в Киеве 10-11 февраля. Этот тренинг посвящен одному из наиболее важных инструментов в руках любого руководителя – метрикам. Ведь еще Том Демарко говорил: «Невозможно управлять тем, что нельзя измерить».
С чем зачастую сталкиваются проектные команды, отделы и целые компании?
- Непредсказуемость сроков окончания проекта
- Наличие только лишь экспертной оценки объема работ, которая не всегда точна
- Регулярное пожаротушение определенных проблем, а не устранение источников их происхождения (почему много дефектов? где наибольшая проблема? требования, планирование, коммуникации или что-то еще?)
- Применение метрик без цели или их неправильная интерпретация
- Несоответствие используемых метрик тому, что действительно нужно конкретному проекту, по конкретному контракту, конкретному заказчику
- Кажущиеся сложность внедрения измерений и бюрократичность процедур измерений
- Невозможность прогнозирования качества и количества работы
- Принятие решений, основанное на субъективных ощущениях
Что делать?
Во-первых, хорошо разобраться в том, а зачем мы вообще что-то хотим измерять в конкретной компании или в конкретном проекте? Какая польза от измерений?
Во-вторых, понять структуру измерений, обеспечить адекватное соответствие подготовки людей, состояния рабочих процессов, наличие инструментария.
В-третьих, и это, наверное, самое важное, должна быть «политическая» воля со стороны руководства компании или проекта по внедрению и поддержке измерений.
Обычно, в том или ином виде, измерения применяются и развиваются, но происходит это довольно долго, и не всегда эффективно.
Поэтому, основная идея тренинга – помочь компании или проекту быстрее понять, зачем и какие измерения нужны, как их внедрить и интерпретировать. Тренинг структурирует теоретическую подготовку в области измерений и вырабатывает эффективный подход к практическому применению измерений. Что важно, вырабатывается понимание выгод измерений для бизнеса, заказчика, проектной команды. Общая направленность на практическое применение. Интерактивное изложение теории и практическая работа в группах, множество практических заданий и кейсов из реальной жизни. Тренинг направлен на практическое применение измерений (метрик) при разработке ПО в проектных командах.
На тренинге будут рассматриваться различные виды метрик: проектные, процессные, качества и кода. Участники смогут получить представление о том, какие метрики стоит использовать в современных Agile методологиях (Scrum, Kanban), а также как и когда их собирать и анализировать. Качество кода также не будет забыто и участникам будут предложены разнообразные методики и инструменты для сбора и контроля метрик кода, не позволяющих проекту «скатываться» на уровень «говнокода».
Вести тренинг будут Сергей Поволяшко и Николай Алименков. Стоимость участия – 1700 гривен за участника (обед включен). При групповой регистрации возможна скидка. Регистрация уже открыта и количество мест ограничено. Торопитесь занять себе место на этом полезном тренинге!
Семинар Сергея Поволяшко на тему «Какая польза от метрик?» 4 ноября
21 Октябрь
Сергей Поволяшко приезжает в Киев с тренингом «Управление рисками в IT проектах» 5 ноября. Данный тренинг уже упоминался в анонсах на сайте. Мы решили воспользоваться этой возможностью и провести бесплатный семинар на тему «Какая польза от метрик?» вечером 4 ноября. Ниже вы найдете всю информацию о семинаре.
Содержание семинара:
Об измерениях в разработке ПО слышали все. Но какая от польза от их внедрения? И какие необходимые условия внедрения? Подробнее рассмотрим какие измерения качества продукта есть и как их можно использовать для улучшений рабочих процессов, определения проблем, поддержки контрактных обязательств, оценки достижения целей индивидуума, отдела или компании. Также будет рассмотрен выбор действительно нужных метрик и их внедрение.
Внимание! Будет приз! За наиболее курьезную историю от слушателей, либо неправильного применения метрик, либо вынесения суждений, принятия решений на основании ощущений (без фактов и цифр). Приходите с историями, будем рады послушать и проголосовать.
Для кого:
Если вы заинтересованы в управлении деятельностью, основанном на фактах и цифрах, а не только на ощущениях, то это для вас.
Детальная программа:
- Зачем вообще что-то мерять?
- Основные концепции метрик
- Области применимости метрик
- Обзор областей
- Подробнее о качестве продукта
- Условия успешности внедрения и применения метрик
- Кейсы реального использования метрик
- Поддержка продукта
- Центр тестирования
- Слабое звено
- Вопросы-ответы
Начало семинара в 19:00. Завершение в 21:30. Точное место проведения будет известно ближе к дате семинара. Участие бесплатное, но по предварительной регистрации. Количество мест ограничено 50 участниками.
