SLA for Agile team?

[malex]

Всем привет!

Наш заказчик хочет SLA (Service Level Agreement) для Agile проекта.
Никто не сталкивался с подобным? Буду благодарен любым идеям :)

Леша

[Артур Ракицкий]

Agile не расчитан на инцидентно-ориентированные проекты. Разделите проект на разработку (Agile) и сервис (ITIL).

14 июля 2008 г. 12:54 пользователь malex <ama...@gmail.com> написал:

--
С уважением,
Артур Ракицкий

------------------
ICQ: 21062147

[Alimenkou Nikolay]

А для чего конкретно он хочет SLA? Вполне нормально иметь SLA на
доступность приложения или сервиса и тут сам Agile в принципе ни при
чем.

[Alexey Krivitsky]

лёша, расскажи больше, тогда мы, возможно, ответим по существу :)

An SLA is a formally negotiated agreement between two parties. It is a contract that exists between customers and their service provider, client or between service providers. It records the common understanding about services, priorities, responsibilities, guarantee, and such ― collectively, the level of service. For example, it may specify the levels of availability, serviceability, performance, operation, or other attributes of the service like billing and even penalties in the case of violation of the SLA....
http://en.wikipedia.org/wiki/Service_level_agreement

то есть если граммотно описать common understanding about services, priorities, responsibilities, guarantee так чтобы оно не противоречило итеративно-инкрементальной разработке, то, как мне кажется sla может нормально лечь под agile (не хуже, чем fixed-bid). когда вы будете биллить клиента по-итеративно.

The technical specifications of an SLA are commonly described through either a Service Level Specification (SLS) or a Service Level Objective (SLO)
http://en.wikipedia.org/wiki/Service_level_objectives

... то есть всё зависит от согласованных objectives, которые включают метрики (velocity? accepted features?) для оценки качества оказываемой услуги

2008/7/14 Alimenkou Nikolay <lumii.su...@gmail.com>:

[Dmitry Danilchenko]

Приветствую!

 Иметь подписанный SLA-нормальная практика, не зависимо от того, Agile проект или да.

 в sla прописывается кто, кому, какой сервис предоставляет и с какими параметрами.
 в СЛА могут быть быть пункты касательно времени обслуживания, доступности, надёдности,
безопасности, непрерывности, поддержки, скорости обработки тасков, порядок расчётов, порядок и форма отчетности, штрафы и премии.  Это теория. (с) 5-55

Вообще СЛА - очень правильный документ. Если его нет, кастомер легко может , например, позвонить в 3 утра и требовать, чтобы какая-то проблема была исправлена за 15 минут.
или же требовать сделать то, чего вы не умеем или не хотим делать в принципе.

Если кастомер не предоставляет требования к уровню сервиса (кот. должны исп-ся как отправная точка для составления SLA), имеет смысл эти требования выдвинуть себе самим (есс-нно, чтобы было удобно себе - а как иначе) и всё равно подписать SLA с заказчиком.

С уважением,
 Дмитрий

[Borys Lebeda]

Не спешите с позитивными выводами господа!

Did you forget agile principle "Customer collaboration over contract negotiation"?

Представьте что заказчик с благими намерениями вводит систему штрафов/премий за количество найденных багов после релиза в трекинговой системе.

У команды появляется желание пользоваться ей не по назначению, а для максимизации тех самых премий. мы можем просто завести внутреннюю систему разработки, что бы минимизировать количество проблем видимых заказчику. Это уже совсем не похоже на Agile, поэтому я бы сказал, что SLA может в какой-то степени конфликтует с Agile.

Ввести показатели времени обслуживания, доступности, надёжности и т.д. было бы очень классно, если бы не одно: самые большие проколы в доступности чаще всего зависят от интернет провайдера, или хостинга, или погоды в Киеве зимой или от того кузьмича, который обесточил офис, что бы включить отбойник.

Вопросы что делать и кто виноват остаются в силе ...

 

 

2008/7/15 Dmitry Danilchenko <dm1...@yahoo.com>:

[sun]

Позволю полностью согласиться с Борей.
Продавать что попало под вывеской Agile, это давно известная практика наших украинских компаний.
Не обманывайте ни себя, ни заказчика.

