Clean out your closet

Robert C. Martin написал книгу «Clean Agile: Back to Basics».

А Любомир Геревич не знает, кто дядя Боб. Так вот, это один из тех семнадцати чуваков, которые собрались в феврале 2001-го в Snowbird ski resort в Юте для того, чтобы потрындеть о том, как можно было бы обустроить жизнь программистскую.

На этом фото Роберт Мартин третий слева.

К тому времени уже оформилось несколько устойчивых и обоснованных мнений о том, что и как надо было бы делать, чтобы было «правильно», поэтому необходимость в общем словаре уже назрела.

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

Книга воспринимается как трёхсоставная:

  1. общий обзор
  2. технарные штучки
  3. менеджерские дрючки

и для простоты можно говорить только про первую часть. Меня первая часть затянула полностью. Было сложно читать, бо я постоянно офигевал по двум векторам:

  1. Да! Именно так! А я говорил! Да!
  2. Неужели!? Неужели я настолько ошибался? Нет!

И да, есть места, в которых я ошибался/заблуждался/был неправ.

Контекст важнее всего. Непонимающие контекст и желающие перенимать только практики (best practices only!) — долбанные придурки с излишним запасом энтузиазма, блеать.

Контекст

важнее

всего.

Контекст определяет содержание и способы решения задачи.

У тех, кто собрался у той доски, понимание контекста было ну прям нутрянное. Им было важно и нужно упростить сотни вариантов до общих принципов. Они это и сделали.

Дальше им следовало бы жить на вершине голой, писать простые сонеты, и брать у людей из дола хлеб, вино и котлеты, изредка объясняя смысл программистской жизни тем немногим, которые до них смогли бы добраться. Но они выпустили это всё в мир. Наверное, им казалось, что общий контекст…

В общем, нет никакого противопоставления Agile vs Waterfall. Сегодня всё точно так же, как было раньше, когда молодой дядя Боб фигачил код на старых компьютерах. Иногда получается. Иногда нет.

In 1970, I was 18 years old, working as a programmer at a company named A. S. C. Tabulating in Lake Bluff, Illinois. The company had an IBM 360/30 with 16K of core, an IBM 360/40 with 64K of core, and a Varian 620/f minicomputer with 64K of core. I programmed the 360s in COBOL, PL/1, Fortran, and assembler. I wrote only assembler for the 620/f.

We wrote our code on coding forms using pencils, and we had keypunch operators punch them onto cards for us. We submitted our carefully checked cards to computer operators who ran our compiles and tests during the third shift because the computers were too busy during the day doing real work. It often took days to get from the initial writing to the first compile, and each turnaround thereafter was usually one day.

What process did we use during those days? It certainly wasn’t Waterfall. We had no concept of following detailed plans. We just hacked away on a day-to-day basis, running compiles, testing our code, and fixing bugs. It was an endless loop that had no structure. There was no discipline in the way we worked. It was just code and fix, code and fix, day after day, month after month.

I first read about Waterfall in a trade journal sometime around 1972. It seemed like a godsend to me. I felt the power of the concept. I wanted to believe it. Because, if it worked, it was a dream come true.

Apparently I wasn’t alone, because many other programmers and programming shops caught the bug too. And, as I said before, Waterfall began to dominate the way we thought.

It dominated, but it didn’t work. For the next thirty years I, my associates, and my brother and sister programmers around the world, tried and tried and tried to get that analysis and design right. But every time we thought we had it, it slipped through our fingers during the implementation phase. All our months of careful planning were made irrelevant by the inevitable mad dash, made before the glaring eyes of managers and customers, to terribly delayed deadlines.

Вот и Agile сегодня dominated, but it didn’t work. Точнее, и не должен работать. Это же не метод, с чего бы ему работать? Это набор принципов, которые просто помогают понять, что правильно, а что нет. Подменять процесс принципами — ой, всё…

И нет у всей этой философии задачи ускорить деплой. Ускорение — это наблюдаемый, даже желаемый, но косвенный результат.

