Ло (_lothar_) wrote,
Ло
_lothar_

Аутентичность людей и целостный порождающий дизайн систем

А вот например, что меня волнует.

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

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

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

В ХР 1.0 (которое я нежно люблю) 12 практик, но внедрять можно не все сразу, а понемногу.
На первых порах можно внедрять не все, а например штуки по три:
— TDD+refactoring+continuous integration например. Или
— pair programming+coding standards+collective code ownership. Или
— planning game+on-site customer+small releases.
— и так далее. На самом деле сочетать можно как угодно, возможных сочетаний из 12 по 3 — 220 штук и все в принципе хорошие.

Если взять вот так всего три практики из референтного описания в книжке Кента Бека, то всё равно у тебя будет работоспособная целостная человеческая система разработки софта. Если добавить четвертую — будет тоже работоспособная и целостная. Если внедрить только две — тоже будет ок.

Про это явление на последней встрече AgileRussia сказали, что «ХР-то ведь обладает фрактальной структурой, что вы хотели?»

Вот меня и волнуют такие фрактальные архитектурные описания. Как сделать такую же крутую систему как ХР, но только не для бизнеса по разработке софта, а например для бизнеса в сфере хлебопечения? Сразу отбрасываем возражение «нельзя выехать на одной практике "замеси тесто"». Это практика более низкого уровня, точно так же как бизнеса нельзя построить из практики "запиши алгоритм в виде функции на Си".

Мне кажется, что такие архитектурные описания становится возможным записывать, только тогда, когда достигнешь определенного уровня честности с самим собой. Например Кент Бек признался себе — я не пишу идеальный код без багов с первого раза, нужно чтобы был критерий, по которому можно проверять. И появляется требование «как бы нам проверять код на баги?», потом происходит какой-то дискурс (magic! креативное брожение и блуждание в потемках в поисках способа через получение разного опыта и его осмысление) и потом придумывают практику TDD.

А потом Кент Бек снова признался себе — программисты, да и я сам такой, часто отвлекаются или наоборот зависают и тупят в процессе написания кода. Человеко-час — мифический, он всегда умножен на велосити, которая всегда меньше единицы, а часто и меньше одной второй. Надо как-то не терять фокус, поставить надсмотрщика что ли. Но как сделать, чтобы надсмотрщик был приятен, а не фрустрировал?
А может быть даже — помогал??? А ведь помощник будет тоже следить и не давать терять фокус, правда? Но будет мешать вопросами тупыми, если он более слаб по квалификации? Значит партнер что ли? Не подмастерье, а коллега? Ну и дальше парное программирование как решение, которое потом начинают защищать от критики, показывая что плюсы от не потерянного фокуса и сохраненной простоты решений (повышения индивидуальной велосити) превышают минусы (якобы уменьшение ресурса человеко-часов вдвое) Было два чувака с велосити по 0.3, в сумме 0.6, а стала одна пара с велосити 0.8, синергия ололо.

Ну и так далее.

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

--
Ах, да. Собственно об аутентичности.
Tags: authenticity, systems engineering, каптеревщина, левенчуковщина, спасительное, хованщина
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 2 comments