2008/7/15 Borys Lebeda <borys....@gmail.com>:

--
sun

[Dmitry Danilchenko]

Заранее прошу прощения за возможный повтор коммента.

----- Original Message ----
From: Borys Lebeda <borys....@gmail.com>
To: agile-...@googlegroups.com
Sent: Tuesday, July 15, 2008 11:03:52 AM
Subject: [agile-ukraine] Re: SLA for Agile team?

>Представьте что заказчик с благими намерениями вводит систему штрафов/премий за количество найденных багов после релиза в

>трекинговой системе.

 

>У команды появляется желание пользоваться ей не по назначению, а для максимизации тех самых премий. мы можем просто

>завести внутреннюю систему разработки, что бы минимизировать количество проблем видимых заказчику. Это уже совсем не

>похоже на Agile, поэтому я бы сказал, что SLA может в какой-то степени конфликтует с Agile.

 

Скорее, это особенности ведения бизнеса командой, а не конфликт с agile. не забываем про Transparency.

 

>Ввести показатели времени обслуживания, доступности, надёжности и т.д. было бы очень классно, если бы не одно: самые большие >проколы в доступности чаще всего зависят от интернет провайдера, или хостинга, или погоды в Киеве зимой или от того кузьмича,

> который обесточил офис, что бы включить отбойник.

>Вопросы что делать и кто виноват остаются в силе ...

 

Для минимизации подобных проблем и нужен SLA.

Кастомеру невероятно всё равно, упал хостинг или канал в интернет. ему нужно, что бы сервер был доступен.

Мы же хотим вовремя и в полном объёме получать оплату за предоставленные услуги.

 

Другой пример. Мы купили комп. ПО субботам он не работает, а по четвергам не работает встроенный WiFi адаптер.

Купим ли мы этот комп, зная о таких  его особенностях заблаговременно?

На счёт кузьмича с отбойником. это скорее попадает под Acts of God.

 

SLA нужен не только для выгоды заказчика, но и для спокойствия исполнителя.

 

[Dmitry Danilchenko]

интересно услышать, что значит: "Не обманывайте ни себя, ни заказчика"?

что есть обман в контексте данной дискуссии? :)

 

----- Original Message ----
From: sun <aleksey....@gmail.com>
To: agile-...@googlegroups.com
Sent: Tuesday, July 15, 2008 12:12:42 PM
Subject: [agile-ukraine] Re: SLA for Agile team?

[Alimenkou Nikolay]

Я абсолютно согласен с Дмитрием. Отличные примеры. SLA - корень
договоренности, своего рода даже acceptance тест. Когда вы
разговариваете о требованиях к проекту, то заказчик может пожелать
иметь 24/7 доступность своего сервиса. Это его требование, иначе он не
хочет иметь данный продукт. Ему не подходит: давайте 23/6, а потом
может быть улучшим. И это никак не завязывается на процесс разработки,
а больше на выбор архитектуры, провайдера, серверов и так далее. Но
многие подписывают SLA не расшифровав термины "доступность",
"поддержка" и так далее. К примеру, является ли поддержкой то, что на
связи всегда есть человек, отвечающий по телефону? Или же поддержка
гарантирует исправление технической поломки в течении часа?
Доступность - это когда приложение выдает ответ в любое время, но
возможно с задержкой в полчаса? Или же когда приложение никогда не
показывает 404? Основная проблема SLA в том, что когда не прописаны
детальные критерии (своего рода acceptance критерии), то SLA лишь
поломает ваши отношения с заказчиком в случае любого рода проблемы. А
говорить что "Мы Agile" и поэтому верьте нам на слово что все будет
работать "24/7" по-моему глупо. У заказчиков может быть
многомиллионный бизнес, который зависит от этого SLA и ему нужны
гарантии. А если вы не уверены что можете обеспечить SLA, то и не
суйтесь, потому что обманете 100%.

> --
> Borys L.

[Alimenkou Nikolay]

Забыл привести источник, где можно найти интереные вещи про SLA:

Pragmatic.Release.It.Design.and.Deploy.Production.Ready.Software.Apr.
2007

