Всем привет, мы – Таня и Лиза, системные аналитики в МТС. В этой статье мы поделимся опытом внедрения структурированного шаблона функциональных требований (ФТ) к разработке ПО в нашей команде.

Статья будет полезна тем, кто работает с фронтовым функционалом – системными и бизнес-аналитикам. Неважно, Junior вы или Lead, в большой работаете компании или в стартапе, – наш рассказ вас наверняка заинтересует. Поговорим не только о том, как мы докатились до такой жизни, приняли единый формат ФТ, но и том, какие именно артефакты аналитик готовит в ходе своей работы. А еще мы подробно расскажем про причины поиска подходящего формата, сложности перехода и составляющие наших ФТ. 

Добро пожаловать под кат!

Введение

• какими бывают нефункциональные требования,
• как определять нефункциональные требования,
• откуда берутся численные значения для нефункциональных требований.

Собеседование в айти это как игра - «кто хочет стать миллионером». Сопоставима по трудности, и с каждым ответом ты приближаешься к цели,

Только тут цель не миллион и не работа мечты, а очередная галера.

Всем привет! Так исторически складывается, что когда вы разрабатываете государственные системы, в большинстве случаев требуется написание большого количества документации, а в данной ситуации такая документация еще и требует соответствию ГОСТ.

Хотелось бы вспомнить одну из парадигм Agile " Работающий продукт важнее исчерпывающей документации ", но в данном случае это не наша история, поэтому сегодня поговорим немного о ГОСТах.

Стоит сделать небольшое лирическое отступление и начать с формального определения:

В этой статье на реальном кейсе я хочу рассмотреть весь путь превращения требований от бизнес-заказчика в техническое задание для разработчиков. Кроме того, в отдельных врезках я буду приводить объяснение той или иной технологии, того или иного понятия на доступном языке — для чайников (сама таким была и очень хотела, чтобы мне кто-то на пальцах объяснил все).

Итак, начнем.

Алексей Барабанов, IT-директор «Хлебница» и спикер курса «RabbitMQ для админов и разработчиков», подготовил конспект, который поможет научиться запускать и настраивать RabbitMQ в Docker. Вы поймёте, как конфигурировать параметры запуска, а также узнаете о возможностях управления через веб-интерфейс.

Всем привет! Сегодня хотелось бы поговорить про такую тему, как оценка времени разработки. Тема достаточно интересная т.к. нет какого-то обобщенного стандарта оценки.

Когда-то это было одной из первых моих задач на работе, и когда мне впервые дали требования и сказали "Оцени сколько нужно времени". Естественно первый мой вопрос был "А как ?". Я тогда и представить не могла, как можно оценить то, что не сделано и непонятно, как будет реализовано...

Какие есть подходы и как аналитику оценить задачу? На этот вопрос постараюсь ответить дальше

1. Введение

В данной статье я хотел бы рассказать об этих трёх буквах, постоянно находящихся на слуху, но для многих являющихся тайной за семью печатями, а так же привести ряд ресурсов, с которыми неплохо было бы познакомиться при желании продолжить развитие в проектировании на основе предметной области (DDD: Domain Driven Design).

Когда вы в последний раз сталкивались с качественно документированным кодом?

С кодом, который можно было использовать буквально «из коробки», просто ознакомившись с небольшим README файлом. Но к которому в то же время прилагалась подробная документация, поясняющая каждую строчку: не только то, что она делает, но и почему она была написана именно так, а не иначе.

Давно ли вы встречали такой код? Неделю назад? Месяц? Год?

Лично мне посчастливилось увидеть такой код пару лет назад. И с тех пор я видел немало кода с… довольно грязной документацией.

Но разве можно винить в этом разработчиков?

Плагины VS Code, без которых техническим писателям и разработчикам документации жить можно, но сложно. В подборке — линтеры, форматирование, работа с git, проектирование API, подготовка схем и милота для удобной разработки.

Требования к качеству, несмотря на свой небольшой размер, очень сильно влияют на реализуемость всей совокупности требований, на трудоёмкость, длительность и стоимость реализации, а следовательно окупаемость инвестиций в разработку и в целом возможную успешность проекта.

Это та причина, по которой многие подрядчики стараются избегать таких требований, как огня, что перекладывает риски во времени на более поздние этапы и на заказчика.

Но в мире честных, открытых отношений выгоднее заранее обсудить эти аспекты, чем потом с удивлением спорить при сдаче, что система тормозит, в ТЗ про это ничего не сказано, «вы же профессионалы» и всё такое.

Стандарты по программной и системной инженерии предлагают десятки видов атрибутов качества системы, а заказчики требуют, чтобы система была удобной, быстрой, надёжной и безопасной.

При этом остаётся прагматический вопрос — а что именно писать в требования, чтобы они были полезными, измеримыми, реализуемыми?

С точки зрения системной инженерии, требования к качеству программной системы являются разновидностью системных ограничений (constraints) и в этом они отличаются от требований к способностям (capabilities) системы, в мире ИТ обычно называемых «функциональными».

Пока что умение специалистов и команд выявлять и формулировать такие ограничения представляет собой скорее искусство, а не ремесло, и не инженерию.

Давайте попробуем сделать это хотя бы ремеслом.

Я работаю техническим писателем в компании documentat.io. Мы занимаемся заказной разработкой технической документации, в том числе на английском языке. Иногда я дорабатываю уже существующие документы или спецификации к API на английском. Как правило, такие документы написаны русскоязычными разработчиками, которые неплохо владеют английским. И всё же они часто допускают характерные грамматические, пунктуационные и стилистические ошибки.

Корень этих ошибок один — разные языковые механизмы. Нам бывает легко запутаться в употреблении временных форм, порядке слов или непонятно зачем придуманных артиклях. 

Поэтому в этой статье я постарался не просто дать рекомендации о том, как можно избежать распространённых ошибок, но и подсветить те отличительные черты английского языка, которые к этим ошибкам приводят.

Меня все сильнее раздражает, сколько людей готовы записывать в REST API любой интерфейс на основе HTTP. Сегодня приведу в качестве примера SocialSite REST API. Это же вызовы удаленных процедур (RPC). Он просто выкрикивает RPC. Связность между элементами на экране настолько сильная, что это творение заслуживает рейтинга X.

Недавно мы писали о том, как меняется ИТ-рынок в России и чего ожидают от наших айтишников за рубежом. У всё большего числа русскоязычных ИТ-специалистов появляется опыт собеседований — успешных и не очень — в компаниях из разных уголков мира. Мы собрали истории соискателей и рекрутеров о приёме на работу за рубежом.

Здравствуйте, предлагаю обзор и разбор проекта Brain Simulator II от Чарльза Дж. Саймона, основателя FutureAI. Этот проект и компания малоизвестны, в русскоязычном сегменте интернета вообще нет никаких упоминаний о ней. Моё внимание компания привлекла благодаря сообщению о том, что недавно FutureAI привлекла 2 миллиона $ инвестиций. Проект оказался для меня очень любопытным и интересным, так как я сам во многом разделяю взгляды на проблематику создания AGI Чарльза Саймона, и у меня была практика создания симулятора подобного Brain Simulator II. Обзор проводится на основе общедоступных материалов с сайта FutureAI.guru, откуда можно свободно скачать сам симулятор (windows), а также найти ссылку на его исходный код (c#). Ниже будет представлен вольный перевод одной из статей с сайта, в сопровождении моих комментариев.