Ты бывал на хакатонах? Там оно именно так и работает, аналитика генерируется в процессе разработки решения, обсуждая сразу с разработчиками возможности и наиболее эффективный и быстрый способ сделать фичу. Тестировщика вообще в скраме существовать не должно. Сам Сазерленд рассказывал, что если речь идет о применении скрама в разработке ПО, то работа должна строиться по extreme programming, с tdd и автотестами. Ну и в целом аналитик, тестировщик и дизайнер не обязаны в команде быть отдельной ролью, которая ничего больше не умеет. Это может быть T-shape разраб с фокусом на QA или дизайн, или бизнес.
У скрама есть очень ограниченная область применения. Как только речь заходит о том, что команда неспособна работать над одной задачей совместно, не представляет как это работать без этапов и конвейера, то это значит только одно - скрам в такой команде не построить. Лучше посмотреть на другие способы организации работы подходящие конвейерной разработке, тот же канбан например.
"Доска - это про канбан" это не так. Доска лишь отражение процессов принятых в команде, а не отдельный инструмент который живет своей жизнь. Тут по скраму, а тут по канбану. Конечно мало 3 поля, ведь команда и ее процессы не перестроены под скрам. Да и не скрам это, про то и говорю.
В плане эффективности тут график показывает, что релизиться чаще, получать чаще фидбек от юзеров и пересматривать бэклог по результатам фидбека полезнее чем релизиться долго. Это решается путем декомпозиции и девопс процессов, которые позволяют релизиться часто. Скрам тут вообще не нужен для этого.
Эффективность в скраме как раз достигается за счет взаимодействия команды. Для интереса вбей в ютуб что такое скрам в регби и посмотри как это выглядит. Ведь фреймворк назвали как раз в честь этого элемента игры. Вы либо толпой перебороли соперника (решили задачу), либо нет. Поэтому таска или не делается, или в процессе, или уже готова. Нет состояния, что один толкает, а другие потолкают попозже.
И вот раз за разом такие статьи. Много внимания каргокультовым практикам и 0 практикам разработки. Было бы 0 вопросов, если бы тут речь шла о скраме в контексте применения в любой сфере деятельности, но тут автор конкретно про айтишку говорит. Так вот Сазерленд утверждал, что скрам в 3-4 раза эффективнее классической каскадной разработки. За счет чего эффективность то будет, если следовать сей инструкции? За счет ретро? Двухнедельного планирования? Аж в 4 раза?
Где про доску из 3 колонок: to do, in progress, done. Где про обязательное условия нахождения всей команды в одном помещении. Где про практики XP, которые Сазерленд подразумевал как само собой разумеющиеся в скраме в it, но исключил их из скрама, чтоб выйти с фреймворком за пределы айтишки. Вот в этих идеях и есть 4-хкратная эффективность. Команда, в одном месте, одновременно работает над задачами цели спринта, как на двухнедельном хакатоне. Постоянно релизит изменения в общую ветку, покрывает все тестами по тдд, используют парное программирование, гибко меняют подзадачи в спринте, чтоб реализовать цель спринта и так далее. Самое главное этапность отсутствует: фронт, бэк, дизайн, аналитика проектируются в одном кабинете за соседними столами одновременно, что позволяет сильно экономить на переделках и сменах контекстов.
Без этого понимания менеджеры обчитываются такими статьями и тащат обычный водопад с двухнедельным планированием по итогу которого еще делают ретро. В одну итерацию у нас инкремент: сделали аналитику для задачи А, дизайн в задаче Б, напрогали В и оттестировали Г. В следующей итерации возьмем задачу Б в проектирование, хотя по скраму задача от бэклога до готовности занимает всегда один спринт.
И вот раз за разом такие статьи. Много внимания каргокультовым практикам и 0 практикам разработки. Было бы 0 вопросов, если бы тут речь шла о скраме в контексте применения в любой сфере деятельности, но тут автор конкретно про айтишку говорит. Так вот Сазерленд утверждал, что скрам в 3-4 раза эффективнее классической каскадной разработки. За счет чего эффективность то будет, если следовать сей инструкции? За счет ретро? Двухнедельного планирования? Аж в 4 раза?
Где про доску из 3 колонок: to do, in progress, done. Где про обязательное условия нахождения всей команды в одном помещении. Где про практики XP, которые Сазерленд подразумевал как само собой разумеющиеся в скраме в it, но исключил их из скрама, чтоб выйти с фреймворком за пределы айтишки. Вот в этих идеях и есть 4-хкратная эффективность. Команда, в одном месте, одновременно работает над задачами цели спринта, как на двухнедельном хакатоне. Постоянно релизит изменения в общую ветку, покрывает все тестами по тдд, используют парное программирование, гибко меняют подзадачи в спринте, чтоб реализовать цель спринта и так далее. Самое главное этапность отсутствует: фронт, бэк, дизайн, аналитика проектируются в одном кабинете за соседними столами одновременно, что позволяет сильно экономить на переделках и сменах контекстов.
Без этого понимания менеджеры обчитываются такими статьями и тащат обычный водопад с двухнедельным планированием по итогу которого еще делают ретро. В одну итерацию у нас инкремент: сделали аналитику для задачи А, дизайн в задаче Б, напрогали В и оттестировали Г. В следующей итерации возьмем задачу Б в проектирование, хотя по скраму задача от бэклога до готовности занимает всегда один спринт.
изучите что такое di и clean architecture — поймете как можно удобно все решить. А еще включите leak canary и попробуйте написать java юнит тесты и поймете почему все эти предложения — тихий ужас.
Отличник отличнику тоже рознь. Вот в школе я был отличником, но если честно мне было пофиг на оценки, просто все давалось достаточно легко и таких штук как сидеть и безвылазно зубрить я вообще не знал, хотя остальные отличники на параллели так же как и вы «брали жопой» и клянчили 5-ки.
Потом поступил на забугорный айтишный факультет и вот тут начилась жопа, т к информатика у нас была ужасная — то первый год из-за тяжелой программы по сишке еле сдавал прдеметы, а вот на втором уже получал стипуху за отличные успехи в учебе, а в третьем пошел работать параллельно.
Про работу могу сказать следующее: «отличник старается все сделать идеально» — это про меня, но это не значит что я буду больше работать, скорее сейчас я хочу сменить компанию т к бизнес компании в которой работаю я требует работать по принипу «хуяк-хуяк в продакшн», ни автоматического тестирования, ни рефакторингов не полагается. «Отличник не готов терпеть какую-либо критику» — тоже да, не люблю когда меня ругают, люблю когда хвалят, это и есть в моем понимании синдром отличника. «Отличник вновь решает избегать ошибок и отказывается от сложной работы» — а это вообще не про меня.
Как видите не все попадают под такую градацию (не только я, но и куча моих знакомых я б сказал не попадают), скорее вы описываете какого-то интроверта социофоба, а тут уже оценки то и не при чем.
Дак на мидлов откликаются де факто джуны, так как джуновских вакансий единицы и на них еще больше откликов на одну вакансию
Ты бывал на хакатонах? Там оно именно так и работает, аналитика генерируется в процессе разработки решения, обсуждая сразу с разработчиками возможности и наиболее эффективный и быстрый способ сделать фичу.
Тестировщика вообще в скраме существовать не должно. Сам Сазерленд рассказывал, что если речь идет о применении скрама в разработке ПО, то работа должна строиться по extreme programming, с tdd и автотестами.
Ну и в целом аналитик, тестировщик и дизайнер не обязаны в команде быть отдельной ролью, которая ничего больше не умеет. Это может быть T-shape разраб с фокусом на QA или дизайн, или бизнес.
У скрама есть очень ограниченная область применения. Как только речь заходит о том, что команда неспособна работать над одной задачей совместно, не представляет как это работать без этапов и конвейера, то это значит только одно - скрам в такой команде не построить. Лучше посмотреть на другие способы организации работы подходящие конвейерной разработке, тот же канбан например.
"Доска - это про канбан" это не так. Доска лишь отражение процессов принятых в команде, а не отдельный инструмент который живет своей жизнь. Тут по скраму, а тут по канбану. Конечно мало 3 поля, ведь команда и ее процессы не перестроены под скрам. Да и не скрам это, про то и говорю.
В плане эффективности тут график показывает, что релизиться чаще, получать чаще фидбек от юзеров и пересматривать бэклог по результатам фидбека полезнее чем релизиться долго. Это решается путем декомпозиции и девопс процессов, которые позволяют релизиться часто. Скрам тут вообще не нужен для этого.
Эффективность в скраме как раз достигается за счет взаимодействия команды. Для интереса вбей в ютуб что такое скрам в регби и посмотри как это выглядит. Ведь фреймворк назвали как раз в честь этого элемента игры. Вы либо толпой перебороли соперника (решили задачу), либо нет. Поэтому таска или не делается, или в процессе, или уже готова. Нет состояния, что один толкает, а другие потолкают попозже.
И вот раз за разом такие статьи. Много внимания каргокультовым практикам и 0 практикам разработки. Было бы 0 вопросов, если бы тут речь шла о скраме в контексте применения в любой сфере деятельности, но тут автор конкретно про айтишку говорит. Так вот Сазерленд утверждал, что скрам в 3-4 раза эффективнее классической каскадной разработки. За счет чего эффективность то будет, если следовать сей инструкции? За счет ретро? Двухнедельного планирования? Аж в 4 раза?
Где про доску из 3 колонок: to do, in progress, done. Где про обязательное условия нахождения всей команды в одном помещении. Где про практики XP, которые Сазерленд подразумевал как само собой разумеющиеся в скраме в it, но исключил их из скрама, чтоб выйти с фреймворком за пределы айтишки. Вот в этих идеях и есть 4-хкратная эффективность. Команда, в одном месте, одновременно работает над задачами цели спринта, как на двухнедельном хакатоне. Постоянно релизит изменения в общую ветку, покрывает все тестами по тдд, используют парное программирование, гибко меняют подзадачи в спринте, чтоб реализовать цель спринта и так далее. Самое главное этапность отсутствует: фронт, бэк, дизайн, аналитика проектируются в одном кабинете за соседними столами одновременно, что позволяет сильно экономить на переделках и сменах контекстов.
Без этого понимания менеджеры обчитываются такими статьями и тащат обычный водопад с двухнедельным планированием по итогу которого еще делают ретро. В одну итерацию у нас инкремент: сделали аналитику для задачи А, дизайн в задаче Б, напрогали В и оттестировали Г. В следующей итерации возьмем задачу Б в проектирование, хотя по скраму задача от бэклога до готовности занимает всегда один спринт.
И вот раз за разом такие статьи. Много внимания каргокультовым практикам и 0 практикам разработки. Было бы 0 вопросов, если бы тут речь шла о скраме в контексте применения в любой сфере деятельности, но тут автор конкретно про айтишку говорит. Так вот Сазерленд утверждал, что скрам в 3-4 раза эффективнее классической каскадной разработки. За счет чего эффективность то будет, если следовать сей инструкции? За счет ретро? Двухнедельного планирования? Аж в 4 раза?
Где про доску из 3 колонок: to do, in progress, done. Где про обязательное условия нахождения всей команды в одном помещении. Где про практики XP, которые Сазерленд подразумевал как само собой разумеющиеся в скраме в it, но исключил их из скрама, чтоб выйти с фреймворком за пределы айтишки. Вот в этих идеях и есть 4-хкратная эффективность. Команда, в одном месте, одновременно работает над задачами цели спринта, как на двухнедельном хакатоне. Постоянно релизит изменения в общую ветку, покрывает все тестами по тдд, используют парное программирование, гибко меняют подзадачи в спринте, чтоб реализовать цель спринта и так далее. Самое главное этапность отсутствует: фронт, бэк, дизайн, аналитика проектируются в одном кабинете за соседними столами одновременно, что позволяет сильно экономить на переделках и сменах контекстов.
Без этого понимания менеджеры обчитываются такими статьями и тащат обычный водопад с двухнедельным планированием по итогу которого еще делают ретро. В одну итерацию у нас инкремент: сделали аналитику для задачи А, дизайн в задаче Б, напрогали В и оттестировали Г. В следующей итерации возьмем задачу Б в проектирование, хотя по скраму задача от бэклога до готовности занимает всегда один спринт.
Потом поступил на забугорный айтишный факультет и вот тут начилась жопа, т к информатика у нас была ужасная — то первый год из-за тяжелой программы по сишке еле сдавал прдеметы, а вот на втором уже получал стипуху за отличные успехи в учебе, а в третьем пошел работать параллельно.
Про работу могу сказать следующее: «отличник старается все сделать идеально» — это про меня, но это не значит что я буду больше работать, скорее сейчас я хочу сменить компанию т к бизнес компании в которой работаю я требует работать по принипу «хуяк-хуяк в продакшн», ни автоматического тестирования, ни рефакторингов не полагается. «Отличник не готов терпеть какую-либо критику» — тоже да, не люблю когда меня ругают, люблю когда хвалят, это и есть в моем понимании синдром отличника. «Отличник вновь решает избегать ошибок и отказывается от сложной работы» — а это вообще не про меня.
Как видите не все попадают под такую градацию (не только я, но и куча моих знакомых я б сказал не попадают), скорее вы описываете какого-то интроверта социофоба, а тут уже оценки то и не при чем.