Так я и не утверждаю, что «развитие» == «работа».
Я говорю о том, что «не рабочее развитие» вполне себе может помогать работе, пытаясь оспорить ваше утверждение что «если не работа — > то отдых, соответственно работе оно не может помогать».
В зависимости от ситуации «не рабочее развитие» может давать больше профита, чем развитие профессиональное. В этом тезис.
На самом деле довольно спорное утверждение. Худлит это, безусловно, не профильное, но всё же развитие.
И тут сильно зависит от того, что человек ожидает получить после прочтения книги.
Мне, например, чтение художественной литературы знатно помогает при последующей генерации сценариев для своих проектов. А техническая литература помогает не меньше, но в рамках уже конкретной реализации этих сценариев.
А иногда и просто читаешь условную фантастику и собираешь себе какую-нибудь софтину, навеянную каким-нибудь нейроинтерфейсным ассистентом в книге.
И тут нужен баланс, т.к. иметь имею, но не знать как её воплотить не сильно полезнее, чем понимать реализацию, но не обладать идеей её применения.
Знаете, мне кажется «Приемы программирования, использованные при написании Властелина колец» — тоже не лучший вариант.
Понабежало бы столько же народу с криками «кликбэйт, где паттерны, микросервисы и ООП?!»
Просто потому, что «приемы программирования» — довольно обширное понятие и много чего можно под ним подразумевать.
В статье же идёт речь, насколько я могу судить, про одну простую вещь — итеративность и, если натягивать сову на глобус, работу с «ветками».
Хотя, это конечно меньший кликбэйт чем слово «Git» в заголовке.
Абзац, на самом деле, предельно логичен и понятен, если не начинать сразу хайпить «аааа, сидят там свои штаны в переговорках просиживают!».
Всё предельно просто. Человек который просто сидит и пишет код, не участвуя в совещаниях ни с командой, ни за её пределами — это простой исполнитель. Он получает рыночную зарплату, фигачит таск за таском и всем доволен.
Человек, который участвует в совещаниях обычно делает это не просто так, а потому, что обладает достаточным авторитетом или квалификацией внутри компании, что бы его мнение было важно при решении вопросов, которые на этом митинге обсуждаются. Такие люди участвуют в принятии решений что и как делать, и как правило несут за эти решения ответственность. Естественно, они получают больше.
В совещаниях нет ничего плохого, когда все участники понимают, зачем и почему они собрались.
Да, и формальное доказательство предполагает либо слабую логическую сложность программы, либо доказательство в рамках одной тестовой модели.
Это, ни в коем случае, не гарантирует её безошибочную работу с любыми данными, на любых девайсах и в любой ситуации.
Ваша фраза про инструменты вполне правильна. Только с парой поправок. Методология разработки — это не инструмент. Это набор методик и рекомендаций, как использовать инструменты.
Это не значит, что эти методики и рекомендации подходят для всех инструментов, всех условий, всех работников идеально.
Это значит, что некогда схававшие на проблемах разработки пуд лиха люди собрались, обсудили и сформировали рекомендации, как стоит использовать инструменты, что бы по максимуму избежать проблем.
Вполне возможно, что вы знаете и умеете готовить процесс разработки лучше. Тогда, у вас не должно возникать поводов внедрять аджайл. Его внедряют, в большинстве случаев, тогда, когда в процессе разработки есть проблемы, которые он призван решать.
Будет он их решать или нет — зависит только от тех, кто его внедряет. Т.е. команды.
Нет, это не так. Потому что термин «неправильно» подразумевает существование термина «правильно».
Ни в случае с ПО, ни в случае процессов разработки — нельзя построить идеально. Всегда будут проблемы.
Важна их частота и степень их влияния.
На примере с ПО — вы никогда не выпустите ПО, которое будет работать без ошибок. Даже если у вас будет неограниченное время и бюджет. Но, вы можете приблизить качество ПО к тому уровню, когда количество мешающих пользователю ошибок будет сведено к минимуму, а обнаружение и исправление пропущенного на продакшен — будет безболезненным.
На примере с процессами — нет идеальных процессов. И речь даже не об универсальности для всех продуктов и компаний. Даже в разрезе одной конкретной компании факторов, которые могут «всё сломать» — слишком много. Пытаться сделать идеально — это борьба с энтропией.
Цель же совсем не в этом. Цель в том, что бы, сначала, максимально эффективно отладить нормальный workflow команды, а затем сделать всё необходимое для максимально безболезненного устранения форс-мажоров. Начиная от бас-фактора среди команды и незапланированных задач и заканчивая падением атомной бомбы на датацентр вашего хостера.
Не очень понимаю суть поправки. То, что что-то оказалось в продакшене подразумевает, что это «что-то» прошло весь SDLC и соответствует всем критериям для попадания в продакшен. Разве нет?
«Готовое к нему, но не в продакшене» — не считается. То, чем не может пользоваться бизнес — не сделано.
Не совсем. В качестве результатов каждого спринта ожидается положительный прирост функциональности приложения. Это, в общем-то, довольно прямым текстом задекларировано.
Это, естественно, не значит, что конец спринта — это дедлайн, к которому все задачи должны быть в продакшене.
Это значит, что какое-то развитие по результатам спринта продукт всё равно должен получить (т.е. сделали меньше, чем запланировали -> неприятный, но валидный исход. Ни одной задачи нет в продакшене -> спринт провален).
Не уверен, специально вы передергиваете, или по незнанию.
Во первых, аджайл придумали именно про это. Что бы не отсылать вас в глубины умных книжек, просто оставлю вам статью на википедию.
Если вы прочитаете хотя бы её, то там подробно изложено что и зачем. Короткие итерации — из-за постоянно меняющихся требований. Беспрерывная доставка — из-за необходимости развивать продукт динамично. И т.д.
Скрам не может быть «про другое», потому что это всего-лишь один из методов «делать разработку гибкой».
Внутри раздных методик могут отличаться детали и процессы, но все они так или иначе наследуются от Agile Manifesto и принципов, в нем изложенных.
По поводу претензий, я специально попросил развернуто, потому что ваши пункты не звучат конструктивно.
Окей, целых три пункта про митинги. Какие митинги в скрам делают вашу работу столь невыносимой?
Дейли митинг на 10 минут с утра, с необходимостью ответить на три простых вопроса? Я не видел более удачных способов синхронизировать между собой, это или полный хаос и «каждый в своём углу херачит неизвестно что» или бредовые письменные репорты и прочий ад.
В любом случае, даже если предположить что вам глубоко положить на то, чем занимаются ваши коллеги по команде — вполне можно потратить 10 минут в день, что бы _они_ знали, чем занимается команда.
Или, может быть, вас жутко бесит ретроспектива раз в спринт, занимающая час-два? Опять же, мне не кажется, что это безумное количество времени, которое нельзя потратить, что бы попытаться вместе с коллегами улучшить процесс работы.
Самый муторный из оных — планирование спринта, с разбором и оценкой задач и вот этим всем. Эта штука может сожрать дохрена времени. Но, надо понимать, что единственная его цель — что бы команда понимала, что нужно сделать. Если вам приходят уже понятные и проработанные требования, то разбор задач на 3 недели для 15 человек занимает… от двух до трех часов. С декомпозицией, оценкой и вот этим всем.
Неприятно, но 2-3 часа в неделю на три недели работы — как-то немного маловато, что бы при этом со слюной у рта кричать «ДОСТАЛЕ МИТИНГИ!!11».
Если планирование, оценка и декомпозиция занимает больше времени — значит на ней объясняются и выясняются требования. Чем более неясны требования — тем дольше будет разбор задач. Но, нужно понимать, что все эти вопросы в любом случае всплыли бы, просто скорее всего позже — когда код (или по крайней мере его часть) уже написана и внесение изменений будет дороже.
Т.е. вы тратите время на митинг сейчас, что бы не перепиливать задачи в последний момент. На мой взгляд — вполне оправданное вложение времени.
В целом, на трехнедельный спринт вы потратите от 5 до 8 часов. Больше никаких обязательных митингов, затрагивающих типичного разработчика, в скраме нет.
8 часов из 120 — это дофига? Я вот так не думаю.
P.S. Все это, конечно, работает только при одном важном условии. Должен выполняться один из важнейших принципов Agile Manifesto:
Projects are built around motivated individuals, who should be trusted
Причем, выполнять его должны не только менеджеры и «заказчики», выполнять его должны в первую очередь разработчики.
Про «средне-низкие» настройки, количество полигонов и прочие истории вы, естественно, правы.
Это всё вполне себе гадание на кофейной гуще и субьективные ощущение, не претендующие на абсолютную истину.
По поводу овервотч, я, к слову, его скорее хвалил в плане оптимизации. Но, согласитесь, требования к динамичному шутеру 6х6 значительно ниже, чем требования к динамичному шутеру 200х200 (условный планетсайд). Просто объем динамики немного другой.
Понятно, что количество игроков — далеко не единственный фактор, который повышает «прожорливость» игры. Факторов много, никто и не спорит.
По поводу печей и ЦПУ: не являюсь экспертом, однако по моим наблюдениям всё зависит от движка. Например последняя мморпг в которую играл, Guildwars2, оказалась в большей степени зависимой от CPU, нежели от GPU. Т.е. замена GPU с относительно старой на топовую почти не дала прироста производительности, а замена проца — дала.
По поводу баттлфиллдов — играл и в то, и в другое. Разница в картинке конечно есть, правда в большинстве своём за счёт пагубного консольного размыливания. Тем не менее, как уже говорил — темпы роста «прожорливости» игр быстро опережают рост качества этих игр.
Что же до «виноваты не разработчики, виноваты менеджеры» — я вполне допускаю, что дело даже в пресловутом «всем выгодно, что бы новое железо покупали».
И не в коем случае не пытаюсь выставить разработчиков некими злыми гениями, вшивающими в глубины графического движка инфинит лупы и майнинг биткоинов, лишь бы мой несчастный ПК грелся и страдал пытаясь запустить их очередное поделие.
Другое дело, что и в просветленных джедаев, готовых писать совершенный и производительный код, но вынужденных говнокодить из-за плохих менеджеров я тоже не очень верю.
Вероятнее, причина и в том, и в другом. Компаниям не выгодно тратить _бешенное_ количество денег на излишнюю оптимизацию, а многие разработчики пренебрегают использовать техники, которые позволили бы им писать более производительный код.
И несмотря на то, что они вполне могут пренебрегать этим по самым разным причинам, одна из возможных причин — банальное незнание, как сделать лучше не увеличив при этом в разы стоимость разработки.
Поэтому я и не согласился с исходным комментарием «те, кто пишет эти движки и так прекрасно знают, как писать».
GTA V не самый плохой пример, спору нет. При этом извините, но всё таки 20 фпс при средне-низких настройках — так себе показатель.
Есть ещё более обидный пример: последняя Цивилизация, у которой память течёт так, что через несколько часов игры начинают лагать и виснуть кат-сцены и переход хода. Это при средних настройках, на более чем нормальном железе.
Есть достойно оптимизированный Overwatch, который не блещет 4к графикой но выдает хороший фпс даже на очень слабых машинах.
Есть, например Ведьмак, который оптимизирован весьма неплохо и даёт хорошую картинку и непросаживающийся фпс на среднем железе. При это для стабильного Ultra всё равно нужен домашний космолёт.
Но это, простите, не MMORPG, где, помимо всего прочего, параллельно несколько сотен тел месятся в войне гильдий. Это сингл-плеер игра (в случае овервотча — тимплей матч 6х6), где динамических объектов в зоне видимости пользователя значительно меньше.
Понятие «старый компьютер» тоже довольно относительное. У меня игровой комп собирался 3 года назад в «хорошей» (но не топовой) комплектации. Сейчас это железо, с точки зрения игр, старое. Вы считаете это нормальным? Я — нет.
Я говорю о том, что отвратительная оптимизация игр фактически не оставляет выбора: если ты хочешь играть на ультра-качестве (т.е. видеть всё, что создал разработчик) и с FPS выше 40 (о стабильных 60 вообще молчу) — будь добр каждые 3 года собирать себе печь с двумя видеокартами и топовым процессором.
А теперь давайте попытаемся ответить себе честно, делает ли за эти три года графика в играх настолько сильный прирост, что бы требовать производительность на 40% выше?
Я вот считаю, что нет.
Мне, лично, кажется что причина значительно проще — в отношении разработчиков к используемым ресурсам. «А, да ладно, докупят ещё одну видяху, есличо».
Если бы не производительность современных игр, в частности GTA 5 (хотя, может в 6ой и правда всё хорошо?) я бы с вами даже согласился.
У меня, лично, складывается ощущение, что этого всего разработчики не знают.
Это уже проблема менеджера в «типо скраме».
Эстимейты устанавливает команда. Thats all, folks.
Если кто-то не может сказать менеджеру «Сорян, друг, но нет» — это уже его проблемы.
Есть разные мнения на этот счёт.
По мне проще и удобнее трекать время на плановые задачи, чем оценивать неплановые постфактум в сторипоинтах.
По поводу включения\выключения из спринта — мне в этом плане вообще ближе всего канбан доска, с бэклогом задач в порядке приоритетов и весьма условным понятием спринта как периода некоторых командных активити.
Это значительно упрощает всем жизнь, на мой взгляд.
В рамках жестких спринтов и чёткого скрама — да, такие задачи надо включать в спринт, а что-то из него выкидывать. Когда их оценивать — заранее или постфактум — тоже открытый вопрос.
В общем, зависит от команды, продукта и множество факторов, надо смотреть и адаптировать под свои реалии. Серебряной пули, как и везде, нет.
А кто-то призывал брать минимальную оценку?
Я нет. Более того, я склоняюсь к тому, что при планировании стоит брать максимальную из незавышенных искусственно оценок.
Вы предлагаете постфактум разбирать, почему успели меньше, чем запланировали.
Я предлагаю стараться заранее закладывать буффер на такие задачи, что бы уменьшить стрессовость всплывающих задач.
Работает и тот, и другой вариант. Я пробовал оба, мне проще трекать время, хотя у меня, как QA, значительно ежедневных больше задач, чем у разработчика.
Я видел scrumban, один раз в российских реалиях, пару раз в международных.
Плюс, пара знакомых которые так же вполне успешно и счастливо работают по довольно каноничному scrum, без всего перечисленного в вашей статье.
А чем вам, как разработчику, не удобен скрам?
Ну, если можно, то развернуто и по пунктам. При этом постарайтесь, пожалуйста, абстрагироваться от сферического вотерфолл в вакууме, когда «мне просто дали идеально проработанное тз на 500 страниц, а я написал код, который идеально работает», а всё таки придти к жизненным реалиям, из-за которых аджайл придумали — заказчик сам не знает, чего хочет, требования меняются, продукт должен развиваться динамично, и вот это всё.
Ну, и я не очень понимаю, как менеджеру может быть удобен аджайл, учитывая что аджайл лишает менеджеров власти, всяческих лавров, а в некоторых случаях и работы вообще.
Я говорю о том, что «не рабочее развитие» вполне себе может помогать работе, пытаясь оспорить ваше утверждение что «если не работа — > то отдых, соответственно работе оно не может помогать».
В зависимости от ситуации «не рабочее развитие» может давать больше профита, чем развитие профессиональное. В этом тезис.
И тут сильно зависит от того, что человек ожидает получить после прочтения книги.
Мне, например, чтение художественной литературы знатно помогает при последующей генерации сценариев для своих проектов. А техническая литература помогает не меньше, но в рамках уже конкретной реализации этих сценариев.
А иногда и просто читаешь условную фантастику и собираешь себе какую-нибудь софтину, навеянную каким-нибудь нейроинтерфейсным ассистентом в книге.
И тут нужен баланс, т.к. иметь имею, но не знать как её воплотить не сильно полезнее, чем понимать реализацию, но не обладать идеей её применения.
Понабежало бы столько же народу с криками «кликбэйт, где паттерны, микросервисы и ООП?!»
Просто потому, что «приемы программирования» — довольно обширное понятие и много чего можно под ним подразумевать.
В статье же идёт речь, насколько я могу судить, про одну простую вещь — итеративность и, если натягивать сову на глобус, работу с «ветками».
Хотя, это конечно меньший кликбэйт чем слово «Git» в заголовке.
Всё предельно просто. Человек который просто сидит и пишет код, не участвуя в совещаниях ни с командой, ни за её пределами — это простой исполнитель. Он получает рыночную зарплату, фигачит таск за таском и всем доволен.
Человек, который участвует в совещаниях обычно делает это не просто так, а потому, что обладает достаточным авторитетом или квалификацией внутри компании, что бы его мнение было важно при решении вопросов, которые на этом митинге обсуждаются. Такие люди участвуют в принятии решений что и как делать, и как правило несут за эти решения ответственность. Естественно, они получают больше.
В совещаниях нет ничего плохого, когда все участники понимают, зачем и почему они собрались.
Это, ни в коем случае, не гарантирует её безошибочную работу с любыми данными, на любых девайсах и в любой ситуации.
Ваша фраза про инструменты вполне правильна. Только с парой поправок. Методология разработки — это не инструмент. Это набор методик и рекомендаций, как использовать инструменты.
Это не значит, что эти методики и рекомендации подходят для всех инструментов, всех условий, всех работников идеально.
Это значит, что некогда схававшие на проблемах разработки пуд лиха люди собрались, обсудили и сформировали рекомендации, как стоит использовать инструменты, что бы по максимуму избежать проблем.
Вполне возможно, что вы знаете и умеете готовить процесс разработки лучше. Тогда, у вас не должно возникать поводов внедрять аджайл. Его внедряют, в большинстве случаев, тогда, когда в процессе разработки есть проблемы, которые он призван решать.
Будет он их решать или нет — зависит только от тех, кто его внедряет. Т.е. команды.
Ни в случае с ПО, ни в случае процессов разработки — нельзя построить идеально. Всегда будут проблемы.
Важна их частота и степень их влияния.
На примере с ПО — вы никогда не выпустите ПО, которое будет работать без ошибок. Даже если у вас будет неограниченное время и бюджет. Но, вы можете приблизить качество ПО к тому уровню, когда количество мешающих пользователю ошибок будет сведено к минимуму, а обнаружение и исправление пропущенного на продакшен — будет безболезненным.
На примере с процессами — нет идеальных процессов. И речь даже не об универсальности для всех продуктов и компаний. Даже в разрезе одной конкретной компании факторов, которые могут «всё сломать» — слишком много. Пытаться сделать идеально — это борьба с энтропией.
Цель же совсем не в этом. Цель в том, что бы, сначала, максимально эффективно отладить нормальный workflow команды, а затем сделать всё необходимое для максимально безболезненного устранения форс-мажоров. Начиная от бас-фактора среди команды и незапланированных задач и заканчивая падением атомной бомбы на датацентр вашего хостера.
«Готовое к нему, но не в продакшене» — не считается. То, чем не может пользоваться бизнес — не сделано.
Это, естественно, не значит, что конец спринта — это дедлайн, к которому все задачи должны быть в продакшене.
Это значит, что какое-то развитие по результатам спринта продукт всё равно должен получить (т.е. сделали меньше, чем запланировали -> неприятный, но валидный исход. Ни одной задачи нет в продакшене -> спринт провален).
Во первых, аджайл придумали именно про это. Что бы не отсылать вас в глубины умных книжек, просто оставлю вам статью на википедию.
Если вы прочитаете хотя бы её, то там подробно изложено что и зачем. Короткие итерации — из-за постоянно меняющихся требований. Беспрерывная доставка — из-за необходимости развивать продукт динамично. И т.д.
Скрам не может быть «про другое», потому что это всего-лишь один из методов «делать разработку гибкой».
Внутри раздных методик могут отличаться детали и процессы, но все они так или иначе наследуются от Agile Manifesto и принципов, в нем изложенных.
По поводу претензий, я специально попросил развернуто, потому что ваши пункты не звучат конструктивно.
Окей, целых три пункта про митинги. Какие митинги в скрам делают вашу работу столь невыносимой?
Дейли митинг на 10 минут с утра, с необходимостью ответить на три простых вопроса? Я не видел более удачных способов синхронизировать между собой, это или полный хаос и «каждый в своём углу херачит неизвестно что» или бредовые письменные репорты и прочий ад.
В любом случае, даже если предположить что вам глубоко положить на то, чем занимаются ваши коллеги по команде — вполне можно потратить 10 минут в день, что бы _они_ знали, чем занимается команда.
Или, может быть, вас жутко бесит ретроспектива раз в спринт, занимающая час-два? Опять же, мне не кажется, что это безумное количество времени, которое нельзя потратить, что бы попытаться вместе с коллегами улучшить процесс работы.
Самый муторный из оных — планирование спринта, с разбором и оценкой задач и вот этим всем. Эта штука может сожрать дохрена времени. Но, надо понимать, что единственная его цель — что бы команда понимала, что нужно сделать. Если вам приходят уже понятные и проработанные требования, то разбор задач на 3 недели для 15 человек занимает… от двух до трех часов. С декомпозицией, оценкой и вот этим всем.
Неприятно, но 2-3 часа в неделю на три недели работы — как-то немного маловато, что бы при этом со слюной у рта кричать «ДОСТАЛЕ МИТИНГИ!!11».
Если планирование, оценка и декомпозиция занимает больше времени — значит на ней объясняются и выясняются требования. Чем более неясны требования — тем дольше будет разбор задач. Но, нужно понимать, что все эти вопросы в любом случае всплыли бы, просто скорее всего позже — когда код (или по крайней мере его часть) уже написана и внесение изменений будет дороже.
Т.е. вы тратите время на митинг сейчас, что бы не перепиливать задачи в последний момент. На мой взгляд — вполне оправданное вложение времени.
В целом, на трехнедельный спринт вы потратите от 5 до 8 часов. Больше никаких обязательных митингов, затрагивающих типичного разработчика, в скраме нет.
8 часов из 120 — это дофига? Я вот так не думаю.
P.S. Все это, конечно, работает только при одном важном условии. Должен выполняться один из важнейших принципов Agile Manifesto:
Причем, выполнять его должны не только менеджеры и «заказчики», выполнять его должны в первую очередь разработчики.
Это всё вполне себе гадание на кофейной гуще и субьективные ощущение, не претендующие на абсолютную истину.
По поводу овервотч, я, к слову, его скорее хвалил в плане оптимизации. Но, согласитесь, требования к динамичному шутеру 6х6 значительно ниже, чем требования к динамичному шутеру 200х200 (условный планетсайд). Просто объем динамики немного другой.
Понятно, что количество игроков — далеко не единственный фактор, который повышает «прожорливость» игры. Факторов много, никто и не спорит.
По поводу печей и ЦПУ: не являюсь экспертом, однако по моим наблюдениям всё зависит от движка. Например последняя мморпг в которую играл, Guildwars2, оказалась в большей степени зависимой от CPU, нежели от GPU. Т.е. замена GPU с относительно старой на топовую почти не дала прироста производительности, а замена проца — дала.
По поводу баттлфиллдов — играл и в то, и в другое. Разница в картинке конечно есть, правда в большинстве своём за счёт пагубного консольного размыливания. Тем не менее, как уже говорил — темпы роста «прожорливости» игр быстро опережают рост качества этих игр.
Что же до «виноваты не разработчики, виноваты менеджеры» — я вполне допускаю, что дело даже в пресловутом «всем выгодно, что бы новое железо покупали».
И не в коем случае не пытаюсь выставить разработчиков некими злыми гениями, вшивающими в глубины графического движка инфинит лупы и майнинг биткоинов, лишь бы мой несчастный ПК грелся и страдал пытаясь запустить их очередное поделие.
Другое дело, что и в просветленных джедаев, готовых писать совершенный и производительный код, но вынужденных говнокодить из-за плохих менеджеров я тоже не очень верю.
Вероятнее, причина и в том, и в другом. Компаниям не выгодно тратить _бешенное_ количество денег на излишнюю оптимизацию, а многие разработчики пренебрегают использовать техники, которые позволили бы им писать более производительный код.
И несмотря на то, что они вполне могут пренебрегать этим по самым разным причинам, одна из возможных причин — банальное незнание, как сделать лучше не увеличив при этом в разы стоимость разработки.
Поэтому я и не согласился с исходным комментарием «те, кто пишет эти движки и так прекрасно знают, как писать».
Есть ещё более обидный пример: последняя Цивилизация, у которой память течёт так, что через несколько часов игры начинают лагать и виснуть кат-сцены и переход хода. Это при средних настройках, на более чем нормальном железе.
Есть достойно оптимизированный Overwatch, который не блещет 4к графикой но выдает хороший фпс даже на очень слабых машинах.
Есть, например Ведьмак, который оптимизирован весьма неплохо и даёт хорошую картинку и непросаживающийся фпс на среднем железе. При это для стабильного Ultra всё равно нужен домашний космолёт.
Но это, простите, не MMORPG, где, помимо всего прочего, параллельно несколько сотен тел месятся в войне гильдий. Это сингл-плеер игра (в случае овервотча — тимплей матч 6х6), где динамических объектов в зоне видимости пользователя значительно меньше.
Понятие «старый компьютер» тоже довольно относительное. У меня игровой комп собирался 3 года назад в «хорошей» (но не топовой) комплектации. Сейчас это железо, с точки зрения игр, старое. Вы считаете это нормальным? Я — нет.
Я говорю о том, что отвратительная оптимизация игр фактически не оставляет выбора: если ты хочешь играть на ультра-качестве (т.е. видеть всё, что создал разработчик) и с FPS выше 40 (о стабильных 60 вообще молчу) — будь добр каждые 3 года собирать себе печь с двумя видеокартами и топовым процессором.
А теперь давайте попытаемся ответить себе честно, делает ли за эти три года графика в играх настолько сильный прирост, что бы требовать производительность на 40% выше?
Я вот считаю, что нет.
Мне, лично, кажется что причина значительно проще — в отношении разработчиков к используемым ресурсам. «А, да ладно, докупят ещё одну видяху, есличо».
У меня, лично, складывается ощущение, что этого всего разработчики не знают.
Эстимейты устанавливает команда. Thats all, folks.
Если кто-то не может сказать менеджеру «Сорян, друг, но нет» — это уже его проблемы.
По мне проще и удобнее трекать время на плановые задачи, чем оценивать неплановые постфактум в сторипоинтах.
По поводу включения\выключения из спринта — мне в этом плане вообще ближе всего канбан доска, с бэклогом задач в порядке приоритетов и весьма условным понятием спринта как периода некоторых командных активити.
Это значительно упрощает всем жизнь, на мой взгляд.
В рамках жестких спринтов и чёткого скрама — да, такие задачи надо включать в спринт, а что-то из него выкидывать. Когда их оценивать — заранее или постфактум — тоже открытый вопрос.
В общем, зависит от команды, продукта и множество факторов, надо смотреть и адаптировать под свои реалии. Серебряной пули, как и везде, нет.
Я нет. Более того, я склоняюсь к тому, что при планировании стоит брать максимальную из незавышенных искусственно оценок.
Я предлагаю стараться заранее закладывать буффер на такие задачи, что бы уменьшить стрессовость всплывающих задач.
Работает и тот, и другой вариант. Я пробовал оба, мне проще трекать время, хотя у меня, как QA, значительно ежедневных больше задач, чем у разработчика.
Плюс, пара знакомых которые так же вполне успешно и счастливо работают по довольно каноничному scrum, без всего перечисленного в вашей статье.
Ну, если можно, то развернуто и по пунктам. При этом постарайтесь, пожалуйста, абстрагироваться от сферического вотерфолл в вакууме, когда «мне просто дали идеально проработанное тз на 500 страниц, а я написал код, который идеально работает», а всё таки придти к жизненным реалиям, из-за которых аджайл придумали — заказчик сам не знает, чего хочет, требования меняются, продукт должен развиваться динамично, и вот это всё.
Ну, и я не очень понимаю, как менеджеру может быть удобен аджайл, учитывая что аджайл лишает менеджеров власти, всяческих лавров, а в некоторых случаях и работы вообще.