Pull to refresh
-5
0
Василий Мажекин @mazhekin

Web программист

Send message

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

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

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

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

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

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

Самое интересное, что я понимаю и одного и другого. Не заострять внимание на качестве кода, тут имеется в виду не слишком детально и полно дописывать прямо код, как в конечном продукте. Но то что подразумевается под термином "архитектура" тоже важно. Это писать код так, чтобы было понятно как его, потом быстро изменить, он должен напоминать структурированную систему блоков, которые можно быстро менять местами, частично заменять, перестраивать и дополнять, это универсальное слово — слабая связанность (loosely coupled).
То есть слабая связанность и неидеальный и как бы незаконченный код, практически на чем строится первый MVP или релизные фичи так что оба правы.


И статья очень толковая, я немного бегло прочитал, но суть скрама там прям полностью поймана и разложена по полочкам. А самое главное, что ребята достигли результатов, а заказчик получил продукт.
))) Вот чем надо хвастаться, а не "я тимлид, и нас большая и дружная команда, мы оторвали ковш от экскаватора (взяли что то из скрама), и уже делаем непонятно что вот уже несколько лет".

О, интересно, какое разнообразие, а тут под термином "тимлид" уже подразумевают руководителя большого подразделения. Тимлид тимлидов)))


Тимлиды — это что то вроде лучшего игрока, в дворовой команде по футболу, на фоне остальных соседских парней, которые знают о профессиональном футболе, только из телевизора(из гугла). Обычно в таких командах, нет профессионалов, типа девопс инженеров, скрам мастеров, ux дизайнеров и.т.п. Ну немного научились все программировать(пинать мяч)… Более того в таких командах даже иногда не то что не понимают четко, чем занимаются эти специалисты, но и названия профессий не всегда могут вспомнить. Поэтому собираются эти ребята и решают кто более менее может бить по мячу лучше всех, назначают его тимлидом, хз какие у него обязанности, главное он будет бегать по полю и заменять кого попало и как попало. Ну вы поняли мысль я думаю ))) ребята, забудьте это слово "тимлид", лучше пойдите учится на курсы какие нибудь )) не выдумывайте чепуху и начните играть в профессиональный футбол. Вот например https://geekbrains.ru/courses

Тимлиды — это что то вроде лучшего игрока, в дворовой команде по футболу, на фоне остальных соседских парней, которые знают о профессиональном футболе, только из телевизора(из гугла). Обычно в таких командах, нет профессионалов, типа девопс инженеров, скрам мастеров, ux дизайнеров и.т.п. Ну немного научились все программировать(пинать мяч)… Более того в таких командах даже иногда не то что не понимают четко, чем занимаются эти специалисты, но и названия профессий не всегда могут вспомнить. Поэтому собираются эти ребята и решают кто более менее может бить по мячу лучше всех, назначают его тимлидом, хз какие у него обязанности, главное он будет бегать по полю и заменять кого попало и как попало. Ну вы поняли мысль я думаю ))) ребята, забудьте это слово "тимлид", лучше пойдите учится на курсы какие нибудь )) не выдумывайте чепуху и начните играть в профессиональный футбол. Вот например https://geekbrains.ru/courses

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


Интересно, как такие курсы выглядят? Приходишь и там тебя учат ответственности, коммуникации, работе в команде и креативности. Все как-то абстрактно. А наставник — похож больше на психолога в компании.
Я согласен, дело не в сертификации, а в реальном обучении, сертификат это всего лишь ориентир или просто значок, а какой путь в обучении прошел человек и какой багаж знаний приобрел, чтобы получить этот значок, очень быстро выявляется в рабочих условиях. Если чеклисты и эксперименты в практической работе начинаются без обучения, вот оно и есть «зомби-скрам». Но, есть вероятность, что может быть будет изобретен какой-то новый более эффективный метафреймворк, но вероятность этого очень мала, и придется загубить немало проектов для обкатки этого нового инструмента, а потом убедить весь мир, что это лучше чем скрам.

«Демократия — наихудшая форма правления, если не считать всех остальных» У. Черчилль.
в ватерфоле, можно подстраиваться к новым бизнес требованиям после каждого спринта (или там все запланировано все до релиза)?
в ватерфоле проводятся ретроспективы после каждого спринта, для адаптации командного взаимодействия (там пока все беды в релизе не вскроются никого ничего не волнует)?
в ватерфоле есть тесное взаимодействие владельца продукта с командой? (как правило овнер только в конце увидит результат)

мне кажется главная ошибка в понимании скрама, это в понимании термина «agile» (гибкости, проворности), эту гибкость воспринимают как анархию для разработчиков (как нам удобно так и будем работать), а на самом деле механизм(правила) скрама позволяет сфокусировать команду на результате (коучинг) и следить и гибко подстраиваться под бизнес требования продакт овнера (аналитика, заказчика, пользователей) эмпирически после каждого спринта, грамотно(гибко) работать с беклогом до запуска задач в спринт, помогать овнеру правильно формулировать пользовательские сценарии(истории) в беклог и т.п. Этим занимается скрам-мастер, который ведет и команду и владельца продукта и отвечает за успех всего мероприятия(проекта) )).
то есть сначала лучше жестко выучить цифры, буквы, слова и пунктуацию, а потом эмпирически пытаться писать стихи, повести и рассказы, также и в обучении, сертификации и применении скрама, там несколько уровней
) ну тогда это не скрам, а какая то своя agile-методология, которую можно назвать, например, скрампам-парампампам. Ибо несоблюдение базовых событий и артефактов скрама уже к скраму имеет небольшое отношение. Первый уровень сертификации по скраму как раз и цементирует этот каркас, другое дело если люди его не понимают и не могут адаптироватся в нем для эмпирического развития, ну так это уже более высшие ступени постижения скрама www.scrum.org, после того как они назубок знают базовые вещи, которые обкатаны под контролем большого сообщества.
Скрам Фреймворк это достаточно жёсткий, с четко прописанными артефактами и событиями, каждое из который имеет достаточно глубокий смысл. Скрам это одна и та же модель, которая применяется для разных проектов (от ремонта до разработки ПО). И знать его надо как воинский устав, ибо высунулся из окопа полголовы снесло (проект забуксовал, упёрся в бесконечность, команда разваливается или начинает заниматься не тем чем нужно). Это жёсткий каркас в который гибко помещают запутанную среду (проекты со слабо сформулированными требованиями, командой и т.п.), для которой он и был создан. Я поэтому и написал, чтобы не было зомби-скрама, нужен Скрам мастер который обучен всем этим жёстким артефактам и событиям, и как хорошим инструментом эмпирически вытачивает успешные проекты. А зомби скрам это нарушение правил скрама, из-за неполного его применения. Там возьму чуть чуть из скрама а это нам не нравится и мы это не будем применять, вот и зомби скрам. Скрам это инструмент его — не надо переделывать и гибко изменять, его надо изучить понять, и умело применять в запутанных средах.