И сегодня на эту тему дядя Боб сделал твит:

Agile is not about going faster. Agile is about destroying hope. The data produced by a good agile team provides a cold dose of reality to the managers — in time for them to — manage.

Делать замеры метриками, да ещё и менеджерскими — нельзя.

Warning

Test coverage is a team metric, not a management metric. Managers are unlikely to know what the metric actually means. Managers should not use this metric as a goal or a target. The team should use it solely to inform their testing strategy.

Double Warning

Do not fail the build based on insufficient coverage. If you do this, then the programmers will be forced to remove enough assertions from their tests in order to get the coverage numbers high enough. Code coverage is a complex topic that can only be understood in the context of a deep knowledge of the code and tests. Don’t let it become a management metric.

Не надо называть итерации спринтами (нагугли, что такое «спринт» в спорте). Разработка ПО — это марафон, тут нужны стайеры. Иногда получается. Иногда нет.

An Agile project begins with analysis, but it’s an analysis that never ends. The first thing you know is the date. We subdivide that time into regular increments called iterations or sprints.

Sprint is the term used in Scrum. I dislike the term because it implies running as fast as possible. A software project is a marathon, and you don’t want to sprint in a marathon.

И нет у всей этой философии задачи поменять способы разработки. Иногда, глядя со стороны, это всё может быть воспринято как изменённый, или даже полностью иной способ разработки. На деле же разработка как была, так и осталась попыткой как-то упорядочить последовательность вычислений так, чтобы результатом стало что-то, что можно назвать «результатом работы» по аналогии с работой, которую делает человек.

Но это так же глупо, как верить в то, что часы отсчитывают время.

Ничего они не отсчитывают.

Если часы остановятся (или мы их поменяем), то что, время перестанет отсчитываться?

Если положение стрелок поменяем, то что, солнце быстрее уйдёт за горизонт?

Но часы нужны, чтобы ориентироваться относительно времени.

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

— Но ведь нам нужен Product Owner! — тонко заскулили из-под шконки. — А если не вовлекать закащщика в нашу кухню, то аджайла не будет!

Вот пример того, до чего доводит это скулёж: эффективные чуваки додумались нанять Product Owner:

Так все же, где найти PO?

Нанять нового? Он продукта не знает, его долго искать и потом вводить в курс дел, а начать делать задачи нужно уже сейчас; и не факт, что он впишется в команду, потом заново искать нового PO.

Может, тогда назначить на эту должность кого-то из уже существующих сотрудников? А кто же тогда на его месте будет? И как он на новом месте вообще справится, он ведь практически ничего о владении продуктом может и не знать? Кто будет его обучать?

Ну не пиф-паф ли?!

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

Но одно дело — замерять и понимать скорость, и другое дело — замерять и заставлять эту скорость выдерживать и доезжать в пункт назначения ровно в %какое-то время%.

Если же тыкать в заказчика этим нашим аджайлом, то придётся очень упрощённо объяснять, что это такое, придётся это всё продавать. И будет вот это вот всё «Ну, это когда быстрый деплой. Всё будет очень быстро. И вам не нужны будут тестировщики. И после каждого спринта у вас будет работающий продукт» с очень далекозаползающими последствиями. Упрощение же. Для дебилов.

Работающий продукт ≠ Хорошо/правильно работающий продукт.

Остальное додумывайте сами.

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

Без звука. Автор видео – Жека Козлов.

Agile нужен затем, зачем нужна вся философия вообще — понимать, что происходит, чтобы принимать взвешенные решения для выполнения задач в конкретных условиях с учётом конкретного контекста. Понимать мир, а не управлять миром (санитарыыыы…)

А, вам же ещё нужна оценка книги и итоговый вердикт? Ну… вместо дурнычных дурныць, будет полезно на десять лет вперёд послушать самого дядю Боба про то, как всё было, и как всё будет, и понять, почему всё именно так.

Бо если не понять, почему всё именно так, то и не понять, как сделать иначе.

Добавить комментарий

Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.