#1 Доверяйте своим сотрудникам

После развития логики работами Буля, Гёделя, Моргана, Лейбница и Фреге, на основе этой дисциплины создаётся новая — информатика. Программирование опирается на базовые законы и операции расширенной логики Аристотеля — предикатной логики, описательная способность которой намного выше. В статье последовательно будет рассмотрено развитие системы логики, её аксиомы, а также связи с информационными технологиями...

Привет, Хабр! Представляю вашему вниманию перевод статьи "The agile swarm: How to design shareable work for software project teams" автора Stephen Frein.

^{Фото: Flickr}

Успешные аджайл-команды склонны ограничивать незавершённую работу (НЗП, незавершённое производство). Предпочитают ли они Скрам, Канбан-метод, или какую-либо другую аджайл-методологию, эти команды особенно выделяют над всем остальным быструю разработку полезной функциональности.

Они больше беспокоятся о пустой работе (подолгу незавершаемые истории), нежели о незанятых руках (есть ли свободная минута у людей, не связанная с их запланированной работой). Соответственно, они идентифицируют высоко-приоритетные истории и «роятся» вокруг них, так, чтобы вся команда, или многие из них, фокусировались на одной и той же истории до самого её завершения. Вместо того, чтобы поделить беклог на несколько отдельных частей, которую каждый член команды сможет брать в частном порядке, высокопроизводительные аджайл-команды предпочитают работать в семейном стиле — они делают всё возможное, чтобы завершить наиболее важные элементы беклога.

Преимущества ограничения НЗП хорошо известны, включая большую сфокусированность, более быстрое выполнение, низкое время цикла и меньшее количество потерь. Эти преимущества делают практику «роения» широко признанной. Тем не менее, хотя многие авторы отмечают необходимость организовывать работу таким образом, чтобы она позволяла «роиться», трудно найти конкретные указания о том, как это сделать. Первый шаг — это понимание того, как организовать работу таким образом, чтобы она была разделяемой между членами команды. К счастью, есть целый ряд конкретных подходов, которые вы можете использовать, чтобы сделать работу более разделяемой.

В идеальном мире можно просто взять исходный код монолита, разделить его код между микросервисами и, соединив их между собой, получить ту же систему, но на новой архитектуре. В жизни так не происходит никогда. Жизнь вносит множество сложностей в эту идеальную картинку. Какие конкретно сложности могут увеличить бюджет перехода на микросервисы в два-три раза?

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

Парное программирование

Привет, Хабр. В этой статье я кратко расскажу о деталях реализации микросервисной архитектуры с использованием инструментов, которые предоставляет Spring Cloud на примере простого концепт-пруф приложения.

Код доступен для ознакомления на гитхабе. Образы опубликованы на докерхабе, весь зоопарк стартует одной командой.

Этой статья раскрывает концепции Middleware в ASP.NET Core. К концу этой статьи вы получите четкое представление о следующих моментах:

- Что такое Middleware?

- Почему порядок расположения Middleware имеет значение?

- Методы Run, Use и Map.

- Как создать собственное Middleware?

- Как реализовать просмотр каталогов с помощью Middleware?

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

Большинство договоров пишут юристы, а руководители, продажники и клиенты, похоже их не читают. Да их и невозможно прочесть. Много ли людей читают договор с банком или лицензионное соглашение?! Или договор с оператором сотовой связи или провайдером?! Скучное и бесполезное занятие. Всё равно на текст договора чаще всего никак не повлиять в крупных компаниях.  

Юристы зачем-то пишут скучнейшим и малопонятным языком, копируют в договор тексты законов. Вероятно их цель, чтобы читатель заснул и не переварил написанного. Или им платят за 1000 знаков, а не за смысл. В тоже время многие российские законы написаны вполне человеческим и понятным языком и имеют хорошие нормы права по умолчанию.

Предлагать клиентам подписать договор, который бы не хотел подписывать сам — хамство.

У нас был договор написанный простым и понятным языком. Но жизнь не стоит на месте и коллеги сказали, что нужен новый договор. И что нужно обязательно обратиться к юристу, чтобы всё профессионально было. Обратились. Получили скучнейшую простыню как у всех. Читать невозможно. 

Выбор методологии разработки новых программных продуктов зависит от ряда следующих факторов: новизна и новаторство концепции; понимание клиента, что он хочет; понимание поставщика программных продуктов, что хочет клиент. Парадокс заключается в том, что и тот и другой ошибаются с самого начала на этапе формирования идеи. Для того чтобы идея была подтверждена в виде MVP и в дальнейшем развивалась в виде продукта, необходимо выбрать подход и механизмы, направленные на быстрое получение обратной связи от клиента.

В этой статье мы поделимся опытом запуска стартапа в компании — системном интеграторе ОТР2000 с точки зрения выбора и внедрения гибкого подхода к разработке протестированных и
работоспособных программных продуктов.

Рекомендации по сравнению и выбору правильного смарт-карт ридера

Данная статья содержит краткое введение в проблематику смарт-карт ридеров (их устройство, классификация, определение параметров для сравнения), предлагает набор критериев и методику для сравнения и анализа конкурирующих продуктов.

В бизнес-моделировании процессы можно условно разделить на два вида — исполняемые, которые действительно будут работать при помощи специального обеспечения, например, Bizagi, и неисполняемые, т.е.бизнес-модели, необходимые только для лучшего понимания бизнес-процессов и его специфики.

Исполняемые бизнес-процессы обязательно должны быть выстроены в строгом соответствие всем правилам нотации BPMN, так как в противном случае программное обеспечение не сможет работать корректно с составленной бизнес-моделью. Данные бизнес-процессы требуют глубоких знаний BPMN, а также внимательного отношения к каждой детали, так как вы, по сути, создаете программу (алгоритм) для компьютера, просто используете для этого не текстовый язык, а графические нотации.

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

Неисполняемые бизнес-процессы нужны исключительно для демонстрации какой-либо бизнес-модели. Это может быть диаграмма, отображающая реальное положение дел на предприятии, может быть наглядной иллюстрацией к предложенным изменениям при реинжиниринге. В этом случае, конечно, можно использовать любые удобные инструменты, в том числе, традиционный для многих IDEF0, или декомпозиция IDF0 до уровня потока работ (EEPC). А соблюдение правил языка моделирование необходимо исключительно для достижения взаимопонимания.

Недавно Gartner опубликовали последнюю версию своего отчета Магический квадрант для умных пакетов управления бизнес-процессами (iBPMS). Вы не найдете Camunda BPM ни в этом отчете, ни в их записи в блоге. Я хочу объяснить почему.

• Аутсорсинг, аутстаффинг — а в чем вообще разница?
• С какими клиентами есть смысл работать по аутстафф-модели?
• Почему аутстафф нравится нам больше, чем аутсорс?
• Почему клиенту аутстафф приятней, чем аутсорс или инхаус?
• В каком случае веб-студии / продакшну лучше не пытаться в аутстафф?