в конце концов они получат никому не нужную CRM систему
Но это будет значить что мы сделали не то что нужно. А это именно тот "былинный отказ" которого мы хотим всеми силами избежать. Нет ничего плохого в кнопке для сортировке числовой колонки, и эта функция по всем канонам ремесла может быть реализована. Но контекст реализации будет не "я как пользователь хочу сортировать таблицу товаров по количеству". А например "заведующий складом должен отслеживать товары с низким резервом, чтобы вовремя их дозаказать" и в рамках этой проблемы, решением может вполне быть кнопка сортировки колонки, потому что из предложеных вариантов заказчик выбрал самый дешевый и приемлемый по удобству. Но среди предложеных вариантов может быть и добавление колонки с каким-нибудь коэффициентом тенденции расхода, что может оказаться еще удобнее, потому что приоритет в реальности зависит не только от запаса но и от тенденции к уменьшению.
Заметьте как только я описал проблему как проблему, а не как решение, мой пример с добавлением колонки родился сам собой. Это возможность для заказчика понять свой бизнес лучше, а для разработчиков возможность проанализировать как цифровые технологии могут ему в этом помочь.
Конечно можно работать с командой как с роботом но тогда получится как эти нелепые виллы в стиле "хочу чтобы дорохо-бохато". Мы же фейспалмим от этого и понимаем, что такое уродство может возникнуть только в том случае если заказчик не предоставляет дизайнеру и архитектору никакой свободы действий. И можно сказать: "Ну и что? Слово клиента - закон!" Значит надо обьяснить заказчику как работает команда. Что она не работает в режиме "пульта дистанционного управления", а работает по методологии, и заказчику будут предоставленны предусмотренные методологией рамки для выражения своих "хотелок", но он ни в коем случае не должен совать свой нос в компетенции команды иначе сотрудничество придется прекратить. (Может помните этот случай https://www.artlebedev.ru/news/2007/nokia/ ?)
Конечно, если ты работаешь не по гибкой методологии, то можно просто фигачить нелепые виллы, за это тоже деньги платят, но тогда не называй это аджайлом.
Совершенно случайно недавно стал интересоваться темой сбора требований и наткнулся на интересный часто задаваемый вопрос, мол как быть с чисто техническими требованиями. Например обновления фреймворка с версии 4.8 на версию 5.0. Пользователя это как бы не касается никак.
Но подумав я пришел к выводу, что это не так. Ведь обновляют фреймворк для чего-то. Значит разработчикам будет легче разрабатывать на нем, т.е. улучшится возможность поддержки приложения. Или например улучшится производительность. Или портируемость. Или поддержка конечных устройств. Или безопасность. Или расширяемость. Даже если разработчиков не считать стейкхолдерами/пользователями, то приложение ведь когда-то передадут заказчику. И вдруг он, бедный, неожиданно получит новую роль - поддержка приложения. (Теперь это его проблема) И тогда модернизация фреймворка вполне себе ложится в пользовательскую историю про поддержку приложения клиентом. Это то, о чем он мог не подумать вовсе, но для этого мы и есть, профессионалы, чтобы объяснить ему, что жизненный цикл приложения установкой на целевые системы не заканчивается.
По этой же самой причине, например, в ноутбуках или автомобилях предусмотрены технические возможности для облегчения ремонта и обслуживания. Пользователю оно напрямую в решении его повседневных задач (то, для чего он это покупал) не помогает. Но рано или поздно случится необходимость ремонта, и тогда наличие таких возможностей, будет влиять на стоимость и скорость ремонта, а также на возможность модернизации и продления срока службы. Т.е. эти предусмотренные чисто технические возможности превратятся в ценность (value) для покупателя.
Так что надо думать шире. И все можно очень стройно обосновать.
Но сказать — вот там хочу кнопку — что в этом может быть неправильного?
На первый взгляд, да. Но если пойти дальше, то окажется, что кнопка ему нужна чтобы выполнить какую-то задачу. Так вот, нужно говорить не о кнопке, а о конечной задаче. Допустим, кнопка ему нужна чтобы сортировать список адресов по удаленности от склада. Значит его интересует не сортировка ради сортировки, а ему нужно знать самый ближний адрес для доставки. А зачем ему знать этот адрес? Чтобы передать его доставщику. И тут слово за слово выясняется, что можно все это сделать без всякой кнопки и доставщику будет автоматически приходить самый приоритетный адрес на мобильное приложение да еще и с оповещением получателя.
Дело в том что заказчик/пользователь предлагает решения в рамках своего ограниченного понимания технологий. Например на Фольксвагене исторически планирование делалось через электронные таблицы, поэтому приложения которые они заказывают часто напоминают навороченые электронные таблицы в браузере.
Можно конечно сказать, мол, ну хочет человек говна на палке, зачем его переубеждать? Но тогда клиент после работы со своим новым приложением подумает, блин, а стоило вообще слезать с экселя, ведь ничего не поменялось, только время и деньги потерял. Так все попытки цифровизация или модернизации пойдут прахом. И мне кажется, что IT-консалтинги, которые дорожат своей репутацией и гордятся своим профессионализмом, должны впрягаться в проблемы клиента, а не просто выставлять счет за человекочасы.
P.S.: У меня был знакомый у него была небольшой печатный бизнес, брошуры всякие, визитки. Он кроме этого делал и дизайн. Так вот, он рассказывал, что сперва приходил к клиенту и проводил у него какое-то время чтобы "понюхать воздух", понять его бизнес и мотивацию. Мне кажется это очень правильный подход. Иначе велик риск сделать не то что надо.
Этот портал, большая часть сотрудников которого - американцы, освещает в т.ч. несправедливости в остальном мире, чтобы окружающие тебя несправедливости не казались тебе такими вопиющими. Похоже на какнасчетизм.
Кардинальная проблема этого сравнения в том, что каста не меняется со временем. Это клеймо которое можно попытаться скрыть, но от которого нельзя избавиться. Вот что печально.
Причем по этой схеме можно писать статьи на любые темы. Даже не имея уникальной информации. Допустим статья "Айфон 14, каким он будет". А в ней, например, рассказывают про предыдущую модель, как она создавалась, и какие технические особенности аппарат имеет на сегодняшний день, потом рассматривают концепт арты комьюнити, а в конце делают вывод, что пока ничего не известно. Но статья на два три экрана есть, она плывет на волне ажиотажа. Маркетинговая задача выполнена. Реклама крутится, деньги мутятся.
И в гугле нет возможности даунвоута выдачи, поэтому такая статья будет сама себя продвигать, если только гугл не следит за временем проведенным пользователем на на статье по ссылке и не делает из этого какие-то выводы по качеству материала. Таких статей-пустышек развелось в последние пару лет огромное количество.
Ну а когда GPT-3 станет доступным всем и каждому, то поисковики захлестнет волна квази-информативного контента, который по факту будет ничем иным как агрегацией уже существующей информации, выраженой стилистически качественным языком, не вызывающем подозрений.
Интересный портал. Из 25 авторов - 15 американцев, 2 англичанина, 2 индийца, 2 китайца, 2 мексиканца, индонезиец и японец, но статьи все про "остальной мир", т.е. страны "третьего мира". Портал так незамысловато и называется: "остальной мир". Удобно показывать как все "загнивает" в других местах, чтобы читателю казалось, что у него-то все еще неплохо. Журнализм в духе "какнасчетизма" времен холодной войны.
С тех пор как я нашел Cucumber Studio (ранше Hip Test), считаю plain text документацию и TMS где описания тестов хранятсся в текстовой форме (а таких больше 99%) - пережитком прошлого.
В Cucumber Studio есть Gherkin Style BDD с возможностью выделять, переиспользовать и отслеживать общие шаги и последовательности.
пара иллюстраций
сценарии где используется шагавтодополнение по всем ранее определенным шагам
Систему можно попробовать самому, она принимает логин через гитхаб аккаунт.
Я бы не стал тыкать внутрь класса. У нас нет никакой гипотезы для выбора такого значения. 10 ничем не лучше 8. Так что если уж "усушивать" количество необходимых проверок, то достаточно двух тестов, для границы класса - 17 и 18.
На практике, конечно, ошибки будут совсем в другом месте. Например список не будет выпадать, кнопка не будет активироваться при выборе нужного значения, список возрастов будет пустой или поле будет неактивно, или не видимо, и прочее и прочее.
Как в том старом анекдоте
У нового испытательного образца советского самолета все время отрывались крылья. Лучшие инженеры страны думали-думали, как это исправить - ничего путного в голову не приходит. Приехал к ним стажер. Позвали и его на совещание. Ну он и предлагает: - А давайте по линии слома просверлим дырочки! - Ты что! Крылья же тогда еще легче будут отваливаться! - Но ведь в туалетной бумаге тоже есть дырочки, но по ним-то никогда не рвется!
Я имел в виду что вокруг того что спросили остаётся то что не спросили. И нужно смотреть на эти белые пятна.
Спрашивая про GC например, вы не спрашиваете про асинхронность. Хотя она в повседневной работе куда важнее для понимания, потому что мусор собирается автоматически, и есть какое-то количество способов устроить утечку памяти и то это становится все сложнее.
А вот накосячить с асинхронность может любой.
Из чего можно сделать вывод что выбранный вопрос - пустая трата времени. И фирма не умеет ставить приоритеты в условиях ограниченного времени. Тревожный звоночек.
Мне бы хотелось порой иметь полную документацию с оглавлением, а не надеяться что поисковик возможно выплюнет статью описывающую решение моей задачи. Например, классно было бы иметь инструкцию по добавленым и измененным функциям новой версии андроида, а не надеяться на обзорщиков на ютубе. То что мы получаем сейчас это "о, видал че могу" от маркетинга и все. "Как этим пользоваться и куда пропало мое ... , это баг или фича?" - всю эту информацию мы получаем часто откуда угодно только не от производителя. Хелпа по андроиду у гугла, надо сказать, еще туда-сюда, неплохая. Если найдешь нужную страницу, конечно. Они, например, ссылаются на смежные настройки. Ведь в сложных приложениях обычно много модификаторов поведения.
Продукт интеллектуальной деятельности сотрудника как правило принадлежит нанимателю. На фрилансе можно, конечно, сойтись на других условиях. Но обычно заказчик / работодатель закрепляют за собой, то что в ГК РФ называется "исключительное право на результат интеллектуальной деятельности".
придумывает, как это реализовать — как выделить MVP или декомпозировать задачу. [...] определяет, как нужно доработать сервис, за который отвечает его команда, с какими внутренними или внешними сервисами придется сделать интеграцию, будет интеграция синхронной или асинхронной. После описания всех нюансов получается постановка задачи, которую системный аналитик передает команде.
Я всегда считал что это работа архитектора. И если нет, тогда в чем задача архитектора?
В прошлом веке эта аргументация, возможно где-то была актуальной. Сегодня только самые упоротые фирмы не понимают, что хорошего сотрудника нужно не увольнять, а давать ему больше ответственности и применять его там где он может причинить максимальную пользу. Поэтому такая фраза больше звучит как отговорка.
Да и проект, он как бы не "твой", а принадлежит фирме. Это обычно в трудовом договоре обозначено. Свой личный проект, конечно, можно не документировать. Тут кто как честолюбием наделен.
Да, сейчас это может быть сравнимо со сложностью одной функции в приложении, однако на проектах не редко сталкивался с ситуацией когда все говорят о том что надо документировать, надо хорошо все задокументировать, а как доходит до дела, то на нее не выделяют должного времени, это раз. А потом разработчики часто просто не имеют опыта написания документации "для других" и она получается весьма скудной и дырявой.
Я помню у нас на фирме был старичок - технический писатель, делал пользовательскую документацию для заказчика на полную ставку. Так он, например просил фидбек у людей с других проектов. Потому что документацию должен в первую очередь понимать не знакомый с продуктом пользователь. Вот там было качество. Структура, добротные иллюстрации где надо. Прослеживался какой-то дидактический вектор. Он делал интерактивные туториалы, обучающие видео, у него даже кабинет звукозаписи был выделен. Вобщем, не хрен собачий. А то что пишут разработчики сейчас, это часто больше похоже на "заметки на полях".
Кстати, старичок ушел на пенсию, на его место никто не пришел. Кабинет звукозаписи переоборудовали. Теряется культура написания технических текстов, теряется. Сейчас возьми любой крупный публичный программный продукт типа сервиса гугла, или эппла, или майков, то там документация больше похожа на сборник HowTo. Да, согласен, продукты развиваются очень быстро, но почему тогда вместе с ними не развиваются концепции по гибкой документации? Хотя, справедливости ради, надо отметить например reStructuredText, как попытку сделать написание документации менее трудозатратным.
Есть подспудное ощущение, что если мы и дальше пойдем по пути импортозамещения*, то такие названия снова появятся на прилавках книжных магазинов. * - и еще снова научимся читать между строк.
Он самописный я так понимаю? Не думаете его заопенсорсить?
А управление курсовым материалом, последние два экрана, это что?
А что это за тулза для управления обучением? Что-то самописное?
Но это будет значить что мы сделали не то что нужно. А это именно тот "былинный отказ" которого мы хотим всеми силами избежать. Нет ничего плохого в кнопке для сортировке числовой колонки, и эта функция по всем канонам ремесла может быть реализована. Но контекст реализации будет не "я как пользователь хочу сортировать таблицу товаров по количеству". А например "заведующий складом должен отслеживать товары с низким резервом, чтобы вовремя их дозаказать" и в рамках этой проблемы, решением может вполне быть кнопка сортировки колонки, потому что из предложеных вариантов заказчик выбрал самый дешевый и приемлемый по удобству. Но среди предложеных вариантов может быть и добавление колонки с каким-нибудь коэффициентом тенденции расхода, что может оказаться еще удобнее, потому что приоритет в реальности зависит не только от запаса но и от тенденции к уменьшению.
Заметьте как только я описал проблему как проблему, а не как решение, мой пример с добавлением колонки родился сам собой. Это возможность для заказчика понять свой бизнес лучше, а для разработчиков возможность проанализировать как цифровые технологии могут ему в этом помочь.
Конечно можно работать с командой как с роботом но тогда получится как эти нелепые виллы в стиле "хочу чтобы дорохо-бохато". Мы же фейспалмим от этого и понимаем, что такое уродство может возникнуть только в том случае если заказчик не предоставляет дизайнеру и архитектору никакой свободы действий. И можно сказать: "Ну и что? Слово клиента - закон!"
Значит надо обьяснить заказчику как работает команда. Что она не работает в режиме "пульта дистанционного управления", а работает по методологии, и заказчику будут предоставленны предусмотренные методологией рамки для выражения своих "хотелок", но он ни в коем случае не должен совать свой нос в компетенции команды иначе сотрудничество придется прекратить. (Может помните этот случай https://www.artlebedev.ru/news/2007/nokia/ ?)
Конечно, если ты работаешь не по гибкой методологии, то можно просто фигачить нелепые виллы, за это тоже деньги платят, но тогда не называй это аджайлом.
Совершенно случайно недавно стал интересоваться темой сбора требований и наткнулся на интересный часто задаваемый вопрос, мол как быть с чисто техническими требованиями. Например обновления фреймворка с версии 4.8 на версию 5.0. Пользователя это как бы не касается никак.
Но подумав я пришел к выводу, что это не так. Ведь обновляют фреймворк для чего-то. Значит разработчикам будет легче разрабатывать на нем, т.е. улучшится возможность поддержки приложения. Или например улучшится производительность. Или портируемость. Или поддержка конечных устройств. Или безопасность. Или расширяемость.
Даже если разработчиков не считать стейкхолдерами/пользователями, то приложение ведь когда-то передадут заказчику. И вдруг он, бедный, неожиданно получит новую роль - поддержка приложения. (Теперь это его проблема) И тогда модернизация фреймворка вполне себе ложится в пользовательскую историю про поддержку приложения клиентом. Это то, о чем он мог не подумать вовсе, но для этого мы и есть, профессионалы, чтобы объяснить ему, что жизненный цикл приложения установкой на целевые системы не заканчивается.
По этой же самой причине, например, в ноутбуках или автомобилях предусмотрены технические возможности для облегчения ремонта и обслуживания. Пользователю оно напрямую в решении его повседневных задач (то, для чего он это покупал) не помогает. Но рано или поздно случится необходимость ремонта, и тогда наличие таких возможностей, будет влиять на стоимость и скорость ремонта, а также на возможность модернизации и продления срока службы. Т.е. эти предусмотренные чисто технические возможности превратятся в ценность (value) для покупателя.
Так что надо думать шире. И все можно очень стройно обосновать.
На первый взгляд, да. Но если пойти дальше, то окажется, что кнопка ему нужна чтобы выполнить какую-то задачу. Так вот, нужно говорить не о кнопке, а о конечной задаче.
Допустим, кнопка ему нужна чтобы сортировать список адресов по удаленности от склада. Значит его интересует не сортировка ради сортировки, а ему нужно знать самый ближний адрес для доставки. А зачем ему знать этот адрес? Чтобы передать его доставщику. И тут слово за слово выясняется, что можно все это сделать без всякой кнопки и доставщику будет автоматически приходить самый приоритетный адрес на мобильное приложение да еще и с оповещением получателя.
Дело в том что заказчик/пользователь предлагает решения в рамках своего ограниченного понимания технологий. Например на Фольксвагене исторически планирование делалось через электронные таблицы, поэтому приложения которые они заказывают часто напоминают навороченые электронные таблицы в браузере.
Можно конечно сказать, мол, ну хочет человек говна на палке, зачем его переубеждать? Но тогда клиент после работы со своим новым приложением подумает, блин, а стоило вообще слезать с экселя, ведь ничего не поменялось, только время и деньги потерял. Так все попытки цифровизация или модернизации пойдут прахом. И мне кажется, что IT-консалтинги, которые дорожат своей репутацией и гордятся своим профессионализмом, должны впрягаться в проблемы клиента, а не просто выставлять счет за человекочасы.
P.S.: У меня был знакомый у него была небольшой печатный бизнес, брошуры всякие, визитки. Он кроме этого делал и дизайн. Так вот, он рассказывал, что сперва приходил к клиенту и проводил у него какое-то время чтобы "понюхать воздух", понять его бизнес и мотивацию. Мне кажется это очень правильный подход. Иначе велик риск сделать не то что надо.
Этот портал, большая часть сотрудников которого - американцы, освещает в т.ч. несправедливости в остальном мире, чтобы окружающие тебя несправедливости не казались тебе такими вопиющими. Похоже на какнасчетизм.
Кардинальная проблема этого сравнения в том, что каста не меняется со временем. Это клеймо которое можно попытаться скрыть, но от которого нельзя избавиться. Вот что печально.
Причем по этой схеме можно писать статьи на любые темы. Даже не имея уникальной информации. Допустим статья "Айфон 14, каким он будет". А в ней, например, рассказывают про предыдущую модель, как она создавалась, и какие технические особенности аппарат имеет на сегодняшний день, потом рассматривают концепт арты комьюнити, а в конце делают вывод, что пока ничего не известно. Но статья на два три экрана есть, она плывет на волне ажиотажа. Маркетинговая задача выполнена. Реклама крутится, деньги мутятся.
И в гугле нет возможности даунвоута выдачи, поэтому такая статья будет сама себя продвигать, если только гугл не следит за временем проведенным пользователем на на статье по ссылке и не делает из этого какие-то выводы по качеству материала. Таких статей-пустышек развелось в последние пару лет огромное количество.
Ну а когда GPT-3 станет доступным всем и каждому, то поисковики захлестнет волна квази-информативного контента, который по факту будет ничем иным как агрегацией уже существующей информации, выраженой стилистически качественным языком, не вызывающем подозрений.
Интересный портал. Из 25 авторов - 15 американцев, 2 англичанина, 2 индийца, 2 китайца, 2 мексиканца, индонезиец и японец, но статьи все про "остальной мир", т.е. страны "третьего мира". Портал так незамысловато и называется: "остальной мир". Удобно показывать как все "загнивает" в других местах, чтобы читателю казалось, что у него-то все еще неплохо. Журнализм в духе "какнасчетизма" времен холодной войны.
Хватить тратить свой талант на такие простые задачи ;) Пора браться за простые числа!
С тех пор как я нашел Cucumber Studio (ранше Hip Test), считаю plain text документацию и TMS где описания тестов хранятсся в текстовой форме (а таких больше 99%) - пережитком прошлого.
В Cucumber Studio есть Gherkin Style BDD с возможностью выделять, переиспользовать и отслеживать общие шаги и последовательности.
пара иллюстраций
Систему можно попробовать самому, она принимает логин через гитхаб аккаунт.
Я бы не стал тыкать внутрь класса. У нас нет никакой гипотезы для выбора такого значения. 10 ничем не лучше 8. Так что если уж "усушивать" количество необходимых проверок, то достаточно двух тестов, для границы класса - 17 и 18.
На практике, конечно, ошибки будут совсем в другом месте. Например список не будет выпадать, кнопка не будет активироваться при выборе нужного значения, список возрастов будет пустой или поле будет неактивно, или не видимо, и прочее и прочее.
Как в том старом анекдоте
У нового испытательного образца советского самолета все время отрывались крылья. Лучшие инженеры страны думали-думали, как это исправить - ничего путного в голову не приходит. Приехал к ним стажер. Позвали и его на совещание. Ну он и предлагает:
- А давайте по линии слома просверлим дырочки!
- Ты что! Крылья же тогда еще легче будут отваливаться!
- Но ведь в туалетной бумаге тоже есть дырочки, но по ним-то никогда не рвется!
Я имел в виду что вокруг того что спросили остаётся то что не спросили. И нужно смотреть на эти белые пятна.
Спрашивая про GC например, вы не спрашиваете про асинхронность. Хотя она в повседневной работе куда важнее для понимания, потому что мусор собирается автоматически, и есть какое-то количество способов устроить утечку памяти и то это становится все сложнее.
А вот накосячить с асинхронность может любой.
Из чего можно сделать вывод что выбранный вопрос - пустая трата времени. И фирма не умеет ставить приоритеты в условиях ограниченного времени. Тревожный звоночек.
Мне бы хотелось порой иметь полную документацию с оглавлением, а не надеяться что поисковик возможно выплюнет статью описывающую решение моей задачи. Например, классно было бы иметь инструкцию по добавленым и измененным функциям новой версии андроида, а не надеяться на обзорщиков на ютубе. То что мы получаем сейчас это "о, видал че могу" от маркетинга и все. "Как этим пользоваться и куда пропало мое ... , это баг или фича?" - всю эту информацию мы получаем часто откуда угодно только не от производителя. Хелпа по андроиду у гугла, надо сказать, еще туда-сюда, неплохая. Если найдешь нужную страницу, конечно. Они, например, ссылаются на смежные настройки. Ведь в сложных приложениях обычно много модификаторов поведения.
Продукт интеллектуальной деятельности сотрудника как правило принадлежит нанимателю. На фрилансе можно, конечно, сойтись на других условиях. Но обычно заказчик / работодатель закрепляют за собой, то что в ГК РФ называется "исключительное право на результат интеллектуальной деятельности".
Я всегда считал что это работа архитектора. И если нет, тогда в чем задача архитектора?
В прошлом веке эта аргументация, возможно где-то была актуальной. Сегодня только самые упоротые фирмы не понимают, что хорошего сотрудника нужно не увольнять, а давать ему больше ответственности и применять его там где он может причинить максимальную пользу. Поэтому такая фраза больше звучит как отговорка.
Да и проект, он как бы не "твой", а принадлежит фирме. Это обычно в трудовом договоре обозначено. Свой личный проект, конечно, можно не документировать. Тут кто как честолюбием наделен.
Да, сейчас это может быть сравнимо со сложностью одной функции в приложении, однако на проектах не редко сталкивался с ситуацией когда все говорят о том что надо документировать, надо хорошо все задокументировать, а как доходит до дела, то на нее не выделяют должного времени, это раз. А потом разработчики часто просто не имеют опыта написания документации "для других" и она получается весьма скудной и дырявой.
Я помню у нас на фирме был старичок - технический писатель, делал пользовательскую документацию для заказчика на полную ставку. Так он, например просил фидбек у людей с других проектов. Потому что документацию должен в первую очередь понимать не знакомый с продуктом пользователь. Вот там было качество. Структура, добротные иллюстрации где надо. Прослеживался какой-то дидактический вектор. Он делал интерактивные туториалы, обучающие видео, у него даже кабинет звукозаписи был выделен. Вобщем, не хрен собачий. А то что пишут разработчики сейчас, это часто больше похоже на "заметки на полях".
Кстати, старичок ушел на пенсию, на его место никто не пришел. Кабинет звукозаписи переоборудовали. Теряется культура написания технических текстов, теряется. Сейчас возьми любой крупный публичный программный продукт типа сервиса гугла, или эппла, или майков, то там документация больше похожа на сборник HowTo. Да, согласен, продукты развиваются очень быстро, но почему тогда вместе с ними не развиваются концепции по гибкой документации? Хотя, справедливости ради, надо отметить например reStructuredText, как попытку сделать написание документации менее трудозатратным.
Есть подспудное ощущение, что если мы и дальше пойдем по пути импортозамещения*, то такие названия снова появятся на прилавках книжных магазинов.
* - и еще снова научимся читать между строк.