Техписателей у нас тоже заменяли. Качество без QA значетельно ухудшается это проверенный временем факт. Я говорю о технологии. Апологет скрама Джефф Сазерленд в ответ на вопрос нашего PO о судьбе QA сказал буквально «get rid of them». Не о чем спорить.
Кстати я работаю на компанию, которая производит известные утилиты для QA. Можете на слово поверить, что я знаю очень много о QA и разработчиках. Можете и не верить.
У нас не вебовый продукт. Все, что вы говорите неактуально для разработки. Однако наш продукт предназначен для решения этой ситуации. Прототипируем бэкэнд за пару часов. Делаем его макет с ограниченным количеством ответов. Пишем фронтэнд на этом прототипе и закрываетм протестированный таск. Делаем бэк и видим, что параметры не подходят. Дальше или останавливаем и перепланируем спринт или делаем бэк как договорились. Задачи совершенно параллельны и объеденения не требуют. Тестирование в спринте в любом случае.
Вроде ничего не упустил.
Это для студентов хорошо. В качестве самореализации. Для меня это не важно. Я делал продкуты, которыми пользовались и их закрывали. И писал дрянь, которая успешно продается по сию пору.
Вид процесса производства продукта в любом случае никак не изменяет удовольствие/стыд от произведенного.
Наш цикл выдачи продукта конечному пользователю — квартал. Разные команды выпускают разные продукты разными процессами примерно в эти сроки.
То есть не вижу никакой радости аджайла опять…
Эм… Тойота как-то выпускает машины аджайлом, говорят. Может врут…
Что касается обратных связей, то это инструмент PO. Это никак не связано с процессом разработки. В далекие нулевые годы мы разрабатывали продукт исходя из запросов пользоввателей без аджайла. Очень редко мы переделывали что-то в те далеки благодатные времена. А с аджайлом делать одно и тоже несколько раз приходилось. Дурные понятия UX и дизайн в целом портят кровь…
Что касается умения работать, то меряться тут нет смысла. Продукт наш общеизвестен и приносит очень хорошую прибыль хозяевам. Это единственный важный критерий, думается. Мне безразлична оценка эффективности аджайла в компании. Я против него.
Проталкивать и есть. Добиться попадания задачи в продукт. Приоритезация задачь не влияет напрямую на их попадание в спринт. Она может быть недостаточно описала или сложна в раелизации и может находиться в топе очень долго. Как PO добъется ее исполнения неизвестно. Вполне возможно он может поти на поводу у команды и отказаться от задачи. У нас такое бывает очень часто.
Не знаю как у кого. У нас PO должен повертеть продукт с заказанной функциональностью. Потом потребует поменять. И каждое требование нельзя предтставить в виде полуработающего прототипа или слепить на коленке — протукт должен быть готовым. Вот те накладные расходы скрама про которые я говорю. Пользователь тут безразличен. Это дело PO слушать его или нет и чаще всего нет в виду отсутствия прямой связи PO-пользователь. PO-маркетинг или PO-support вполне работающий диалог, а конечный пользователь недоступен… Ну у нас так.
Частично так. Но по нашему опыту людям не стыдно сказать я вчера, сегодня и завтра буду делать то-то. И так три дня подряд, хотя всем ясно, что работы там на день. Скрам для стыдливых японцев из тойоты работать может.
Да с какое это стороны? Он не может руководить командой. Его дело проталкивать задачи. Это все, что он может. Команда решит что, когда и как будет делать. PO может что-то себе планировать исходя из опыта и капасити/велосити, но решать-то не моежт. Это отличие от менеджера, как мне видится.
Почему вы думаете, что это должно как-то регламентироваться? Кто как закончит, так и будет. В последний день итерации подходит вполне. И, ктсати, тестируют у нас тоже разработчики. Сазерленд требует тестировщиков увольнять. Команда должна быть универсальна и равномерна. Это требование скрама от апологета.
Никак не могу согласиться. Зачем разработчику тянуть с задачей до конца спринта? Если задача нестолько долгая, что занимает почти весь спринт, то она должна быть побита на подзадачи. А задача на три дня не должна породить багов на спринт. Мне так кажется. Бывает все, но нетривиальные задачи довольно редки. По моему очень богатому опыту.
Я не могу себе представить чистого скрама в жизни живущего продукта. Эскалейшены и прочие срочные беды всегда его нарушают. Возможно, что в среде аутсорса или подобных независимых команд, он может существовать. Но в жизни продукта после 1.2 я его представить не могу.
Скрам хорош для экстравертов. Я мало видел программистов экстравертов. Скрам нужен менеджменту как средство уменьшения рисков. А зачем он человеку я представить не могу.
Не знаю как у кого. Мы включает тестирование в спринт. Сроки на него закладываются изначально. При большом количестве серьезных багов можно говорить о неправильной оценке задачи. Что делать с ней дальше дело десятое. При правильной оценке сроки не горят.
Как итеративный процесс может привести к минимуму лишней работы? У вас должен быть законченный продкут каждый спринт. Вы выполните работу под доделке каждый раз переделывая неудачные с точки зрения PO реализации. Я действительно не вижу как тут можно получить выгоду.
Корпоративные выгоды я вижу легко, но мне это безразлично.
Я просто не могу себе представить сложившейся команды, которая в один день проснулась и попросила скрама. Людям не нужен скрам — он обесценивает их и препятствует карьерному росту. Скрам нужен компании и это разные вещи. Можно было бы коротко ответить да сверху, но это слишком банально.
Сопровождение скрама в наших реалиях невозможно просто теоретически: нас и PO разделяют континеты. Раньше были страны, но теперь решили улучшить ситуацию, по аналогии увеличения любви к теще с увеличением расстояния до нее, видимо. Скрам у нас песня очень забавная. Он нам с проектом в наследство достался. А проблемы для скрама решать никто и не должен. Основная идея в том, что скрам саморешающая затея. У нас скрам мастера-то нет. А тут проблемы внедрения… Ну главное отрапортовать, что скрамим со всей силы и демы. А там хоть не рассветай. Интересно, что за последние два года количество посещающих демы уменьшилось в несколько раз. Маркетинг с них просто исчез. При этом продажи выросли и довольно значительно. Что-то не так с этим скрамом в наших реалиях…
У нас нескрамовская команда в 13 человек. Животрепещущие темы обсуждаются сразу же.
Гайдов у нас нет. Причина проста — берндаун чарт полезет вверх. Скоуп спринта не должен меняться для нас посулат. Менеджерский постулат, выведенный из слушания Сазерленда. Так уж получилось, что все его слушали как-то особенно и услышали совершенно разное. Каких-то материальных потверждений этого выслушивания они не привезли. Ну колоды карт не в счет.
Не знаю что там сейчас спрашивают на собеседованиях. Мне это мало интересно. Мы будем дальше писать поделки с моим мнением а маркетинг продолжит продавать их другим непонимающим.
Это актуально только для маленьких проектов. Любой более-менее сложный многопоточный проект рано или поздно упадет с нехваткой памяти. Надеяться на GC можно только до определенного времени. Дальше нужно переосмысливать архитектуру. Ява тут беспомощна, ничего не поделать. Как пример JMeter, который обязательно упадет в какой-то момент времени.
Есть еще одна беда с ArrayList. Постоянное добавление эелементов реаллоцирует память, что приводит к неизбезной сегментации и резервации следующей кучи менеджером памяти. В итоге менеджер не может найти нужного куска, хотя пустых фрагментированных сегментов достаточно. В многопоточных нагруженных системах это приводит к полной аккупации CPU GC и ошибкам нехватки памяти. То есть свободные зарезервированные куски не такая уж и большая проблема, хотя может быть это частная беда конкретного проекта. Людям привыкшим к нативному управлению памятью, к которым я отношусь, проблема видится нерешаемой и требующей архитектурных изменений.
Кстати я работаю на компанию, которая производит известные утилиты для QA. Можете на слово поверить, что я знаю очень много о QA и разработчиках. Можете и не верить.
Вроде ничего не упустил.
Вид процесса производства продукта в любом случае никак не изменяет удовольствие/стыд от произведенного.
Наш цикл выдачи продукта конечному пользователю — квартал. Разные команды выпускают разные продукты разными процессами примерно в эти сроки.
То есть не вижу никакой радости аджайла опять…
Что касается обратных связей, то это инструмент PO. Это никак не связано с процессом разработки. В далекие нулевые годы мы разрабатывали продукт исходя из запросов пользоввателей без аджайла. Очень редко мы переделывали что-то в те далеки благодатные времена. А с аджайлом делать одно и тоже несколько раз приходилось. Дурные понятия UX и дизайн в целом портят кровь…
Что касается умения работать, то меряться тут нет смысла. Продукт наш общеизвестен и приносит очень хорошую прибыль хозяевам. Это единственный важный критерий, думается. Мне безразлична оценка эффективности аджайла в компании. Я против него.
Скрам хорош для экстравертов. Я мало видел программистов экстравертов. Скрам нужен менеджменту как средство уменьшения рисков. А зачем он человеку я представить не могу.
Корпоративные выгоды я вижу легко, но мне это безразлично.
Сопровождение скрама в наших реалиях невозможно просто теоретически: нас и PO разделяют континеты. Раньше были страны, но теперь решили улучшить ситуацию, по аналогии увеличения любви к теще с увеличением расстояния до нее, видимо. Скрам у нас песня очень забавная. Он нам с проектом в наследство достался. А проблемы для скрама решать никто и не должен. Основная идея в том, что скрам саморешающая затея. У нас скрам мастера-то нет. А тут проблемы внедрения… Ну главное отрапортовать, что скрамим со всей силы и демы. А там хоть не рассветай. Интересно, что за последние два года количество посещающих демы уменьшилось в несколько раз. Маркетинг с них просто исчез. При этом продажи выросли и довольно значительно. Что-то не так с этим скрамом в наших реалиях…
Гайдов у нас нет. Причина проста — берндаун чарт полезет вверх. Скоуп спринта не должен меняться для нас посулат. Менеджерский постулат, выведенный из слушания Сазерленда. Так уж получилось, что все его слушали как-то особенно и услышали совершенно разное. Каких-то материальных потверждений этого выслушивания они не привезли. Ну колоды карт не в счет.