Спасибо

Да, всегда занятно это наблюдать. Хоть бы оригиналы ITIL почитали для начала и посмотрели, как работает любая большая дорогая инфраструктура...

я читал ITIL, могу сказать, что для технологических компаний, делающих цифровой продукт он не работает

и не потому что стар и плох, а потому что другую задачу решает

так что тут спорить бесполезно, надо вначале определить, кто в какой компании работает

если в компании с корпоративным устройством и корпоративными продуктами, то ITIL необходим, если в технологической компании, то лучше даже не начинать читать

если в компании с корпоративным устройством и корпоративными продуктами, то ITIL необходим, если в технологической компании, то лучше даже не начинать читать

Поясните, что вы называете "технологической компанией"? И что насчёт принципа "adopt and adapt" ITIL?

технологическая компания делает цифровой продукт, основная особенность цифрового продукта, что с клиентом основное взаимодействие происходит через программу, а human by exception

Кто-нибудь сможет ответить на этот вопрос?

Евгений, может, вам это поможет. В 6 PMBoK заточат под agile вообще всё :) https://www.pmi.org/certifications/types/agile-acp

насчет adopt and adapt это хорошее дополнение для повышения эффективности работы в корпорации

технологическая компания делает цифровой продукт, основная особенность цифрового продукта, что с клиентом основное взаимодействие происходит через программу, а human by exception

И? Это что, отменяет для этой программы необходимость работать?:)

нет, не отменяет, но ITIL как системный подход не может обеспечить функционирование такой программы

не только ITIL про это)

нет, не отменяет, но ITIL как системный подход не может обеспечить функционирование такой программы

? Вы какой-то другой ITIL читали. Что, по-вашему, должно обеспечить функционирование цифрового продукта, конкретно?

ну я тогда с другой стороны зайду

используется ли ITIL в спотифае и фейсбуке?

? Вы какой-то другой ITIL читали. Что, по-вашему, должно обеспечить функционирование цифрового продукта, конкретно?

конкретно обеспечивает DevOps со всеми его практиками

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

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

даже неделя это много

отсюда кстати береться понятие Time-To-Market

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

Так, ITIL вы читали когда-то давно :) там нет никаких слов про то, что CI - плохо или что эксплуатация и разработка обязаны быть разделены.

я 4ую версию в последний раз читал

конечно там нет таких слов

Вчера уже искала ссылку, но, вкратце, то, что называется термином DevOps, не противоречат ITIL, а в фб и Spotify используются в том числе процессы, описанные в ITIL.

не, процессы другие

у них только названия одинаковые

то есть конечно там есть управление конфигурацией и инцидент менеджмент

но внутри все по-другому

можно мне не верить конечно :)

но я из своего опыта построения эксплуатации в технологических компаниях говорю

Извиняюсь, не могли бы вы писать всю мысль в 1 сообщении?

но внутри все по-другому

Так что конкретно по-другому?:)))

конечно там нет таких слов

То есть слов таких нет, adopt & adapt должно быть принципом только для корпораций (хм, оригинально), всякие глобал гуру говорят, что ITIL и девопс не противоречат друг другу - но всё по-другому?:)

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

глобал гуру много чего говорят, если бы я им верил, то не делал бы дела :)

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

Что есть конкретная реализация configuration management practice. И?

да, она другая по принципу

да, она другая по принципу

Чем?

тем что подразумевает гибкое изменение стандарта процесса всеми участниками процесса

не надо для этого писать документ

Процесс, в вашем описании, это: что делается, где, кем и при каких условиях считается ок. Об этом есть явная договорённость, и дока может быть, может не быть, а практика - работать.

вот в DevOps эта явная договоренность может меняться любым участником процесса в любое время по согласованию с другими

для того, чтобы это реализовать надо по-другому работать

не надо для этого писать документ

Что-то мне говорит, если произойдёт одностороннее нарушение практики и начнут игнорить правила без согласования - будет атата:)

для того, чтобы это реализовать надо по-другому работать

В чем по-другому-то?:) в ITIL через страницу: хотите изменить, обсуждайте и изменяйте. И вообще adopt and adapt :)

ну ITIL же не только про adopt and adapt, если конкретно про эти слова говорить, то вообще много похожего

и у лодки на крыльях и реактивного самолета есть крылья

я тут не спорю

реально есть

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

Александр, честно, не понимаю почему вы, внедряя инструменты автоматизации, говорите об процессных подходах и что процессные подходы не работают.

я не внедряю инструменты автоматизации, я внедряю процесс, потому что инструменты без процесса не работают

И не ясно, с чего вдруг в спотифай фреймворк отменяет сервисный подход

