Скрам - это одна из аджайл методик, которых довольно много. Скрам, Канбан, Скрамбан и т.д. А то, что он вырос в карго-культ (как вы абсолютно верно написали), как раз и является причиной всех мучений автора статьи.
Когда в руках молоток, весь мир состоит из гвоздей. К сожалению Скрам воспринимается многими как тот самый молоток. Если к этому еще добавить типовое понимание Скрам по принципу "Там есть спринты и оценка эффективности. Любая задача должна быть завершена за один спринт", то на выходе получаем адскую жесть, после которой люди начинают шарахаться от слова Скрам как черт от ладана. Если же к этому добавить, что найти нормального Скрам-мастера еще сложнее чем нормального менеджера проектов, то результат отношения людей к подобной псевдо-Скрам организации процесса абсолютно предсказуем. Знаю пару особо упоротых случаев, когда дэйлики использовались начальством для штрафов и наказаний. Ведь как удобно, когда народ сам говорит о проблемах: не надо даже искать кого наказывать. Т.е. некий Вася сказал на дейлике, что у него по таким-то причинам затормозилась разработка и все будет реализовано с задержкой в сколько-то дней. Васю немедленно карают, т.к. он по мнению начальства плохо работает. Что в результате думает о Скрам Вася, можно описывать только ненормативной лексикой.
А что же скрам, пора отправить его на свалку? Вовсе нет, есть сферы, где он отлично работает. Там, где задачи легки в оценке, а количество неизвестного и нового довольно низко - например, проекты поддержки и сопровождения.
Простите, но вышенаписанное абсолютно неверно. Скрам создан как противовес водопадной разработке и нужен в первую очередь как раз для задач, когда мы (или заказчики) сами точно не представляем, что именно хотим получить. Когда требования и планы могут меняться каждый месяц. Когда сам заказчик сначала говорит сделать "А", а потом через пару недель приходит и говорит, что они опробовали "А", и лучше переделать его в "Б". Или когда у нас есть 100500 теоретически требуемых фич, а порядок их реализации (и нужна ли реализация вообще) определяется по факту их реального использования в поле. Легкость или сложность оценки задач при этом вообще не важна. Описанное вами является не Скрамом, а, к сожалению, очень типовым случаем, который представляет собой водопадную разработку, завернутую в псевдо-Скрам. В вашем сценарии не имеет никакого значения, будет задача реализована за 2 спринта, или за один, т.к. конечная цель неизменна: реализовать заранее определенный заданный функционал. В такой ситуации Скрам вообще не нужен, т.к. если у нас нет изменений требований в процессе разработки, то нам не требуется Скрам. Если я буду писать софт для управления ядерным реактором, то использовать там Скрам не имеет никакого смысла, т.к. все требования к его функционалу жесточайшим образом уже прописаны на 100500 листах документации, и никаких отклонений изначально не планируется и не допускается. А вот если я буду разрабатывать игру, то Скрам там зайдет просто идеально, т.к. изменение требований может происходить чуть ли не каждую неделю, и ни разработчики, ни сама целевая аудитория заранее не могут 100% быть уверены, что понравится, а что нет.
Не совсем понятно, что имеется в виду под "в рамках старой "изначально выбранной парадигмы", если всё впишется в неё ". Вот, например, раньше в С++ не было default в классах, а потом он появился. Можно его можно использовать, если код написан до того, как эта фича стала поддерживаться? Лямбд раньше не было, а потом появились. Можно их использовать, если весь код усеян std::bind1st, std::std::bind2nd ? Аналогично с auto и вообще со всеми остальными фичами, реализованными в C++ после выхода самой первой версии языка.
Именно так. Я даже больше скажу. 5 лет - не так уж и много. У нас в кампании есть С / С++ проект, который стартовал в 1995 году. Разумеется, с тех пор там многое переписано, но есть и немало кода из 90-х годов, т.к. он полностью рабочий и его ни разу не требовалось менять. При этом новые части, разумеется, пишутся с использованием фич из самой свежей версии С++. И что в таком случае предлагает делать автор? Переписать почти весь проект, чтобы он соответствовал последнему стандарту С++ ? Переписать не потому, что там баги, не потому что там спагетти, которое невозможно поддерживать, и т.п., а просто, чтобы все было на С++ 20 ? А с выходом С++ 23 снова все переписать, чтобы была возможность использовать фичи из нового стандарта? И делать так с каждым релизом С++? Внутренний голос говорит мне, что это, ну очень мягко говоря, не самая хорошая идея :)
Циклическая ссылка первый объект ссылается на второй, а 2-й на первый. В результате они никогда не будут удалены, и получаем утечку памяти. Полная аналогия, когда в C++ 2 shared_ptr указывают друг на друга.
От "Examples of memory safe language include C#" я очень сильно удивился. Дабы далеко не ходить классика жанра с циклическими ссылками
public class Pet{
Dog petName;
}
public class Dog{
Pet petName;
}
class HelloWorld
{
static void Main()
{
Dog tom = new Dog();
System.Console.WriteLine("Hello, World!");
}
}
О, да…. Капчу Яндекса обычный человек пройти вообще не в состоянии. Был у них аккаунт, в который не заходил около года, потом зашел, выдает капчу. Логично. Ввожу. Неверно. Опять ввожу. Опять неверно. Да что ж такое? Позвал еще одного человека, он читает ее точно также, как и я. Все равно неверно. Позвали 3-го, он читает то же самое, что и мы двое. Все равно неверно. Из чисто спортивного интереса пробовали вводить штук 20. Все неверно. Ладно, думаю, м.б. аудио-капча поможет, уж понять, что мне скажут, я точно смогу. Наивный… Понять аудио-капчу Яндекса человек не может принципиально. Боты с фильтрами - те поймут, а человек - никогда. Забил на аккаунт и больше туда не заходил.
Работодатель должен иметь право знать, чем занят сотрудник, но если это влияет на выполнение задачи.
Для этого есть трекеры задач. Не будем забывать, что по факту здесь идет не обсуждение "сотрудника вообще", а ИТ-шников, у которых в первую очередь работа идет в голове, а уже в последнюю в виде стучания клавиатурой. Работодателю нужен сотрудник, который будет 8 часов в день стучать по клавиатуре? Не вопрос, но не надо таких сотрудников путать с ИТ-шниками.
Вопросы "Кем вы себя видите в нашей компании через 5 лет?" и т.п. берутся отнюдь не из ВУЗа. Точнее м.б. вас там именно так учили, но ВУЗ - не первоисточник этих идей и не он их создавал. Первоисточник этих вопросов - FAANG, а остальные просто тупо копируют их практику, совершенно не учитывая разницу между рядовой кампанией и, например, Гугл. Когда вы - Гугл, или аналогичная фирма, куда ломится народ со всей планеты, у вас стоит задача отфильтровать кандидатов. Разумеется, вы фильтруете их по техническим знаниям, опыту, реальным проектам, в которых они принимали участие и т.д. Но тут у вас возникает забавная проблема: даже после таких фильтров подходящих кандидатов слишком много. Вам нужно из уже отфильтрованных претендентов, каждый из которых как минимум на 100% подходит под ваши технические требования, выбрать по каким-то критериям еще более подходящих. И вот здесь начинается область "Кем вы себя видите в нашей компании через 5 лет?", "Почему канализационные люки круглые?", корпоративные ценности т.д. Потому что можно взять хорошего программиста Васю, а можно Петю, который ничуть не хуже Васи, но всю жизнь мечтал у вас работать и м.б. даже работать по совершенно конкретному направлению, которое он четко себе представляет. Но, как здесь было написано в комментариях к какой-то статье другого HR: "Вы - не Гугл". К вам тоже ломятся стада ИТ-шников, и количество кандидатов превышает количество вакансий в несколько раз? Если нет, то м.б. стоит осознать эту печальную истину и не задавать вопросов а-ля "Кем вы видите себя в нашем ООО "Рога и Копыта" через 5 лет?"
Я конечно не претендую на истину потому что могут быть подводные камни.Но от мобилки с разницей в 3-4 года ожидается как минимум снижение техпроцесса чипов, а вследствие чего и более низкое энергопотребление при тех же задачах, что как минимум должно увеличивать время жизни от батареи.
Судя по обзорам, время жизни от одного заряда как было раньше пара дней, так и у современных моделей тоже по-прежнему максимум пара дней. Скорее всего потому что преимущества более тонких техпроцессов съедаются более навороченными камерой, экраном, процессором и т.д. Вот если мой Samsung Galaxy S7 перенести на современный техпроцес без улучшения параметров (т.е. не делать его быстрее и т.д.), тогда скорее всего он покажет увеличение жизни как минимум в два раза.
Плюсом наверно стоит ожидать что при более отзывчивой работе приложений, снижается время при котором нужно держать включенным экран, например что бы что-то быстро загуглить на ходу, быстрее сохранить файл и т.д. что так же должно положительно на это сказываться.
До определенного предела, безусловно, но с некоторого момента это ускорение уже просто незаметно. Будет ли у меня гугление занимать на 2 - 3 секунды меньше, или нет, для меня уже никакой разницы не играет
Почему экстрим? Смотря, как используется смартфон. Samsung Galaxy S7, купленный в 2017, по-прежнему отлично работает, и менять его не собираюсь. В игры на нем не играю, камера только для чисто утилитарных целей (поиск по фото, ценники и т.п.), а сам смарт используется как справочник + органайзер. При таких потребностях смысла в чем-то более быстром, качественной камере и т.п. я абсолютно не вижу.
Да и BoundsChecker хотя в теории предназначался для мониторинга производительности, по факту использовался совсем в другой области и для других целей :)
Вы смешиваете два разных аспекта "марсианской деревни": технический и человеческий. Для вас, насколько я понимаю, интереснее технический аспект: замкнутый цикл по жизнеобеспечению, строительство базы и восполнение топлива из местных материалов и т.д. А изоляционные эксперименты (официально они - космические изоляционные эксперименты) - это в первую очередь про людей. Что происходит с психикой человека при настолько долгом пребывании в ограниченном пространстве и коллективе? Что происходит с психикой человека при задержках с ответами от базы? Как это влияет на физическое здоровье? Как это влияет на работоспособность? Что можно / нужно предпринять, чтобы нивелировать эти эффекты? И т.д. Хотя иногда сюда незапланированно приходят и чисто технические моменты. Например, Биосфера 2 не удалась по чисто техническим причинам - неправильно рассчитали ресурс системы жизнеобеспечения.
Есть как успешно завершенные, так и неудачные эксперименты такого плана. Из успешных, например, "Марс 500". Вот его сайт, там есть краткое (надо признать, ну очень краткое) описание того, что именно изучалось. Сайт несколько кривой, поэтому список доступен только при выборе из меню слева "520-суточная изоляция\Эксперименты" http://mars500.imbp.ru/
Очередное прозрение очередного недо-миддла, который просветлился истиной, что прибитый гвоздями хардкод в задании на сотню-другую строк - вершина эволюции. Сразу вспомнился отличный пример здесь на хабре полностью аналогичный вышеописанному. https://habr.com/ru/articles/153225/
А потом "внезапно" оказалось, что это - не полимиорфизм и прочие паттерны такие ужасные и сложные, а просто автор не умел ими пользоваться. https://stdray.livejournal.com/74041.html
Я привел его в цитате. Вот цитата еще раз. Вам не нравится и кажется диким. Вопрос, почему вам кажется диким именно это, а не, например, весь русский язык после реформы 1918 года, вы упорно игнорируете. Мыслию по древу я не растекаюсь, а всего лишь комментирую ваши то, что написали вы. Если бы вы не начали писать про то, почему меняется язык, я бы не начал комментировать ваши мысли эту тему.
А то, что "дорожная карта" выглядит весьма дико на фоне десятилетиями употреблявшихся "план действий"/"план развития", употребителей этой самой "дорожной карты" не волнует.
"Scrum is an agile project management framework"
https://www.atlassian.com/agile/scrum
Скрам - это одна из аджайл методик, которых довольно много. Скрам, Канбан, Скрамбан и т.д. А то, что он вырос в карго-культ (как вы абсолютно верно написали), как раз и является причиной всех мучений автора статьи.
Когда в руках молоток, весь мир состоит из гвоздей. К сожалению Скрам воспринимается многими как тот самый молоток. Если к этому еще добавить типовое понимание Скрам по принципу "Там есть спринты и оценка эффективности. Любая задача должна быть завершена за один спринт", то на выходе получаем адскую жесть, после которой люди начинают шарахаться от слова Скрам как черт от ладана. Если же к этому добавить, что найти нормального Скрам-мастера еще сложнее чем нормального менеджера проектов, то результат отношения людей к подобной псевдо-Скрам организации процесса абсолютно предсказуем.
Знаю пару особо упоротых случаев, когда дэйлики использовались начальством для штрафов и наказаний. Ведь как удобно, когда народ сам говорит о проблемах: не надо даже искать кого наказывать. Т.е. некий Вася сказал на дейлике, что у него по таким-то причинам затормозилась разработка и все будет реализовано с задержкой в сколько-то дней. Васю немедленно карают, т.к. он по мнению начальства плохо работает. Что в результате думает о Скрам Вася, можно описывать только ненормативной лексикой.
Простите, но вышенаписанное абсолютно неверно. Скрам создан как противовес водопадной разработке и нужен в первую очередь как раз для задач, когда мы (или заказчики) сами точно не представляем, что именно хотим получить. Когда требования и планы могут меняться каждый месяц. Когда сам заказчик сначала говорит сделать "А", а потом через пару недель приходит и говорит, что они опробовали "А", и лучше переделать его в "Б". Или когда у нас есть 100500 теоретически требуемых фич, а порядок их реализации (и нужна ли реализация вообще) определяется по факту их реального использования в поле. Легкость или сложность оценки задач при этом вообще не важна. Описанное вами является не Скрамом, а, к сожалению, очень типовым случаем, который представляет собой водопадную разработку, завернутую в псевдо-Скрам. В вашем сценарии не имеет никакого значения, будет задача реализована за 2 спринта, или за один, т.к. конечная цель неизменна: реализовать заранее определенный заданный функционал. В такой ситуации Скрам вообще не нужен, т.к. если у нас нет изменений требований в процессе разработки, то нам не требуется Скрам. Если я буду писать софт для управления ядерным реактором, то использовать там Скрам не имеет никакого смысла, т.к. все требования к его функционалу жесточайшим образом уже прописаны на 100500 листах документации, и никаких отклонений изначально не планируется и не допускается. А вот если я буду разрабатывать игру, то Скрам там зайдет просто идеально, т.к. изменение требований может происходить чуть ли не каждую неделю, и ни разработчики, ни сама целевая аудитория заранее не могут 100% быть уверены, что понравится, а что нет.
Не совсем понятно, что имеется в виду под "в рамках старой "изначально выбранной парадигмы", если всё впишется в неё ". Вот, например, раньше в С++ не было default в классах, а потом он появился. Можно его можно использовать, если код написан до того, как эта фича стала поддерживаться? Лямбд раньше не было, а потом появились. Можно их использовать, если весь код усеян std::bind1st, std::std::bind2nd ? Аналогично с auto и вообще со всеми остальными фичами, реализованными в C++ после выхода самой первой версии языка.
Именно так. Я даже больше скажу. 5 лет - не так уж и много. У нас в кампании есть С / С++ проект, который стартовал в 1995 году. Разумеется, с тех пор там многое переписано, но есть и немало кода из 90-х годов, т.к. он полностью рабочий и его ни разу не требовалось менять. При этом новые части, разумеется, пишутся с использованием фич из самой свежей версии С++. И что в таком случае предлагает делать автор? Переписать почти весь проект, чтобы он соответствовал последнему стандарту С++ ? Переписать не потому, что там баги, не потому что там спагетти, которое невозможно поддерживать, и т.п., а просто, чтобы все было на С++ 20 ? А с выходом С++ 23 снова все переписать, чтобы была возможность использовать фичи из нового стандарта? И делать так с каждым релизом С++? Внутренний голос говорит мне, что это, ну очень мягко говоря, не самая хорошая идея :)
Меня тут ниже абсолютно верно поправили, что GC прекрасно умеет такое обрабатывать. Извиняюсь за неверную информацию.
Извиняюсь, за ложную информацию. Вы, правы, а - нет. У меня какие-то давние воспоминания, что он такое обрабатывать не умеет.
https://stackoverflow.com/questions/8840567/garbage-collector-and-circular-reference
Циклическая ссылка первый объект ссылается на второй, а 2-й на первый. В результате они никогда не будут удалены, и получаем утечку памяти. Полная аналогия, когда в C++ 2 shared_ptr указывают друг на друга.
От "Examples of memory safe language include C#" я очень сильно удивился. Дабы далеко не ходить классика жанра с циклическими ссылками
О, да…. Капчу Яндекса обычный человек пройти вообще не в состоянии. Был у них аккаунт, в который не заходил около года, потом зашел, выдает капчу. Логично. Ввожу. Неверно. Опять ввожу. Опять неверно. Да что ж такое? Позвал еще одного человека, он читает ее точно также, как и я. Все равно неверно. Позвали 3-го, он читает то же самое, что и мы двое. Все равно неверно. Из чисто спортивного интереса пробовали вводить штук 20. Все неверно. Ладно, думаю, м.б. аудио-капча поможет, уж понять, что мне скажут, я точно смогу. Наивный… Понять аудио-капчу Яндекса человек не может принципиально. Боты с фильтрами - те поймут, а человек - никогда. Забил на аккаунт и больше туда не заходил.
Для этого есть трекеры задач. Не будем забывать, что по факту здесь идет не обсуждение "сотрудника вообще", а ИТ-шников, у которых в первую очередь работа идет в голове, а уже в последнюю в виде стучания клавиатурой. Работодателю нужен сотрудник, который будет 8 часов в день стучать по клавиатуре? Не вопрос, но не надо таких сотрудников путать с ИТ-шниками.
Во времена MS-DOS каждый уважающий себя программист был обязан написать свою оконную библиотеку :)
Вопросы "Кем вы себя видите в нашей компании через 5 лет?" и т.п. берутся отнюдь не из ВУЗа. Точнее м.б. вас там именно так учили, но ВУЗ - не первоисточник этих идей и не он их создавал. Первоисточник этих вопросов - FAANG, а остальные просто тупо копируют их практику, совершенно не учитывая разницу между рядовой кампанией и, например, Гугл. Когда вы - Гугл, или аналогичная фирма, куда ломится народ со всей планеты, у вас стоит задача отфильтровать кандидатов. Разумеется, вы фильтруете их по техническим знаниям, опыту, реальным проектам, в которых они принимали участие и т.д. Но тут у вас возникает забавная проблема: даже после таких фильтров подходящих кандидатов слишком много. Вам нужно из уже отфильтрованных претендентов, каждый из которых как минимум на 100% подходит под ваши технические требования, выбрать по каким-то критериям еще более подходящих. И вот здесь начинается область "Кем вы себя видите в нашей компании через 5 лет?", "Почему канализационные люки круглые?", корпоративные ценности т.д. Потому что можно взять хорошего программиста Васю, а можно Петю, который ничуть не хуже Васи, но всю жизнь мечтал у вас работать и м.б. даже работать по совершенно конкретному направлению, которое он четко себе представляет. Но, как здесь было написано в комментариях к какой-то статье другого HR: "Вы - не Гугл". К вам тоже ломятся стада ИТ-шников, и количество кандидатов превышает количество вакансий в несколько раз? Если нет, то м.б. стоит осознать эту печальную истину и не задавать вопросов а-ля "Кем вы видите себя в нашем ООО "Рога и Копыта" через 5 лет?"
Судя по обзорам, время жизни от одного заряда как было раньше пара дней, так и у современных моделей тоже по-прежнему максимум пара дней. Скорее всего потому что преимущества более тонких техпроцессов съедаются более навороченными камерой, экраном, процессором и т.д. Вот если мой Samsung Galaxy S7 перенести на современный техпроцес без улучшения параметров (т.е. не делать его быстрее и т.д.), тогда скорее всего он покажет увеличение жизни как минимум в два раза.
До определенного предела, безусловно, но с некоторого момента это ускорение уже просто незаметно. Будет ли у меня гугление занимать на 2 - 3 секунды меньше, или нет, для меня уже никакой разницы не играет
Почему экстрим? Смотря, как используется смартфон. Samsung Galaxy S7, купленный в 2017, по-прежнему отлично работает, и менять его не собираюсь. В игры на нем не играю, камера только для чисто утилитарных целей (поиск по фото, ценники и т.п.), а сам смарт используется как справочник + органайзер. При таких потребностях смысла в чем-то более быстром, качественной камере и т.п. я абсолютно не вижу.
Да и BoundsChecker хотя в теории предназначался для мониторинга производительности, по факту использовался совсем в другой области и для других целей :)
Вы смешиваете два разных аспекта "марсианской деревни": технический и человеческий. Для вас, насколько я понимаю, интереснее технический аспект: замкнутый цикл по жизнеобеспечению, строительство базы и восполнение топлива из местных материалов и т.д. А изоляционные эксперименты (официально они - космические изоляционные эксперименты) - это в первую очередь про людей. Что происходит с психикой человека при настолько долгом пребывании в ограниченном пространстве и коллективе? Что происходит с психикой человека при задержках с ответами от базы? Как это влияет на физическое здоровье? Как это влияет на работоспособность? Что можно / нужно предпринять, чтобы нивелировать эти эффекты? И т.д. Хотя иногда сюда незапланированно приходят и чисто технические моменты. Например, Биосфера 2 не удалась по чисто техническим причинам - неправильно рассчитали ресурс системы жизнеобеспечения.
Есть как успешно завершенные, так и неудачные эксперименты такого плана. Из успешных, например, "Марс 500". Вот его сайт, там есть краткое (надо признать, ну очень краткое) описание того, что именно изучалось. Сайт несколько кривой, поэтому список доступен только при выборе из меню слева "520-суточная изоляция\Эксперименты"
http://mars500.imbp.ru/
Из неспешных, например "Биосфера 2". Вот его сайт в архиве. Оригинала почему-то уже нет
https://web.archive.org/web/20061220012010/http://www.bio2.com/
Очередное прозрение очередного недо-миддла, который просветлился истиной, что прибитый гвоздями хардкод в задании на сотню-другую строк - вершина эволюции. Сразу вспомнился отличный пример здесь на хабре полностью аналогичный вышеописанному.
https://habr.com/ru/articles/153225/
А потом "внезапно" оказалось, что это - не полимиорфизм и прочие паттерны такие ужасные и сложные, а просто автор не умел ими пользоваться.
https://stdray.livejournal.com/74041.html
Я привел его в цитате. Вот цитата еще раз. Вам не нравится и кажется диким. Вопрос, почему вам кажется диким именно это, а не, например, весь русский язык после реформы 1918 года, вы упорно игнорируете.
Мыслию по древу я не растекаюсь, а всего лишь комментирую ваши то, что написали вы. Если бы вы не начали писать про то, почему меняется язык, я бы не начал комментировать ваши мысли эту тему.