On Jul 15, 1:30 pm, Alimenkou Nikolay <lumii.subscri...@gmail.com>
wrote:

[malex]

Мне очень понравился твой ответ, все верно. Ведь заказная разработка -
это по-сути сервис, целью которого (в идеале) является эффективная
разработка ПО, соответствующего требованиям заказчика и своевременная
поставка ПО заказчику. Есть еще что-то, что я упустил?


On Jul 15, 12:01 am, "Alexey Krivitsky" <alexeykrivit...@gmail.com>
wrote:

> лёша, расскажи больше, тогда мы, возможно, ответим по существу :)

> *

> An SLA is a formally negotiated agreement between two parties. It is a

> contract <http://en.wikipedia.org/wiki/Contract> that exists between
> customers and their service
> provider<http://en.wikipedia.org/wiki/Service_provider>,

> client or between service providers. It records the common understanding

> about services, priorities, responsibilities, guarantee, and such --
> collectively, the **level of service. For example, it may specify the levels

> of availability, serviceability, performance, operation, or other attributes
> of the service like billing and even penalties in the case of violation of
> the SLA....http://en.wikipedia.org/wiki/Service_level_agreement

> *

> то есть если граммотно описать common understanding about services,
> priorities, responsibilities, guarantee так чтобы оно не противоречило
> итеративно-инкрементальной разработке, то, как мне кажется sla может
> нормально лечь под agile (не хуже, чем fixed-bid). когда вы будете биллить
> клиента по-итеративно.
>

> *The technical specifications of an SLA are commonly described through

> either a Service Level Specification (SLS) or a Service Level

> Objective<http://en.wikipedia.org/wiki/Service_level_objectives>(SLO)http://en.wikipedia.org/wiki/Service_level_objectives
> *

> ... то есть всё зависит от согласованных objectives, которые включают
> метрики (velocity? accepted features?) для оценки качества оказываемой
> услуги
>

> 2008/7/14 Alimenkou Nikolay <lumii.subscri...@gmail.com>:

[malex]

Заказчик хочет договориться о неком уровне сервиса разработки ПО,
который мы (GlobalLogic) как исполнители обязуемся предоставить.

On Jul 14, 5:53 pm, Alimenkou Nikolay <lumii.subscri...@gmail.com>
wrote:

[malex]

Разве разработка не может быть сервисом?

On Jul 14, 4:38 pm, "Артур Ракицкий" <arty...@gmail.com> wrote:
> Agile не расчитан на инцидентно-ориентированные проекты. Разделите проект на
> разработку (Agile) и сервис (ITIL).
>

> 14 июля 2008 г. 12:54 пользователь malex <amas...@gmail.com> написал:

[malex]

Полностью согласен, что SLA не должен создавать ситуацию, когда
"плохие" решения удобны команде или заказчику. Суть вопроса собственно
в том, какой SLA работает в Agile среде.

On Jul 15, 11:03 am, "Borys Lebeda" <borys.leb...@gmail.com> wrote:

> --
> Borys L.

[malex]

Друзья,

Всем огромное спасибо за дискуссию :).

Попробую поставить более четкий вопрос. Представьте себе, что вы -
заказчики на Agile проекте и платите собственные $$$ за очень нужный
вам продукт (скажем, IDE). Для этого вы наняли нового подрядчика, с
которым никогда не работали ранее. Есть ли какие-то метрики или
показатели, которые вы хотели бы контролировать?

Еще раз огромное спасибо, теперь уже за ответы :).

Леша

[sun]

Дима, давай для примера возьмём условие "24/7".
И вспомнил треугольник менеджмента.Для Agile проектов характерным является фиксируемые время и ресурсы. Мы играемся набором задач.И считаем что команда выкладывается всегда по максимуму.
В предложенной схеме мы имеем фиксируемый набор задач,времени и ресурсов. Из чего вытекает перегруженность команды и внутреннее недовольство разработчиков. А это в свою очередь тянет огромный набор болячек таких как "CYA (Cover your ass)", абсолютное безразличие к качеству, т.е халтура и прочее.

Ты также говорил про открытость. Открытость и доверие ходят рядом. В нашем же случае клиент явно не доверяет заказчику. Нет доверия - нет Agile.

