Это может повлиять на ИТ закупки в рамках параллельного импорта, обхода санкий и тп? Если после этого госы станут тратить меньше денег на продукты условного Майкрософта, то для экономики и внутренних ИТ продуктов это должно стать плюсом.
кем ты себя видишь в конечном итоге: сеньором, тимлидом, менеджером проектов и т. д.
Культ достигаторства вошёл в чат!
Ты обязательно должен хотеть стать кем-то ещё. Получить очередную лычку. Добавить в резюме ещё один язык. Получить власть. Как это ты не хочешь быть тимлидом? Ты что, остановился в развитии?!
Это навязывают инфо-цыгане и обучающие платформы. Потому что они делают на этом деньги.
Это навязывают эйчары. Потому что им нужно что-то навязывать, чтобы оправдывать своё существование.
Это навязывает мачизм и вот этот культ достигаторства. Потому что в большинстве своём люди живут во власти своих комплексов.
Но если ты хороший такой миддл, у тебя устройчивая работа, крепкие знания, охват которых и тебе, и твоему руководству понятнет, то... Ты не можешь позволить себе зону комфорта?
Адекватные спецы перестают быть джунами "автоматически". Вот ты усвоил базу, вот избавился от детских ошибок, вот освоил коммуникацию с коллегами. Бац - ты миддл.
Перейти на сеньора так просто не получится. Это ступень, на неё нужно забраться. Но. Оставаться миддлом долго и не скатываясь в задачи уровня разгребания чужих конюшен, это тоже требует работы и развития. Как говорится, чтобы оставаться на одном и том же месте нужно очень быстро бежать.
В общем. Быть миддлом - нормально. Берегите менталочку.
Что тут говорить? Все надеялись пересидеть. Бизнес надеялся, что посидит годик-два без обновлений, а потом всё будет как прежде. Компании-разработчики не хотели вкладывать все бабки и силы в разработку ПО, потому что сложно за год запилить такой-то крутой инструмент, который занимает лидирующие позиции на мировом рынке 10+ лет - а потом санкции снимут и кому ты нужен?
Рекрутеры и эйчары - самая большАя мистификация в айтишке. В моём понимании работник компании, нанимающий других работников, должен быть мастером своего дела. Но в итоге даже на вакансиях мидлового уровня (а иногда и сеньорского) вы можете столкнуться с человеком "21 год, после курсов, год назад в KFC работала".
Алсо, в эйчарах и рекрутерах повальное кумовство. Жёны, дочери, подруги, дочери маминых подруг. О каком эффективном построении работы в такой ситуации можно говорить?
На первый из них автор успел ответит ещё в статье в лайфхаке номер 3 - за это спасибо. Кмк, использование "прокси" ИБ архитекторов будет весьма и весьма оправдано. Особенно, если у продуктов уже есть ИТ архитекторы - как будто в их стек компетенций некоторый уровень ИБ архитекторы ложится очень удачно. Когда разработка выходит на плато и нет такого, что каждую неделю к продукту приделывают новый костыль, задачи становятся типовыми. А к типовым задачам можно применять типовые решения. Тогда и ИБ архитектора можно привлекать реже, ведь такие вопросы закроет и его "прокси".
Второй вопрос остался актуальным. В статье говорится о том, что надо очерчивать зоны ответственности и стараться вписать активности безопасной разработки в существующий продуктовый флоу. На практике часто возникает дилемма, мол, безопасники - они просто рекомендуют или согласовывают/запрещают? Вот видит ИБ архитектор критичный риск, а его фикс может быть сложным/дорогим и владелец продукта не готов заносить его в бэклог. Как быть? Ладно, с критами ещё может быть попроще, но как быть с менее судьбоносными задачами?
Опять же, на практике у вас могут быть процессы, роли и общее согласие по применению концепции безопасной разработке. Но в моменте бизнес часто использует аргумент "мы зарабатываем бабки, значит мы правы". Что в таком случае делать ИБ архитектору? Имеет ли он право вето? Исходя из опыта автора.
Хотелось бы узнать, если ли ещё менеджеры в команде кроме автора? Как будто в статье добавлены функции за пределом роли чистого продакта. Можно предположить,что менеджера проекта или некого коуча больше нет?
Ещё я не особо понял, зачем в команде, которой доверяешь и которая обладает экспертизой, обладать пониманием архитектуры и т.п., чтобы выполнять роль фасилитатор. Фасилитация - это в целом опосредованная от темы обсуждения вещь. Хотя суровые разработчики сейчас могут прибежать в комменты и рассказать, что не будут считать за человека и признавать менеджером любого, что не отпахал на их стеке минимум десятку лет)
Кмк на базе одного хаоса построили другой хаос. Если он работает, то ок, это победа. Значит ли это, что "традиционный Agile" не работает? Нет.
Команда всё равно пришла к релизам по плану, оценке и приоритезации задач. Кто-то выполняет функции продакта, кто-то поддерживает прозрачную коммуникацию. Планировать релиз на основе мощности QA? Так это чистый лимит WIP из Канбана.
Автор правильно называет такой подход "конструктором". Команда взяла какие-то отдельные элементы и некоторым образом "адаптировала" их. Почему это "победа" над "неработающими" Agile методологиями? Потому что так говорить круче/приятнее, чем "мы не умеем в Scrum/Kanban/XP и т.д., но пытаемся".
Но есть момент, на который я хочу обратить внимание автора. Допустим вы купили шкаф в IKEA и он приехал естественно в разобраном виде. Вы можете собрать из него самые разные штуки. Даже скворечник. Но это штука задумана как шкаф и проще всего её собрать как шкаф, и лучше всего она вам будет служить как шкаф. Вам нужно где-то хранить вещи, вы знаете это. Вы можете положить вещи стопкой на нераспакованную коробку со шкафом. Можете собрать каркас, но не вставлять внутрь полки, а просто сложить вещи одной высокой стопкой. А можете собрать его должным образом и хранить свои вещи удобно и эстетично.
На какой стадии сборки шкафа находится команда на данный момент?
Я что-то запутался. Почему вы убеждены, что всем нужны слёзы? И почему вы считаете, что раз всем нужны слёзы, даже неискренние слёзы - это эмпатия?
Это выглядит как очень грубое упрощение. Человек грустит - грусти с ним. Человек радуется - радуйся с ним. Но это не эмпатия, это мимикрия. Чистый рефлекс.
Мне импонирует определение эмпатии от Маршалла Розенберга:
эмпатия это уважительное понимание того, что переживают другие, это опустошение ума и слушание всем своим существом.
Эмпатичный человек не ориентирован на то, чтобы отгрузить собеседнику свои эмоции в ответ. И тем более он не навязывает советы, оценки или личный опыт в ответ на проявление эмоций собеседником. Эмпатия это про умение слушать и помогать собеседнику выражать свои эмоции и переживания. А ещё про "понимание", а не переживание своих эмоций.
Не соглашусь. Утверждение, что эмпатия это эмоциональная реакция, смещает фокус со способности воспринимать собеседника на внутреннее (эмоциональное) состояние эмпата. Это нас довольно быстро приведёт к тому, что, условно, более эмпатичным мы будем считать того человека, который слушает грустную историю со слезами на глазах, а не того, что не проявляет таких ярких эмоций.
Сразу скажу, что QA не являюсь и богатого опыта самостоятельной оценки затрат времени на тестирование не имею. Возможно из-за этого вопросы и возник)
А можно хотя бы грубо раскладку по часам? Что сколько времени заняло? Тут грубо говоря получилось, что один-единственный тестировщик затащил разработку мобильного приложения с нуля (ну ок, при готовых требованиях) за три месяца, работая на 0.2 ставки 0_о
Немного подушню: сторипоинты - это не часть Скрама. И соглашусь: однажны абстрактные оценки должны соотнестись с реальными трудозатратами.
И вот эти два момента часто приводят к ситуации, когда люди теряют веру в Скрам да и в Аджайл в целом. На самом деле вы можете использовать голую астракцию или трекать всё до каждой минуты. Важно найти такой способ, который подходит вам и приближает вас к цели.
Сами сторипоинты к этому моменту тоже сильно искажены. Как уже отмечено выше, "замешивание" в оценку в сторипоинтах времени полностью рушит концепцию. В целом, то, что автор описывает в статье как своё достижение, это убийство сторипоинтов.
Что делать? Опять же, сказано выше: перестать называть свою оценку сторипоинтами. Отделить оценку реальных трудозатрат от оценки... эм... инженерной сложности задачи.
Зачем это делать? И вновь, сказано выше: сторипоинты помогают с оценкой в условиях высокой неопределённости. Даже опытная команда на стабильном проекте может ВНЕЗАПНО получить от заказчика такой фича-реквест, что всем дружно придётся чесать затылок. И тут поможет абстракция. Потом уже декомпозированные задачи можно будет оценить ещё раз, в реальных трудозатратах будь то фокус-часы или ещё что.
А чему конкретно не верите вы в этой истории?
И она написана ИИшкой 0_о
Это может повлиять на ИТ закупки в рамках параллельного импорта, обхода санкий и тп? Если после этого госы станут тратить меньше денег на продукты условного Майкрософта, то для экономики и внутренних ИТ продуктов это должно стать плюсом.
А с художкой сложнее "попасть" рекомендацией. Там переменных гораздо больше.
Культ достигаторства вошёл в чат!
Ты обязательно должен хотеть стать кем-то ещё. Получить очередную лычку. Добавить в резюме ещё один язык. Получить власть. Как это ты не хочешь быть тимлидом? Ты что, остановился в развитии?!
Это навязывают инфо-цыгане и обучающие платформы. Потому что они делают на этом деньги.
Это навязывают эйчары. Потому что им нужно что-то навязывать, чтобы оправдывать своё существование.
Это навязывает мачизм и вот этот культ достигаторства. Потому что в большинстве своём люди живут во власти своих комплексов.
Но если ты хороший такой миддл, у тебя устройчивая работа, крепкие знания, охват которых и тебе, и твоему руководству понятнет, то... Ты не можешь позволить себе зону комфорта?
Адекватные спецы перестают быть джунами "автоматически". Вот ты усвоил базу, вот избавился от детских ошибок, вот освоил коммуникацию с коллегами. Бац - ты миддл.
Перейти на сеньора так просто не получится. Это ступень, на неё нужно забраться. Но. Оставаться миддлом долго и не скатываясь в задачи уровня разгребания чужих конюшен, это тоже требует работы и развития. Как говорится, чтобы оставаться на одном и том же месте нужно очень быстро бежать.
В общем. Быть миддлом - нормально. Берегите менталочку.
Что тут говорить? Все надеялись пересидеть. Бизнес надеялся, что посидит годик-два без обновлений, а потом всё будет как прежде. Компании-разработчики не хотели вкладывать все бабки и силы в разработку ПО, потому что сложно за год запилить такой-то крутой инструмент, который занимает лидирующие позиции на мировом рынке 10+ лет - а потом санкции снимут и кому ты нужен?
Рекрутеры и эйчары - самая большАя мистификация в айтишке. В моём понимании работник компании, нанимающий других работников, должен быть мастером своего дела. Но в итоге даже на вакансиях мидлового уровня (а иногда и сеньорского) вы можете столкнуться с человеком "21 год, после курсов, год назад в KFC работала".
Алсо, в эйчарах и рекрутерах повальное кумовство. Жёны, дочери, подруги, дочери маминых подруг. О каком эффективном построении работы в такой ситуации можно говорить?
По ходу чтения статьи возникло два вопроса.
На первый из них автор успел ответит ещё в статье в лайфхаке номер 3 - за это спасибо. Кмк, использование "прокси" ИБ архитекторов будет весьма и весьма оправдано. Особенно, если у продуктов уже есть ИТ архитекторы - как будто в их стек компетенций некоторый уровень ИБ архитекторы ложится очень удачно. Когда разработка выходит на плато и нет такого, что каждую неделю к продукту приделывают новый костыль, задачи становятся типовыми. А к типовым задачам можно применять типовые решения. Тогда и ИБ архитектора можно привлекать реже, ведь такие вопросы закроет и его "прокси".
Второй вопрос остался актуальным. В статье говорится о том, что надо очерчивать зоны ответственности и стараться вписать активности безопасной разработки в существующий продуктовый флоу. На практике часто возникает дилемма, мол, безопасники - они просто рекомендуют или согласовывают/запрещают? Вот видит ИБ архитектор критичный риск, а его фикс может быть сложным/дорогим и владелец продукта не готов заносить его в бэклог. Как быть? Ладно, с критами ещё может быть попроще, но как быть с менее судьбоносными задачами?
Опять же, на практике у вас могут быть процессы, роли и общее согласие по применению концепции безопасной разработке. Но в моменте бизнес часто использует аргумент "мы зарабатываем бабки, значит мы правы". Что в таком случае делать ИБ архитектору? Имеет ли он право вето? Исходя из опыта автора.
Ничего себе локализация! Заменить облачный офисный пакет Майкрософт и антивирус!
(нет, это не впечатляет)
Хотелось бы узнать, если ли ещё менеджеры в команде кроме автора? Как будто в статье добавлены функции за пределом роли чистого продакта. Можно предположить,что менеджера проекта или некого коуча больше нет?
Ещё я не особо понял, зачем в команде, которой доверяешь и которая обладает экспертизой, обладать пониманием архитектуры и т.п., чтобы выполнять роль фасилитатор. Фасилитация - это в целом опосредованная от темы обсуждения вещь. Хотя суровые разработчики сейчас могут прибежать в комменты и рассказать, что не будут считать за человека и признавать менеджером любого, что не отпахал на их стеке минимум десятку лет)
Кмк на базе одного хаоса построили другой хаос. Если он работает, то ок, это победа. Значит ли это, что "традиционный Agile" не работает? Нет.
Команда всё равно пришла к релизам по плану, оценке и приоритезации задач. Кто-то выполняет функции продакта, кто-то поддерживает прозрачную коммуникацию. Планировать релиз на основе мощности QA? Так это чистый лимит WIP из Канбана.
Автор правильно называет такой подход "конструктором". Команда взяла какие-то отдельные элементы и некоторым образом "адаптировала" их. Почему это "победа" над "неработающими" Agile методологиями? Потому что так говорить круче/приятнее, чем "мы не умеем в Scrum/Kanban/XP и т.д., но пытаемся".
Но есть момент, на который я хочу обратить внимание автора. Допустим вы купили шкаф в IKEA и он приехал естественно в разобраном виде. Вы можете собрать из него самые разные штуки. Даже скворечник. Но это штука задумана как шкаф и проще всего её собрать как шкаф, и лучше всего она вам будет служить как шкаф. Вам нужно где-то хранить вещи, вы знаете это. Вы можете положить вещи стопкой на нераспакованную коробку со шкафом. Можете собрать каркас, но не вставлять внутрь полки, а просто сложить вещи одной высокой стопкой. А можете собрать его должным образом и хранить свои вещи удобно и эстетично.
На какой стадии сборки шкафа находится команда на данный момент?
Я что-то запутался. Почему вы убеждены, что всем нужны слёзы? И почему вы считаете, что раз всем нужны слёзы, даже неискренние слёзы - это эмпатия?
Это выглядит как очень грубое упрощение. Человек грустит - грусти с ним. Человек радуется - радуйся с ним. Но это не эмпатия, это мимикрия. Чистый рефлекс.
Мне импонирует определение эмпатии от Маршалла Розенберга:
эмпатия это уважительное понимание того, что переживают другие, это опустошение ума и слушание всем своим существом.
Эмпатичный человек не ориентирован на то, чтобы отгрузить собеседнику свои эмоции в ответ. И тем более он не навязывает советы, оценки или личный опыт в ответ на проявление эмоций собеседником. Эмпатия это про умение слушать и помогать собеседнику выражать свои эмоции и переживания. А ещё про "понимание", а не переживание своих эмоций.
Не соглашусь. Утверждение, что эмпатия это эмоциональная реакция, смещает фокус со способности воспринимать собеседника на внутреннее (эмоциональное) состояние эмпата. Это нас довольно быстро приведёт к тому, что, условно, более эмпатичным мы будем считать того человека, который слушает грустную историю со слезами на глазах, а не того, что не проявляет таких ярких эмоций.
Искусственный интеллект, перелогинься, мы тебя узнали.
Сразу скажу, что QA не являюсь и богатого опыта самостоятельной оценки затрат времени на тестирование не имею. Возможно из-за этого вопросы и возник)
А можно хотя бы грубо раскладку по часам? Что сколько времени заняло? Тут грубо говоря получилось, что один-единственный тестировщик затащил разработку мобильного приложения с нуля (ну ок, при готовых требованиях) за три месяца, работая на 0.2 ставки 0_о
Вроде начинали за здравие, а в итоге... Просто перечисление практик и артефактов ITIL? С минимумов примеров реализации(
Немного подушню: сторипоинты - это не часть Скрама. И соглашусь: однажны абстрактные оценки должны соотнестись с реальными трудозатратами.
И вот эти два момента часто приводят к ситуации, когда люди теряют веру в Скрам да и в Аджайл в целом. На самом деле вы можете использовать голую астракцию или трекать всё до каждой минуты. Важно найти такой способ, который подходит вам и приближает вас к цели.
Сами сторипоинты к этому моменту тоже сильно искажены. Как уже отмечено выше, "замешивание" в оценку в сторипоинтах времени полностью рушит концепцию. В целом, то, что автор описывает в статье как своё достижение, это убийство сторипоинтов.
Что делать? Опять же, сказано выше: перестать называть свою оценку сторипоинтами. Отделить оценку реальных трудозатрат от оценки... эм... инженерной сложности задачи.
Зачем это делать? И вновь, сказано выше: сторипоинты помогают с оценкой в условиях высокой неопределённости. Даже опытная команда на стабильном проекте может ВНЕЗАПНО получить от заказчика такой фича-реквест, что всем дружно придётся чесать затылок. И тут поможет абстракция. Потом уже декомпозированные задачи можно будет оценить ещё раз, в реальных трудозатратах будь то фокус-часы или ещё что.
Я нигде не утверждал, что чистый Скрам работает и я знаю такие команды.
Я утверждаю, что вы делаете вывод "Скрам не работает" на основе ложных посылок.
Более того, что случится, если я назову команду, где чистый Скрам работает? Вы уверуете и удалите эту статью?
Меня привлекла аргументация "Почему Скрам не работает". Собственно, разбору этих аргументов и посвящены мои комментарии. Не более того.
Это не какой-то конкретный монстр. У каждого этот монстр свой.
Как видится мне, основная проблема во внедрении Скрама заключается в изначальном желании "адаптировать" Скрам, а не инициировать изменения в компании.
В итоге компания, которая недовольна текущей орагнизацией работы, протаскивает эту неэффективность в свою "адаптацию" Скрама.