Pull to refresh
6
0
Валерий Куваев @Vkuvaev

DevSecOps

Send message
Это разные вещи. В статье, думаю, имелось в виду совокупное зло пренебрежения минимально необходимыми KPI и пренебрежения минимальным объемом формального описания бизнес-процессов.

Лучше без KPI, если компания не жадная(% с продаж, например), а то можно увлечься и очень легко накидать таких KPI, что сотрудники начнут хакать эти самые KPI, сводя всю деятельность к «полезной», т.е. только той, которая улучшает показатели KPI.

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

Попробую аналогию. Тут сказано, что все должны дружить и нужен клевый менеджмент. Супер, а куда деть реальность? Предположим, что организация это как клетка: есть органеллы, что делают свою работу и есть оболочка через которую идет взаимодействие- менеджмент. Новые идеи, чтобы они проникли внутрь организации и были восприняты менеджментом приходится как ДНК вируса обрамлять в оболочку способную помочь в проникновении в клетку. В данной аналогии такой оболочкой служит «маркетинг». Как ни хотелось бы чтобы дримтим был, в реальности требуются капитальные усилия, чтобы люди купили простые и понятные идеи. А «маркетинг» способствует тому, что если поблизости окажется эффективный менеджер, то он не будет активно противодействовать, восприняв адаптированную идею.

Ну и разумеется, есть те кто за видимым фасадом прячут пустоту. Мое мнение, плевать на тех, кто декларирует, что он develop'ит по agile, deploy и Test у него по Devops, хотя организация лишь перевесила таблички и перепечатала визитки. Если то, что мы пишем, будут читать разумные люди и делать определенные выводы, значит написали не зря.
Это в общем-то факт, про Excel. Есть такие примеры.
Разумеется, все по-разному подходят к учету. Кто-то пользуется тем, что Вы описали, кто-то хочет более комплексных вещей, как в статье.
Довольно самонадеяно приписывать все баги софта лени разработчика.

Имея в виду коммерческую разработку, думаю, здесь присутствует сочетание разных факторов, один явный общий фактор это зрелость, определяющий то, что мы все считаем нормой:
  • Разумная попытка менеджмента сэкономить — Очень трудно построить вменяемый бизнес кейс, почему нужно тестирование разного типа. Ну и построив его — попробуйте этот кейс протащить до бюджетного комитета. Инициатор, скорее всего столкнется с людьми далекими от понимания сути тестирования, но знакомыми с финансовыми расчетами, надо их суметь грамотно убедить не только в конечных 100500% ROI, но и в изначальных посылках
  • Безграмотность руководства — слепая уверенность, что разработчик сам все протестирует, а если не сделает, мы его накажем. При этом упускается из вида, что отвечает за продукт сам заказчик в итоге, тот кто акты подписывает. В конечном счете, тот, кто подписывает, понимает, что нужно тестировать, обычно после факапа, но сталкивается с тем, что это надо как-то продать наверх, может получится, а может нет: лень, боится за свое место, не разбирается в теме… (нужное подчеркнуть). По принципу лучшее из двух зол, попытается создать тестирование своими силами, тут и велосипеды бывают и удивительно удачные попытки
  • Пользователи — в общем-то они стали драйвером толкнувшим рынок в гибкие методики и в DevOps. Они неразборчивы в среднем, ведь нужно понимать что такое качественный софт, чтоб как-то ранжировать тот софт которым пользуешься.
  • Отсутствие обратной связи — Коммерческие разработчики пытаются удовлетворить этого среднего пользователя, тщась угадать, что из параметров софта ему важно. Скорость выпуска фич? Продвинутость фич? UX? Стабильность? и так далее… При этом угадать — самое верное слово. Сейчас появляются решения которые могут помочь выяснить профиль использования софта, т.е. понять как используется то, что сделано, используется ли, есть ли какие ошибки. Пока этой обратной связи нет для большинства коммерческих разработчиков. Типовую поддержку я не считаю этой связью, т.е. она не собирает профиль использования и т.д.


