Мы тут дискутируем с коллегой на эту тему периодически. На мой взгляд проблема с микросервисами в том, что по сути предполагается, что они реализованы плюс-минус идеально и никому не надо лезть внутрь для поддержки и развития. А если уже понадобилось соответствовать, то выбросили старый и написали другой. Проблема в наших спорах одна — коллега он такой чистый теоретический программист уровня спикера митапов, а я прикладной математик — 3Dшник. Для него микросервис это блок кода, а для меня в нём возможно запрятан сложный вычислительный алгоритм с прибамбасами. Который реализует какую-то бизнес-логику и требования к ней, в отличие от протоколов TCP/IP могут измениться из разряда «а теперь котики умеют летать».
В таком варианте микросервис, на мой взгляд, оказывается адским адом поскольку, во первых, предполагается, что внутри «ящика» разработчик может делать что угодно, главное чтобы интерфейс был удобным. А во вторых… Во вторых по сути поддержка этого дела ничем не отличается от поддержки блока кода кроме усложнённых взаимодействий с внешними элементами системы.
А переписать какой-нибудь тесселятор для извращённых геометрий, на который потратили полтора года с нуля — утопия, которую никакому менеджменту не продашь.
Так что, как мне кажется, в мире систем с долгим жизненным циклом и сложными компонентами это чревато наоборот деградацией в возможности поддержки и развития кода.
Моими глазами в описаном кейсе нарушено сразу несколько важных моментов AGILE и SCRUM в частности, то есть, согласно евангелистам получившееся SCRUMом называть негоже.
Самое главное — любая AGILE методология предполагает участие команды в формировании самой методологии, то есть если команду что-то не устраивает команда меняет правила, подстраивая процесс под себя. Собственно главной постулируемой целью появления AGILE методологий была разгрузка команд, вывод их на ровный режим работы без пиковых перегрузок и внезапного заваливания «срочными» никому не нужными задачами.
Ну и в SCRUM трудоёмкость измеряется в сторипоинтах, причем на реальное рабочее время это должно проецироваться только для всей команды в целом, причем производительность команды оценивается по результатам нескольких предыдущих спринтов.
К сожалению часто когда инициатором внедрения AGILE, особенно SCRUM является большое начальство, по сути, внедрение agile рассматривается как внедрение жесткой контролирующей процедуры для маскировки собственной некомпетентности, нежелания вникать в детали и неуверенности в себе.
В итоге в приведённой выше истории получился непонятный уродец, удобный для рисования табличек, но совершенно не ориентированный на удобство разработчиков и, более того, не обладающий возможностью ретроспективной модификации процессов. Развал команды — естественное следствие. Называть это Agile примерно как написать «Боинг» на газовом баллоне с примотанным скотчем крыльями и после рассказывать всем о том, какие плохие они самолеты клепают.
В таком варианте микросервис, на мой взгляд, оказывается адским адом поскольку, во первых, предполагается, что внутри «ящика» разработчик может делать что угодно, главное чтобы интерфейс был удобным. А во вторых… Во вторых по сути поддержка этого дела ничем не отличается от поддержки блока кода кроме усложнённых взаимодействий с внешними элементами системы.
А переписать какой-нибудь тесселятор для извращённых геометрий, на который потратили полтора года с нуля — утопия, которую никакому менеджменту не продашь.
Так что, как мне кажется, в мире систем с долгим жизненным циклом и сложными компонентами это чревато наоборот деградацией в возможности поддержки и развития кода.
Самое главное — любая AGILE методология предполагает участие команды в формировании самой методологии, то есть если команду что-то не устраивает команда меняет правила, подстраивая процесс под себя. Собственно главной постулируемой целью появления AGILE методологий была разгрузка команд, вывод их на ровный режим работы без пиковых перегрузок и внезапного заваливания «срочными» никому не нужными задачами.
Ну и в SCRUM трудоёмкость измеряется в сторипоинтах, причем на реальное рабочее время это должно проецироваться только для всей команды в целом, причем производительность команды оценивается по результатам нескольких предыдущих спринтов.
К сожалению часто когда инициатором внедрения AGILE, особенно SCRUM является большое начальство, по сути, внедрение agile рассматривается как внедрение жесткой контролирующей процедуры для маскировки собственной некомпетентности, нежелания вникать в детали и неуверенности в себе.
В итоге в приведённой выше истории получился непонятный уродец, удобный для рисования табличек, но совершенно не ориентированный на удобство разработчиков и, более того, не обладающий возможностью ретроспективной модификации процессов. Развал команды — естественное следствие. Называть это Agile примерно как написать «Боинг» на газовом баллоне с примотанным скотчем крыльями и после рассказывать всем о том, какие плохие они самолеты клепают.