п.с. ну и ещё раз про Борины мысли - в Agile манифесте всё упрощено до предела, там уже нечего выкидывать (так сказать "Квадрат" Малевича :))). Если у табуретки отломать одну из четырёх ножек то ты по прежднему сможешь усидеть на ней, держа в руках кружку горячего чая, но надолго ли?

2008/7/15 Dmitry Danilchenko <dm1...@yahoo.com>:

--
sun

[Dmitry Danilchenko]

Алексей,

Спасибо за развёрнутый ответ.

 

на счет доверия не согласен. shit happends. когда одна из сторон будет терять миллионы денег из-за того,

что она всецело доверяла другой, будет ли легче первой?

для чего подписывать контракт, NDA, если мы друг другу доверяем. :)

 

ещё раз подчеркну: SLA  - не только для заказчика.

 

теперь про треугольник. почему так и не записать в драфте сла: "мы делаем быстро, качественно, в срок.

выберите любые два варианта. "

кроме того, в сла можно прописать, что релизы раз в 50 дней, не работаем в гос. праздники,

не работаем только за еду и т.д.

 

Допустим (на секунду), что SLA никак не коррелируется с Agile.

Но ведь тот же Agile Manifesto - это не свод законов.

Это скорее рекомендации, правила.

а быть agile - значит корректировать правила в каждой конктретной ситуации :)

 

С уважением,

 Дмитрий

[Serhiy Yevtushenko]

Первый вопрос - какие сервисы вы предоставляете ?
Второй вопрос - какие параметры качества сервиса могут быть объективно измерены? Можно ли их измерить с допустимой стоимостью?
Третий вопрос - каковы штрафы за нарушение?


Тут, как на меня, начинается узкое место - потому что большинство аутсоурсинговых контор продает время людей определенной квалификации для выполнения задач заказчика (без гарантий каких-то результатов).
Плюс заказчики вводят некоторую средства контроля, которые дают им возможность судить о уровне выполняемых работ.

Отсюда возникают Тайм трекинг + оценки.



Что можно предложить в качестве метрик
(с точки зрения разработки):

Параметры внешнего качества:
Метрики - демонстрируемая / отчуждаемая версия продукта в конце каждой итерации (позволяет принимать решение продлевать/не продлевать контракт)
Количество принятых итераций (итерации, результаты которых были приняты заказчиками)
Количество багов (с ранкингом по категориям), которые возникли в продакшн

С точки зрения сервиса:
Скорость начала работы над багом (реакция на баг ) - время (или распределение времени)
Наличие людей на работе (какое количество дней в году люди из нанятой комманды будут на работе)
Укладывание в естимейты (либо распределение отклонений)
Наличие связи с сетью заказчика



Параметры внутреннего качества:

Процент покрытия кода юнит тестами (> 80%)
Наличие циклических зависимостей
Наличие дупликаций в коде
Соответствие кода определенным стандартам кодирования

15 июля 2008 г. 15:03 пользователь malex <ama...@gmail.com> написал:

[Dmitry Danilchenko]

follow up.

 

про треугольник конечно же нужно читать: "мы делаем дёшево, качественно, в срок.  выберите любые два варианта. "

[Dmitry Danilchenko]

с т.зрения заказчика можно добавить миллион всего, например:

что бы мне отвечали на звонки только девушки и только на французском языке,

что бы можно было с 8 до 17 по моему локальному времени смотреть,

что происходит в офисе :)

 

Но про себя ни в коем случае нельзя забывать:

структура багрепорта (что делал, что хотел получить, что получил, приоритет, а не :"у меня ничего не работает, исправьте асап"), что считается багом, поощрения, частота и структура отчётности, порядок и форма расчетов,

порядок работы над багом, время реакции на инциденты с различными приоритетами, office hours. 

 

особенно если речь идет о новом, не проверенном контрагенте.

 

 

Regards,

 Dmitry

 

 

----- Original Message ----
From: Serhiy Yevtushenko <syevtu...@gmail.com>
To: agile-...@googlegroups.com
Sent: Tuesday, July 15, 2008 5:18:15 PM
Subject: [agile-ukraine] Re: SLA for Agile team?

[Serhiy Yevtushenko]