Думаю много еще факторов есть, и не надо валить все на Agile методики, это лишь инструменты.
Но, очевидно, что происходящее на рынке это что-то новое, так что все держим ухо востро.
Во всех организациях, в которых я наблюдал внедрение Scrum, менеджеры начинали с утреннего standup и planning сессий. При этом все остальное они оставляют как было. Ни вам создания cross-functional команд и делегирования им полномочий. Ни сосредоточения у product owner'у права расставлять приоритет. Ни retrospections. Вишенкой на торте обычно является совмещение роли product owner и scrum-master.

Согласен, Некоторые люди полагают, что гибкость заключается в том, чтобы внедрить Scrum частично. Жаль, что они не поняли идею.

Но есть ведь и другая сторона:
Организация включающая хотя бы 100 разработчиков с менеджерами, директором, руководителями PM'ами, и иже с ними, закосневшая в годовых релизах и управляемая прямой иерархией не сможет воспринять эти четыре ценности. Даже если владелец послушал Германа Оскаровича, и очень хочет чтобы его компания стала феноменально гибкой.

Иногда нужно пнуть, чтоб полетело. За это и платят деньги. Я как-то имел бесплодный диспут с разработчиком банка, я ему про идеи Scrum, как это работает в маленькой команде, про психологию самоорганизации, а он все гнет про то, что как это без руководства и утверждения планов, непорядок…

Ну не виноваты разработчики SAFe, что в манифесте нет ответа на то, как масштабировать эти принципы на большую организацию и как подтягивать уровень зрелости людей. Эволюционно получается медленно. Революционно — плохо. Что делать-то?

… Идет смещение акцента с ценностей в сторону инструментов.

Смещение от ценностей в сторону инструментов присутствует, но с SAFe это никак не связано, тут скорее жажда наживы, как и всегда было до этого, ну вот хоть с ITIL. Или наивная надежда, что начнем как нибудь, а там стерпится — слюбится.

вы объяснили в точности то, что предлагает Dave. И заметьте, для того чтобы донести суть, вы не использовали SAF.

Мне приятно, разумеется, что я как-то сумел переформулировать цикл Деминга.
Но как PDCA применить к большой организации, предположим вы приглашенный гуру подписавший манифест и вот перед вами сидят эти самые, полные скепсиса, 100 разработчиков, весь управленческий состав и PMO. И вы рисуете этот круг и говорите — вот цикл, и четыре ценности в манифесте. Это все что нужно. Стряхиваете мел с рук и говорите немому залу — какие будут вопросы. Думаю будет тишина, затем шум отодвигаемых стульев.
Люди не смогут этому следовать, в это нужно поверить и желательно попробовать как ребенок, под контролем, провести ретроспективу с опытным гуру, осознать ошибки в восприятии предмета, еще раз, и еще, и еще. И так полетит. CSM тренинг не напоминает? Ну а SAFe, чуть сложнее.

Может быть это я наивен и не видел трэш тренингов по Scrum где ценность и идея отодвинуты на задний план? Мне даже интересно есть ли такие примеры?
странная система комментирования, :( хотел доразвить мысль, и подкорректировать неясности, сказала, что поздно. Подозрительно напоминает системы helpdesk \ crm где ничего нельзя менять… Или после нескольких минут это все куда-то отсылается ;)?
Бесспорно, равно как и то, что Agile есть прилагательное, и если его употреблять как прилагательное, можно многих ловушек избежать.

Если Agile — это в первую очередь идея, то SAFe — инструмент. Не надо его возводить в ранг чего-то высокого. Т.е. сертификация SAFe лишь на уровне понимания фреймворка. В этом плане он честнее чем CSM.

Если интересно, посмотрите на их сайте, все что там написано немыслимо постичь, без принятия образа мышления описанного в манифесте, ну и без понимания Lean.

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

