ИТ-рекрутер в 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?
Скрам - это одна из аджайл методик, которых довольно много. Скрам, Канбан, Скрамбан и т.д. А то, что он вырос в карго-культ (как вы абсолютно верно написали), как раз и является причиной всех мучений автора статьи.
Когда в руках молоток, весь мир состоит из гвоздей. К сожалению Скрам воспринимается многими как тот самый молоток. Если к этому еще добавить типовое понимание Скрам по принципу "Там есть спринты и оценка эффективности. Любая задача должна быть завершена за один спринт", то на выходе получаем адскую жесть, после которой люди начинают шарахаться от слова Скрам как черт от ладана. Если же к этому добавить, что найти нормального Скрам-мастера еще сложнее чем нормального менеджера проектов, то результат отношения людей к подобной псевдо-Скрам организации процесса абсолютно предсказуем. Знаю пару особо упоротых случаев, когда дэйлики использовались начальством для штрафов и наказаний. Ведь как удобно, когда народ сам говорит о проблемах: не надо даже искать кого наказывать. Т.е. некий Вася сказал на дейлике, что у него по таким-то причинам затормозилась разработка и все будет реализовано с задержкой в сколько-то дней. Васю немедленно карают, т.к. он по мнению начальства плохо работает. Что в результате думает о Скрам Вася, можно описывать только ненормативной лексикой.
А что же скрам, пора отправить его на свалку? Вовсе нет, есть сферы, где он отлично работает. Там, где задачи легки в оценке, а количество неизвестного и нового довольно низко - например, проекты поддержки и сопровождения.
Простите, но вышенаписанное абсолютно неверно. Скрам создан как противовес водопадной разработке и нужен в первую очередь как раз для задач, когда мы (или заказчики) сами точно не представляем, что именно хотим получить. Когда требования и планы могут меняться каждый месяц. Когда сам заказчик сначала говорит сделать "А", а потом через пару недель приходит и говорит, что они опробовали "А", и лучше переделать его в "Б". Или когда у нас есть 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 часов в день стучать по клавиатуре? Не вопрос, но не надо таких сотрудников путать с ИТ-шниками.
Перевод на русский язык: кандидат должен уметь правильно и складно пи..ть. А что он там представляет собой в профессиональном плане - дело десятое.
Если хотите, чтобы к вам приходили по специальности, пишите реальные требования, а не 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?
"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 каждый уважающий себя программист был обязан написать свою оконную библиотеку :)