я не внедряю инструменты автоматизации, я внедряю процесс, потому что инструменты без процесса не работают

Так выше вы пишите про инструменты. Тут у нас автоматизация и поэтому ITIL не работает.

Devops -классная штука, но только он о чем?

DevOps это другой подход к разработке и эксплуатации ПО

пока для него стандарта нет и это проблема, потому что мне можно сослаться только на Фаулера здесь

DevOps это другой подход к разработке и эксплуатации ПО

А не про доставку ли решения?

но Фаулер пишет не про инструменты, а про процесс

Процесс доставки, он же не отменяет сопровождение

DevOps это другой подход к разработке и эксплуатации ПО

DevOps это другой подход, чем ITIL. Чем другой? Чем ITIL.

нет, не про доставку, про доставку отдельная практика Девопс - Continuous Delivery

нет, не про доставку, про доставку отдельная практика Девопс - Continuous Delivery

Тааак. И какие еще праутики есть в DevOps-Continouos Integration? О чем еще забыли?

смотрите в DevOps требуется изменение подхода к разработке, разработчик не просто пишет алгоритм, он должен понимать, как работает его код в системе. Для этого разработчику требуется специальная компетенция и практика CI и доставки изменений на тестовое окружение самим разработчиком

я выделяю в DevOps три базовые практики: Infrastructure as Code Continuous Delivery Continuous Monitoring

Процесса нового не вижу.как была цепочка: Потребность-тз-код-тест-прод. Так и осталась

не ТЗ, а бэклог

и в цепочке можно сразу на прод с Canary Release

смотрите в DevOps требуется изменение подхода к разработке, разработчик не просто пишет алгоритм, он должен понимать, как работает его код в системе. Для этого разработчику требуется специальная компетенция и практика CI и доставки изменений на тестовое окружение самим разработчиком

А что мешает разработчику писать код строго по спеке "контейнер получает на вход это, отдает то" и понятия не иметь о целостной системе?

А что мешает разработчику писать код строго по спеке "контейнер получает на вход это, отдает то" и понятия не иметь о целостной системе?

Саппорт никуда не девается. То что часть можно автоматизировать, не говорит о полном его исключении

А что мешает разработчику писать код строго по спеке "контейнер получает на вход это, отдает то" и понятия не иметь о целостной системе?

это работает, когда есть общий стандарт, для быстрого движения надо уйти от опоры на строгий стандарт и сделать стандарт гибким

Не понимаю, почему цифровая трансформвция или внедрение практик DevOps изменят, по вашему мнению, процессные вещи

Коллеги, скажите, особенно те кто агайлизирует на регулярной основе командой от 5 человек в достаточно динамичном потоке (несколько разнородных длинных проектов), какой софт вы используете? Вопрос безусловно холиворный, но очевидно носящий крайне высокую практическую ценность. Мы используем pivotal, он очень узкий хотя и хорош. Пробуем wrike (несовсем агилен) и hive (на первый взгляд лучший но еще сыроват по перформансу и интеграции). Еще встречал какойто redbooth подходил под требования, но он какойто совсем неотмира. Я кажется перебрал очень много всего, но есть ощущение что список решений бесконечен, каждый раз как начинаю гуглить нахожу что-то новое. Что я выделил как необходимое с опытом: 1) агайл/канбан борд стайл - самый рабочий вариант 2) наличие вложенностей задач хотя бы несколько уровней, с разными исполнителями (один уровень проще в голове держать чем оформлять) 3) взаимосвязи и как следствие представление в гантте - в этом случае работа разнородных команд не требует ручной синхронизации постоянной спринтов/тактов 4) интеграция качественная с облаком, репо и почтой хотя бы на вход - опять же для автоматизации ручного хэндджобп который должны давно роботы делать.

И я всеми руками за DevOps и Scrum, XP и т.д.

Но сервисы и услуги никуда не пропали, они все на месте:)

Не понимаю, почему цифровая трансформвция или внедрение практик DevOps изменят, по вашему мнению, процессные вещи

я тут сошлюсь на свое видео https://www.youtube.com/watch?v=c_PR9Zoy5oo&t=2893s Спасибо кстати коллеги, по результатам обсуждения напишу статью, где приведу все в стройный вид

ТЗ никогда не бывает статичен, сильно отличается это от backlog'a?

базово сошлюсь на то, что оргструктура обусловлена задачей, которая решается

я тут сошлюсь на свое видео https://www.youtube.com/watch?v=c_PR9Zoy5oo&t=2893s Спасибо кстати коллеги, по результатам обсуждения напишу статью, где приведу все в стройный вид

Да вот статья прям правда нужна:)

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

Модель все та же: Заказчик-исполнитель