« Rev
@agile_ru   96
Fwd »


Denis
В первой итерации вот такие формулировки по метрикам сделал
Denis
Это нужно для того, чтобы оценивать работу
Denis
Разработчики могут про них даже не знать)
Николай
На самом деле есть SLA, он немного условный, это же сервис)
возникает вопрос: а можем ли мы говорить про SLA и вообще про "сервисы" в agile-подходах?.. вообще, это ведь к ITSM/ITIL немного ближе... а это ведь совсем другая парадигма!
Николай
напр. Comments Count - если метрикуемые про неё пронюхают, то будут стремиться уменьшать кол-во коммуникаций => ухудшать кач-во обратной связи, которое является одной из главных ценностей agile... 🤔
Ksenya
Это нужно для того, чтобы оценивать работу
Денис, если есть сапорт - нужно со стейкхолдерами (либо внутри команды) договориться про SLA. Супортовую задачу, если у вас Jira, удобно проводить отдельным stripe-ли (потоком на доске). Метрики, которые вы накидали, используйте для себя, а то люди убегут из вашего трекера :) через месяц можно спросить: "что я узнал? О чем это может говорить? Есть ли взаимосвязь между состоянием метрики и качеством продукта?" :) а дальше по обстоятельствам...
Ksenya
Это нужно для того, чтобы оценивать работу
А чего придумали с процессами, качеством постановки задачи и передачей в тестирование?
Denis
Есть же даже проекты вроде https://www.scoro.com/blog/16-essential-project-kpis/
Denis
https://www.scoro.com/
Denis
А чего придумали с процессами, качеством постановки задачи и передачей в тестирование?
Мне очень понравилась мысль привлекать QA. Это правильно, но пока непонятно, что он должен дать на выходе. Какие операции применить к задаче? :)
Стас Щетинников
Мне очень понравилась мысль привлекать QA. Это правильно, но пока непонятно, что он должен дать на выходе. Какие операции применить к задаче? :)
Мы привлекаем. Чем раньше приходит тестирование к задаче тем лучше. А вообще тестирование должно приходить на этапе сбора требований вместе с разработкой. И тестирование должно быть параллельно разработке (и вместе с ней). И это очень хорошо спасает от мискоммуникаций разработки и тестирования. Плюс тестирование практически не задерживает поставку.
Ksenya
Разве должны быть разделены? :) Вся разработка – это сплошной Support
Если у вас легаси система, то разработку удобно тогда заканбанить:) сделать SLA для передачи в анализ, оценку и декомпозицию. 90% сапорт не такой частый случай в девелопменте :)
Ksenya
Мне очень понравилась мысль привлекать QA. Это правильно, но пока непонятно, что он должен дать на выходе. Какие операции применить к задаче? :)
А кто ставит задачи разработке, в итоге? Как включать - добавить в декомпозированные тикеты definitions of done, которые pm/аналитик/po/кто у вас там пишет вместе с QA + technical definitions of done, которые добавляют разрабы/админы
Ksenya
Есть же даже проекты вроде https://www.scoro.com/blog/16-essential-project-kpis/
Тут же менеджерские метрики про то, с какой скоростью просираются/зарабатываются деньги и доставляется ценность. Ваши метрики - сугубо метрики обслуживания. Чтобы их собирать, думать над ними и делать выводы, вы потратите время (накладные расходы), но мало чего полезного узнаете :) хотя для встречи с реальностью ("все косят и забивают, один Вася молодец") - может сработать :)
Евгений
С точки зрения классического подхода, основанного на pmbok, внедрение начинается с написания внутреннего нормативного документа, который описывает процессы управления проектами, заточенные под реалии данной компании. Это может быть политика, регламент, методология и т.д., в которой определяются сами процессы, ответственные, термины, шаблоны документов и т.д. Вопрос - с точки зрения Agile и внедрения одного из фреймворков (SAFe, Scrum, XP, FDD и т.д.), есть аналогичный документ? И как он называется? Если у кого есть пример, киньте плз ссылку?
Николай
Разве должны быть разделены? :) Вся разработка – это сплошной Support
я имею в виду: Разработка - создание продукта на основе его видения, тестирование новых фич в рамках разработки - это всё здесь Support - поддержка созданной части продукта: консультации, исправления ошибок, сбор пожеланий на доработку Задача на доработку - это уже часть разработки В support'е эти метрики годятся для прохождения заявки (инцидента) до этапа попадания в разработку/доработку - вот тут уже я насчет них очень сомневаюсь...
Николай
а разработку уже лучше кабанить, скрамить или как-то по-другому аджайлить
Николай
и метрики брать пытаться стандартные для выбранного фреймворка сначала а потом уже под себя адаптировать
Николай
но не делить support и development методологически... в общем, есть опыт, когда это плохо поделено было - не очень позитивный такой как был и опыт, когда руководство решили сверху всё в ITIL запилить, в т.ч. и разработку - этот опыт ещё похуже)))
Николай
в целом - ITIL - это бюрократия, обезличенность и т.д. - это противоречит базовым ценностям Agile (каким - см. манифест)
Николай
хотя, вот, загуглил (в яндексе)) тему - https://yandex.ru/search/?text=agile%20vs%20itil - оказывается вполне так поднимается, и есть любопытные вещи - напр. http://www.realitsm.ru/2016/05/itil-vs-agile/
Oleg
в целом - ITIL - это бюрократия, обезличенность и т.д. - это противоречит базовым ценностям Agile (каким - см. манифест)
Какая там бюрократия? Даже не думал, что настанет время, когда люди будут про ITSM так писать. Там все ориентировано на заказчика-бизнес. В разработке так же.бизнес-заказчик
Oleg
В ITSM сервисный подход. Чем он плох?
Oleg
Лет 10 назад говорили: ITSM, ITIL ? Нее это для больших компаний, где большое кол-во ресурсов. Сейчас так говорят про DevOps, Agile
Oleg
Компания по разработке предоставляет сервис в виде разработки готовых решений, если говорить в рамках одной компании, то отдел разработки предоставляет услуги соседнему отделу в ИТ (OLA) или бизнесу (SLA)
Николай
В ITSM сервисный подход. Чем он плох?
Не плох! И даже хорош) Я вообще за него и в целом я даже больше за бюрократию, чем против)) Но! Я за ITSM для саппорта, а не для разработки. Всему своё место.
Ksenya
в целом - ITIL - это бюрократия, обезличенность и т.д. - это противоречит базовым ценностям Agile (каким - см. манифест)
ITIL - библиотека лучших практик обслуживания. Там ровно такая же бюрократия, как в правилах дорожного движения :) многие вещи написаны кровью сисадминов и инфраструктурщиков.
Oleg
Тсправление дефектов к чему отнесем?
Николай
Hotfix -это разработка или поддержка?
Хороший вопрос. Думаю, что это поддержка, плавно переходящая в разработку)
Николай
Тсправление дефектов к чему отнесем?
Не ушедшие в продакшен - точно чисто в разработку
Oleg
И еще вопрос: с чего вдруг devops появился? Это про поддержку, переходящую в разработку
Oleg
В ITIl есть разработка?;)
Oleg
Разработанное решение надо поддерживать?
Николай
Хорошие вопросы..) Отвечает Друзь! 😄
Donald
разве ITIL - не окаменевшее дно?
Николай
Разработанное решение надо поддерживать?
Ну это ясный красный!..
Donald
примерно противоположное agile
Николай
Буду сегодня курить матчасть - если времени и сил хаатит))
Накопал, что по мнению многих экспертов совсем нет! Как могло показаться...
Oleg
А после разработки решения, нужна ли мне разработка?
Николай
А после разработки решения, нужна ли мне разработка?
Разработка продукта заканчивается с его смертью
Николай
Разработка продукта заканчивается с его смертью
Или со смертью разработчиков! Уахахаха! 👹 Шутка
Oleg
Разработка продукта заканчивается с его смертью
Так а саппорт? Мы же все разработали?!Внедрили-все рады
Ksenya
разве ITIL - не окаменевшее дно?
Ахаха, вот это поворот :) задевелопили - пусть умрет неиспользованным :)
Oleg
Ахаха, вот это поворот :) задевелопили - пусть умрет неиспользованным :)
Так теперь многие про ITIL говорят, он теперь не моден :))) Только разработка это маленькая часть того, что предлагает IT
Oleg
Из новых перлов- DeVOps заменит все динии поддержки. ServiceDesk не нужен
Oleg
Автоматизируем все!
Ksenya
Так теперь многие про ITIL говорят, он теперь не моден :))) Только разработка это маленькая часть того, что предлагает IT
Да, всегда занятно это наблюдать. Хоть бы оригиналы ITIL почитали для начала и посмотрели, как работает любая большая дорогая инфраструктура...
Ksenya
Когда цена получасового простоя равна 10 годовым бюджетам "звёздной команды разработки"...
Donald
если под большой дорогой инфраструктурой понимать кровавый ынтырпрайз - он, как показывает практика, не работает. Вместе со всеми прекрасными процедурами. всё держится на мастерстве местных админов-эксплуатантов
Donald
ну и да, есть ли итил в компаниях, которые можно подозревать в разумности? в гугле? в фейсбуке? в твиттере?
Donald
по буквам. и пока что вы мне его не продали))
Donald
да вроде аджайл и девопс там сплошной, в разработке-то.
Oleg
В оазработке есть управление релизами, а конфигурациями, а изменениями?
Oleg
А вы знаете, что эти процессы описаны в ITIL? А про управление мощностями слышали? Ну да, скорее нет. Главное де херачить код и все. Главное аджайл и девопс. Только аджайл о чем? А девопс?
Donald
упраление мощностями это когда новые ноды в амазоне поднимаются по мере роста нагрузки?
Donald
:D
Donald
главное - придумать солидное название для банальных вещей, а там, глядишь, и 30 книг издадим
Ksenya
главное - придумать солидное название для банальных вещей, а там, глядишь, и 30 книг издадим
Это вы года 98 рождения? Сами серверные кластеры никогда не собирали, не обновляли и не мониторили, да? Фигак-фигак, и в продакшн? :)
Oleg
упраление мощностями это когда новые ноды в амазоне поднимаются по мере роста нагрузки?
Ну да чего там думать- оплачивай счета от амазона и все. Вы про 152 закон слышали?)
Donald
Это вы года 98 рождения? Сами серверные кластеры никогда не собирали, не обновляли и не мониторили, да? Фигак-фигак, и в продакшн? :)
собирал, обновлял и мониторил, но как-то обходился без итил, здравым смыслом и best practicles. Я всё делал не так, да?
Oleg
Владимир, вы мне девопс с аджайлом не продали;) да и на вопросы не отвечаете. Из контекста дергаете пока удобные фразы и все ;)
Ksenya
собирал, обновлял и мониторил, но как-то обходился без итил, здравым смыслом и best practicles. Я всё делал не так, да?
Если собирали, то, открыв ITIL, найдёте там свой здравый смысл. Это же даже не BOK, а library.
Donald
возможно, я бы его там стал искать, но пока такой потребности не возникло. кстати, там про микросервисы и continuous delivery что-нибудь есть, например?
Donald
очень модная вещь сейчас, как раз для управления мощностью и обновлений придумана
Ksenya
очень модная вещь сейчас, как раз для управления мощностью и обновлений придумана
Откройте первоисточники. Есть и про микросервисы, и про частоту релизов и правила интеграции.
Donald
а там точно первоисточник? откуда ж они берут это сакральное знание?
Oleg
возможно, я бы его там стал искать, но пока такой потребности не возникло. кстати, там про микросервисы и continuous delivery что-нибудь есть, например?
Там больше про организацию, про технологии и инструменты там нет. Потому как ранее говорили про виртуальные машины и SOA, теперь про контейнкры и микросервисы, что дальше?
Ksenya
Там больше про организацию, про технологии и инструменты там нет. Потому как ранее говорили про виртуальные машины и SOA, теперь про контейнкры и микросервисы, что дальше?
Главное, разницы ноль с точки зрения системной архитектуры...но слова поновее и помоднее, маркетинг такой маркетинг.
« Rev
@agile_ru   96
Fwd »