Есть один момент, которым я был недоволен раньше и укрепился в своем мнении сейчас. Dave критикует индустрию «Agile», но совершенно не признает, что именно благодаря ей, настоящих последователей гибких методик стало очень много, т.е. Людей которые поняли в чем идея. Да, побочно, что есть люди которые считают Agile отличной методикой. Но так бывает с любым знанием, что оно искажается.

Поэтому, когда кто-то ругает инструмент, или людей которые его придумали, и огорчается, что он не это имел в виду, мне становится неприятно. Черт возьми, если считаешь, что все исказили и неправильно делают, помоги, объясни как надо. А если не знаешь как, то не мешай тем кто пусть и топорными методами, с точки зрения критикующего, но все же помогает, т.е. реально результаты проектов разработки улучшаются.

Все кто в теме знают, что на большую организацию эти подходы не ложатся просто так. Есть спрос на это знание и опыт. Его кто-то и как-то заполняет. Очевидно, что под копирку это знание не работает. То вот KPI какой-то мешается, то планирование сложное.

Можно всегда что-то улучшить.
Может быть с этого все же можно начать? Сделать на одном проекте, посмотреть как получилось, понять что не так, что-то изменить, повторить цикл. Так родится собственный набор правил конкретной организации. Я не прав?

Или дело в зависти?
1. Это конкретная предметная область, масштабирование гибких подходов к разработке на крупную организации. Эта тема достаточно близка мне, и я общаясь с крупными компаниями вижу её очень даже вживую, потому ну никак не соглашусь, что это абстракция :)

2. расширю, что речь про организацию, процессы и технологии ( проект это частность), далее, усложняющие факторы, навскидку:
— Количество разработчиков (настаиваю:) и их структура подчинения
— Иерархия организации
— Количество систем и их архитектура
— Зрелость организации и каждого сотрудника в частности
— Степень автоматизации существующих процессов

Я, кстати, думаю, что основной трэш для гибкого подхода как раз не 2 на БД, 2 на API, 2 на бек офис.., а те самые 10 на фронт :)

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

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

Есть ведь задачи когда lead time должен составлять недели, дни или даже часы, минуты. Это и есть двигатель изменений. Тут вопрос не в том какая методика нравится. А в том, какая подходит под текущую бизнес ситуацию и под конкретные задачи. У каждой есть зона(ы) применимости и зона(ы) непригодности. Точка.

Если говорить о верхнеуровневой задаче то да, это одна из них. По-сути идея стоящая за этим фреймворком- перенести все прелести работающих гибких методик на масштаб крупного разработчика ( крупного это где-то более чем 100 разработчиков). Есть и другие подходы к масштабированию, но SAFe, на мой взгляд, один из самых проработанных, хотя при этом и несколько сложный в восприятии. Сравнение их — это другая тема.
SAFe, корректнее назвать фреймворком, который под собой собрал несколько методик: Scrum, Kanban, практики XP, Lean Software Development и связал их вместе.
А вот вопрос можно ли поподробнее раскрыть? Какие задачи У этого фреймворка? Или какие стадии задачи (на разработку, к примеру) в рамках этого фреймворка? И все равно нужно будет пояснить более конкретно сам вопрос.
Под зонтиком обычно подразумевается сбор и корреляция всего, что "намониторили" со всех других систем мониторинга, (включая тот же Zabbix).
Зоопарка везде хватает, на рынке ни у кого, пожалуй, нет инструмента, который бы собирал все и отовсюду, буквально.
А на единое окошко мониторинга с корреляцией есть реальный спрос. Собственно об этом и написано.

Добавлю, заранее, что речь идет о корреляции по хронометражу и по топологии на базе сервисно-ресурсной модели, которая автоматически строится с помощью средств автообнаружения.
Карма была нужна для саморегулирования комьюнити, если кто помнит, до Хабра был популярен NNM, он умер, когда в комментарии стали постить рекламу, ссылки куда-то, ну и всякую нецензурщину. Админы не справились и люди просто ушли. Похоже, общее мнение, что сейчас наоборот, фильтр слишком сильный.

Information

Rating
Does not participate
Registered
Activity