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