У меня был случай, когда MVP был настолько востребован, что его сразу пустили в боевой прод. Потом, разумеется, всегда не было времени на нормальный дизайн, а количество требуемых фич постоянно росло. Кончилось тем, что в этом кодовом аду не смогли пофиксить ошибку после недели поисков, после чего все-таки было принято решение сделать все по уму. Но не тут-то было... За это время MVP успел обрасти фичами, которые делались по принципу "запили вот это к позавчера", и без какого-либо контроля, насколько эти фичи дополняют друг друга, перекрывают друг друга, или даже вообще друг другу противоречат. При этом заказчики уже во всю пользовались всем спектром функционала. В результате при перезагрузке проекта получилось нечто, что внутри имело хороший дизайн, было поддерживаемо и т.д., и при этом эмулировало наружу весь тот ад, который успел появиться за годы жизни проекта.
Пошлина 20% вообще фигня. Ее кроме вас никто и не заметит
Вот это утверждение полностью ошибочно. Достаточно просто посмотреть на то, что сейчас творится в мире в ответ на инициативы Трампа. Пошлина в 20% означает или сильно урезанную (если вообще существующую) конкурентоспособность или уменьшение прибыли на 20% То, что я писал вам в ответе выше. Разумеется, это заметили все. Вот я сейчас прочёл в новостях, что Ауди заморозила все поставки автомобилей в США, а существующих складских запасов у дилеров там хватит максимум на 2 месяца. Причина именно в этом: или Ауди надо снижать себе прибыль от торговли в США на 20%, или она там станет неконкурентоспособной (как минимум менее конкурентоспособной, а значит просядут продажи) по сравнению с Фордом и остальными американскими производителям.
Добавлю ещё , что в отношении электроники идея независимости нереализуема никак, т.к. цепочка производства очень длинная. В представлении Трампа есть завод, и на нем делают чипы. Если завод в США, то США независимы в области чипов. Но для завода нужны пластины, без них он бесполезен, а это - отдельное производство. Для пластин нужны кристаллы, без них завод пластин бесполезен, а выращивание кристаллов - тоже отдельное производство, и т.д. Короче говоря, цепочка настолько длинная, что реализовать идею электронного чухче просто нереально. И это мы ещё не дошли до оборудования для самих заводов, где та же ASML - верхушка айсберга. Например, им нужны сверхточные линзы. Точность там такая, что на финальной стадии доводки с них сбивают отдельные молекулы. Единственная фирма в мире, которая умеет это делать - немецкая Карл-Цейс, и т.д.
Для некоторых видов продукции с точки зрения независимости и безопасности страны определенный смысл есть. Тут хочу сразу уточнить, что коммерческий смысл и безопасность часто если не строго противоположны, то как минимум не идут в одном направлении. Пример. В современном мире у всех стран есть прямая зависимость от чипов. Все оружие США невозможно произвести без чипов. Чем современнее оружие, тем более навороченная электроника для него нужна. Соответственно, в США появляются мысли: если Китай завтра нападет на Тайвань и пусть даже не захватит его, а как минимум разнесет там заводы, где нам брать чипы, да ещё и в нужном количестве? Помимо электроники есть ещё передовая металлургия, химия, робототехника и т.д. и в отношении них в США ровно те же мысли. И там появляются идеи, которые сейчас выражает Трамп: давайте заставим производить у нас если не все, то хотя бы самое важное (те же чипы, например). Насколько сия идея реализуемая вообще, и тем более насколько она коммерчески осуществима - это очень большой вопрос, но Трамп, похоже, вознамерился ее реализовать любой ценой.
Соответственно, там пошлины (в теории, если верить СМИ и самому Трампу) не только, чтобы заставить перенести производство к себе, но и заставить меньше продавать и больше покупать. Метод (точнее его реализация), выбранный для достижения этих целей, мне лично представляется странным. Это если считать, что Трамп хочет именно этого и именно такими методами, что далеко не факт, т.к. он может все поменять в течении пары часов. Что на самом деле у него в голове, и как он все видит, знает только он и м.б. несколько находящихся рядом с ним людей.
Вот я произвожу продукт за 100 рублей себестоимости и продаю его за 200р. Какая мне разница сколько этот продукт будет стоить в США? Ну ввели пошлины, ну и пусть себе Американцы покупают мой продукт по 200р + их пошлина. Платят же пошлину Американцы? Ведь Американцы? Да?
Все верно, просто вы не сделали следующий шаг. До пошлины ваш товар продавался за 200 рублей, после он стал стоить для американских покупателей, например, 250 рублей. И тут оказывается, что за 200 рублей ваш товар конкурентоспособен, а за 250 - уже нет. И вы встаете перед выбором
оставить ситуацию как есть, мирясь с просевшими продажами из-за того, что ваш товар перестал быть конкурентоспособным
сделать цену на американском рынке 200 рублей, переняв разницу в 50 рублей на себя. Т.е. уменьшив свою прибыль, причем если вы работаете с очень небольшой нормой прибыли, такая большая разница может сделать ваш бизнес принципиально нерентабельным
начать искать пути, каким образом вы можете уменьшить себестоимость своего продукта на 50 рублей (использование более дешевых материалов, найм менее профессиональных сотрудников и т.п.), что вполне может привести к тому, что цену вы удержите, а вот качество продукта уже нет, что опять-таки сделает его неконкурентоспособным на американском рынке за исходную цену в 200 рублей
Я понял в месте, где начались требования к знанию различных версий языка. Кажется это - единственное, что сложно (но наверняка не невозможно) встретить в реальности. В остальном отличный сборник откровений HR на Хабре.
Это все отлично описано ещё у Ричарда Фейнмана в одной из его историй со студентами, где он в конце концов пришел к выводу, что студенты все знали (мгновенно давали определения, писали формулы и т.д.), но при этом ничего не понимали (не могли применить знания на практике даже в простейшей и очевидной ситуации)
Один мой знакомый - очень сильный программист, однажды, готовясь к собеседованию, попросил у меня известную книгу Эль Гамма по паттернам. Когда он ее вернул, у нас состоялся диалог
- Нашёл что-нибудь новое?
- Абсолютно ничего нового. Теперь самое главное - не забыть, как все это называется
eSet это умеет. Я тоже после Outpost долго печалился, что нет вот такого параноика, который на любой чих будет выдавать запрос на разрешение или запрет. Совершенно случайно наткнулся на eSet, который, как оказалось, тоже имеет такой режим
Нормальный код. Ничего особенного. Любой, кто тогда хоть сколько-нибудь серьезно лез в ассемблер, обязательно имел Ralf Brown's Interrupt List, где были тонны недокументированных функций для всех прерываний. В дополнение к нему была еще одна библия по организации памяти MS-DOS, но к сожалению, уже не помню, как она называлась
ИТ-рекрутер в hh.ru Александр Дворник называет такие базовые стоп-факторы. Если брать коммуникационные навыки — сложно формулирует мысли, нелогичный, очень медленный или, наоборот, очень болтлив и перебивает собеседника. Если поведенческие факторы — токсичность, хамство, завышенное самомнение.
Перевод на русский язык: кандидат должен уметь правильно и складно пи..ть. А что он там представляет собой в профессиональном плане - дело десятое.
Если хотите испортить о себе впечатление – откликнитесь на вакансию, которая вам явно не по силам. Даже если с кандидатом могли сложиться отношения в рамках другой ставки, это могут расценить как полное непонимание, чем в принципе предстоит заниматься на работе.
Если хотите, чтобы к вам приходили по специальности, пишите реальные требования, а не 100500% технологий, которые HR нагуглили за 5 минут. Как посмотришь на массу заявок, так там, судя по требованиям, планируется как минимум разработка Гугл номер 2, а на практике оказывается, что менее 10% указанного в списке хватает с головой.
Но потенциал, умение подать себя на собеседовании, настойчивость – это то, что позволяет обходить некоторые формальные преграды.
См. выше про самое важное по мнению HR умение для кандидата: умение правильно пи..ть. А профессиональные навыки… Да какая разница, если человек умеет так хорошо и складно вешать лапшу на уши. Сразу видно, что уж он-то точно подойдет на позицию
Бывает, что изначально нанимающий менеджер ищет кандидата уровнем выше, но на собеседование приходит человек с высоким потенциалом, который может быстро обучиться и благодаря качественному онбордингу быстро выйти на необходимый уровень. В таком случае время, которое может быть потрачено на поиск специалиста заявленного уровня, тратится на онбординг сотрудника — и все остаются в выигрыше
Не подавайтесь на позицию, которая не подходит для вашего опыта! Это "это могут расценить как полное непонимание, чем в принципе предстоит заниматься на работе" (c) Подавайтесь на позицию, которая не подходит для вашего опыта! "Время, которое может быть потрачено на поиск специалиста заявленного уровня, тратится на онбординг сотрудника — и все остаются в выигрыше" (c)
В очередной раз вижу подтверждение, что самое главное при подаче, проскочить HR, чтобы попасть на разговор к техам. Потому что критерии подходящего / неподходящего кандидата в голове у HR определяются фазами Луны, утренним завтраком, вчерашней попойкой, Марсом в доме Меркурия и еще черти знает чем, но только не профессиональным уровнем кандидата.
Теперь я понял, что вы имели в виду. Извиняюсь за непонимание. Да, формально в рамках одного спринта у нас водопад. Т.е. вот эти типовые две недели у нас ведутся с заранее согласованным планом, и если рассматривать их обособленно от всего остального, то мы получим 2-недельный водопад. Тут, конечно, можно начать углубляться в детали, что, например, в Скрам нет заданных ролей (т.н. трансформация Т ролей в Х роли), соответственно, по сравнению с водопадом там, например, нет отдельных тестировщиков для ловли багов и т.д., но в целом, да - вы правы: формально получаем 2 недели водопада.
Чем это концептуально отличается от описанного Вами? "Спринты" в несколько лет вместе двух недель? Долго ждали обратной связи?
В т.ч. и это - принципиальное отличие, о чем я писал в этой ветке выше. Продукт меняется не через 100 лет, когда все уже перестало соответствовать условиям, а прямо сейчас.
Так это, опять же, вопрос масштаба.
Нет. Это - принципиальное отличие. Пока вы в вашем "большом масштабе" через -цать лет отреагируете на изменения, эти самые изменения уже 100 раз успеют поменяться и выша реакция не будет соответствовать текущим реалиям. Весь смысл именно в мгновенной реакции на изменения окружающих условий здесь и сейчас. Поэтому в Скрам явным образом прописано, что 30 дней - максимальный размер спринта, а на практике спринт обычно длится 2 недели, т.к. за месяц можно успеть наворотить массу ненужного https://scrumguides.org/scrum-guide.html#the-sprint
Мне кажется, у нас есть глобальное недопонимание, т.к. некоторые очевидные для меня вещи, для вас неочевидны :) Разумеется, некоторые версии выкатываются в реальный прод после соответствующих тестов на баги. И если по результатам реального прода будет выявлено, что какая-то уже одобренная фича не подходит, то она снова будет изменена. Проект в Скраме не является чем-то застывшим, в.т.ч и уже одобренный функционал. Абсолютно любой функционал может быть изменен в любой момент, если окажется, что он не устраивает заказчика. Это процесс продолжается до тех пор, пока заказчик не будет удовлетворен результатом и / или пока у него есть время и деньги на разработку.
Первое совершенно не требует второго. Вы путаете тестирование в смысле тестирование на наличие багов и тестирование функционала. Под тестированием в Скрам имеется в виду именно функционал, а не ловля багов. Для тестирования функционала совершенно необязательно выкатывать его в прод. Как в Скрам организуется качество разработки (в смысле отлова багов) - это отдельная большая тема
а это где-то описано в "документации, которая есть только у скрам", что длина спринта в первую очередь задаётся необходимой длительностью реальной работы новой версии софта у покупателя?
Не в настолько явном виде. 30 дней прописаны в явном виде, а вот насчет времени для обкатки прописаны в виде "Product Goal". Тут мы опять приходим к тому, что создатели не описывали некоторые очевидные для них вещи. "Product Goal" - заказчик доволен текущей версией продукта. Он доволен, если успел ее обкатать и дать отзыв, что там надо поменять. А для этого ему нужно время и т.д. https://scrumguides.org/scrum-guide.html#the-sprint
Следовательно, если мы не можем гарантировать, что заказчик начнет пользваться новым релизом
немедленно
на реальных или идентичных реальным задачах
то вот и получился критерий "не тот случай"
Именно так. Только под "пользоваться" надо, разумеется, понимать тестовую обкатку с использованием всего реализованного в последнем спринте, а не выкат каждой версии в боевой прод.
Вы на 100% ошибаетесь, когда понимаете Скрам как "серия коротких (длиною в спринт) вотерфолов "
К сожалению 99% "внедрятелей Скрама" именно так его и понимают + дэйлики, которые часто длятся по часу каждый день, где внезапно могут начать решать любые проблемы и т.д. В результате народ совершенно справедливо шарахается от Скрам как черт от ладана.
Проблема на мой взгляд состоит в том, что есть два основных ресурса, связанных со Скрам, которые отвечают на вопрос "как", но абсолютно игнорируют вопросы "в каких случаях?" и "зачем?"
Игнорируют они эти вопросы потому, что авторы этих методик прекрасно себе представляли, для решения каких конкретных проблем они создаются, и совершенно не рассчитывали на то, что успех данного подхода в его конкретной нише приведет к настоящему карго-культу, когда Скрам пихают везде и всюду, при этом не имея ни малейшего представления, как он на самом деле должен быть организован, и зачем он нужен. Дополнительных проблем добавляет то, что другие аджайл методики, не документированы практически никак. Т.е. есть те, кто в теме, и знают, как и когда ими пользоваться, но эти знания передаются исключительно коллегам во время работы. Ресурсов а-ля как для Скрам для них нет, есть только множество статей на разных сайтах различной степени детальности. Между тем имеется целая охапка только наиболее популярных базовых аджайл методик: Scrum, Kanban, Scrumban, Feature-Driven Development (FDD), Extreme Programming (XP)б Dynamic Systems Development Method (DSDM), и еще масса менее известных. Теперь конкретно про Скрам и ваше заблуждение. Я, разумеется, не могу тут пересказывать всю документацию, но это и не надо. Основной проблемой, которую решает Скрам, является разработка с заданием "Сделай то, не знаю что". Заказчик представляет, что он хочет, в самых общих чертах (хочу программу торговли на бирже, хочу шутер и т.п.), т.к. не имеет опыта, не знает, что понравится его аудитории, как будет работать его персонал, какие конкретно процессы появятся во время и т.д. и т.п. Как эту проблему решает Скрам (очень короткое и поверхностное описание). Мы пилим очень небольшой функционал в течении короткого времени (тот самый спринт) и сразу отдаем его заказчику на обкатку. Заказчик играется с полученной версией и дает отзыв в виде обратной связи, что и как надо поменять, а команда немедленно (уже в следующем спринте) реагирует на этот отзыв. Т.е. имеем список а-ля (просто как пример)
Фича A отлично подошла, но там есть пара багов. Вот баг-репорты
Фича B получилась неудобной в использовании, уберите ее. Вместо нее нам срочно нужна фича X, которая ранее была с очень низким приоритетом. С этого момента бросьте все силы на ее разработку, что мы получили фичу X как можно скорее
Фича C в общем неплохая, но там надо поменять вот это и это. Эти изменения важны, но их приоритет ниже чем у фичи X
Понимаете глобальную разницу между отписанным вами "серия коротких (длиною в спринт) вотерфолов" и данным процессом?
Во-первых, если у нас нет нужды менять функционал, и заказчик точно знает, что он хочет получить, что нам не нужен Скрам. Нам необязательно использовать водопад, возможно лучше подойдет другая аджайл техника. Чаще всего это Канбан или Скрамбан (надо смотреть ситуации). Но вот Скрам нам точно не нужен. Более того, даже если мы точно знаем, что функционал будет меняться на ходу, то и здесь Скрам не всегда оптимален. Повторюсь: это конкретный инструмент, созданный для решения конкретной (хотя и достаточно часто встречающейся) проблемы. Если я буду пытаться проделать отверстие в доске при помощи рубанка, это не значит, что рубанок плохой. Это значит, что я - идиот, который использует инструмент не по назначению
Во-вторых нет никакого водопада. Мы не разбиваем один большой отрезок разработки на кучу маленьких, а заказчик видит продукт в самом конце.
В-третьих заказчик принимает участие в разработке наравне с командой. В водопаде мы берем задание и заказчик может идти спать до даты релиза. В Скраме такое в принципе невозможно, т.к. для разработки нужно прямое и постоянное участие заказчика в процессе.
В-четвертых, у нас нет и не может быть сколько-нибудь долгого плана по работе, т.к. никто не знает, что будет разрабатываться даже в следующем спринте, не говоря уже о следующем месяце или квартале. Горизонт планирования - один спринт (обычно 2 недели)
И еще забавный момент. Если спросить "внедрятелей Скрама", какой длины должен быть спринт, то 99% ответов будет: "2 недели". Но если спросить "А почему именно 2 недели? А можно короче или длиннее?", то ответа не будет., т.к. у них нет ни малейшего понимания о вышеописанном процессе. На самом деле ответ очень прост, если знать вышеописанное: по результатам практического использования выяснилось, что 2 недели - наиболее оптимальный срок для заказчика, чтобы обкатать новую функциональность и дать по ней отзыв. Неделя - слишком короткий срок (хотя иногда встречаются проекты, где неделя оптимальна), а 3 недели и тем более 4 - слишком долгий срок без обратной связи, за который можно успеть наворотить массу ненужного заказчику функционала.
Удивительно, но вообще не существует такой методологии, куда RnD вписывается как родной.
Никогда не работал в чистом R&D, поэтому возможно предположу что-то совершенно неправильное. Поправьте меня тогда, пожалуйста, но мне кажется, что Канбан зайдет в R&D на ура. У вас имеются некие задачи. Срок выполнения этих задач очень размытый, и не факт, что каждая вообще может быть выполнена на 100% В то же время имеется ограниченное количество ресурсов (ученых, доступного времени на лабораторных установках и т.д.), поэтому нельзя допустить, чтобы в работе было одновременно 100500 задач, т.к. это будет крайне неэффективно. Соответственно, мы имеем доску задач с колонками:
Общий список задач, над которыми еще не начинали работать, но возможно будут взяты в работу. Количество задач нелимитированно.
Список задач которые решено взять в работу, но работа над ними еще не начата. Количество от нелимитированного, до некоего предела, чтобы не получилось очень большого списка.
Список задач, над которыми ведется работа. Количество жестко лимитировано. Нельзя взять в работу новые задачи, пока не решены предыдущие
Время решения каждой задачи неограниченно. Или ограничено неким приемлемым для всех логическим пределом (нельзя решать одну задачу год, или 10 лет и т.д.) Такая организация не подходит для R&D?
У меня был случай, когда MVP был настолько востребован, что его сразу пустили в боевой прод. Потом, разумеется, всегда не было времени на нормальный дизайн, а количество требуемых фич постоянно росло. Кончилось тем, что в этом кодовом аду не смогли пофиксить ошибку после недели поисков, после чего все-таки было принято решение сделать все по уму. Но не тут-то было... За это время MVP успел обрасти фичами, которые делались по принципу "запили вот это к позавчера", и без какого-либо контроля, насколько эти фичи дополняют друг друга, перекрывают друг друга, или даже вообще друг другу противоречат. При этом заказчики уже во всю пользовались всем спектром функционала. В результате при перезагрузке проекта получилось нечто, что внутри имело хороший дизайн, было поддерживаемо и т.д., и при этом эмулировало наружу весь тот ад, который успел появиться за годы жизни проекта.
Вот это утверждение полностью ошибочно. Достаточно просто посмотреть на то, что сейчас творится в мире в ответ на инициативы Трампа. Пошлина в 20% означает или сильно урезанную (если вообще существующую) конкурентоспособность или уменьшение прибыли на 20% То, что я писал вам в ответе выше. Разумеется, это заметили все. Вот я сейчас прочёл в новостях, что Ауди заморозила все поставки автомобилей в США, а существующих складских запасов у дилеров там хватит максимум на 2 месяца. Причина именно в этом: или Ауди надо снижать себе прибыль от торговли в США на 20%, или она там станет неконкурентоспособной (как минимум менее конкурентоспособной, а значит просядут продажи) по сравнению с Фордом и остальными американскими производителям.
Добавлю ещё , что в отношении электроники идея независимости нереализуема никак, т.к. цепочка производства очень длинная. В представлении Трампа есть завод, и на нем делают чипы. Если завод в США, то США независимы в области чипов. Но для завода нужны пластины, без них он бесполезен, а это - отдельное производство. Для пластин нужны кристаллы, без них завод пластин бесполезен, а выращивание кристаллов - тоже отдельное производство, и т.д. Короче говоря, цепочка настолько длинная, что реализовать идею электронного чухче просто нереально. И это мы ещё не дошли до оборудования для самих заводов, где та же ASML - верхушка айсберга. Например, им нужны сверхточные линзы. Точность там такая, что на финальной стадии доводки с них сбивают отдельные молекулы. Единственная фирма в мире, которая умеет это делать - немецкая Карл-Цейс, и т.д.
Для некоторых видов продукции с точки зрения независимости и безопасности страны определенный смысл есть. Тут хочу сразу уточнить, что коммерческий смысл и безопасность часто если не строго противоположны, то как минимум не идут в одном направлении. Пример. В современном мире у всех стран есть прямая зависимость от чипов. Все оружие США невозможно произвести без чипов. Чем современнее оружие, тем более навороченная электроника для него нужна. Соответственно, в США появляются мысли: если Китай завтра нападет на Тайвань и пусть даже не захватит его, а как минимум разнесет там заводы, где нам брать чипы, да ещё и в нужном количестве? Помимо электроники есть ещё передовая металлургия, химия, робототехника и т.д. и в отношении них в США ровно те же мысли. И там появляются идеи, которые сейчас выражает Трамп: давайте заставим производить у нас если не все, то хотя бы самое важное (те же чипы, например). Насколько сия идея реализуемая вообще, и тем более насколько она коммерчески осуществима - это очень большой вопрос, но Трамп, похоже, вознамерился ее реализовать любой ценой.
Там официально две цели:
Заставить перенести производство обратно к себе
Уменьшить дефицит торгового баланса
Соответственно, там пошлины (в теории, если верить СМИ и самому Трампу) не только, чтобы заставить перенести производство к себе, но и заставить меньше продавать и больше покупать. Метод (точнее его реализация), выбранный для достижения этих целей, мне лично представляется странным. Это если считать, что Трамп хочет именно этого и именно такими методами, что далеко не факт, т.к. он может все поменять в течении пары часов. Что на самом деле у него в голове, и как он все видит, знает только он и м.б. несколько находящихся рядом с ним людей.
Все верно, просто вы не сделали следующий шаг. До пошлины ваш товар продавался за 200 рублей, после он стал стоить для американских покупателей, например, 250 рублей. И тут оказывается, что за 200 рублей ваш товар конкурентоспособен, а за 250 - уже нет. И вы встаете перед выбором
оставить ситуацию как есть, мирясь с просевшими продажами из-за того, что ваш товар перестал быть конкурентоспособным
сделать цену на американском рынке 200 рублей, переняв разницу в 50 рублей на себя. Т.е. уменьшив свою прибыль, причем если вы работаете с очень небольшой нормой прибыли, такая большая разница может сделать ваш бизнес принципиально нерентабельным
начать искать пути, каким образом вы можете уменьшить себестоимость своего продукта на 50 рублей (использование более дешевых материалов, найм менее профессиональных сотрудников и т.п.), что вполне может привести к тому, что цену вы удержите, а вот качество продукта уже нет, что опять-таки сделает его неконкурентоспособным на американском рынке за исходную цену в 200 рублей
Говорят; что если в голом деде быстро нажать SADM , то на экране покажут смешную картинку...
Я понял в месте, где начались требования к знанию различных версий языка. Кажется это - единственное, что сложно (но наверняка не невозможно) встретить в реальности. В остальном отличный сборник откровений HR на Хабре.
Это все отлично описано ещё у Ричарда Фейнмана в одной из его историй со студентами, где он в конце концов пришел к выводу, что студенты все знали (мгновенно давали определения, писали формулы и т.д.), но при этом ничего не понимали (не могли применить знания на практике даже в простейшей и очевидной ситуации)
Один мой знакомый - очень сильный программист, однажды, готовясь к собеседованию, попросил у меня известную книгу Эль Гамма по паттернам. Когда он ее вернул, у нас состоялся диалог
- Нашёл что-нибудь новое?
- Абсолютно ничего нового. Теперь самое главное - не забыть, как все это называется
eSet это умеет. Я тоже после Outpost долго печалился, что нет вот такого параноика, который на любой чих будет выдавать запрос на разрешение или запрет. Совершенно случайно наткнулся на eSet, который, как оказалось, тоже имеет такой режим
Нормальный код. Ничего особенного. Любой, кто тогда хоть сколько-нибудь серьезно лез в ассемблер, обязательно имел Ralf Brown's Interrupt List, где были тонны недокументированных функций для всех прерываний. В дополнение к нему была еще одна библия по организации памяти MS-DOS, но к сожалению, уже не помню, как она называлась
Перевод на русский язык: кандидат должен уметь правильно и складно пи..ть. А что он там представляет собой в профессиональном плане - дело десятое.
Если хотите, чтобы к вам приходили по специальности, пишите реальные требования, а не 100500% технологий, которые HR нагуглили за 5 минут. Как посмотришь на массу заявок, так там, судя по требованиям, планируется как минимум разработка Гугл номер 2, а на практике оказывается, что менее 10% указанного в списке хватает с головой.
См. выше про самое важное по мнению HR умение для кандидата: умение правильно пи..ть. А профессиональные навыки… Да какая разница, если человек умеет так хорошо и складно вешать лапшу на уши. Сразу видно, что уж он-то точно подойдет на позицию
Не подавайтесь на позицию, которая не подходит для вашего опыта! Это "это могут расценить как полное непонимание, чем в принципе предстоит заниматься на работе" (c)
Подавайтесь на позицию, которая не подходит для вашего опыта! "Время, которое может быть потрачено на поиск специалиста заявленного уровня, тратится на онбординг сотрудника — и все остаются в выигрыше" (c)
В очередной раз вижу подтверждение, что самое главное при подаче, проскочить HR, чтобы попасть на разговор к техам. Потому что критерии подходящего / неподходящего кандидата в голове у HR определяются фазами Луны, утренним завтраком, вчерашней попойкой, Марсом в доме Меркурия и еще черти знает чем, но только не профессиональным уровнем кандидата.
Теперь я понял, что вы имели в виду. Извиняюсь за непонимание. Да, формально в рамках одного спринта у нас водопад. Т.е. вот эти типовые две недели у нас ведутся с заранее согласованным планом, и если рассматривать их обособленно от всего остального, то мы получим 2-недельный водопад. Тут, конечно, можно начать углубляться в детали, что, например, в Скрам нет заданных ролей (т.н. трансформация Т ролей в Х роли), соответственно, по сравнению с водопадом там, например, нет отдельных тестировщиков для ловли багов и т.д., но в целом, да - вы правы: формально получаем 2 недели водопада.
В т.ч. и это - принципиальное отличие, о чем я писал в этой ветке выше. Продукт меняется не через 100 лет, когда все уже перестало соответствовать условиям, а прямо сейчас.
Нет. Это - принципиальное отличие. Пока вы в вашем "большом масштабе" через -цать лет отреагируете на изменения, эти самые изменения уже 100 раз успеют поменяться и выша реакция не будет соответствовать текущим реалиям. Весь смысл именно в мгновенной реакции на изменения окружающих условий здесь и сейчас. Поэтому в Скрам явным образом прописано, что 30 дней - максимальный размер спринта, а на практике спринт обычно длится 2 недели, т.к. за месяц можно успеть наворотить массу ненужного
https://scrumguides.org/scrum-guide.html#the-sprint
Мне кажется, у нас есть глобальное недопонимание, т.к. некоторые очевидные для меня вещи, для вас неочевидны :) Разумеется, некоторые версии выкатываются в реальный прод после соответствующих тестов на баги. И если по результатам реального прода будет выявлено, что какая-то уже одобренная фича не подходит, то она снова будет изменена. Проект в Скраме не является чем-то застывшим, в.т.ч и уже одобренный функционал. Абсолютно любой функционал может быть изменен в любой момент, если окажется, что он не устраивает заказчика. Это процесс продолжается до тех пор, пока заказчик не будет удовлетворен результатом и / или пока у него есть время и деньги на разработку.
Первое совершенно не требует второго. Вы путаете тестирование в смысле тестирование на наличие багов и тестирование функционала. Под тестированием в Скрам имеется в виду именно функционал, а не ловля багов. Для тестирования функционала совершенно необязательно выкатывать его в прод. Как в Скрам организуется качество разработки (в смысле отлова багов) - это отдельная большая тема
Не в настолько явном виде. 30 дней прописаны в явном виде, а вот насчет времени для обкатки прописаны в виде "Product Goal". Тут мы опять приходим к тому, что создатели не описывали некоторые очевидные для них вещи. "Product Goal" - заказчик доволен текущей версией продукта. Он доволен, если успел ее обкатать и дать отзыв, что там надо поменять. А для этого ему нужно время и т.д.
https://scrumguides.org/scrum-guide.html#the-sprint
Именно так. Только под "пользоваться" надо, разумеется, понимать тестовую обкатку с использованием всего реализованного в последнем спринте, а не выкат каждой версии в боевой прод.
Могу вас одновременно обрадовать огорчить :)
Вы на 100% ошибаетесь, когда понимаете Скрам как "серия коротких (длиною в спринт) вотерфолов "
К сожалению 99% "внедрятелей Скрама" именно так его и понимают + дэйлики, которые часто длятся по часу каждый день, где внезапно могут начать решать любые проблемы и т.д. В результате народ совершенно справедливо шарахается от Скрам как черт от ладана.
Проблема на мой взгляд состоит в том, что есть два основных ресурса, связанных со Скрам, которые отвечают на вопрос "как", но абсолютно игнорируют вопросы "в каких случаях?" и "зачем?"
Agile Manifesto
https://agilemanifesto.org/iso/ru/manifesto.html
Собственно документация по Скрам
https://www.scrum.org/
Игнорируют они эти вопросы потому, что авторы этих методик прекрасно себе представляли, для решения каких конкретных проблем они создаются, и совершенно не рассчитывали на то, что успех данного подхода в его конкретной нише приведет к настоящему карго-культу, когда Скрам пихают везде и всюду, при этом не имея ни малейшего представления, как он на самом деле должен быть организован, и зачем он нужен.
Дополнительных проблем добавляет то, что другие аджайл методики, не документированы практически никак. Т.е. есть те, кто в теме, и знают, как и когда ими пользоваться, но эти знания передаются исключительно коллегам во время работы. Ресурсов а-ля как для Скрам для них нет, есть только множество статей на разных сайтах различной степени детальности. Между тем имеется целая охапка только наиболее популярных базовых аджайл методик: Scrum, Kanban, Scrumban, Feature-Driven Development (FDD), Extreme Programming (XP)б Dynamic Systems Development Method (DSDM), и еще масса менее известных.
Теперь конкретно про Скрам и ваше заблуждение. Я, разумеется, не могу тут пересказывать всю документацию, но это и не надо. Основной проблемой, которую решает Скрам, является разработка с заданием "Сделай то, не знаю что". Заказчик представляет, что он хочет, в самых общих чертах (хочу программу торговли на бирже, хочу шутер и т.п.), т.к. не имеет опыта, не знает, что понравится его аудитории, как будет работать его персонал, какие конкретно процессы появятся во время и т.д. и т.п. Как эту проблему решает Скрам (очень короткое и поверхностное описание). Мы пилим очень небольшой функционал в течении короткого времени (тот самый спринт) и сразу отдаем его заказчику на обкатку. Заказчик играется с полученной версией и дает отзыв в виде обратной связи, что и как надо поменять, а команда немедленно (уже в следующем спринте) реагирует на этот отзыв. Т.е. имеем список а-ля (просто как пример)
Фича A отлично подошла, но там есть пара багов. Вот баг-репорты
Фича B получилась неудобной в использовании, уберите ее. Вместо нее нам срочно нужна фича X, которая ранее была с очень низким приоритетом. С этого момента бросьте все силы на ее разработку, что мы получили фичу X как можно скорее
Фича C в общем неплохая, но там надо поменять вот это и это. Эти изменения важны, но их приоритет ниже чем у фичи X
Понимаете глобальную разницу между отписанным вами "серия коротких (длиною в спринт) вотерфолов" и данным процессом?
Во-первых, если у нас нет нужды менять функционал, и заказчик точно знает, что он хочет получить, что нам не нужен Скрам. Нам необязательно использовать водопад, возможно лучше подойдет другая аджайл техника. Чаще всего это Канбан или Скрамбан (надо смотреть ситуации). Но вот Скрам нам точно не нужен. Более того, даже если мы точно знаем, что функционал будет меняться на ходу, то и здесь Скрам не всегда оптимален. Повторюсь: это конкретный инструмент, созданный для решения конкретной (хотя и достаточно часто встречающейся) проблемы. Если я буду пытаться проделать отверстие в доске при помощи рубанка, это не значит, что рубанок плохой. Это значит, что я - идиот, который использует инструмент не по назначению
Во-вторых нет никакого водопада. Мы не разбиваем один большой отрезок разработки на кучу маленьких, а заказчик видит продукт в самом конце.
В-третьих заказчик принимает участие в разработке наравне с командой. В водопаде мы берем задание и заказчик может идти спать до даты релиза. В Скраме такое в принципе невозможно, т.к. для разработки нужно прямое и постоянное участие заказчика в процессе.
В-четвертых, у нас нет и не может быть сколько-нибудь долгого плана по работе, т.к. никто не знает, что будет разрабатываться даже в следующем спринте, не говоря уже о следующем месяце или квартале. Горизонт планирования - один спринт (обычно 2 недели)
И еще забавный момент. Если спросить "внедрятелей Скрама", какой длины должен быть спринт, то 99% ответов будет: "2 недели". Но если спросить "А почему именно 2 недели? А можно короче или длиннее?", то ответа не будет., т.к. у них нет ни малейшего понимания о вышеописанном процессе. На самом деле ответ очень прост, если знать вышеописанное: по результатам практического использования выяснилось, что 2 недели - наиболее оптимальный срок для заказчика, чтобы обкатать новую функциональность и дать по ней отзыв. Неделя - слишком короткий срок (хотя иногда встречаются проекты, где неделя оптимальна), а 3 недели и тем более 4 - слишком долгий срок без обратной связи, за который можно успеть наворотить массу ненужного заказчику функционала.
Никогда не работал в чистом R&D, поэтому возможно предположу что-то совершенно неправильное. Поправьте меня тогда, пожалуйста, но мне кажется, что Канбан зайдет в R&D на ура. У вас имеются некие задачи. Срок выполнения этих задач очень размытый, и не факт, что каждая вообще может быть выполнена на 100% В то же время имеется ограниченное количество ресурсов (ученых, доступного времени на лабораторных установках и т.д.), поэтому нельзя допустить, чтобы в работе было одновременно 100500 задач, т.к. это будет крайне неэффективно. Соответственно, мы имеем доску задач с колонками:
Общий список задач, над которыми еще не начинали работать, но возможно будут взяты в работу. Количество задач нелимитированно.
Список задач которые решено взять в работу, но работа над ними еще не начата. Количество от нелимитированного, до некоего предела, чтобы не получилось очень большого списка.
Список задач, над которыми ведется работа. Количество жестко лимитировано. Нельзя взять в работу новые задачи, пока не решены предыдущие
Время решения каждой задачи неограниченно. Или ограничено неким приемлемым для всех логическим пределом (нельзя решать одну задачу год, или 10 лет и т.д.) Такая организация не подходит для R&D?