Inject Agile practices for project health
Статьи
Что общего у холодильника и CMMI (ISO, PMBOK, …)
21 Февраль
Давно собирался написать рецензию на статью моей коллеги «Мифы о CMMI, или кому и зачем она нужна». Причем, основной идеей рецензии хотелось сделать известное выражение о пользовании, например, бытовыми приборами – «если ничего не помогает, то прочитайте же наконец инструкцию». Как-то долго не складывалось, но холодильник сдвинул дело.
Так вот, начну с холодильника. Буквально неделю назад у моих родителей случилась какая-то беда с холодильником – мигает лампочкой – о помощи просит, и морозилка плохо морозит. Поставили регулятор на более низкую температуру – не помогает, та же картина. Холодильник, к слову сказать, относительно новый и хороший. Позвали [горе]мастера. Пришел, посмотрел, подул щеки, поморщил лоб, и сказал со знанием дела – холодильник мол плохой, и ремонтировать его тяжело, скорее всего выбрасывать надо, и вообще негодяи производители делают технику на срок службы 5-7 лет, чтобы, значит, на потребителях наживаться.
Не буду томить перипетиями, перейду сразу к финалу. Оказывается, если почитать инструкцию, то при пониженной температуре окружающей среды (дело было в феврале, на улице минус 20-25С, отопление не справляется, в квартире плюс 16-17С), нужно поставить регулятор температуры на более высокую температуру, и все должно быть хорошо. Так и сделали, холодильник тут же отблагодарил, отключив лампочку помощи. НО, в инструкцию-то вчиталась мама, а не [горе]мастер, которому по долгу службы надо бы знать «физику процесса»!
Вот и напрашиваются параллели:
- Холодильник – хорошая, но зачастую недопонятая система, то ли CMMI, то ли PMBOK, то ли другая подобная.
- Инструкция – собственно документ, описывающий систему, который надо бы читать, и иногда больше одного раза. Но что поделаешь, мы же не в сказке, напрягаться надо для понимания и корректного применения с пользой для дела. Как и рекомендовано в статье, любую сложную систему нужно начинать понимать с прочтения более легковесных, доступных материалов. Сам так делаю, помогает
. - Производитель – орган, который придумал и поддерживает систему. Конечно он в том числе и денег хочет заработать, так же как и производитель холодильника. Но великая-то цель – применение на практике консолидированного опыта предыдущих поколений специалистов, написанного кстати пОтом и кровью. Иначе зачем нам холодильник? Давайте лед с северного полюса возить.
- Лампочка с регулятором – необходимость и способы «заточить» (по-научному – tailoring) систему под ваши нужды, чтоб она никого не напрягала, работала и была полезна.
- [Горе]мастер – без обид, это мы, делающие суждения о «работает-неработает», «плохая-хорошая» та или иная система, не разобравшись зачем она, какая к ней инструкция, и как ее правильно настроить.
- Мама – это тоже мы, но, соответственно, разобравшиеся… И заслуживающие профессионального уважения.
Да, статья и комментарии к ней здесь, рекомендую потратить 10 минут, оно того стоит.
Использование ASP.NET MVC валидационного механизма, без ASP.NET MVC
19 Февраль
В своей практике использования фреймворка ASP.NET MVC, я очень привык к DataAnnotations аттрибутам, для валидации классов модели. В самом деле, это отличный подход. Аннотируешь модель соответвующими аттрибутами, всю остальную работу делает фреймворк. Простым вызовом ModelState.IsValid внутри екшина, можно узнать состояние модели.
Во время реализации одной из фич, для candidate я подумал, что мне нужна похожая валидационная модель, для моих классов, но без использования самого MVC фреймворка. А именно, для класса типа Github.cs я хочу знать, «сконфигурирован» он или нет. И «сконфигурирован» == «валиден», в моем контексте. Вместо того, чтобы писать кастомный код, который бы проверял все свойства на предмет заполненности, я хотел сделать тоже, что делает ASP.NET MVC, через DataAnnotations. Самое крутое, что это оказалось возможным, причем сделать это очень просто.
Простое начало
Предположим, есть такая модель:
public class SimpleModel
{
[Required]
public string SomeProperty { get; set; }
[Range(0,50)]
public int SomeAnotherProperty { get; set; }
}
Если, наша цель, просто получить ответ «да» или «нет» (валидна или нет), мы можем сделать такую функцию:
public bool ValidateSimpleModel(SimpleModel validate)
{
return Validator.TryValidateObject(validate, new ValidationContext(validate, null, null), null);
}
Validator это статический класс, находящийся в неймспейсе DataAnnotations. Он принимает целевой объект, валидационный контекст и коллекцию результатов валидации. Но в силу того, что он лишь «пытается» выполнить валидацию, почти все эти параметры могуть быть null.
Использование результатов валидации
Если нужна более специфическая информация, как – какое именно свойство невалидно, то можно использовать ICollection<ValidationResult>.
public ICollection<ValidationResult> ValidateSimpleModel(SimpleModel validate)
{
var validationResults = new List<ValidationResult>();
Validator.TryValidateObject(validate, new ValidationContext(validate, null, null), validationResults);
return validationResults;
}
В том случае, когда объект находится в невалидном состоянии, этот метод вернет коллекцию ValidationResult, которая содержит всю релевантную информацию.
Оборачиваем все в екстеншн метод
Наконец-то, я сделал просто екстеншн метод, с помощью которого можно применить DataAnnotations валидацию, к любому объекту:
public static class ValidatorExtensions
{
public static bool TryValidateObject(this object validate)
{
return Validator.TryValidateObject(validate, new ValidationContext(validate, null, null), null);
}
}
Теперь, модель может иметь метод IsValid() типа:
public bool IsValid()
{
return this.TryValidateObject();
}
Для той простой задачи, которую я пытался решить, это сработало просто отлично!
Оригинал статьи – http://www.beletsky.net/2012/01/using-aspnet-mvc-validation-mechanism.html
Новые инструменты в моем арсенале TDD
17 Февраль
Недавно, я открыл для себя 3 новых интструмента, которыми хочу поделится с вами. Более точно, это один инструмент и два фреймворка. Посмотрим!
NCrunch
NCrunch это просто потрясающее расширение к Visual Studio созданный @remcomulder. Он детектирует все тесты в вашем солюшине и перезапускает их как только исходный код меняется. Забудте про ручной запуск тестов навсегда, это просто потеря времени. Вам даже не обязятельно нажимать Ctrl + S, просто продолжаем кодить как и раньше.
Сначала, я очень скепртически относился к подобным инструментам, но NCruch изменил мое мнение. Он поддерживает все главные юнит тест фреймворки как NUnit, XUnit, MSpec etc. Кроме того, он позволяет собирать метрики покрытия (которые, отображаются прямо в VS редакторе), запуск тестов в дебаггере, поддержка многих ядер и т.д.
NCruch, это то что сделает ваш TDD более «гладким», позволяется сфокусироваться на главных вещах и отвлечся от рутины.
NSubstitute
На протяжении долгого времени, я был приверженцем Moq фреймворка и не видел причин его менять. До того как появился NSubsitute. Я с трудом представляю, что может двигать разработчиками, которые начинает делать «еще один фреймворк для моков», кажется, что это не имеет смысла. Но эти ребята доказывают, что я не прав.
Итак, что там нового? Во-первых это очень понятный API. Никаких тебе new Mock() или MockGenerator.GenerateMock(), создание тестовых двойников это не более, чем Substitute.For<IEntityToMock>(). Мокирование свойств, возращение множественных результатов, поддержка событий и т.д. Для начала очень круто прочитать getting started материалы для старта.
Лучшая фича, как по мне, это то, что с использованием экстеншн методов они отказались от лямбд, для инициализации моков. Это делает код более читаемым и чистым. Я сделал маленький gist, в который поместил примеры использования Moq и NSubstitute вместе.
Я не могу сказать, что Rhino или Moq это гораздо хуже NSubstitute.. Нет, я могу сказать, что NSubstitute немного лучше их. Таже функциональность, но с меньшим количесвом кода, это серьезный аргумент для меня.
[Test]
public void should_send_an_email_if_users_signs_up_nsub()
{
// arrange
var emailService = Substitute.For<IEMailService>();
var controller = new LoginController(emailService);
// act
controller.SignUp(new SignUpModel { Email = "a@a.com", Password = "xxx" });
// assert
emailService.Received().SendEmail(Arg.Any<EmailMessage>(), "current");
}
FluentAssertions
Опять же, годами я следовал простому NUnit’s Assert.That() методу. Я также немного смотрел в сторону SharpTestsEx, но FluentAssertions от @ddoomen изменил это.
FluentAssertions также основан на екстенш методах, и позволяет избавиться от вызова Assert.That, применяя ассерты непосредсвенно к объекту. Пару примеров:
{
// NUnit.Assert style..
Assert.That(result, Is.EqualTo(3);
// FluentAssert style..
result.Should().Be(3);
}
Это очень простой пример. Мощь FluentAssertions проявляется тогда, когда необходим множественный ассерт на сложных объектах:
{
"somestring".Should().Contain("some").And.HaveLength(10);
}
Он также добавляет хорошую поддержку для работы с Коллекциями, Датами, Guids, Исключениями, XML и т.д. Проект размещен на codeplex, вот документация.
Выводы
Очень классные инструменты, которые я осванию сейчас и пока что впечатления очень хорошие. Большое спасибо @skalinets, которые покаазал мне их.
Оригинал статьи – http://www.beletsky.net/2012/02/new-tools-in-my-tdd-arsenal.html.
Метрики в 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 проектах. Я буду рассказывать о метриках на различных уровнях в разных методологиях, методике их сбора и анализа.
Стоимость качества. Часть 3 – Как это посчитать?
30 Январь
Завершая серию статей о стоимости качества подходим к практической части, а именно, как это посчитать? Для того, чтобы были конкретные данные, на основании которых можно было бы принимать какие-либо управленческие решения. Напомню о предыдущих статьях и для начала рекомендую их прочесть: «Стоимость качества. Часть 1 – Что это такое?», «Стоимость качества. Часть 2.1 – Зачем это надо?», «Стоимость качества. Часть 2.2 – Кому это надо?».
Так как сбор и интерпретация данных относится к дисциплине метрик, то здесь стоит обратить внимание на классический треугольник успешности и полезности измерений:
- Люди – должны быть обучены данной дисциплине, по крайней мере понимать зачем все это. И, естественно, должны иметь возможность (санкционированное время, желание, инструментарий и т.п.)
- Процессы – должны быть. Все рабочие процессы, например: как мы готовим тестовую документацию и тестируем, жизненный цикл дефекта, жизненный цикл задач и т.п. должны быть в том или ином виде описаны-оговорены и донесены до исполнителей
- Инструментарий – собственно те технические средства, которые помогают людям делать их процессы – тайм трекеры, баг трекеры, таск трекеры и т.п. Именно они, при корректной интеграции в процессы работы и при соответствующей настройке, позволяют и собирать данные, и обрабатывать, и презентовать.
В этой статье поговорим именно об инструментарии.
Для начала обратимся к такой дисциплине как Scope Management – управление объемом работ по проекту. В первую очередь это правило 100%, т.е. список работ по проекту должен отражать абсолютно ВСЕ работы и им должно быть место в расписании работ, плановые и фактические трудозатраты по ним должны быть оценены и отрапортованы. ВСЕ – в т.ч. инспекции документов, устранение дефектов, совещания, и даже участие в интервью по набору персонала на проект…
Хорошо помогают шаблоны списков работ (WBS – work breakdown structure).
Ключевым моментом является такая декомпозиция списка работ, где были бы выделены отдельные задачи (берем для примера разработчика), и, соответственно временнАя отчетность на:
- Инспекцию спецификаций (COQ)
- Разработку архитектуры
- Юнит тесты (COQ)
- Кодирование
- Инспекцию кода (COQ)
- Устранение дефектов после тестирования (COPQ)
- Разворачивание продукта в тестовом окружении
- Устранение дефектов по гарантийным обязательствам (COPQ)
- Устранение дефектов после инспекции кода (COPQ)
- И т.п.
В скобках указаны интересующие нас категории – COQ, COPQ. На самом деле, отнесение некоторых задач в какую-то категорию – это ваше решение, например, юнит тесты можно отнести и в разработку. Общие же рекомендации что есть что приведены в первой статье «Стоимость качества. Часть 1 – Что это такое?».
Как далеко идти с декомпозицией – решать вам в зависимости от того, что нужно и что вообще имеет смысл. Например, устранение дефектов после тестирования можно отнести как в общую для всех разработчиков задачу «Устранение дефектов», так и разделять, например, по модулям – «Устранение дефектов по модулю №1» и т.д.
Таким образом, если у вас есть такие компоненты:
- Корректная декомпозиция работ
- Таск-тайм трекер, который позволяет отразить и декомпозицию, и отчетность о затраченном времени
- Обучающие меры для сотрудников – как пользоваться таск-тайм трекером
То сбор данных по соответствующим категориям у вас настроен, и что немаловажно, интегрирован в рабочие процессы. И вы легко можете получать информацию о стоимости качества.
Конечно же, возникают некоторые тонкости в организации и процессов работы, и инструментария. Давайте посмотрим на примеры.
Что такое дефект и как его учитывать? Обычно, если тестировщик находит дефект, то он (дефект) попадает в систему управления дефектами как отдельная запись с описанием, серьезностью и другими параметрами. Но ведь дефекты, найденные, например, на инспекции кода, по существу, ничем не отличаются от дефектов, найденных тестировщиком. И они обычно никак не учитываются, в лучшем случае фиксируется время, потраченное на инспекцию кода. Но возникает резонный вопрос – а зачем это надо вообще? Если уж вы решили определять стоимость качества, то нужно, как минимум фиксировать время на инспекцию кода и время на исправление дефектов, найденных при инспекции. Если вам это не нужно – то не делайте, это будет пустая трата времени и раздражающий фактор для сотрудников. Если вы хотите таки фиксировать не только время на инспекцию, то можно осторожно попробовать использовать систему управления дефектами – например на каждый факт инспекции внести одну запись, к которой приложить список дефектов в коде. По крайней мере необходимость исправить код не потеряется и у вас будут данные о результатах инспекции.
Интенсивная работа с требованиями. А что если требования обсуждаются настолько интерактивно между заказчиком, аналитиком, разработчиками, тестировщиками, что четкая разница между формализацией требований, их инспекцией (обсуждениями) и устранением дефектов (рекомендации, выданные при обсуждениях) не видна? Или же не имеет смысла это разделять. Тут, наверное, лучший вариант – без фанатизма, просто отнести такой вариант работы в задачу «Разработка требований», т.е. к COQ или COPQ не относить вообще. Если же такого интерактива нет, а есть четкое разделение на формализацию, инспекции, и исправление дефектов, и, внимание!, вам действительно надо выделять COQ и COPQ, то предлагаю такой же подход, как и в предыдущем примере – с использованием системы управления дефектами.
Завершая цикл хочу сказать, что серьезно «заводиться» со стоимостью качества и метриками стоит лишь в том случае, если у вас есть:
- Великая цель – зачем это делать и кому от этого будет лучше
- Подготовка по теме – как это работает
- Здравый смысл – в разумной реализации Великой цели
Надеюсь, что это было вам полезно.
Оригинал статьи здесь.
Стоимость качества. Часть 2.2 – Кому это надо?
23 Январь
Продолжаю серию статей о стоимости качества. Две предыдущие: «Стоимость качества. Часть 1 – Что это такое?» и «Стоимость качества. Часть 2.1 – Зачем это надо?». В этой же статье рассмотрим «Кому это надо?». Очень рекомендую обратить внимание на предыдущие статьи, т.к. они представляют собой логическую цепочку рассуждений.
Здесь рассмотрим, в каких ситуациях следует (или не следует) озаботиться стоимостью качества и относительной величиной его доли в общем объеме работ. Давайте рассмотрим несколько вариантов. Но для начала вспомним классическую диаграмму стоимости изменений (Cost of Change), но будем ее понимать в контексте стоимости устранения дефектов, т.к. график по своей сути не меняется.
Смысл в том, что чем дальше мы продвигаемся по времени, тем дороже обходится устранение дефектов. Например, если не удалось выявить несоответствие в требованиях вначале (что на самом деле очень дешево сделать), то потом скорее всего придется «перепедаливать» на значительно бОльшую сумму.
Представленный ниже список вариантов далеко не исчерпывающий, рассмотренные ситуации и выводы по ним в вашей деятельности могут отличаться от приведенных ниже. А также могут быть и комбинации этих вариантов.
Вариант 1. Проект типа Fixed Price.
Соответственно, и скорее всего, помимо бюджета четко зафиксированы объем работ и сроки. Здесь нужно в первую очередь обращать внимание на требования и критерии приемки. Оставим в стороне дискуссию о возможной неполноте и изменчивости требований, о применимости этого типа контракта, это регулируется другими механизмами. Здесь становиться очевидным, что нужно стараться минимизировать COPQ, т.к. это напрямую влияет на доход и, возможно, на штрафные санкции, и-или на расходы по гарантийным обязательствам. Но с другой стороны минимизация COPQ выражается в увеличении COQ, и тут тоже нужно не переусердствовать. На помощь приходит вышеуказанная диаграмма «Стоимость устранения дефектов». Напрашивается вывод, что имеет смысл уделить особое внимание процедурам из COQ как можно раньше. А именно – постановке процессов обеспечения качества и реализации мер контроля (инспекции спецификаций, архитектуры, кода, тестовой документации и т.п.). См. подробности в статье «Стоимость качества. Часть 1 – Что это такое?». Стоимость процедур COQ легко считается и планируется, и также легко соотносится со штрафными санкциями.
Кому это надо? Компании Исполнителю, т.к. это ее доход и репутация. Говоря о процедурах из COQ, то немного бОльший фокус должен быть на эти меры на начальных стадиях, т.к. последствия от их неприменения скорее всего аукнутся относительно бОльшими расходами на COPQ.
Вариант 2. Служба поддержки (или любая деятельность, которая по своей сути не есть проектом, а есть повседневной операционной деятельностью, или для простоты – конвейером).
Этот вариант является просто идеальной почвой для «экспериментов» по выявлению наилучшего соотношения COQ, COPQ и собственно стоимости предоставления услуг. Путем внедрения улучшений можно определить какой процесс и какое соотношение COQ и COPQ способствует наилучшему соотношению стоимости, количества и качества результатов деятельности. Под COPQ в этом случае подразумеваются переделки из-за некорректного выполнения запроса на поддержку.
Кому это надо? Компании Исполнителю для снижения расходов и увеличения удовлетворенности пользователей, клиентов. Но опять же, тогда, когда есть явные проблемы. Если все всех устраивает, то нужно ли что-то менять или считать?
Вариант 3. Проект или долгосрочное партнерство по контракту типа Cost Reimbursable.
Контракт Cost Reimbursable предполагает что Заказчик оплачивает исполнителю его расходы плюс прибыль. Есть несколько разновидностей. Не вдаваясь в подробности, это хорошо подходит для долгосрочного outstaffing, в основном по разработке, развитию или поддержке больших продуктов. Здесь особенность в том, что Исполнитель не очень заинтересован сокращать свои расходы, т.к. на каждый доллар расходов он получает некий % прибыли. И если у Заказчика нет жестких требований к процессам работы, то так или иначе это расслабляет Исполнителя. И этот «расслабон» по традиции уменьшает усилия, входящие в COQ и увеличивает COPQ. В таком типе взаимоотношений Заказчик обычно имеет гораздо бОльший контроль над процессами и в принятии решений, чем в Fixed Price. Поэтому…
Кому это надо? Я бы сказал 50-50 и Заказчику и Исполнителю. Заказчику – для снижения своих расходов и увеличения производительности Исполнителя. Исполнителю – для поддержания репутации и, как результат для сохранения взаимоотношений. Причем, в силу долгосрочности отношений, это также является благодатной почвой для улучшений и оценки их эффективности.
Вариант 4. Деятельность или продукт для систем класса life critical или mission critical.
Здесь, очевидно, доля COQ будет (и должна быть) очень высока, причем все ее аспекты, а особенно превентивная составляющая. И она может легко превышать и собственно долю разработки и долю COPQ. Обычно только достаточно зрелые компании могут обеспечить выполнение процедур, из которых состоит COQ.
Кому это надо? И Заказчику и Исполнителю, причем для обоих фокус скорее не в снижении расходов, или в скорости работы, а в качестве (надежности) таких систем.
Вариант 5. Пилотные проекты с целью развития бизнеса.
Здесь могут быть какие угодно варианты о том, что важно или нужно. От «слепить» что-то побыстрее, до демонстрации зрелости процессов работы. Также играет роль бизнес перспектива, Исполнитель легко может сработать себе в убыток, чтобы заполучить «вкусного» заказчика. Говоря о COQ и COPQ для этого варианта, и основываясь на собственном опыте скажу, что это вариант очень похож на mission critical. Но есть и отличия. К COPQ здесь можно, без преувеличения, прибавить стоимость упущенной возможности, т.е. потенциальную сумму контракта (если вы потеряли потенциального заказчика именно из-за плохого качества «пилота»).
Кому это надо? Однозначно Исполнителю. По-моему, пилотные проекты «вкусного» класса должны рассматриваться как mission critical, с особым вниманием процедурам из COQ.
Вариант 6. Качество устраивает.
В своей деятельности сталкивался с ситуациями, когда заказчик совершенно осознанно диктовал условия по занижению COQ по причине бюджетного ограничения. А именно, или исключались некоторые процедуры по контролю качества, и-или была явно недостаточная пропорция разработчиков или тестировщиков. Заказчику нужно было «напедалить» как можно больше. Причем Заказчик совершенно осознавал к чему это приведет, и его совершенно устраивало то среднее качество, которое он получал. К счастью, такие заказчики были достаточно технически развиты и адекватны.
Кому это надо? В этом случае больше Заказчику, т.к. он совершенно осознает что делает и отдает себе отчет о результатах.
В итоге, чтобы понимать, кто и в каких ситуациях заинтересован в улучшениях, затрагивающих соотношение затрат на COQ, COPQ и разработку продукта (и процедуры входящие в них), нужно проанализировать среду обитания проекта, деятельности. Надеюсь, что приведенные выше варианты прояснили как это можно сделать.
Просьба не воспринимать буквально следующие цифры, это скорее относительные взаимоотношения доли COQ и COPQ в общей стоимости проекта, деятельности. Приведу по тем вариантам, где есть опытные данные.
- Вариант 1. COQ + COPQ – 40-50% от общей стоимости
- Вариант 3. COQ + COPQ – 30-40% от общей стоимости
- Вариент 4. Опытных данных нет, но осмелюсь предположить что COQ + COPQ – 50-80% от общей стоимости
- Вариант 5. COQ + COPQ – 40-60% от общей стоимости
- Вариант 6. COQ + COPQ – 20-30% от общей стоимости, но из COQ + COPQ бОльшая доля принадлежит COPQ
В следующей статье «Стоимость качества. Часть 3 – Как это посчитать?» поговорим о практических вопросах сбора и интерпретации данных для подсчета COQ + COPQ.
Стоимость качества. Часть 2.1 – Зачем это надо?
18 Январь
Продолжаю тему «Стоимость качества», начало было в предыдущей статье «Стоимость качества. Часть 1 – Что это такое?». Здесь выскажу некоторые соображения о том, зачем и когда нам вообще нужно беспокоиться о стоимости качества и качестве как таковом, а также какая польза от того, что мы его можем определить. Под качеством здесь понимается не только качество конечного и промежуточных результатов работы, но и качество инженерных и управленческих практик, принимаемых решений.
Наиболее очевидны ситуации, когда что-то явно идет не так и нужно как-то реагировать. В общих чертах это типичные проблемы со сроками, качеством, бюджетом, а соответственно недовольные заказчик, руководство, команда проекта. Реагировать – значить что-то менять, улучшать, и в большинстве случаев это что-то – рабочие процессы или какие-то организационные моменты.
Но, возникают вопросы:
- Как доказать и убедиться, что улучшение полезно, для кого или чего именно?
- Как понять, чьим интересам улучшение соответствует, или не соответствует?
Небольшое отступление, скорее всего есть инициатор такого изменения, и скорее всего есть участники проекта, с которыми нужно согласовать (доказать целесообразность) внедрение этого изменения и/или получить их разрешение. Ну а убедиться, что изменение помогло нужно наверное всем в нем участвующим.
Основные согласующие-разрешающие участники это заказчик и руководство, они хорошо понимают язык денег и производительности, т.е. количество пригодных результатов, произведенных проектной командой за эти деньги. Соответственно на этом языке и будем стараться говорить далее.
Еще одно необходимое отступление – по поводу производительности. Это некоторое количество работы в единицу времени. Количество работы «по научному» – размер (size). Наиболее понятный пример – Velocity (Story Points per Sprint), где Story Point – одна единица размера. Это конечно не идеальный способ, но все же существенно лучше чем человеко-часы. Или же, за единицу размера могут приниматься какие-то дискретные виды работ (например, разработка стандартного баннера). Тема размера – это отдельная довольно серьезная дисциплина, по этому поводу есть небольшая ознакомительная статья, а более полный комплект доступен здесь (за подписку).
Для плавного перехода к практическому применению давайте сначала для наглядности посмотрим на следующие диаграммы, иллюстрирующие потенциальное влияние изменений. Предположим, что у нас работает стабильная по составу команда, и за последнее время в среднем соотношение затрат между видами работ такое (из спринта в спринт, из месяца в месяц и т.п.). Где «Создание продукта» – это все что не «Total Quality Costs – TQC» (см. Часть 1), т.е. кодирование, требования и т.п.
Соотношение №1
Исходная ситуация. Соотношения приводятся только в демонстрационных целях, у вас могут быть иные.
Предположим, что кого-то такая ситуация не устраивает, то ли по стоимости, то ли по производительности, то ли по качеству.
Решили что следующие улучшения могут быть наиболее полезными:
- ввести инспекцию спецификаций,
- или же добавить нагрузочное тестирование,
- или же ввести инструментарий прослеживаемости (traceability) требований
Пусть это будут Соотношения №№2-4 соответственно. И пусть они для простоты будут внедряться независимо, по-одному. Рассмотрим потенциальные варианты.
Соотношение №2
Инспекция спецификаций помогла, она, как часть COQ (+5%), помогла существенно сократить COPQ (-10%), высвободив ресурсы. Причем, высвобождение может пойти либо на увеличение производительности (Соотношение №2), либо на экономию средств (Соотношение №2.1).
Соотношение №3
Введение нагрузочного тестирования, очевидно, не помогло – производительность команды понизилась (-5%), т.к. время на него тратится, а COQ повысился (+5%). Заметим, что проверка достижения запланированной нагрузки на приложение тоже входит в TQC, а дефекты, вызванные, якобы, нагрузочными проблемами, таковыми не оказались. Значит, «копали не туда».
Соотношение №4
Внедрение инструментария traceability (+5% COQ) на первый взгляд, не сказалось ни на производительности, ни на экономии средств. Но снизило COPQ (-5%), что можно рассматривать как позитивное явление, т.к. часть дефектов всегда просачивается заказчику, а их меньшее количество вообще означает и меньшее их обнаружение заказчиком, что, как минимум, носит положительный репутационный характер.
Из этих рассуждений, а также забегая немного вперед, скажу, что нет какого-то универсального рецепта о корректном соотношении между COQ, COPQ и общей стоимостью проекта, все зависит от приоритетов по производительности проекта, стоимости, качества, интересов основных заинтересованных лиц.
Подводя итог можно сказать, что:
- Во-первых, если что-то кого-то в проекте не устраивает, то проблемы есть, и надо что-то улучшать
- Во-вторых, если проблемы есть, но непонятно что конкретно может помочь, то можно предположить несколько наиболее полезных улучшений
- НО, в-третьих, нужно понимать, чьим интересам какое улучшение соответствует, или не соответствует. Т.к. даже от самого очевидного улучшения не все участники проекта могут быть счастливы . Об этом в следующей Части 2.2
- В-четвертых, нужно определить, каким образом будет оцениваться успешность улучшений, так чтобы было поменьше субъективных ощущений и побольше цифр и фактов. Об этом в еще одной – Части 3.
Спасибо за внимание, продолжение следует.
Оригинал статьи здесь.
Получится ли у вас Continuous Delivery?
13 Январь
На данный момент подход Continuous Delivery стремительно набирает популярность. Все больше начинают о нем говорить на конференциях, встречах сообществ, интервью и прочих выступлениях. Многие компании построили свой процесс разработки так, чтобы поставлять «свежие» фичи конечным пользователям десятки раз в день. В чем же тут дело? Почему для большей части компаний это еще является заоблачной мечтой и недостижимым идеалом?
В действительности, за редкими поставками кода стоит вполне себе научное обоснование. За все в жизни приходится платить. Затраты на работу с готовой функциональностью делятся на два типа: стоимость поставки кода и стоимость накапливания функциональности. Стоимость поставки складывается из времени на его выполнение, определенных рисков, связанных с поставкой, и человеческих ресурсов, которые будут ее выполнять. Тут все просто. Стоимость накапливания готовой функциональности состоит, в свою очередь, из недополученной прибыли в результате отложенного появления нужной пользователю функции, поздней обратной связи, необходимости поддерживать непроверенные решения и прочих факторов.
Стоимость поставки уменьшается с количеством функциональности в этой поставке. Не надо, к примеру несколько раз в день производить тестирование, обновлять код на продакшене, делать обновления данных и т.д. Все это делается одним скопом в конце итерации или недели, месяца, квартала. Стоимость накапливания наоборот растет. Чем больше готовой функциональности ждет поставки, тем больше затраты на ее «содержание». И тут вырисовывается вполне математически и экономически выверенное решение. Нужно минимизировать суммарную стоимость.
Графики стоимости в зависимости от размера релиза вы можете наблюдать на картинке. Стоимость накапливания очень тяжело уменьшить, так как она больше связана с бизнесом и конечными пользователями. Многие просто даже не считают эту стоимость и не задумываются о ней. Релиз раз в две недели? Ну и нормально! А то, что важная фича была реализована в первый же день и могла бы уже почти две недели использоваться, никого не волнует.
А вот уменьшить стоимость поставки вам под силу. Тут на помощь приходит автоматизация. Ведь машины делают повторяющиеся операции гораздо быстрее и качественнее людей. Речь идет о тестировании, сборке, установке, обновлению данных и т.д. Только уменьшив стоимость всех этих операций за счет правильных инструментов и автоматизации, можно говорить об уменьшении суммарной стоимости поставки кода.
Подведем итог. Попробуйте расписать график стоимости поставки и накопления функциональности для своего проекта, а потом проверьте оптимально ли у вас выбрана частота релизов. Результатами поделитесь в комментариях к статье. Удачи!
Стоимость качества. Часть 1 – Что это такое?
10 Январь
Хочу предложить вашему вниманию несколько статей, посвященных стоимости качества. Эта, первая часть, приводит некоторые базовые положения на эту тему. В остальных же буду приводить свои соображения по поводу практического внедрения и применения.
Давайте подумаем, во что выливается плохое качество продукции, причем, неважно о чем речь, то ли о программном продукте, то ли о производстве автомобилей. И не только плохое качество продукции, но и плохое качество процесса производства продукции.
Давайте на примере. Допустим, разрабатываем какое-нибудь более-менее сложное приложение без достаточного внимания таким практикам как бизнес анализ и проектирование (элементы процесса). Вдобавок к этому имеем некачественный код, и для полного «счастья» не выделяем достаточного времени на тестирование.
В совокупности вся эта «радость» приводит к:
- Внутренним переделкам, устранению дефектов. Плохо
- Внешним претензиям от заказчика, опять же ведущим к переделкам, а то и к штрафным санкциям. Очень плохо
- Потере репутации и бизнес возможностей. Невыносимо плохо
Причем уже никого не интересует, что работа сделана «быстро» и «без бюрократии» (процессы, инженерные практики, документация). Работа сделана ПЛОХО.
Смотрим – переделки, штрафы, тестирование, процессы, «бюрократия» и т.п. имеют свою стоимость, и свое влияние на результаты работ. Стоимость качества может носить как позитивный оттенок (тестирование, процессы), так и негативный (переделки, штрафы). Забегая вперед, скажу, что эта стоимость является всего лишь ОДНИМ ИЗ параметров успеха проекта, услуги. Если качество продукта по моей субъективной оценке посредственное, но при этом заказчик счастлив, достиг своей бизнес цели, расплатился и рекомендует вас кому-то еще – то все отлично, по крайней мере для другого подобного заказчика вы скорее всего тоже выдадите хороший результат. Поэтому, все, о чем здесь говориться, должно очень взвешенно восприниматься, как говориться it depends.
Итак, существуют такие основные понятия:
- Общая стоимость качества (Total Quality Costs – TQC), что включает:
- Стоимость качества (Cost of Quality – COQ)
- Стоимость плохого качества (Cost of Poor Quality – COPQ)
В разных источниках по-разному определяют, что именно относиться к COQ или COPQ (а то и вообще не разделяют), мы же здесь посмотрим на наиболее распространенное распределение. Причем, я не претендую на абсолютную правоту, в вашей практике вы можете захотеть сделать это немного по-другому.
- Стоимость качества (Cost of Quality – COQ)
- Cтоимость превентивных мер (Prevention Costs), например
- Настройка и внедрение процессов (разработки ПО), в организации и/или на проекте
- Обучение процессам, инженерным и управленческим практикам, концепциям качества
- Подбор на этапе инициирования проекта совместимых методологий, технологий, типов контрактов, фаз, которые бы наиболее эффективно достигали бизнес целей проекта/продукта
- Идентификация и внедрение улучшений в организации и/или на проекте
- Планирование качества на проекте – виды работ, направленные на обеспечение качества на проекте
- Стоимость контроля (Appraisal Costs), например
- Инспекции спецификаций, архитектуры продукта
- Инспекции кода
- Разнообразные виды тестирования продукта, как конечного, так и промежуточных результатов
- Приемочное тестирование
- Ассоциированные затраты на разворачивание тестовых сред
- Аудиты процессов, результатов
- Cтоимость превентивных мер (Prevention Costs), например
- Стоимость плохого качества (Cost of Poor Quality – COPQ)
- Стоимость устранения внутренних дефектов (Internal failure costs), например
- Затраты на «багфикс» и переделки кода, документа, архитектуры
- Затраты на непригодные к дальнейшему использованию результаты работы
- Вынужденные ре-тестирование и ре-инспекции
- Стоимость устранения внешних дефектов (External failure costs), например
- То же, что и для внутренних, но обнаруженных заказчиком, плюс
- Обработка претензий заказчика
- Затраты по гарантийным обязательствам
- Контрактные штрафные санкции
- Стоимость непрямых убытков (Indirect poor-quality costs), сложно количественно оценить, но это
- Потеря внешней репутации, потенциально ведущая к сокращению, потере бизнеса
- Потеря внутренней репутации – демотивация, сокращение персонала
- Стоимость устранения внутренних дефектов (Internal failure costs), например
В завершении этой статьи приведу классическую фразу Philip B. Crosby, который внес значительный вклад в практики управления качеством и теорию менеджента:
- «Quality is free. It’s not a gift, but it’s free. The ‘unquality’ things are what cost money.»
Он же ввел принцип «Ноль дефектов, – сделай правильно с первого раза».
Далее, в следующих статьях, постараюсь изложить некоторые дальнейшие соображения по поводу стоимости качества, как минимум видится вот это: а – «Зачем и кому это надо?»; б – «Как это работает?».
Оригинал статьи здесь.
Памятка участника конференций. Часть 2 – Посещение конференции.
28 Декабрь
Я продолжу давать советы по поводу конференций, пользуясь своим богатым опытом. В первой части я рассмотрел вопрос выбора конференции. Сейчас речь пойдет о самом важном – ее посещении. Будем много советов от кэпа, но надеюсь и полезные вещи тоже.
- Обязательно убедитесь в том, что вы представляете, где расположено место проведения. При необходимости распечатайте карту или договоритесь поехать на конференцию вместе с коллегами.
- Запишите на всякий случай контакты организаторов. Это очень поможет вам в случае, если возникнут проблемы на месте.
- Заведите будильник на такое время, чтобы не опоздать на регистрацию. Время регистрации как нельзя лучше подходит для общения и знакомства с новыми людьми. Также у вас будет возможность выпить кофе, окончательно проснуться и подготовиться к восприятию информации.
- Не пропускайте открытие конференции. Помимо слов благодарности и приветствия участников, на открытии сообщается много важной информации, которая может оказаться вам очень полезной.
- Не стесняйтесь и как можно больше знакомьтесь. Вы пришли на конференцию получать знания и ответы на свои вопросы. Поэтому грех не воспользоваться возможностью обсудить свои проблемы с другими участниками.
- Заранее определите для себя примерную программу на день. Выберите наиболее полезные для вас доклады, посовещавшись с коллегами или организаторами конференции. Тогда вы не будете разочарованы и не придется шататься из зала в зал в поисках интересного.
- Не стремитесь попасть на все доклады сразу. Нормальные конференции выкладывают видеозаписи и вы сможете наверстать упущенное позже.
- Разберитесь с форматом выбранного выступления. Будет это доклад, мастер-класс, демонстрация продукта или что-то еще. Перечисленные форматы очень сильно отличаются и, возможно, не оправдают ваших ожиданий. Помочь в этом вопросе могут представители программного комитета или организаторы.
- Обязательно делайте заметки на докладах. Записывайте интересные мысли, вопросы, упоминания об полезных для вас вещах. Человеческий мозг не способен держать одновременно много информации в памяти. Поэтому все полезное стоит записывать.
- Не стесняйтесь задавать вопросы докладчикам. Ведь для этого вы и пришли на конференцию. Если вы не успели задать вопрос после доклада, то пообщайтесь с докладчиком на перерыве. Обычно они очень охотно идут на контакт после доклада. Если вас несколько человек и вы собираетесь после конференции отметить, то можете пригласить докладчика с собой и пообщаться в неформальной атмосфере.
- Возьмите с собой все необходимые документы для организаторов, которые связаны с вашим пребыванием на конференции (договора, акты, счета и т.д.). Этим вы сильно упростите им жизнь.
- Заранее уточните ситуацию по поводу обеда – будет ли он организован на месте проведения конференции или вы будете обедать самостоятельно. Во втором случае заранее посмотрите где вам будет удобнее всего пообедать и, возможно, распечатайте карту мест общественного питания.
- Заполняйте анкеты обратной связи ответственно. Это дает организаторам очень много полезной информации и возможность сделать конференцию следующий раз более удобной для вас. А это только в ваших интересах.
И помните – вы идете на конференцию прежде всего за знаниями. Поэтому приложите со своей стороны максимум усилий, чтобы этот день для вас прошел максимально эффективно!