Из того, что описано, возникает вопрос :

Как провести границу между контрактом и SLA ?

15 июля 2008 г. 17:51 пользователь Dmitry Danilchenko <dm1...@yahoo.com> написал:

[Dmitry Danilchenko]

по своей сути SLA и есть контракт.

[sun]

agile манифест - это не свод законов, это конституция.
ты можешь вводить любые законы, но если они идут вразрез конституциии, тогда придётся всё таки либо менять конституцию (читай: не называться всё что мы нахимичили agile-ом) либо принимать новый закон.

2008/7/15 Dmitry Danilchenko <dm1...@yahoo.com>:

--
sun

[Dmitry Danilchenko]

"Working software is the primary measure of progress."
как понять, что the software is working?
или что такое "done"?

[sun]

1. Это значит что в конце каждой итерации ты должен показыать полностью рабочую функциональность (см. пункт 2)
2. для этого команда определяет для себя "definition of done"

2008/7/15 Dmitry Danilchenko <dm1...@yahoo.com>:

--
sun

[Borys Lebeda]

Вообще говоря мы здесь отошли от основной темы: но в agile командах обычно очень легко прийти к мысли что такое done, хотя это зависит от обязаностей возложенных на команду. Лично мне больше всего нравится такое определение:

Done это когда no more to do

2008/7/15 Dmitry Danilchenko <dm1...@yahoo.com>:

--
Borys L.

[Serhiy Yevtushenko]

Еще немного из Википедии о компонентах SLA:
SLAs commonly include segments to address:
          a definition of services;
          performance measurement;
          problem management;
          customer duties;
          warranties;
          disaster recovery;
          termination of agreement.

16 июля 2008 г. 9:57 пользователь Borys Lebeda <borys....@gmail.com> написал:

[Dmitry Danilchenko]

неее, я намекал на то, что определения "working software" и "done" - это и есть элементы SLA.

 

----- Original Message ----
From: sun <aleksey....@gmail.com>
To: agile-...@googlegroups.com
Sent: Tuesday, July 15, 2008 11:51:57 PM
Subject: [agile-ukraine] Re: SLA for Agile team?

1. Это значит что в конце каждой итерации ты должен показыать полностью рабочую функциональность (см. пункт 2)
2. для этого команда определяет для себя "definition of done"

2008/7/15 Dmitry Danilchenko <dm1...@yahoo.com>:

"Working software is the primary measure of progress."
как понять, что the software is working?
или что такое "done"?

----- Original Message ----
From: sun <aleksey....@gmail.com>
To: agile-...@googlegroups.com

Sent: Tuesday, July 15, 2008 11:02:39 PM
Subject: [agile-ukraine] Re: SLA for Agile team?

agile манифест - это не свод законов, это конституция.
ты можешь вводить любые законы, но если они идут вразрез конституциии, тогда придётся всё таки либо менять конституцию (читай: не называться всё что мы нахимичили agile-ом) либо принимать новый закон.

--

sun

[Alimenkou Nikolay]

После разъяснений автора вопроса стало понятно, что это не совсем
классическое понимание SLA. Мой ответ: считать разработку сервисом и
подписывать на нее SLA неприемлимо по той простой причине что это
почти всегда провально. Разработка связано очень сильно с человеческим
фактором. К примеру, вашим сотрудникам надоест у вас работать и они
уволятся. Получается что вы не выполнили SLA и на вас налагаются
штрафные санкции. По мне гораздо приемлимее просто строить разработку
на доверии, а пока оно не сформировалось использовать гибкий контракт
с проплатой на основе time and materials. При этом действительно для
оценки качества вашего сотрудничества могут пригодиться некоторые
метрики, снимаемые с процесса разработки. По ним может быстро стать
понятно подходит ли заказчику данная команда. А вот зато SLA на
выпускаемый продукт надо подписывать обязательно, иначе на выходе
получается "что-то", что вроде работает, но не всегда. Acceptance
критерии будут заведомо управлять качеством вашего продукта и его
разработкой.

Критерий Done по-моему тут ни при чем. Это более низкий уровень,
который можно применять для стори или фичи. Продукт Done не бывает
наверное никогда. Всегда есть что еще доделать.