По факту все выбирают платить и поддерживать совместимость. Если ваш подход даст мегапреимущество, это всех завоюет. Но он не дает. Рантаймы и нативные приложения есть и известны, он не вытесняют веб
Не для всех видов массажа необходим хороший массажист, насколько я знаю. Некоторые виды массажа непрофессиональные люди волне успешно делают друг другу.
Бекэнд может помочь фронтенду, например, со вспомогательными — развертывание сред, воспроизведение багов, тестирование и т.д.
Да, если объем работы для Бека и фронта в среднем статистически соответствует их возможностям. То есть команда сбалансирована. Иначе будет просто накопление wip
А ещё есть куча не продуктовых задач, которые тоже надо делать.
Боюсь даже спрашивать какая чёрная магия позволила вам сделать такой вывод.
"Сбалансировать" — достигнуть наилучшего соотношения фронта и бека для решения поставленных задач. Если нельзя достигнуть наилучшего соотношения, то все соотношения одинаковы — в том числе один бек.
Но если вам нужно решение, то оно простое — отдельно оценивать и набирать в спринт задачи по каждой специализации.
Т.е. результатом спринта может быть что-то неготовое к использованию, например, сделан один бек без фронта?
Чтобы сформулировать идею, каким образом в отличие от других компании собираются заработать денег.
Google: Цель компании Google – упорядочить всю информацию в мире и сделать ее доступной каждому
Amazon: Our vision is to be Earth's most customer centric company; to build a place where people can come to find and discover anything they might want to buy online.
...
Киоск с шаурмой: Мы накормим Южное Бутово самой дешевой шаурмой с картошкой
Разумеется, если вы еще не заметили, то люди из всего делают карго культ.
Насколько я понял, чтобы дроп что-то делал он должен еще не сидеть. Если их регулярно сажать, по идее предложение дропов может уменьшиться и цена возрасти
И тут появляется только что закончивший читать Scrum and XP from the Trenches PM и говорит
Если я правильно понимаю, что написано в книжке и вашу ситуацию, то увеличить количество сторипоинтов на следующую итерацию это против книжки потому, что считаются только готовые истории, а те, в которых сделан только бекенд не считаются.
А что, если история была почти закончена? Почему мы не используем дробные значения для таких
историй при подсчете реальной производительности? Потому, что Scrum (как и гибкая разработка (agile), да и
бережливое производство (lean)) ориентирован на то, чтобы создавать законченный, готовый к поставке
продукт! Ценность реализованной наполовину истории нулевая (а то и отрицательная). См. книгу “Managing
the Design Factory” автора Donald Reinertsen или одну из книг авторов Mary Poppendieck и Tom Poppendieck.
С моей точки зрения в духе книжки было бы попросить бекенд помочь фронтенду на простых или вспомогательных задачах — ситуация аналогична главе Чем занимается тестировщик, когда нечего тестировать. Либо устранением технического долга — внутренними вещами — если они совсем ничем не могут помочь спринту.
Два программиста говорят о том, какую библиотеку выбрать для логгирования, третий это слышит, подключается и советует им что-то по своему опыту, например.
Это зависит от, того, что считать моком и как он реализован. В статически типизированном языке можно динамически генерить моки а волшебство зафигачит Not Implemented Exception, например, во все методы кроме явно указанных.
Если вы для 3х методов класса тесты пишете, а для 4го, который, например, всего лишь однострочная обертка библиотечной функции — нет, то используете ли вы для разработки TDD?
Да. Если я использовал для гвоздя молоток, а для шурупа отвертку, то я использую молоток.
А если вы именно по принципам TDD которые описывают его применимость определили что для этого метода тесты не нужны, то использовали ли вы его для разработки?
А вот тут я бы хотел ссылочку. Я слышал принцип "Тестировать надо то, что может сломаться". В моем представлении тестировать надо то, тестирование чего окупается (легко тестировать или выигрыш от предотвращения багов и влияния на дизайн большой).
Статьи, книжки, теоремы и саги уже написаны :) осталось их нагуглить
Это результат прогиба И контракта с фиксированной ценой.
Я слышал, что это временно:
По факту все выбирают платить и поддерживать совместимость. Если ваш подход даст мегапреимущество, это всех завоюет. Но он не дает. Рантаймы и нативные приложения есть и известны, он не вытесняют веб
Лучше вы расскажите — это ж у вас принят "массаж напряженным членом" а у нас и фронт и бек — разработчики.
Не для всех видов массажа необходим хороший массажист, насколько я знаю. Некоторые виды массажа непрофессиональные люди волне успешно делают друг другу.
Бекэнд может помочь фронтенду, например, со вспомогательными — развертывание сред, воспроизведение багов, тестирование и т.д.
Да, если объем работы для Бека и фронта в среднем статистически соответствует их возможностям. То есть команда сбалансирована. Иначе будет просто накопление wip
Это да
"Сбалансировать" — достигнуть наилучшего соотношения фронта и бека для решения поставленных задач. Если нельзя достигнуть наилучшего соотношения, то все соотношения одинаковы — в том числе один бек.
Т.е. результатом спринта может быть что-то неготовое к использованию, например, сделан один бек без фронта?
То есть любое соотношение бека и фронта эквивалентно? Можно оставить один бек и решать все задачи?
Чтобы сформулировать идею, каким образом в отличие от других компании собираются заработать денег.
Google: Цель компании Google – упорядочить всю информацию в мире и сделать ее доступной каждому
Amazon: Our vision is to be Earth's most customer centric company; to build a place where people can come to find and discover anything they might want to buy online.
...
Киоск с шаурмой: Мы накормим Южное Бутово самой дешевой шаурмой с картошкой
Разумеется, если вы еще не заметили, то люди из всего делают карго культ.
Насколько я понял, чтобы дроп что-то делал он должен еще не сидеть. Если их регулярно сажать, по идее предложение дропов может уменьшиться и цена возрасти
А нельзя сделать больно дропу чтобы они были дороже?
Кстати, решение "те, кто освободились, помогают тем кто работает" делает потихонечку всех T-shaped
Если я правильно понимаю, что написано в книжке и вашу ситуацию, то увеличить количество сторипоинтов на следующую итерацию это против книжки потому, что считаются только готовые истории, а те, в которых сделан только бекенд не считаются.
С моей точки зрения в духе книжки было бы попросить бекенд помочь фронтенду на простых или вспомогательных задачах — ситуация аналогична главе Чем занимается тестировщик, когда нечего тестировать. Либо устранением технического долга — внутренними вещами — если они совсем ничем не могут помочь спринту.
Интересно было бы сравнить с .NET Core 3.0 и System.Text.JSON. По ссылкам обещают ускорение:
https://www.scrumalliance.org/get-certified/developer-track/certified-scrum-developer
Два программиста говорят о том, какую библиотеку выбрать для логгирования, третий это слышит, подключается и советует им что-то по своему опыту, например.
Это зависит от, того, что считать моком и как он реализован. В статически типизированном языке можно динамически генерить моки а волшебство зафигачит Not Implemented Exception, например, во все методы кроме явно указанных.
https://habr.com/ru/post/150859/
Пусть это будет не сервис, а просто функция или метод для заказа пиццы?
Да. Если я использовал для гвоздя молоток, а для шурупа отвертку, то я использую молоток.
А вот тут я бы хотел ссылочку. Я слышал принцип "Тестировать надо то, что может сломаться". В моем представлении тестировать надо то, тестирование чего окупается (легко тестировать или выигрыш от предотвращения багов и влияния на дизайн большой).