Вузов с качетсвенной программой и преподовательским составом можно по пальцам руки перичислить. По сути две столицы и Томск с Новосибом, а в остальном как пишет автор полная рулетка
Как организуются команды и осуществляется процесс разработки когда нужно собрать несколько продуктов в "бандл" (и управлять продуктом как "бандлом" а не отдельными наборами продуктов)?
И еще вопрос как вы привлекаете и удерживаете HPE, как работаете с культурой внутри фирмы?
А почему именно интерпритируемые? Вам шашечки или ехать, хотите корректности и проверки на уровне типов, gcи тд — берите java,c# etc. Нужна динамика и строгость + функциональная парадигма, а еще что бы работа с многопоточностью из коробки — берете elixir, erlang. Как говорится best/right tool for the job
Именно что страдает консистентность. Вы можно писать с типами можно без, с strict_types и без и это не только в вопросе типов.
Не подумайте я не против типов. Просто существуют инструменты которые гораздо лучше решают эту проблему
Проблема не в типах как feature, проблема в том что усидеть на двух стульях не получится. Либо гарантии как в строго типизированных статических языках (+ все накладные на работу с типами), либо type hinting который в лучшем случае что то гарантирует
Конечно, именно поэтому у нас в каждом языке кучи фреймворков и библиотек которые решают типовые проблемы разработчика. Если посмотреть на чем происходит экономия то основная часть как раз на переиспользовании модулей или имеющегося кода.
Согласен, типизация снимает ряд ошибок связанных с типами, но в тоже время добавляет дополнительной сложности. Необходимо добавлять классы обертки, маппить классы и тд. Если у вас сохранились данные по работе команды (запуск фич, исправление багов и тд) было бы здорово на них посмотреть.
Спасибо за статью. Было бы здорово рассмотреть критику подхода (или добавить ссылки) так как более 25% респондентов недовольны, это сложно назвать справедливым.
У каждого работодателя свой подход. Некоторые психологически не готовы инвестировать в только что пришедшего сеньора.
Ну и в ту же копилку человек проработавший 2-3+ года на определенном стэке знает все ограничения и неочевидные места фреймворка.
Я очень давно интересуюсь вопросами и подходами найма, но внятной статистике мне найти не удалось. Может быть у вас есть корреляция условий найма и скорости?
Здесь вопрос не в ненависти а в том как это выглядит для двух сторон
Как пример:
руководство заинтересованное и дающее возможности проявить себя на местах (взяв при этом ответственность за результат и качество) — это прекрасно
Но чаще руководители стараются постоянно контролировать PO (не допускал ошибок) на этом этапе Agile "контракт" перестает работать
Вы пишите что внедрение OKR было однозначно полезным, подскажите как сравнивали эффективность предыдущего планирования и через OKR? Не могли бы привести примеры метрик по которым работа с помощью OKR дала наибольший эффект. Спасибо
Прочитал статью, но так и не понял за счет чего бот решает проблемы собеседований (субъективизм оценки, участие человека и т.д). Стоит больше внимания уделить тому как вы решаете проблемы соискателя, которые сейчас нельзя решить имеющимися средствами
Хочется уточнить какой продукт был у команды, какова роль проектного менеджера и арт-директора в scrum команде и откуда появились «подкоманды»?
Кажется что это больше похоже на смесь водопадного подхода и итеративного, отсюда и растут «ноги» всяких дополнительные артефактов и tools в виде спринт-пульсов.
Было бы интересно посмотреть на сравнение Т2М и других показателей команд «классического» scrum с командами их спринт-пульсов
Вузов с качетсвенной программой и преподовательским составом можно по пальцам руки перичислить. По сути две столицы и Томск с Новосибом, а в остальном как пишет автор полная рулетка
Как организуются команды и осуществляется процесс разработки когда нужно собрать несколько продуктов в "бандл" (и управлять продуктом как "бандлом" а не отдельными наборами продуктов)?
И еще вопрос как вы привлекаете и удерживаете HPE, как работаете с культурой внутри фирмы?
Development + operations, что не так? Или DevOps это админ только для микросервисов?
А почему именно интерпритируемые? Вам шашечки или ехать, хотите корректности и проверки на уровне типов, gcи тд — берите java,c# etc. Нужна динамика и строгость + функциональная парадигма, а еще что бы работа с многопоточностью из коробки — берете elixir, erlang. Как говорится best/right tool for the job
Именно что страдает консистентность. Вы можно писать с типами можно без, с strict_types и без и это не только в вопросе типов.
Не подумайте я не против типов. Просто существуют инструменты которые гораздо лучше решают эту проблему
Проблема не в типах как feature, проблема в том что усидеть на двух стульях не получится. Либо гарантии как в строго типизированных статических языках (+ все накладные на работу с типами), либо type hinting который в лучшем случае что то гарантирует
Вопрос не в принуждении, а в том куда развивается язык и в его консистентности
Не понятно зачем тогда нужен PHP когда есть в плане типов и строгости есть достойные кандидаты
Конечно, именно поэтому у нас в каждом языке кучи фреймворков и библиотек которые решают типовые проблемы разработчика. Если посмотреть на чем происходит экономия то основная часть как раз на переиспользовании модулей или имеющегося кода.
Согласен, типизация снимает ряд ошибок связанных с типами, но в тоже время добавляет дополнительной сложности. Необходимо добавлять классы обертки, маппить классы и тд. Если у вас сохранились данные по работе команды (запуск фич, исправление багов и тд) было бы здорово на них посмотреть.
Давно ищу материалы и статистику по влиянию типизации на скорость разработки, не могли бы вы поделиться своими результатами?
Спасибо за статью. Было бы здорово рассмотреть критику подхода (или добавить ссылки) так как более 25% респондентов недовольны, это сложно назвать справедливым.
У каждого работодателя свой подход. Некоторые психологически не готовы инвестировать в только что пришедшего сеньора.
Ну и в ту же копилку человек проработавший 2-3+ года на определенном стэке знает все ограничения и неочевидные места фреймворка.
Я очень давно интересуюсь вопросами и подходами найма, но внятной статистике мне найти не удалось. Может быть у вас есть корреляция условий найма и скорости?
Так же хотелось отметить пункт "Работа короткими итерациями":
Здесь вопрос не в ненависти а в том как это выглядит для двух сторон
Как пример:
руководство заинтересованное и дающее возможности проявить себя на местах (взяв при этом ответственность за результат и качество) — это прекрасно
Но чаще руководители стараются постоянно контролировать PO (не допускал ошибок) на этом этапе Agile "контракт" перестает работать
Сложилось двоякое впечатление от статьи
Кажется что вы используете Agile только для того что дать ощущение ответственности, как пример:
и т.д.
Если подходить к сотрудникам с такой позиции то в какой-то момент они за эту двойственности будут ненавидеть Agile и все что с ним связано
Вы пишите что внедрение OKR было однозначно полезным, подскажите как сравнивали эффективность предыдущего планирования и через OKR? Не могли бы привести примеры метрик по которым работа с помощью OKR дала наибольший эффект. Спасибо
Если не сложно не могли бы вы дать примеры хороших книг и гайдов по elixir (можно в лс). Спасибо
Кажется что это больше похоже на смесь водопадного подхода и итеративного, отсюда и растут «ноги» всяких дополнительные артефактов и tools в виде спринт-пульсов.
Было бы интересно посмотреть на сравнение Т2М и других показателей команд «классического» scrum с командами их спринт-пульсов