Интервью Ваше программное обеспечение может быть быстрым или находиться в состоянии, когда оно не взорвется у вас на глазах. Но добиться того и другого одновременно в эпоху увольнений и реструктуризации в лучшем случае сложно, а в худшем — невозможно.
Так говорит доктор Джунаде Али (на фото выше), который говорил с The Register после шумихи, вызванной исследованием, которое показало, что не все хорошо в состоянии Agile.
Многие сторонники Agile утверждают, что пользовательских историй достаточно. По сути, они просто описывают функциональное поведение, но им не хватает обобщаемой спецификации или нефункциональных требований
Али указывает на исследование (заказанное им самим), которое показывает, что взрослые британцы предпочли бы, чтобы программное обеспечение работало как следует, а не было переполнено новыми функциями. «Они на самом деле считают получение последних функций как можно быстрее наименее важной для них вещью при использовании компьютерных систем».
Соавтор Agile Manifesto раскритиковал отчет о частоте неудач и рассказал о проекте «переосмысления»
ПРОЧИТАТЬ ДАЛЬШЕ
«Общественность, скорее всего, согласится с тем, что безопасность данных, точность данных и отсутствие серьезных ошибок — это то, что для них важно.»
По словам Али, это резко контрастирует с несколькими метриками, используемыми в методологиях DevOps и Agile. «Они во многом касаются скорости поставки программного обеспечения, с одной стороны, и, с другой стороны, скорости решения проблем».
Это была золотая эра для тех, кто освещал сбои, поскольку банки, ритейлеры, мобильные сети и поставщики облачных услуг недавно пострадали, что Али связывает с ненадёжной выгрузкой обновлений. Он продолжает беспокоиться о влиянии инцидентов, таких как недавние проблемы CrowdStrike, на доверие пользователей.
В конце концов, законные исправления безопасности, возникающие из-за 0-day и т. п., должны быть установлены как можно скорее. Однако, по словам Али, потеря доверия может привести к сопротивлению пользователей.
У Али есть целая библиотека думов, и он много писал на эту тему, охватывая многочисленные инженерные катастрофы за эти годы. Однако он считает, что проблема не обязательно кроется в процессе тестирования: «Вы часто обнаруживаете, что типичный катастрофический сбой компьютера начинается с недостатка в первоначальном процессе разработки требований».
«А затем происходит то, что это каскадируется, потому что часто эти проблемы скрываются или инженеры не чувствуют, что могут безопасно поднять тревогу. И так это снежный ком на протяжении всего процесса разработки программного обеспечения, пока не произойдет катастрофа».
CrowdStrike — пример катастрофы, которая была настолько очевидной, что попытка ее тихо скрыть была просто невозможна.
Фреймворки и процессы
Виноват ли в этом Agile? Боязнь инженеров высказаться — это, конечно, не то, что имели в виду авторы первоначального манифеста. Однако идеалы оригинального Agile-манифеста с годами были размыты, поскольку вокруг них возникли структуры и процессы. Как выразился Джон Керн, один из авторов манифеста: «Существуют некоторые неправильные представления о разнице между использованием какой-либо Agile-структуры и тем, чтобы быть Agile».
Доктор Джунад Али Фото: Никола Бэлд Фотография
Али заинтересовался темой сбора требований как ключа к предотвращению потенциальной катастрофы и тестированию того, что необходимо протестировать .
«Тестирование — это своего рода один из тех инструментов, которые есть, но для того, чтобы тестирование вообще работало, вам нужно знать, что вы тестируете. Поэтому вам нужны хорошие требования, чтобы описать нефункциональные требования, которые там есть».
Например, надежность.
«Интересно то, что многие люди, я думаю, в сообществе Agile, многие фундаменталисты Agile будут утверждать, что пользовательских историй достаточно. Они по сути просто описывают функциональное поведение, но им не хватает обобщаемой спецификации или нефункциональных требований».
«И поэтому я думаю, что это один из ключевых недостатков. Когда вы в конечном итоге посмотрите на самое догматичное применение Agile, у нас есть только пользовательские истории, но вам не хватает этой обобщающей спецификации».
Керн бы сказал: не соглашаться и утверждать, что приведенные выше четкие требования «просто глупы». Взглянув на «Манифест гибкой разработки программного обеспечения», можно увидеть, что ценятся как работающее программное обеспечение, так и исчерпывающая документация (хотя первое ценится больше, чем второе).
Публикация Agile-манифеста датируется 2001 годом, и Али больше всего интересует его эволюция на протяжении многих лет. Али говорит, что его меньше всего беспокоит управление проектами, пока его дополняет строгий процесс сбора требований.
Однако с разработкой программного обеспечения дела обстоят менее радужно. Он указывает на такую интерпретацию DevOps, при которой проблемы не имеют особого значения, пока система восстанавливается после них, а скорость и качество никогда не противоречат друг другу. «В прошлом это приводило к абсолютно катастрофическим результатам».
Однако именно организационная трансформация, когда методология и образ мышления, именуемые «Agile», применяются по всему бизнесу, может действительно сойти с ума. Али указывает на попытки трансформации без осознанного согласия заинтересованных лиц или на случаи, когда компания могла быть продана на основе ложной истории.
«Не существует универсальных решений, при которых вы можете получить все сразу, и вы можете получить свой пирог и съесть его. Но именно это часто продают подобные методологии трансформации».
Поскольку бюджеты становятся все более сжатыми, соблазн волшебной палочки, которая может компенсировать увольнения и нехватку ресурсов с помощью методологии, которая утверждает, что компания может сделать «больше с меньшими затратами», становится заманчивым. Однако, с точки зрения Джона Керна, соавтора Agile Manifesto, и доктора Джунаде Али, критика Agile-методологий, предположение о том, что проблемы проекта и организации можно прикрыть лейкопластырем с надписью «Agile», в лучшем случае близоруко, а в худшем — катастрофично. ®
