Комментарии 9

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

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

Ну я же спросил не про общие принципы, а именно про инженерные коммуникации. Вы написали:


Во время коммуникации каждый понимает все по-своему, интерпретирует как-то иначе, нежели чем было сказано.

Если посмотреть в сторону традиционных инженерных практик, таких как электротехника или машиностроение, то там есть формальные инструменты в виде чертежей, принципиальных или монтажных схем.


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


А если вы программист? Что вы можете использовать в качестве формального инструмента коммуникаций эффективностью не хуже чертежа? Что лично вы используете? Что использует ваша команда?

Абсолютно с вами согласен насчет чертежа — много лет это действительно отличный инструмент, так как в нем есть формальные правила, с которыми все согласны. Тут вопрос скорее в другом — что было в голове у главного инженера, когда он создавал этот чертеж? и является ли он действительно отображением того, что он хотел сделать.

Ну да Бог с ним. Насчет программистов. Вроде бе подробное ТЗ, составленное аналитиков, с описанием форм, входных и выходных данных является примерно таким же формальным и относительно точно интерпретируемым «чертежом». Особенно если еще дополнено графическим дизайном. И следуя этому, программист сделает то, что от него «хотели». вопрос, который я в статье затрагиваю, и из-за которого, как мне думается, и появился манифест agille — а что на самом деле хотели сделать?

между двумя программистами наиболее эффективно, после того как словами обсудили идею, описать приницпиальную схему модулей программы (приложения), интерфейсы REST Api в чем-то формальном (Postman, Swagger), с указанием всех входных и выходных данных. если проект позволяет такое сделать — это очень здорово. Мы стараемся в своих проектах это применять

Мартин в последнее время не особо счастлив от того, во что вылился agile. Несмотря на хайп, у многих разработчиков agile вызывает скорее негативные эмоции. Как вы считаете, почему?
Лейтмотивом последних его выступлений проходит тезис: нет, мы совсем не это имели ввиду. https://martinfowler.com/articles/agile-aus-2018.html

Потому гибкие практики (Agile) были придуманы для того, чтобы достигать технического совершенства. А кого в наше время это интересует?


Я много раз собеседовался в разные компании, разрабатывающие и собственные продукты и подвизающиеся на ниве аутсорса. Большинство из них считают что у них есть Agile-Scrum, и в то же время все они сообщили мне что готовы мириться с массой ошибок в своем программном обеспечении, главное чтобы оно было выпущено в срок.


Лишь в одной из сотни интервьюировавших меня компаний сообщили что их разработчики всегда сначала пишут модульные тесты.

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

Agile, в долгосрочной перспективе как раз позволяет быстрее получать качественный результат. За счет автоматизации, за счет всеобъемлющего тестирования, за счет повторного использования кодовой базы. Проблема в том, что у собственников софтверных бизнесов "нет денег" на долгосрочную перспективу.

Однако несколько аутсайдеров той встречи через год организовали свою. Началось все с того, что Боб Мартин <...> сделал рассылку
Что-то у меня внутренний парсер барахлит. Я понимаю эту фразу так, что аутсайдеры, среди них Боб Мартин, организовали встречу. Я правильно понял?
На встрече тоже были только аутсайдеры прошлой встречи?
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.