Пришли злобные скрамщики, что-то сделали ("но я не скажу что изменилось, т.к. это не важно")
Эта статья не про конкретику и не про анализ решений принимаемых в рамках проекта. Я избегаю конкретики не потому что она не важна, а потому что не могу ей поделиться не рассказав слишком много. Кроме того я не могу её правильно проанализировать.
И все стало плохо.
Плохо стало не всё и не для всех, я описал свой опыт. Статья рассчитана на людей которые испытывают то же что и я. Она для тех кто понимает что у них что-то идёт не так и это как-то связано со скрамом, но не могут сформулировать мысль.
Скрам описан через набор артефактов, событий и ценностей, он не содержит цикл, цикл реализует команда, скрам лишь декларирует факт наличия цикла. Скрам декларирует события но не описывает как именно их реализовать, какую последовательность действий выполнить чтобы успешно провести событие, какие проблемы могут возникнуть в процессе и как их решить, всё это должна знать команда. Скрам декларирует ценности но не показывает как именно их проявлять, это ответственность команды. Если команда не имеет достаточно опыта для реализации закдекларированных в скраме концептов, скрам им не поможет, и скрам-мастер не подстрахует.
Опытный мастер - опытный менеджер. Неопытный мастер - неопытный менеджер. Как и любой менеджер он не обязан быть специалистом в чем-то ещё, чтобы быть полезным но это ему поможет.
Так всё таки скрам-мастеру нужны навыки менеджера? а если разработчики не понимают как оценивать задачи из-за того что не знают как именно будут их решать? Чистый скрам-мастер в такой ситуации сможет прежложить в лучшем случае менее точную систему оценки, вместо часов сторипоинты или размеры футболок. Менеджер предложит оформить задачу как исследовательскую и отказаться от её оценки, ограничившись лимитом времени на исследование. Тимлид же засчёт технических навыков и опыта может подсказать решение тем самым устранив неопределённость при оценке вместо борьбы с её симптомами.
Вы пришли к тому же примеру что я привёл в статье, там где я говорю о том что скрам напоминает интерфейс из языков программирования. А реализацию этого интерфейса предстоит реализовать команде вместо того чтобы переиспользовать дефолтную реализацию которая могла бы быть предоставлена фреймворком. Детали реализации, такие как практики не являются частью интерфейса и сильно зависят от контекста конкретной команды и могут не иметь смысла в тех или иных ситуациях, для правильного их использования требуется опыт, которым обладают сильные профильные специалисты например инженеры и/или менеджеры, скрам-мастер же сам по себе таким опытом не обладает и поэтому не может подстраховать команду если та не справится.
Ценности - это из области Ваших внутренних убеждений. Разделять ценности - принимать решения и действовать в соответствии с ними. Например, если с планирования спринта Вы уходите с мыслью "мне за спринт надо реализовать такую-то фичу в моем компоненте", а не "мы за спринт должны достичь такой-то цели", то приверженность - это не про Вас. Уважение - признать, что коллега имеет право на свое собственное мнение, право его высказывать, право на поддержку, право совершить ошибку в той же мере, что и Вы.
Я ничего не имею против ценностей. Я недоволен методом их изложения. Просто задекларировать ценность недостаточно. Нужно уметь эту ценность реализовать самому и научить ей других а этого в скраме нет. Я не получал негатива от команды и команда уважала моё право совершать ошибки. Но для того чтобы эти ошибки прекратились этого было недостаточно. Цель ведь не в том чтобы придерживаться какой-либо ценности а в том чтобы извлекать из этой ценности пользу, например прекращеие ошибок. Я проявлял приверженность, и активно участвовал в процессе трансформации, поначалу и довольно долго это держалось на вере, но время прошло, вера закончилась, проблемы остались. Какой смысл от приверженности бесполезного в новых условиях человека?
Ещё пример распада ценности без изменения последовательности действий. Когда ты просишь человека проявить открытость, например спрашивая чем ты можешь ему помочь. Ты как бы берёшь обязательство ему помочь. Если ты ему не помог, один раз, нестрашно. Но если это происходит постоянно или ещё хуже если ни один такой вопрос не привёл к решению. Ценность открытости скрывавшаяся за предложением помощи рассыпается, на её месте возникает ощущение пассивного давления. Цель осталось прежней, средство реализации осталось прежним а эффект со временем изменился.
Я сразу написал, что это не более, чем предположения. Но в статье не упоминается, что Вы демострировали желание работать над общими задачами или обсуждать с командой проблемы скрам на ретро, фраза про тим-лида, компетенции которого никуда не делись, косвенно говорит, что у остальных членов команды компетенции развиты слабее.
Нежелание возникло не сразу, это шло постепенно. Заявлением о необходимости тимлида в команде я не пытаюсь принизить других её членов. Тимлид в моём представлении не водит коллег за ручку, а лишь иногда подстраховывает когда те не могут решить проблему сами.
Для меня скрам - это способ решения проблем, например, избавление от "функциональных колодцев". Или обеспечение прозрачности статуса в долгосрочных проектах (через спринты).
Рад за вас, я не ощутил его как способ решения проблем, а скорее как набор норм который воспринимается как инструмент но им не является.
Ритуалы на начальном этапе - это Сю в Сю-Ха-Ри. Проверенный на протяжении веков путь к мастерству. Я видел многих, которые начинали с Ри и фейлились.
То что я видел не было похоже на Сю. Когда ты делаешь сю, у тебя и измеримый результат должен появится, совпадающий с результатом мастера по искомому критерию, рано или поздно. Я же не увидел результата, а продолжать повторять то что не приносит результата без каких либо изменений я не видел смысла.
Да, каркас дома это не дом, но каркас дома это часть реализации дома, элемент его конструкции, физический объект, если использовать готовый каркас то часть работ можно будет не делать оперевшись на готовое. Скрам же это не каркас, это описание каркаса, его стандарт. Если каркас можно чем-то обшить, например сайдингом. То описание каркаса обшить не получится. Я поймал себя на мысли что пытаюсь обшить сайдингом стандарт не имеющий физического воплощения а сайдинг почему то падал на землю вместо того чтобы висеть на каркасе. Об этой несостыковке я и попытался рассказать.
Я больше не могу класть задачи по компоненту в беклог(только на самое дно). Как у вас получается одновременно и могу, и не могу?
Хорошо, вы меня подловили, формально я мог создавать задачи в беклоге, но смысла делать это я не увидел, цель ведь не в том чтобы просто создать задачу а в том чтобы выполнить доработу по этой задаче. И потом, в чём принципиальная разница между тем чтобы класть задачи на дно беклога или не класть вообще? Ни в том ни в другом случае они не будут сделаны. Так как я не могу обосновать бизнес-ценность, они наврядли будут учтены при планировании. Это не значит что мои задачи не имеют бизнес-ценности, это значит что я не могу её оценить. Они могут просто пропасть из беклога при очередном "причёсывании".
И на основании этого вы делаете выводы какие-то, очевидно тоже противоречивые
Я делаю выводы на основе тех данных которые у меня есть. Я бы рад использовать что-то более надёжное но не могу. Однако, я верю что даже такие выводы могут кому-то помочь, поэтому я ими и поделился.
сдобрив всю историю кликбейтом, в чем сами и признаетесь
Я сомневался, делать его кликбейтным или нет, решил сделать. Лучше кликбейтный заголовок который привлечёт внимание чем неприметный который отобъёт желание даже просто открыть статью.
Однокомандники не могут решить все проблемы. То что я не жду от них решения не означает что я не считаю их программистами, это означает что я не вижу в их руках рычагов влияния на ситуацию. Я не скрывал своих проблем, но это не привело к изменениям. К скрам-мастерам я обращался потому что до трансформации многие из них были менеджерами.
Я готов работать в команде и я делал это пока мог. Я не готов работать в команде которая не нуждается в моих услугах. Мне просто нечего им предложить. Да и зачем, когда можно найти команду я буду полезен таким какой я есть?
Я верю в идею командной работы и верю в идею коллективной ответственности, хоть и не до конца их понимаю. Я лишь заявляю что скрам - не является инструментом их построения. Он является лишь стандартом описывающим черты команд которые смогли это построить раньше в своих условиях.
Нет, это явно компромисс а не подчинённость. У бизнеса свои интересы, у наёмных инженеров - свои. Часть этих интересов пересекается, что позволяет бизнесу и инженеру договориться о взаимовыгодном сотрудничестве для решения проблемы в интересах пользователя и извлечения выгоды (необязательно денег) из этого решения. Перекос в любую из сторон создаст проблемы, просто проявляться они будут по-разному.
Я раньше так думал но нет, не сходится, скрам-гайд не содержит каркаса дома. Нету в нём "Сетунь-3".В нём есть только описание того что в скрам-доме есть стены, крыша, окна, двери, что ходить надо через двери, смотреть лучше через окна. Это круто но этого не достаточно для постройки дома на основе такого "фреймворка". Для постройки дома нужны навыки проектирования, инструменты, материалы, умение с ними работать, знание СНИПов. А в скрам-гайде этого нет. поэтому он и не дотягивает до фреймворка а годится только как стандарт.
Вот ещё аналогия: нельзя написать приложение на JPA, JPA это только стандарт, логику реализует реализация этого стандарта, например Hibernate. Твой код останется совместимым с JPA если выкинуть Hibernate из приложения но работать он перестанет.
Автор, а Вы ценности scrum разделяете? Приверженность, сфокусированность, открытость, уважение и смелость?
А как это, разделять ценности? Как мне определить разделяю ли я их, каков критерий? Как тому кто хочет научиться уважению перейти от декларативного концепта уважения к процедурной последовательности действий сливающейся в проявление уважения?
В частности, между строк читается, что своих коллег вы не уважали и совместно работать с ними над общими задачами были не готовы. Я прав?
Моё нежелание работать над общими задачами появилось не сразу а после нескольких неудачных попыток. А откуда у вас взялась мысль о том что я не уважал своих коллег?
В этом случае опытный скрам-мастер не стал бы включать Вас в скрам-команду, а использовал как внешний сервис.
Такой вариант меня бы вполне устроил.
И авторы скрама предполагают, что скрам команда самостоятельно создаст такую методологию, пользуясь принципами. А вот осилить это могут только достаточно зрелые компании.
Ну или не создаст, о том и речь. Скрам это не инструмент достижения цели а рамки ограничиющие выход за пределы некоторой области внутри которой предположительно находится решение.
Роль скрам-мастера - научить команду правильно взаимодействовать (внутри себя, с владельцем продукта, с заказчиками и прочими заинтересованными лицами). И если брать аналогию с тренером, то задача тренера как раз сделать из отдельных игроков команду и подобрать для них оптимальную тактику на игру. "Порядок бьет класс".
Мой опыт свидетельствует о том что чистый скрам-мастер не может помочь команде во взаимодейтсвии. Он может только выполнять ритуалы. Для того чтобы реально помогать он должен быть ещё и менеджером и/или инженером. И это выглядит не как тренерство а как судейство. Об этом я и написал.
Да я воспринимаю фреймворк как класс программных продуктов, потому что предметной областью моей работы является разработка программных продуктов. Откровенно говоря до вашего комментария я не знал что фреймворк можно перевести не только как каркас но и как рамки. Это несколько меняет мою позицию, но не отменяет проблемы. Слово "фреймворк" содержит оба смысла, как каркас так и ограничение. Слово "стандарт" же фокусируется на ограничении, соответствии чего-то эталону. Я по-прежнему считаю что оно лучше отражает суть.
не согласен, работу над проектом (по скраму или нет) я считаю компромиссом между бизнесом и инженерами, как инженеры должны помнить о целесообразности своих доработок для бизнеса, так и бизнес должен понимать что запущенные инженерные проблемы могут подкосить их бизнес-модель.
Я нашёл то, что меня беспокоило и явно обозначил что считаю главной ложью скрама, а именно несоответствие определения скрама и того как он ощущается в реальности. А громкий заголовок нужен чтобы привлечь внимание)
я не предоставлю конкретику, в этом задумка статьи - абстрагироваться от событий, оставив только реакцию на них
в этом и дело, я тоже так думал, а мой опыт показал что скрам-мастер больше похож на инспектора дорожной полиции, он не учит водить он проверяет соответствие твоей манеры вождения общепринятому стандарту. а водить учит тимлид/архитектор/менеджер
у них получалось работать, выглядело так как будто им норм.
там сложнее получилось, реальное влияние на приоритеты было только у ПО. Человека который раньше получал пользу от моей работы не было среди них.
ума не приложу как бы я приоретизировал на их месте
да, это правда, поезд пошёл без меня, я смирился и перестал пытаться его остановить, позже я сошёл как только был готов. думаю от этого стало лучшие и мне и проекту. Да, моё мнение ненадёжно и субъективно, однако я не считаю его вредным для проекта, скорее недоработанным. Я не виню всех вокруг себя, наоборот я пытаюсь этого избежать. Мне кажется что компромиссный вариант, который устроил бы всех, мог быть достигнут но этого не произошло.
Коллеги как-то работали, да и мои проблемы особо не влияли на их работу. А столько "я" потому что в основе статьи лежит не анализ процессов а анализ моей реакции на процессы.
Я намеренно убрал конкретику, когда начинаешь описывать детали процессов, они тянут друг-друга за собой. В итоге у меня получалось подробное описание процессов проекта, а это не то чем я хотел поделиться. Кроме того после описания процессов, следовало бы их проанализировать и найти ошибки а я не могу этого сделать. Я заметил что мой анализ скатывается в необоснованные обвинения и отказался от этого. Проблемы на проекте это повод задуматься, причина в стойком ощущении что со скрамом что-то не так.
На первый взгляд набор инстументов не изменился команды, дейли, ретро, планирование, беклог, это было до трансформации это никуда не делось после. В каждом инструменте зменилось что-то внутри, в качестве примера приведу команду. до трансформации это были люди собравшиеся вместе для решения конкретных задач, команду собирали тимлид и менеджер, мы понимали что делаем и зачем. В рамках трансформации же команды перетряхнули, для того чтобы добиться кроссфункциональности и на месте сработавшейся команды собравшейся по своей воле, появилась группа людей оказавшаяся вместе по случайности.
Моей основной проблемой было несоответствие моих навыков и желаний моей новой работе. Если бы мне предложили такие условия на собесе, я бы отказался.
Это подводка к мысли о том что скрам не определяет процесс работы, только отдельные ограничения. Да, не надо знать строение двс, но было бы неплохо знать что такое руль, педали, коробка передач, а также быть в курсе пдд. Нельзя просто посадить человека в машину и ждать что он доедет сам.
Когда ты единственный недовольный из нескольких десятков человек, это не ощущается как обсуждение проблем с людьми, это ощущается как противостояние коллективу. Как дёрнуть стоп-кран остановив поезд целиком. Так можно сделать но после этого придётся объясниться.
Я больше не могу класть задачи по компоненту в беклог(только на самое дно) я не мог выдвигать задачи на планирование, не мог брать их в спринт, я был занят чем угодно кроме того что умел.
Эта статья не про конкретику и не про анализ решений принимаемых в рамках проекта. Я избегаю конкретики не потому что она не важна, а потому что не могу ей поделиться не рассказав слишком много. Кроме того я не могу её правильно проанализировать.
Плохо стало не всё и не для всех, я описал свой опыт. Статья рассчитана на людей которые испытывают то же что и я. Она для тех кто понимает что у них что-то идёт не так и это как-то связано со скрамом, но не могут сформулировать мысль.
Рад что мне удалось вас впечатлить)
Скрам описан через набор артефактов, событий и ценностей, он не содержит цикл, цикл реализует команда, скрам лишь декларирует факт наличия цикла. Скрам декларирует события но не описывает как именно их реализовать, какую последовательность действий выполнить чтобы успешно провести событие, какие проблемы могут возникнуть в процессе и как их решить, всё это должна знать команда. Скрам декларирует ценности но не показывает как именно их проявлять, это ответственность команды. Если команда не имеет достаточно опыта для реализации закдекларированных в скраме концептов, скрам им не поможет, и скрам-мастер не подстрахует.
Так всё таки скрам-мастеру нужны навыки менеджера? а если разработчики не понимают как оценивать задачи из-за того что не знают как именно будут их решать? Чистый скрам-мастер в такой ситуации сможет прежложить в лучшем случае менее точную систему оценки, вместо часов сторипоинты или размеры футболок. Менеджер предложит оформить задачу как исследовательскую и отказаться от её оценки, ограничившись лимитом времени на исследование. Тимлид же засчёт технических навыков и опыта может подсказать решение тем самым устранив неопределённость при оценке вместо борьбы с её симптомами.
Вы пришли к тому же примеру что я привёл в статье, там где я говорю о том что скрам напоминает интерфейс из языков программирования. А реализацию этого интерфейса предстоит реализовать команде вместо того чтобы переиспользовать дефолтную реализацию которая могла бы быть предоставлена фреймворком. Детали реализации, такие как практики не являются частью интерфейса и сильно зависят от контекста конкретной команды и могут не иметь смысла в тех или иных ситуациях, для правильного их использования требуется опыт, которым обладают сильные профильные специалисты например инженеры и/или менеджеры, скрам-мастер же сам по себе таким опытом не обладает и поэтому не может подстраховать команду если та не справится.
Я ничего не имею против ценностей. Я недоволен методом их изложения. Просто задекларировать ценность недостаточно. Нужно уметь эту ценность реализовать самому и научить ей других а этого в скраме нет. Я не получал негатива от команды и команда уважала моё право совершать ошибки. Но для того чтобы эти ошибки прекратились этого было недостаточно. Цель ведь не в том чтобы придерживаться какой-либо ценности а в том чтобы извлекать из этой ценности пользу, например прекращеие ошибок. Я проявлял приверженность, и активно участвовал в процессе трансформации, поначалу и довольно долго это держалось на вере, но время прошло, вера закончилась, проблемы остались. Какой смысл от приверженности бесполезного в новых условиях человека?
Ещё пример распада ценности без изменения последовательности действий. Когда ты просишь человека проявить открытость, например спрашивая чем ты можешь ему помочь. Ты как бы берёшь обязательство ему помочь. Если ты ему не помог, один раз, нестрашно. Но если это происходит постоянно или ещё хуже если ни один такой вопрос не привёл к решению. Ценность открытости скрывавшаяся за предложением помощи рассыпается, на её месте возникает ощущение пассивного давления. Цель осталось прежней, средство реализации осталось прежним а эффект со временем изменился.
Нежелание возникло не сразу, это шло постепенно. Заявлением о необходимости тимлида в команде я не пытаюсь принизить других её членов. Тимлид в моём представлении не водит коллег за ручку, а лишь иногда подстраховывает когда те не могут решить проблему сами.
Рад за вас, я не ощутил его как способ решения проблем, а скорее как набор норм который воспринимается как инструмент но им не является.
То что я видел не было похоже на Сю. Когда ты делаешь сю, у тебя и измеримый результат должен появится, совпадающий с результатом мастера по искомому критерию, рано или поздно. Я же не увидел результата, а продолжать повторять то что не приносит результата без каких либо изменений я не видел смысла.
Нет, с таким не сталикался. Могу посоветовать спрость в профильном сообществе. Найти такие сообщества можно например здесь.
Да, каркас дома это не дом, но каркас дома это часть реализации дома, элемент его конструкции, физический объект, если использовать готовый каркас то часть работ можно будет не делать оперевшись на готовое. Скрам же это не каркас, это описание каркаса, его стандарт. Если каркас можно чем-то обшить, например сайдингом. То описание каркаса обшить не получится. Я поймал себя на мысли что пытаюсь обшить сайдингом стандарт не имеющий физического воплощения а сайдинг почему то падал на землю вместо того чтобы висеть на каркасе. Об этой несостыковке я и попытался рассказать.
Хорошо, вы меня подловили, формально я мог создавать задачи в беклоге, но смысла делать это я не увидел, цель ведь не в том чтобы просто создать задачу а в том чтобы выполнить доработу по этой задаче. И потом, в чём принципиальная разница между тем чтобы класть задачи на дно беклога или не класть вообще? Ни в том ни в другом случае они не будут сделаны. Так как я не могу обосновать бизнес-ценность, они наврядли будут учтены при планировании. Это не значит что мои задачи не имеют бизнес-ценности, это значит что я не могу её оценить. Они могут просто пропасть из беклога при очередном "причёсывании".
Я делаю выводы на основе тех данных которые у меня есть. Я бы рад использовать что-то более надёжное но не могу. Однако, я верю что даже такие выводы могут кому-то помочь, поэтому я ими и поделился.
Я сомневался, делать его кликбейтным или нет, решил сделать. Лучше кликбейтный заголовок который привлечёт внимание чем неприметный который отобъёт желание даже просто открыть статью.
Однокомандники не могут решить все проблемы. То что я не жду от них решения не означает что я не считаю их программистами, это означает что я не вижу в их руках рычагов влияния на ситуацию. Я не скрывал своих проблем, но это не привело к изменениям. К скрам-мастерам я обращался потому что до трансформации многие из них были менеджерами.
Я готов работать в команде и я делал это пока мог. Я не готов работать в команде которая не нуждается в моих услугах. Мне просто нечего им предложить. Да и зачем, когда можно найти команду я буду полезен таким какой я есть?
Я верю в идею командной работы и верю в идею коллективной ответственности, хоть и не до конца их понимаю. Я лишь заявляю что скрам - не является инструментом их построения. Он является лишь стандартом описывающим черты команд которые смогли это построить раньше в своих условиях.
Нет, это явно компромисс а не подчинённость. У бизнеса свои интересы, у наёмных инженеров - свои. Часть этих интересов пересекается, что позволяет бизнесу и инженеру договориться о взаимовыгодном сотрудничестве для решения проблемы в интересах пользователя и извлечения выгоды (необязательно денег) из этого решения. Перекос в любую из сторон создаст проблемы, просто проявляться они будут по-разному.
Я раньше так думал но нет, не сходится, скрам-гайд не содержит каркаса дома. Нету в нём "Сетунь-3".В нём есть только описание того что в скрам-доме есть стены, крыша, окна, двери, что ходить надо через двери, смотреть лучше через окна. Это круто но этого не достаточно для постройки дома на основе такого "фреймворка". Для постройки дома нужны навыки проектирования, инструменты, материалы, умение с ними работать, знание СНИПов. А в скрам-гайде этого нет. поэтому он и не дотягивает до фреймворка а годится только как стандарт.
Вот ещё аналогия: нельзя написать приложение на JPA, JPA это только стандарт, логику реализует реализация этого стандарта, например Hibernate. Твой код останется совместимым с JPA если выкинуть Hibernate из приложения но работать он перестанет.
А как это, разделять ценности? Как мне определить разделяю ли я их, каков критерий? Как тому кто хочет научиться уважению перейти от декларативного концепта уважения к процедурной последовательности действий сливающейся в проявление уважения?
Моё нежелание работать над общими задачами появилось не сразу а после нескольких неудачных попыток. А откуда у вас взялась мысль о том что я не уважал своих коллег?
Такой вариант меня бы вполне устроил.
Ну или не создаст, о том и речь. Скрам это не инструмент достижения цели а рамки ограничиющие выход за пределы некоторой области внутри которой предположительно находится решение.
Мой опыт свидетельствует о том что чистый скрам-мастер не может помочь команде во взаимодейтсвии. Он может только выполнять ритуалы. Для того чтобы реально помогать он должен быть ещё и менеджером и/или инженером. И это выглядит не как тренерство а как судейство. Об этом я и написал.
Да я воспринимаю фреймворк как класс программных продуктов, потому что предметной областью моей работы является разработка программных продуктов. Откровенно говоря до вашего комментария я не знал что фреймворк можно перевести не только как каркас но и как рамки. Это несколько меняет мою позицию, но не отменяет проблемы. Слово "фреймворк" содержит оба смысла, как каркас так и ограничение. Слово "стандарт" же фокусируется на ограничении, соответствии чего-то эталону. Я по-прежнему считаю что оно лучше отражает суть.
не согласен, работу над проектом (по скраму или нет) я считаю компромиссом между бизнесом и инженерами, как инженеры должны помнить о целесообразности своих доработок для бизнеса, так и бизнес должен понимать что запущенные инженерные проблемы могут подкосить их бизнес-модель.
Я нашёл то, что меня беспокоило и явно обозначил что считаю главной ложью скрама, а именно несоответствие определения скрама и того как он ощущается в реальности. А громкий заголовок нужен чтобы привлечь внимание)
у меня его нет, только вера в его существование и накопленный опыт для того чтобы не упустить момент в следующий раз
я не предоставлю конкретику, в этом задумка статьи - абстрагироваться от событий, оставив только реакцию на них
в этом и дело, я тоже так думал, а мой опыт показал что скрам-мастер больше похож на инспектора дорожной полиции, он не учит водить он проверяет соответствие твоей манеры вождения общепринятому стандарту. а водить учит тимлид/архитектор/менеджер
у них получалось работать, выглядело так как будто им норм.
там сложнее получилось, реальное влияние на приоритеты было только у ПО. Человека который раньше получал пользу от моей работы не было среди них.
ума не приложу как бы я приоретизировал на их месте
да, это правда, поезд пошёл без меня, я смирился и перестал пытаться его остановить, позже я сошёл как только был готов. думаю от этого стало лучшие и мне и проекту. Да, моё мнение ненадёжно и субъективно, однако я не считаю его вредным для проекта, скорее недоработанным. Я не виню всех вокруг себя, наоборот я пытаюсь этого избежать. Мне кажется что компромиссный вариант, который устроил бы всех, мог быть достигнут но этого не произошло.
дело не в объёме нагрузки а в её типе, меня посадили заниматься тем что я не хотел и не мог, отодвинув то что я хотел и мог.
Коллеги как-то работали, да и мои проблемы особо не влияли на их работу. А столько "я" потому что в основе статьи лежит не анализ процессов а анализ моей реакции на процессы.
Я намеренно убрал конкретику, когда начинаешь описывать детали процессов, они тянут друг-друга за собой. В итоге у меня получалось подробное описание процессов проекта, а это не то чем я хотел поделиться. Кроме того после описания процессов, следовало бы их проанализировать и найти ошибки а я не могу этого сделать. Я заметил что мой анализ скатывается в необоснованные обвинения и отказался от этого. Проблемы на проекте это повод задуматься, причина в стойком ощущении что со скрамом что-то не так.
На первый взгляд набор инстументов не изменился команды, дейли, ретро, планирование, беклог, это было до трансформации это никуда не делось после. В каждом инструменте зменилось что-то внутри, в качестве примера приведу команду. до трансформации это были люди собравшиеся вместе для решения конкретных задач, команду собирали тимлид и менеджер, мы понимали что делаем и зачем. В рамках трансформации же команды перетряхнули, для того чтобы добиться кроссфункциональности и на месте сработавшейся команды собравшейся по своей воле, появилась группа людей оказавшаяся вместе по случайности.
Моей основной проблемой было несоответствие моих навыков и желаний моей новой работе. Если бы мне предложили такие условия на собесе, я бы отказался.
Это подводка к мысли о том что скрам не определяет процесс работы, только отдельные ограничения. Да, не надо знать строение двс, но было бы неплохо знать что такое руль, педали, коробка передач, а также быть в курсе пдд. Нельзя просто посадить человека в машину и ждать что он доедет сам.
Когда ты единственный недовольный из нескольких десятков человек, это не ощущается как обсуждение проблем с людьми, это ощущается как противостояние коллективу. Как дёрнуть стоп-кран остановив поезд целиком. Так можно сделать но после этого придётся объясниться.
Я больше не могу класть задачи по компоненту в беклог(только на самое дно) я не мог выдвигать задачи на планирование, не мог брать их в спринт, я был занят чем угодно кроме того что умел.
за мысль о спеллчекере спасибо)