Коснусь всё же недочётов модели. В некоторых режимах ПП происходит вот какой интересный эффект.
У отдельного программиста ресурс внимания, "рабочая память", имеет достаточно ограниченный объём, и в рамках одиночной работы в эту ограниченную память приходится по очереди загружать разные аспекты задачи. Частое переключение между разными аспектами (например, между низкоуровневым кодом и общей архитектурой, или между требованиями и ограничениями) приводит к когнитивной нагрузке и замедляет работу.
А вот если над кодом работают два человека, то они могут разделить эту нагрузку на двоих. Например, в режиме "водитель+навигатор" один человек ("водитель") фокусируется на решении текущего шага задачи, а второй ("навигатор") тем временем планирует следующий шаг и следит, чтобы решение в целом вписывалось в требование. Как результат, у каждого участника нагрузка становится меньше, переключений становится меньше, и работа делается быстрее и качественнее.
Т.е., сам подход "у разных людей разные скиллы", безусловно, правильный, но далеко не полный. Излишняя простота модели может приводить к появлению иллюзии того, что всё остальное несущественно. Типа: на локальных масштабах поверхность земли кажется плоской, так давайте и глобально считать Землю плоской. Модель же проста как пять копеек!
Менеждеры как от огня, зажмурившись, шарахаются от ПП, а если присмотреться, то потенциально оно может быть целесообразно с точки зрения временных затрат при некоторых условиях. Каких - вопрос для отдельного изучения.
Боюсь, что ни в каких условиях, покуда менеджеры рассуждают в "ресурсной парадигме". Им и так-то сложно со всеми этими "хэдкаунтами", "степенью загрузки" и "человекочасами", а Вы тут со своей синергией лезете. Мой опыт показывает, что до большинства даже не доходят базовые выводы из теории массового обслуживания, а-ля "если систему нагружать под максимум, то задержки улетают в небеса". Во главу угла ставится принцип "во что бы то ни стало нагрузить каждого", иначе, якобы, люди будут зря зарплату получать. А когда получаем задержки, то надо просить больше людей. Какое тут ещё ПП, ну?
Впрочем, и Амундсен, и Шеклтон также умерли в последующих полярных экспедициях. Все работали на износ. Во многом, наша оценка зависит от того, как именно подходить к оценке "успешности" и "правильности".
Возможно, Амундсен и отвечал за организацию в их тандеме.
Амундсен, вообще-то, был его конкурентом. В гонке до Южного Полюса его команда обогнала команду Скотта на несколько дней. Считается, что это послужило одной из причин гибели Скотта с командой на обратном пути (разочарование от проигрыша, в дополнение к стратегическим просчётам).
Боюсь, что игнорирование Амундсена англоязычными авторами объясняется, в первую очередь, тем, что он был норвежцем - т.е., "чужаком" для бритишей.
Шеклтона я бы всё же поставил выше Скотта. Да, он чуток не дошёл до Полюса, но хотя бы сберёг себя и людей. Именно его решения как руководителя в экстремальных условиях высоко оценивались современниками.
Это я всё к тому, что общепринятого определения ООП у сообщества нет. Каждый понимает его по-своему.
Есть ли в мире хотя бы одна вещь, которую все определяют и понимают одинаковым образом? Не думаю. Почему же тогда Вы считаете, что ООП чем-то выделяется на общем фоне?
Инструмент, конечно, перспективный. Но довольно грустно, когда буквально при первом же "нестандартном" способе использования спотыкаешься о баги типа этого. Даже года на это не понадобилось - скорее, буквально пара дней. Дорабатывать и дорабатывать ещё надо.
Кому-то понятно, а кому-то и нет. Не так уж редко встречаю людей, которые такой подход ни разу не пробовали. Сражаются с симптомами, а системно порешать проблемы не могут.
Впрочем, если мы говорим о технических спорах, то в них редко бывает одна единственно верная "правда". Ни одно решение не идеально и несёт свои риски и негативные стороны. В таких случаях долгие и упорные споры вредят. Нередко бывает полезнее временно согласиться на не-идеальное, но рабочее и понятное коллегам решение, чем упорно топить за свою "правду" и не получать никакого результата.
Более того, в сложных окружениях задачи вообще ведут себя фрактальным образом: любой шажок, который изначально казался совсем маленьким и простым, может резко вырасти в размерах и стать едва ли не больше изначальной оценки всей задачи. А потом ещё один шажок, и другой...
Не все подводные камни удаётся находить заранее, хотя в целом практика очень полезная.
Коснусь всё же недочётов модели. В некоторых режимах ПП происходит вот какой интересный эффект.
У отдельного программиста ресурс внимания, "рабочая память", имеет достаточно ограниченный объём, и в рамках одиночной работы в эту ограниченную память приходится по очереди загружать разные аспекты задачи. Частое переключение между разными аспектами (например, между низкоуровневым кодом и общей архитектурой, или между требованиями и ограничениями) приводит к когнитивной нагрузке и замедляет работу.
А вот если над кодом работают два человека, то они могут разделить эту нагрузку на двоих. Например, в режиме "водитель+навигатор" один человек ("водитель") фокусируется на решении текущего шага задачи, а второй ("навигатор") тем временем планирует следующий шаг и следит, чтобы решение в целом вписывалось в требование. Как результат, у каждого участника нагрузка становится меньше, переключений становится меньше, и работа делается быстрее и качественнее.
Т.е., сам подход "у разных людей разные скиллы", безусловно, правильный, но далеко не полный. Излишняя простота модели может приводить к появлению иллюзии того, что всё остальное несущественно. Типа: на локальных масштабах поверхность земли кажется плоской, так давайте и глобально считать Землю плоской. Модель же проста как пять копеек!
Боюсь, что ни в каких условиях, покуда менеджеры рассуждают в "ресурсной парадигме". Им и так-то сложно со всеми этими "хэдкаунтами", "степенью загрузки" и "человекочасами", а Вы тут со своей синергией лезете. Мой опыт показывает, что до большинства даже не доходят базовые выводы из теории массового обслуживания, а-ля "если систему нагружать под максимум, то задержки улетают в небеса". Во главу угла ставится принцип "во что бы то ни стало нагрузить каждого", иначе, якобы, люди будут зря зарплату получать. А когда получаем задержки, то надо просить больше людей. Какое тут ещё ПП, ну?
Впрочем, и Амундсен, и Шеклтон также умерли в последующих полярных экспедициях. Все работали на износ. Во многом, наша оценка зависит от того, как именно подходить к оценке "успешности" и "правильности".
Амундсен, вообще-то, был его конкурентом. В гонке до Южного Полюса его команда обогнала команду Скотта на несколько дней. Считается, что это послужило одной из причин гибели Скотта с командой на обратном пути (разочарование от проигрыша, в дополнение к стратегическим просчётам).
Боюсь, что игнорирование Амундсена англоязычными авторами объясняется, в первую очередь, тем, что он был норвежцем - т.е., "чужаком" для бритишей.
Шеклтона я бы всё же поставил выше Скотта. Да, он чуток не дошёл до Полюса, но хотя бы сберёг себя и людей. Именно его решения как руководителя в экстремальных условиях высоко оценивались современниками.
Есть ли в мире хотя бы одна вещь, которую все определяют и понимают одинаковым образом? Не думаю. Почему же тогда Вы считаете, что ООП чем-то выделяется на общем фоне?
Инструмент, конечно, перспективный. Но довольно грустно, когда буквально при первом же "нестандартном" способе использования спотыкаешься о баги типа этого. Даже года на это не понадобилось - скорее, буквально пара дней. Дорабатывать и дорабатывать ещё надо.
1453 тоже нельзя, получается...
Спасибо за статью! Пошёл считать MOSCOW и WSJF для своих двухминутных задач.
Если я правильно понял, то это тупенькая игрушка на базе
term.js(который и выполняет всю основную работу)? В чём вообще смысл такого поделия?Интересно, как он будет справляться с надетой сверху коробкой или выбираться из мусорного бака. Мясные мешки - существа жестокие и изобретательные!
Кому-то понятно, а кому-то и нет. Не так уж редко встречаю людей, которые такой подход ни разу не пробовали. Сражаются с симптомами, а системно порешать проблемы не могут.
Впрочем, если мы говорим о технических спорах, то в них редко бывает одна единственно верная "правда". Ни одно решение не идеально и несёт свои риски и негативные стороны. В таких случаях долгие и упорные споры вредят. Нередко бывает полезнее временно согласиться на не-идеальное, но рабочее и понятное коллегам решение, чем упорно топить за свою "правду" и не получать никакого результата.
Благодарю за признание моих достижений! Я долго к этому шёл /s
Что значит "сбойнёт"? Традиционный японский способ купания подразумевает кипяток по-умолчанию!
Ещё можно порекомендовать не работать на сложных проектах, хах. /s
Более того, в сложных окружениях задачи вообще ведут себя фрактальным образом: любой шажок, который изначально казался совсем маленьким и простым, может резко вырасти в размерах и стать едва ли не больше изначальной оценки всей задачи. А потом ещё один шажок, и другой...
Не все подводные камни удаётся находить заранее, хотя в целом практика очень полезная.
Извините
Школа астартес, штурмовые болтеры. Изи!
Ссылочку на оспариваемую статью хорошо бы добавить
"... не имеющего аналогов в мире (но это не точно)" - судя по комментариям в этой ветке.
Вот теперь уж точно норм заголовок, не придраться! /s