Scrum (skrʌm; англ. scrum «схватка») — Фреймворк гибкой разработки ПО. Фреймворк основан на эмпирическом методе и предназначен для разработки продуктов высокой ценности в запутанной среде.

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

Не надо через боль, нужно сначала обучится, https://www.scrum.org/. В штатах эта профессия в топе высокооплачиваемых профессий наряду с прокурорами, инженерами т.п. https://www.forumdaily.com/top-25-samyx-vysokooplachivaemyx-professij-v-ssha/. Боль и страдания уже прошли предыдущие поколения разработчиков, которые уже выработали успешные рабочие модели.

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

Профессионалы, которые пишут сложные проекты понятным кодом, а не простые приложения сложными каруселями. Умеют технически корректно декомпозировать приложения, и не раздувают рулоны перепутанных файлов огромным количеством строк.
Про гиганта Microsoft постеснялся написать )). Подумал они колаборационируют с Гуглом только по тайпскрипту. Согласен, он больше похож на десктопные приложения, я думаю программистам потому и легче в него перейти. Но кажись в Реакт прут в основном из верстки с меньшим опытом программирования, поэтому их и много.
React же в свою очередь сразу отпугивает профессионалов, у которых большой опыт разработки, вводными курсами где сразу нарушается основополагающий принцип всего программирования как separation of concerns (SoC), смешивается html и js. А также отсутствие контроля над кодом как с тайпскриптом в ангуляре сразу, для тех кто привык компилировать, а не в рантайме ошибки ловить.
Ангуляр по популярности не превосходит Реакт потому, что новичкам труднее в него войти. Путаница с первой версией мешает новичкам. И то что надо сразу знать и тайпскрипт и rxjs тоже препятствие для многих. Для больших командных коммерческих приложений стайлгайд (https://angular.io/guide/styleguide) желательно знать, чтобы писать однообразный командный код и никто не запутывался в коде. Но если все преодолеть, то ангуляр в руках разработчика становится мощной перспективой машиной для очень серьезных приложений, которая ещё и поддерживается таким гигантом как Гугл.
Статью можно было назвать так «Почему Экскаватор не работает и что с этим делать»

Аджайл — это инструмент, если инструментом неправильно пользоваться то он и не принесет никакого профита, а только навредит. Есть замечательная басня Крылова очень актуальная сейчас, что то там про одно животное и приспособление для улучшения зрения.

Увлечение личными встречами тоже имеет свои негативные последствия

Находим или вспоминаем уроки по скраму, и обнаруживаем что таймбоксы мы забыли или посчитали их ненужными.

Менеджер vs Надзиратель. «идеальный PM» должен быть на стороне команды, помогать каждому ее участнику разобраться в целях и задачах проекта


Идеальный ПМ в аджайле как-бы не определен, ну может быть это Product Owner, он может представлять интересы заказчика и замещать его как типа его представитель, работать вместе с аналитиками и дизайнерами и формировать беклог продукта. Открываем опять учебники, и еще одна важная роль, это скрам-мастер без которого даже не стоит вводить аждайл подход, который следит за правилами нарушение которых ведет к бедам типа расхода времени (из за не соблюдения таймбоксов). Он не менеджер и не надзиратель, а тренер и мотиватор, причем он одинаково помогает и овнеру формировать требования и команде понять, декомпозировать и работать с требованиями заказчика. Если его нет аджайл будет убыточным.

Agile-принципы != KPI

Самый супер тренер или скрам-мастер не поможет если не подобрана квалифицированная команда. Аджайл (тренер) нам не помог поэтому он плохой, а может нет игроков способных вытянуть проект.

«Неформальный» agile

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

Итого, мы узнали, что модно и круто копать котлованы экскаватором, взяли его, пнули по колесу дернули ручку, пролистали бегло скучную и длинную инструкцию, все таки вырыли яму лопатами, и всем рассказываем потом, что экскаватор — это какой-то неэффективный, модный тренд, который не работает.
Круг замкнулся,

Расскажите, пожалуйста, что за нормальные проекты такие, чем отличаются от «ненормальных», и почему тимлиды на них еще и тормозить других начинают

Если с кадрами и управлением на проекте все печально, конечно «тимлид» нужен. Но имейте в виду, что появится побочка, в том, что кадры и управление не смогут улучшаться из-за ограничения в виде того самого тимлида.
только поинты эти берутся не столько от роли, сколько от того, как работу этой роли организовали и других внешних факторов

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

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

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

Information

Rating
Does not participate
Location
Калининград (Кенигсберг), Калининградская обл., Россия
Registered
Activity