Раз так не делают, наверное, эффект сильно гомеопатический.
В описанном случае вряд ли. У меня тогда машины не было, поэтому глубоко не вникал – но занимался этим весьма грамотный инженер, он снимал характеристики аккумулятора до и после, и получал вполне значимые цифры улучшения.
Почему не покупать аккумулятор в 2 раза реже, не прилагая никаких усилий.
Может быть, потому, что усилий как раз требуется немало, и затраты времени + стоимость оборудования в условиях свободной доступности аккумуляторов за разумные деньги делают все эти телодвижения неоправданными? Повторюсь, в то время аккумулятор нужно было ещё "достать". А сейчас достаточно оплатить замену. Причём и срок службы самих аккумуляторов с тех пор увеличился, это нужно делать реже.
В начале 80х один коллега собрал установку для десульфатации аккумуляторов импульсным током. По-моему, даже изобретение зарегистрировал на неё. Боюсь соврать, но вроде хватало нескольких часов. Тогда (в эпоху дефицита) это имело очевидный смысл. Сейчас – сильно сомневаюсь, проще поменять.
Видимо, где как. Я в качестве ПМ проработал лет 25 – и всегда тимлиды были в моём непосредственном подчинении, я их сам подбирал, сам назначал з/п, потом ставил задачи, контролировал исполнение и т.д. Речь о долгосрочных проектах.
Важно не путать его с проджект-менеджером, менеджером по продажам и другими позициями без подчиненных
С каких пор ПМ – должность без подчинённых? Может, и существуют такие структуры, но мне до сих пор не встречались. В частности, те самые тимлиды в норме и есть подчинённые ПМ.
Самоорганизующаяся команда - это та, что может работать без тимлида, коллективно решая, что и как ей сделать.
Неверные определения неизбежно приводят к неверным выводам. Нигде не прописан запрет на наличие тимлида в самоорганизующейся команде. Просто его роль в ней иная: не надзирательная, а координирующая и/или экспертная.
Вы подменяете понятия. Запланированные групповые обсуждения - это одно
Нет, я как раз о спонтанных. У кого-то возник вопрос, и человек обращается в группу за советом. Совершенно обычная ситуация, и никому это не мешает – наоборот, все в курсе, почему принято именно такое решение.
Сложно представить, даже теоретически, чтобы кто-то в мессенджере стучался, чтобы сообщить решение моей рабочей задачи.
Мне несложно, если несколько человек работают над разными частями одной задачи и в курсе возникающих друг у друга проблем. У меня программисты нередко устраивают вероятно, вообще невообразимую с точки зрения автора вещь: групповые обсуждения в чатах – т.е. отвлекается не один человек, а сразу несколько. И это (сюрприз!) в конечном итоге ведёт к повышению общей эффективности команды. Если же рассматривать программиста как слепого исполнителя, которого ничего не интересует за рамками текущей задачи – то конечно, любые контакты отвлекают. У нас не так.
Ваш сарказм (это ведь был он?) мне не вполне понятен. Подозреваю, что Dr. Milan Milanović, пишущий:
Я работаю с командами разработчиков вот уже десять лет
тоже находится скорее на руководящей позиции – но его экспертность у Вас почему-то сомнений не вызывает. Почему так? У меня опыта заметно побольше – как в качестве программиста, так и руководителя, так что наши мнения как минимум равноценны.
Спольски в книжке «Джоэл о программировании» пишет об этом же
Да мало ли кто о чём пишет – нельзя же всякое печатное слово принимать на веру. В реальности это крайне индивидуально – есть люди, способные к быстрому переключению, и те, кому нужна полная концентрация на текущей задаче. Я вот вполне могу поддерживать до трёх технических чатов одновременно – проверено практически. Правда, сам не программирую уже давно – но тем не менее речь именно об обсуждениях, требующих глубокого погружения в тему.
Понимаете, не люблю, когда с большим апломбом и без малейшего обоснования выдаётся набор якобы универсальных рекомендаций, которым должен следовать каждый. А статья как раз из таких.
Каждое короткое сообщение, которое вы отправляете коллеге в Slack, отнимает у него 23 минуты продуктивной работы
Или наоборот – экономит несколько часов, а то и дней – если содержит решение проблемы, над которой коллега сейчас бьётся. А в общем случае в башке хорошего айтишника обычно стоит ось с поддержкой вытесняющей многозадачности.
Глупо спорить с переводом, но в статье нет ни малейшего обоснования ни исходных данных (ровно 23 минуты и никак иначе, really?), ни рекомендаций, набор голословных утверждений.
В книгах любых нормальных по методологиям пишется "не надо слепо применять описанное. Надо адаптировать под свои задачи/раработу
Так и адаптируем. Разумеется, с сохранением базовых принципов – как то быстрые итерации в тесном контакте с заказчиком. Именно это – основа эджайла, а не разного рода ритуалы – которые могут быть или применимы в конкретном контексте, или нет.
Кейс и правда довольно странный и не вписывается в стандартные процессы, но тем он и интересен. Часто же описывают только идеальные случаи и как должно быть.
Понимаете, при наличии выстроенных стандартных процессов такой кейс попросту невозможен. Особенно если заказчик внутренний и работает по тем же внутренним стандартам.
Вы нам рассказываете о том, что иногда и при скверной организации работы можно выкрутиться, уговорив заказчика – тогда как тут был бы уместен системный анализ организационных ошибок и предложения по их исправлению/недопущению. Тогда статья, возможно, могла бы кому-то помочь.
Любая доработка выполняется по методологии Agile, и пока она дойдет до этапа системного анализа требования могут круто поменяться.
Собственно, эта фраза всё и объясняет: эджайл у вас только по названию. В труЪ эджайле системный анализ есть составная часть планирования изменений, и никак не может выполняться позже самой доработки.
Клавиатуры целы, антидепрессанты не тронуты, заказчик доволен.
Простите, я правильно понял, что заказчик у вас остался доволен отказом сделать необходимые ему изменения в срок? Звучит довольно необычно.
А какое стоп-слово в вашей команде?
Нет никаких стоп-слов, да и не должно быть. Есть (должно быть) совместное планирование спринтов – с учётом как потребностей заказчика, так и возможностей исполнителя. И очень похоже, у вас этот процесс либо отсутствует, либо не настроен должным образом.
Только это все как бы более сложно, возможно подход Kotlin более продвинутый, как бы переработка концепции.
Да честно говоря, мне кажется, что оба в принципе об одном и том же – если их использовать, как изначально задумано.
Котлин появился (и стал популярным), как альтернатива джаве – но в какой-то момент они решили отвязаться от JVM и запилили кучу компиляторов под разные платформы – aka KMP.
Дарт задумывался, как альтернатива JS, но в этом качестве не взлетел – и тогда они решили сделать его универсальным, и опять же напилили кучу компиляторов.
Но поскольку оба – универсальные языки, ничего не знающие о том, где будут запускаться, им понадобилась адаптация к средствам отображения целевых платформ. У котлина это СМР, у дарта – флаттер. Собственно, всё. Дальше вопрос в значительной степени вкусовщины, а возможности там и там примерно те же. Наверное, КМР (по уже обсуждавшимся причинам) несколько ближе к железу, чем дарт – но зато флаттер предлагает побольше, чем чисто гуёвый СМР.
Так что если опустить странные сценарии типа прикручивания мультиплатформенных модулей к уже готовым нативным приложениям, то выбор не совсем очевиден – собственно, поэтому я и влез в тему, было интересно, что движет теми, кто выбрал КМР.
А чел. говорит об обратном - он пишет класс на Kotlin Multiplatform и потом дергает этот класс из Android-Kotlin или iOS-Swift-кода.
Ух. Тогда точно у меня главный вопрос – зачем. Есть нативные аппы для Х платформ, и чтобы расширить их функционал, пишется некий общий модуль на КМР, а потом в них вкорячивается? Звучит крайне экзотично, мне такое и в голову не приходило. Тут ведь не просто
фактически вам нужно знать два языка
Нужно знать Х+1 – ибо вероятно, команды, разрабатывавшие натив тоже никуда не делись. И теперь каждой из них нужно осваивать интеграцию с КМР. А если понадобится внести мелкое изменение в нативный код – что делаем? Переписываем на КМР, потому что политика партии поменялась? В нативе это может быть фикс на пару минут, а переписывание занять недели, если не месяцы. С Андроидом вообще какой-то бред получается – часть кода на чистом Котлине (который там и так вполне родной), часть под зонтиком КМР. Ну или Андроид реализация отличается от всех остальных.
А как СМР ко всему этому пристёгивается? Добавляется к нативным библиотекам? Какое-то месиво получается, никогда бы не пошёл на такое. Ради чего? Ну или я по-прежнему чего-то не понимаю.
Кстати, формально флаттер тоже умеет работать в обе стороны. Но да, это не будет выглядеть, как вызов родного класса/метода – ни в одном направлении. Только с JS можно делать нечто похожее.
Я скорее про случай, когда у тебя есть готовое приложение и тебе из него готового надо дергать флаттер кусочками.
Этого совсем не понял. Пишем новое приложение, прямо на флаттере, где надо, вставляем ffi. Повторюсь – если надо. Можно пример, где это вообще необходимо? Вот реально ни разу не понадобилось, всё решается средствами языка/фреймворка.
Котлин в этом плане синхронен и платформенен - он просто в objC компилится.
И дарт ровно то же делает, компилится в нативный код платформы. Флаттер как таковой тут вообще ни при чём, ffi – фича языка, а не фреймворка. Библиотека dart:ffi
Для понимания – я не пытаюсь тут доказать, что флаттер чем-то лучше котлина, мне реально интересно.
В описанном случае вряд ли. У меня тогда машины не было, поэтому глубоко не вникал – но занимался этим весьма грамотный инженер, он снимал характеристики аккумулятора до и после, и получал вполне значимые цифры улучшения.
Может быть, потому, что усилий как раз требуется немало, и затраты времени + стоимость оборудования в условиях свободной доступности аккумуляторов за разумные деньги делают все эти телодвижения неоправданными? Повторюсь, в то время аккумулятор нужно было ещё "достать". А сейчас достаточно оплатить замену. Причём и срок службы самих аккумуляторов с тех пор увеличился, это нужно делать реже.
В начале 80х один коллега собрал установку для десульфатации аккумуляторов импульсным током. По-моему, даже изобретение зарегистрировал на неё. Боюсь соврать, но вроде хватало нескольких часов. Тогда (в эпоху дефицита) это имело очевидный смысл. Сейчас – сильно сомневаюсь, проще поменять.
Видимо, где как. Я в качестве ПМ проработал лет 25 – и всегда тимлиды были в моём непосредственном подчинении, я их сам подбирал, сам назначал з/п, потом ставил задачи, контролировал исполнение и т.д. Речь о долгосрочных проектах.
В целом толково, но вот с этим я бы поспорил:
С каких пор ПМ – должность без подчинённых? Может, и существуют такие структуры, но мне до сих пор не встречались. В частности, те самые тимлиды в норме и есть подчинённые ПМ.
Неверные определения неизбежно приводят к неверным выводам. Нигде не прописан запрет на наличие тимлида в самоорганизующейся команде. Просто его роль в ней иная: не надзирательная, а координирующая и/или экспертная.
Это банально 😁 А тут можно было бы раскрутить рекламу мамонтомышей и на доходы от продаж профинансировать исследования.
Хвост всё равно голый. Вырастили бы с пушистым – их бы сразу девушки полюбили, был бы бум популярности в качестве домашних любимцев 😁
Нет, я как раз о спонтанных. У кого-то возник вопрос, и человек обращается в группу за советом. Совершенно обычная ситуация, и никому это не мешает – наоборот, все в курсе, почему принято именно такое решение.
Мне несложно, если несколько человек работают над разными частями одной задачи и в курсе возникающих друг у друга проблем. У меня программисты нередко устраивают вероятно, вообще невообразимую с точки зрения автора вещь: групповые обсуждения в чатах – т.е. отвлекается не один человек, а сразу несколько. И это (сюрприз!) в конечном итоге ведёт к повышению общей эффективности команды. Если же рассматривать программиста как слепого исполнителя, которого ничего не интересует за рамками текущей задачи – то конечно, любые контакты отвлекают. У нас не так.
Ваш сарказм (это ведь был он?) мне не вполне понятен. Подозреваю, что Dr. Milan Milanović, пишущий:
тоже находится скорее на руководящей позиции – но его экспертность у Вас почему-то сомнений не вызывает. Почему так? У меня опыта заметно побольше – как в качестве программиста, так и руководителя, так что наши мнения как минимум равноценны.
Листочки – для длинных, уникальных паролей? 😁
Да мало ли кто о чём пишет – нельзя же всякое печатное слово принимать на веру. В реальности это крайне индивидуально – есть люди, способные к быстрому переключению, и те, кому нужна полная концентрация на текущей задаче. Я вот вполне могу поддерживать до трёх технических чатов одновременно – проверено практически. Правда, сам не программирую уже давно – но тем не менее речь именно об обсуждениях, требующих глубокого погружения в тему.
Понимаете, не люблю, когда с большим апломбом и без малейшего обоснования выдаётся набор якобы универсальных рекомендаций, которым должен следовать каждый. А статья как раз из таких.
Или наоборот – экономит несколько часов, а то и дней – если содержит решение проблемы, над которой коллега сейчас бьётся. А в общем случае в башке хорошего айтишника обычно стоит ось с поддержкой вытесняющей многозадачности.
Глупо спорить с переводом, но в статье нет ни малейшего обоснования ни исходных данных (ровно 23 минуты и никак иначе, really?), ни рекомендаций, набор голословных утверждений.
У меня работает, уже 20+ лет как. "Клавиатуры целы, антидепрессанты не тронуты, заказчик доволен. ©" Видимо, тот эджайл, который используете Вы, таки не вполне труЪ.
Так и адаптируем. Разумеется, с сохранением базовых принципов – как то быстрые итерации в тесном контакте с заказчиком. Именно это – основа эджайла, а не разного рода ритуалы – которые могут быть или применимы в конкретном контексте, или нет.
Понимаете, при наличии выстроенных стандартных процессов такой кейс попросту невозможен. Особенно если заказчик внутренний и работает по тем же внутренним стандартам.
Вы нам рассказываете о том, что иногда и при скверной организации работы можно выкрутиться, уговорив заказчика – тогда как тут был бы уместен системный анализ организационных ошибок и предложения по их исправлению/недопущению. Тогда статья, возможно, могла бы кому-то помочь.
Собственно, эта фраза всё и объясняет: эджайл у вас только по названию. В труЪ эджайле системный анализ есть составная часть планирования изменений, и никак не может выполняться позже самой доработки.
Простите, я правильно понял, что заказчик у вас остался доволен отказом сделать необходимые ему изменения в срок? Звучит довольно необычно.
Нет никаких стоп-слов, да и не должно быть. Есть (должно быть) совместное планирование спринтов – с учётом как потребностей заказчика, так и возможностей исполнителя. И очень похоже, у вас этот процесс либо отсутствует, либо не настроен должным образом.
Да честно говоря, мне кажется, что оба в принципе об одном и том же – если их использовать, как изначально задумано.
Котлин появился (и стал популярным), как альтернатива джаве – но в какой-то момент они решили отвязаться от JVM и запилили кучу компиляторов под разные платформы – aka KMP.
Дарт задумывался, как альтернатива JS, но в этом качестве не взлетел – и тогда они решили сделать его универсальным, и опять же напилили кучу компиляторов.
Но поскольку оба – универсальные языки, ничего не знающие о том, где будут запускаться, им понадобилась адаптация к средствам отображения целевых платформ. У котлина это СМР, у дарта – флаттер. Собственно, всё. Дальше вопрос в значительной степени вкусовщины, а возможности там и там примерно те же. Наверное, КМР (по уже обсуждавшимся причинам) несколько ближе к железу, чем дарт – но зато флаттер предлагает побольше, чем чисто гуёвый СМР.
Так что если опустить странные сценарии типа прикручивания мультиплатформенных модулей к уже готовым нативным приложениям, то выбор не совсем очевиден – собственно, поэтому я и влез в тему, было интересно, что движет теми, кто выбрал КМР.
Ух. Тогда точно у меня главный вопрос – зачем. Есть нативные аппы для Х платформ, и чтобы расширить их функционал, пишется некий общий модуль на КМР, а потом в них вкорячивается? Звучит крайне экзотично, мне такое и в голову не приходило. Тут ведь не просто
Нужно знать Х+1 – ибо вероятно, команды, разрабатывавшие натив тоже никуда не делись. И теперь каждой из них нужно осваивать интеграцию с КМР. А если понадобится внести мелкое изменение в нативный код – что делаем? Переписываем на КМР, потому что политика партии поменялась? В нативе это может быть фикс на пару минут, а переписывание занять недели, если не месяцы. С Андроидом вообще какой-то бред получается – часть кода на чистом Котлине (который там и так вполне родной), часть под зонтиком КМР. Ну или Андроид реализация отличается от всех остальных.
А как СМР ко всему этому пристёгивается? Добавляется к нативным библиотекам? Какое-то месиво получается, никогда бы не пошёл на такое. Ради чего? Ну или я по-прежнему чего-то не понимаю.
Кстати, формально флаттер тоже умеет работать в обе стороны. Но да, это не будет выглядеть, как вызов родного класса/метода – ни в одном направлении. Только с JS можно делать нечто похожее.
Готов скорректировать свою позицию: в описанных случаях навык скоропечатания действительно имеет ценность, не поспоришь.
Не я принимал.
Этого совсем не понял. Пишем новое приложение, прямо на флаттере, где надо, вставляем
ffi. Повторюсь – если надо. Можно пример, где это вообще необходимо? Вот реально ни разу не понадобилось, всё решается средствами языка/фреймворка.И дарт ровно то же делает, компилится в нативный код платформы. Флаттер как таковой тут вообще ни при чём,
ffi– фича языка, а не фреймворка. Библиотекаdart:ffiДля понимания – я не пытаюсь тут доказать, что флаттер чем-то лучше котлина, мне реально интересно.