Comments 13
И как же нам повысить эффективность хотя бы инженерных коммуникаций в процессе разработки программных продуктов? Как это реализовано у вас?
Ну я же спросил не про общие принципы, а именно про инженерные коммуникации. Вы написали:
Во время коммуникации каждый понимает все по-своему, интерпретирует как-то иначе, нежели чем было сказано.
Если посмотреть в сторону традиционных инженерных практик, таких как электротехника или машиностроение, то там есть формальные инструменты в виде чертежей, принципиальных или монтажных схем.
Когда у вас в руках чертеж с указанием проекций, разрезов, размеров и допусков вы более-менее однозначно понимаете чего же от вас хочет ваш коллега или заказчик. Чертеж — вполне себе эффективный инструмент инженерной коммуникации, неплохо зарекомендовавший себя за сотни лет эксплуатации. Поэтому при подготовке инженеров принято развивать навыки разработки и чтения чертежей.
А если вы программист? Что вы можете использовать в качестве формального инструмента коммуникаций эффективностью не хуже чертежа? Что лично вы используете? Что использует ваша команда?
Ну да Бог с ним. Насчет программистов. Вроде бе подробное ТЗ, составленное аналитиков, с описанием форм, входных и выходных данных является примерно таким же формальным и относительно точно интерпретируемым «чертежом». Особенно если еще дополнено графическим дизайном. И следуя этому, программист сделает то, что от него «хотели». вопрос, который я в статье затрагиваю, и из-за которого, как мне думается, и появился манифест agille — а что на самом деле хотели сделать?
между двумя программистами наиболее эффективно, после того как словами обсудили идею, описать приницпиальную схему модулей программы (приложения), интерфейсы REST Api в чем-то формальном (Postman, Swagger), с указанием всех входных и выходных данных. если проект позволяет такое сделать — это очень здорово. Мы стараемся в своих проектах это применять
Рискну предположить: возможно есть некие программные инструменты для формализации бизнес- процессов и/или Информационных потоков, в чем-то напоминающие блок-схемы Алгоритмов ?
Мартин в последнее время не особо счастлив от того, во что вылился agile. Несмотря на хайп, у многих разработчиков agile вызывает скорее негативные эмоции. Как вы считаете, почему?
Лейтмотивом последних его выступлений проходит тезис: нет, мы совсем не это имели ввиду. https://martinfowler.com/articles/agile-aus-2018.html
Потому гибкие практики (Agile) были придуманы для того, чтобы достигать технического совершенства. А кого в наше время это интересует?
Я много раз собеседовался в разные компании, разрабатывающие и собственные продукты и подвизающиеся на ниве аутсорса. Большинство из них считают что у них есть Agile-Scrum, и в то же время все они сообщили мне что готовы мириться с массой ошибок в своем программном обеспечении, главное чтобы оно было выпущено в срок.
Лишь в одной из сотни интервьюировавших меня компаний сообщили что их разработчики всегда сначала пишут модульные тесты.
Однако несколько аутсайдеров той встречи через год организовали свою. Началось все с того, что Боб Мартин <...> сделал рассылкуЧто-то у меня внутренний парсер барахлит. Я понимаю эту фразу так, что аутсайдеры, среди них Боб Мартин, организовали встречу. Я правильно понял?
На встрече тоже были только аутсайдеры прошлой встречи?
Над проектом должны работать мотивированные профессионалы.
^^ А настоящее Масло должно быть Масляным,
А настоящая Вода должна быть Водянистой.
? Мне одному только кажется , что этот т.н. "манифест" - это словоблудие "эффективных" менеджеров и жуликоватых юристов, имеющее целью следующее:
- Свой непрофессионализм при постановке ТЗ (логически неполное/противоречивое/плохо формализованное ТЗ) выставить как "изменение требований", продиктованное жизнью.
- Кинуть разработчиков на бабло, т.е. не только не заплатить за программный продукт но, при возможности, еще и обложить штрафами, за то что- "не успели к сроку" , "есть отклонения от ИХ видения конечного продукта", Приемо-сдаточные испытания вообще непонятно как проводить без четкого ТЗ.
Вообще, адекватные программисты в моем понимании - Люди инженерного склада ума, которые получив информацию на входе:
Постановку Задачи в виде некоего набора текстов на бумаге или устной дискуссии, на выходе стремятся построить - стройную, полную и непротиворечивую математическую/логическую модель. Построение такой модели, на первый взгляд, должно было бы способствовать взаимопониманию Продукт-оунеров/Заказчиков и Разработчиков. Но это лишь на первый взгляд, а по существу, такой подход высветил бы с предельной ясностью никчёмность "эффективных менеджеров", и последующее отстранение их от корыта. Вот они и изобрели сей опус.
Вангую - среди изобретателей этого "манифеста" нет НИ ОДНОГО настоящего программиста !
=============================
Конструктивная критика приветствуется!
Пример из практики моих коллег — проект для налоговой инспекции одной из стран СНГ. Гос проект по сути, ТЗ, законодательство, ни о каком аджайле и речи не велось. Но команде пришлось проявить гибкость в тот момент, когда государство в стране заказчика изменило свое налоговое законодательство настолько, что проект не имел бы смысла вообще в том виде, в котором его запланировали. Пришлось изменять ТЗ и переделывать почти готовый проект, чтобы заказчик смог им пользоваться. Иначе — в работе не было бы смысла, ну разве кроме заработка как такового.
Вопросы к Продукт-менеджерам со стороны Заказчика и Подрядчика:
- они знали, что Предметная область (в частности налоговое законодательство) может меняться ? - Обязаны были знать и предусмотреть в ТЗ такой вариант развития событий, и заложить в ТЗ не жесткую а гибкую формальную модель.
Но во первых - это несколько дороже (допустим на 50%), во вторых - сроки длиннее допустим на 30%, в третьих - степень интеллектуального развития Продукт-менеджера должна быть выше.
- Ну и Решили - и бабки сэкономим и чуть что - спишем на форс- мажор, ну а программерам - не заплатим им, кинем. В договоре должно быть оговорено, что изменение законодательства не должно считаться форс мажором.
Мы agile или аджайл нас?