Странная политика Russian Podcasting

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

1. Права на чтение книги - на support@rpod.ru плиз
и да - сообществ нам и так хватает...

1. Я не понял, зачем на обсуждение книги нужно право? :(
2. И сервис у них не для участников сайта, а ради, чтобы хватало...

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

... добавлено через 4 часа ...
Нашёл выход, просто завёл фэйковый адрес и подписался на все подкасты в качестве ленты друзей. Получилось: http://u19376.rpod.ru/friends. Вроде неплохо. Остаюсь на первом :)

О целях использования Study-Group

Кратенько выскажусь о сути явления :)
Вопрос был поднят в стади-групп обсуждениях.

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

Study-group - всего лишь определённый инструмент добывания теоретических знаний (даже если это опыт участников), объединяющий структурный (фильтр восприятия) и системный (обсуждения) анализ. Это способ изменения мышления на системный. Когда мы критериально оцениваем информацию. Возможно развитие этой практики в стороную формирования целостного восприятия. Кстати, подготовка, встреча, резюме по главе, резюме по книги формирует цепь закрепляющей обратной связи и глубокого освоения материала.

Касательно целей. Думаю, у инструментов врядли есть цели. Цели есть у желающего пользоваться этим инструментом (например для персонального использования я повышаю свой теоретический уровнь, а если используешь в команде - синхронизация и выравнивание командного инженерного видения на подходы, принципы и способы решения проектных задач). Цели нужны для мотивации объединения вокруг общей задачи. У нас такой задачи нету, каждый сам решает свои цели в стади-групп. Я усматриваю другого рода мотивацию - плановость и предсказуемость. А сама стади-групп состоя из двух этапов: подготовки и встречи. Отражает разные варианты мотивации. Например, неменуемость встречи и желания плодотворно в ней поучаствовать толкает нас к нахождению времени на подготовку. Без стади-групп это бы носило несистемный характер, к тому же нужна была бы сила воли. Встреча смещает акцент в область взаимоотношений. И связана с самореализацией и самоидентификацией каждого участника.

В общем я к чему. Не стоит смотреть на данное явление через призму известных вещей. Принцип аналогии сковывает наше развитие, формируя однобокий способ мышления в рамках, и может отвести в сторону. Нужно оставлять самобытность и самоопределяющуюся суть такой формы обучения. Инструментарий "видение-цели-принципы" в одной области деятельности нужны, но это такой же инструментарий, который приследует определеённые цели и должен быть использован сообразно. В стади-групп я не усматриваю пока таких вещей, к которым инструмент "видение-цели-принципы" нужны. Достаточно определиться принципами и паттернами проведения.

В общем, заметки - определённый фильтр восприятия, который отмечает важное и позволяет осознать посыл автора, плюс ещё хитрым способом определяет область непонимаемого, незнаемого и даже неосознаваемого. И за счёт коллективного подхода (встречи), о чем раньше бы и не помыслил во время чтения, мы начинаем не только осознавать, но и включать в свою область понимания новое и полезное.

То же самое в цифрах.
1. Читая один книгу я получу пусть 80% информации от автора.
2. Работая в стади-групп я потенцильно могу получить 80% из п.1 + 20% между строк через обсуждения и доосмысления авторской информации+ 100% (и более) информации из группы и её опыта.

А для максимизации п.2 система заметок должна спровоцировать появления 20% и 100%. Система заметок как ключ для подключения и аккумулации этих процентов.

Цифры взяты с потолка. Опять же важная сейчас не количественная составляющая, а качественная.

Сопротивляемость изменениям или про тюрьму опыта

Просто приведу цитату, которая просто вызывает благоговенный лепет в моей душе:

Идея о тюрьме впервые была исследована Платоном в «Республике» в знаменитой аллегории пещеры, где Сократ рассуждает о связи видимости, реальности и знания. Перед входом в подземную пещеру пылает костер. В пещере находятся люди, закованные цепями и лишенные возможности двигаться. Они видят только ту стену пещеры, что прямо перед ними. Она освещена пламенем, и тени людей и предметов видны на ней. Обитатели пещеры думают, что тени - реальность, дают им имена, говорят о них и даже связывают звуки, доносящиеся снаружи, с движением теней на стене. Истина и реальность для пленников заключаются в этом мире теней, поскольку они не знают другого.
Однако, считает Сократ, если бы одному из жителей пещеры позволили покинуть пещеру, он понял бы, что тени - всего лишь отражение более сложной реальности, а знания и восприятия его товарищей неверны и искажены. Если бы он вернулся потом в пещеру, он никогда уже не смог бы жить по-старому, поскольку для него мир был бы уже другим. Несомненно, ему трудно было бы смириться со своим затворничеством и стало бы жалко других пленников. Однако если бы он попытался поделиться с ними своим новым знанием, его, вероятно, осмеяли бы. Для пленников знакомые образы пещеры имели бы гораздо большую значимость, чем тот мир, который они никогда не видели. Более того, поскольку человек, получивший новое знание, больше уже не сможет функционировать с прежней убежденностью относительно теней на стене, его сотоварищи, скорее всего, посчитают внешний мир опасным. Это происшествие приведет к тому, что они станут жестче придерживаться знакомого образа мыслей.
Герет Морган. Образы Организации. с.235

И в продолжение к сравнению не-Agile подхода и Agile подхода: многие пытаются устранить неопределённость и защититься от неё через предварительное проектирвоание, детальное изучение требований и анализ. Agile же состоит в том, чтобы учиться на неопределнности и лавировать в её условиях. Аналогичную метафору можно проследить в западном подходе производства (предотвращения через накопление и буфферизацию на складах) и японской модели (от куда, кстати пошли многие Agile практики) производства.

Теперь я полностью понимаю своих не-Agile оппонентов, видать им в пещере уютней :)

Story Points vs Ideal Hours

Для многих возникает неоднозначность и недопонимание, зачему вводить такую характеристику, как Story Point. А так же в продолжение предыдущего поста.
Объяснения очень просты. В Agile используется и то и другое. Но для разных уровней декомпозиции требований и реализации.

Я выделяю следующую пирамиду требований к разрабатываему продукту. От верхнеуровневой бизнес идеи до задач для разработчиков. В этой пирамиде требования к продукту (1-3) постепенно разбиваются до требований разработчика к коду (4-5) :)

1. Метафора продукта
2. Фичи продукта
3. User Story
4. Task
5. Task List

Каждый нижний пункт является декомпозицией верхнего. Мерить п.1 и п.2 очень сложно. Так как это очень высоко и тяжело оценить хоть как-то. п.5 (декомозиция задачи на мелкие шаги; Test List - шаги по задаче) слишком мелкий для оценки и нецелесообразен для оценок.

Рассмотрим п.3 и п.4
3. User Story оцениваем в Story Points с использование Planning Poker.
4. Tasks оцениваем в Ideal Days/Hours используя одну из схем: индивидуально (старый подход) или коллективно (новый с 2004 года).

В переводе на русский
3. Функциональные требования оцениваются в единицах трудоёмкости
4. Задачи оценивают в идеальных часах задачи (до 2 дней)

Продолжительность Ideal Hour адаптивно выбирается. В классике отталкиваются от 6 часов. Остальное адаптируется по ситуации.
Во время планирования на выходе мы получаем
1. Плановую суммарную Story Points
2. Плановое суммарное Ideal Days/Hours

Управление скоростью разработки легче вести с более высокоуровнего пункта. А так как у нас оценке подлежит только п.3 и п.4 - выбор очевиден. К тому же Story Points непосредственно связаны с функциональными требованиями и бизнес ориентированы. В тоже время под Ideal Hours может подпасть много не входящее в User Story, и носят инженерный оттенок реализации. Далее вводится фокус-фактор, но об этом смотрите в предыдущем посте.

Это классическая схема работы. Опыт показывает, что изобретать альтернативы не имеет смысла. Но это не должно останавливать.

Дополнительные ссылки:
1. Об agile по-русски: User Stories
2. Planning Poker

Мотивация в три шага

По эволюции развития существует три шага:

Шаг 1. Принуждение
Шаг 2. Стимулирование
Шаг 3. Прямая мотивация

Принуждение - моральное, экономическое (премии, бонусы, штрафы и т.п.) и физическое принуждение. В общем смотрим на наши команды в ИТ и понимаем. Мы здесь! Здраствуй принуждение :)

Кстати, яркий пример шага 1 это командно-административная, карьерная и бюракратическая машина. Если в вашей организации есть карьерная лестница, бонусы и т.п. - вы на шаге 1.

Нас всю жизнь учат этому способу работы. Паутина подчинения проявляется во всём: учёба, семья, институт и т.п. создают и культивируют в нас "подчинение". И потом удивляемся, почему бывшие рабы становясь начальниками используют этот вариант с большим усердием.

Кстати, В.И.Ленин знал только такой способ мотивации работников: записка В. И. Ленина: «…а Ильина… и весь фабком этого завода… и весь состав комячейки… объявляем виновниками… и объявляем строгий выговор и общественное порицание, с предупреждением, что только на первый раз так мягко караем, а впредь будем сажать за это профсоюзную и коммунистическую сволочь (суд, пожалуй, помягче выразится) в тюрьму беспощадно» (Ленин В. И. Полн. собр. соч. Т. 54.)

Стимулирование - когда мы обеспечиваем достаточный уровень мат.потребностей, создаём независимость работников от эконом. характеристик его бытия. Некоторые продвинутые команды разработчиков, да и вообще в России робко говорят и смотрят в эту область мотивации. Жаль, что многие менеджеры, тим лиды (специально не обученные) и бывшие программисты только используют шаг 1. И просто не понимают, как передвинуться к шагу 2.

Для меня этот уровень тяжело пока определить. В переходе между шагом 2 и шагом 3 появляются Формулировка миссии организации, видения (образа ее будущего), декларации ценностей, кредо, этические кодексы, использование корпоративных историй и мифов, разработка идеологии социально-ответственного маркетинга и управления т. п., призваны наполнить смыслом деятельность людей в организации.

Прямая мотивация - удовлетворенность содержанием, процессом и смыслом, значимостью труда (Р. Шпренгеру). Когда создаётся вовлечение участников разработки в процесс, в коллективное творчество.
Этот шаг и создаётся Agile-коучером.

К чему, я это написал. Да убеждаю себя купить книгу.

Dependency Inversion Principle, Dependency Injection и Inversion of Control

Кратко напишу так
Dependency inversion principle (DIP) - разрыв ЗАВИСИМОСТЕЙ через абстракцию
То есть, когда мы выводим интерфейс IA и скармлеваем потребителю B, мы отрываемся от зависимости, когда потребитель зависит от изменений конкретного класса A. А рассуждая далее, получаем, что логичней переименовать IA и IB, то есть клиент B определяет, что ему нужно от А:

B использует IB
A реализует IB

Dependency injection - механизм использующий DIP, DIP создает возможность использования DI

Inversion of control (IoC) - Don't call us, we'll call you (Hollywood principle) - принцип, когда основной поток управления (алгоритм) определён, и мы кастомизируем части. Частный случай, когда поток управления скрыт в базовом одном классе - паттерн Template Method. Более сложный вариант - модель Framework и частичная передача управления выполнения нашему приложению.

Очень жаль, что такие понятия путаются. А особенно это замечено в русской википедии. Ну и даже Роберт Мартин в своей книге попутал. Привязав голливудскую фразу к DIP. И вообще в его английском и русском варианте много неточностей, которые мы обнаружили коллективным разумом стади-групп.

Ссылки по теме:
- http://igor.quatrocode.com/2008/09/solid-top-5.html

Образы организации

Случайно зашёл в книжный, а там случайно открыл случайную страницу этой книги - прочитал. Автор дельные мысли написал. Купил. Читаю... Расстраиваюсь.

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

Конечно, тем людям, которые любят строгую иерарихию, планы, распределение обязанностей и т.п. в разработке ПО. Книга будет полезна. Её объём достаточный, что потихой убедить этих людей в их ограниченном восприятии. Книга покажет им все многообразие смыслов и восприятий. Глубина и важность человеческого фактора выварачивается вдоль и вширь :)

С точки зрения Agile там мало чего полезного. Если вы практикуете Agile вы сами будете думать ещё похлеще автора. Отличие автора от вас лишь в его научном описании, то что вы знаете и так :)

Очень порадовали библиографические заметки. Единственно насыщенная информацией часть книги :)

Для Agile-истов: не рекомендую
Для не-Agile-истов: обязательная к прочтению.

Проектирование Static Verbs английского языка

Лог переписки English Grammar Study Group. Использованы все принципы проектирования :)

[23:11:49] Ilya говорит: Нашел - эти слова, которые не употребляются в continious по научному называются статические, нединамические (stative verbs). Вот список http://www.perfect-english-grammar.com/stative-verbs.html
[23:12:41] Ilya говорит: Т.е. нельзя сказать I hating или I wishing
[23:21:35] Кирилл говорит: прям не полиморфные глаголы, статика :) Избегаем её всеми силами и несилами :)))
[23:21:47] Ilya говорит: :)
[23:45:22] Denis говорит: sealed к тому же :)
[23:45:46] Denis говорит: хотя нет, need есть наследник - needed ;)
[23:47:08] Кирилл говорит: а может "ed" - это агрегируемая часть класса need :) Neet.ToString() = "Needed"
[23:47:10] Кирилл говорит: )
[23:47:33] Denis говорит: не это врапер
[23:48:06] Кирилл говорит: не, просто булево поле IsInPast = false, и поэтому ToString по-другому работает))
[23:48:26] Denis говорит: class Needed
{
Need need;
ToString() { MakeItInPast() }
}
[23:48:50] Denis говорит: хотя чё-то не так
[23:48:54] Denis говорит: но смысл понятен
[23:49:00] Denis говорит: :)
[23:49:11] Кирилл говорит: class Need
{
bool IsInPast;

}
[23:49:21] Denis говорит: Неее
[23:49:22] Кирилл говорит: override string ToString()
[
[23:49:39] Кирилл говорит: return IsInPast? "Needed" : "Need"
[23:51:02] Denis говорит: фуууу
[23:51:05] Denis говорит: :)
[23:51:08] Кирилл говорит: Я понимаю, но всё же :)
[23:51:45] Denis говорит: понял!

Verb
virtual PresentContinousForm()
{
return "to be" + name + "ing";
}

Need : Verb, IStaticVerb
{
override PresentContinousForm()
{
return PresentSimple();
}
}
[23:52:25] Denis говорит: а нет гоню
[23:52:42] Denis говорит: StaticVerb : Verb

Need: StaticVerb
[23:53:01] Кирилл говорит: мм... IPresentContiniousable, IPresentSimpleable, ... :)))
[23:53:05] Denis говорит: даже ещё хуже!
[23:53:13] Denis говорит: Need - как класс нужен ли?
[23:53:36] Кирилл говорит: таак... Надо подумать. Так как слова - это тоже абстракции, которые что-то означают, то.... да)
[23:53:39] Denis говорит: конструктор - Verb(string name)

и пораждаем need:

need = new StaticVerb("need");
[23:54:12] Кирилл говорит: Ну это смотря что нужно от приложения. Если ИИ строить, то нужны классы на каждое слово)
[23:54:30] Denis говорит: Другой вопрос, будет мина:

fly = new StaticVerb("fly");
[23:54:36] Denis говорит: вроде код корректен, а неверный
[23:54:43] Denis говорит: поэтому нужно где-то словарь заложить
[23:54:49] Denis говорит: а!!!!
[23:54:54] Denis говорит: исопльзуем flyweight! ^)
[23:54:58] Кирилл говорит: Словам нужно атрибуты сделать, либо абстрагировать атрибуты до состояний
[23:55:41] Denis говорит: можно конечно все спрятать в StaticVerbFactory
[23:55:58] Denis говорит: с сылкой на http://www.perfect-english-grammar.com/stative-verbs.html
[23:56:07] Denis говорит: сорри, в VerbFactory
[23:56:16] Кирилл говорит: )))
[23:56:50] Кирилл говорит: А как синонимами управлять... Каждый объект слова должен хранить списки синонимых, антонимых и тд
[23:57:17] Denis говорит: ну это другая юзер стори :)
[23:57:22] Кирилл говорит: :)

Коммитмент и ответственности в разработке

Я не держу слово. Да такая фигня случается. Я не держу слово перед командой, когда обещаю сделать работу за 6 часов, а выполняю за 12. Я не держу слово родными, когда обещаю купить хлеб, но забываю. Я не держу слово перед самим собой, когда обещаю встать в 9 утра и дрыхну без задних ног. Я часть системы. Системы, которую создаю я. В этой системе таких как я рать. Мы придумываем кучу оправданий, почему это не вышло, почему я не смог или не успел. Мы переносим ответственность на других, делегируем им нашу ответственность за себя. А потом удивляемся миру, который образовался вокруг нас.

Вопрос становится - почему я так поступаю? Почему я принимаю решения и возлагаю ответственность на себя и не выполняю её. Будет ли чувство доверия, чувство, что можно положиться на меня и планировать уже свои активности. Нет!

Мне это сходит с рук. Может быть везёт. Но если не я один такой? Если ты тоже так поступаешь. Если поступает сосед, коллега, партнёр. То какой мы мир строим?

Другой вопрос - какие решения важны, а какие нет. Насколько важно давать обещание самому себе встать в 9 утра и дать обещание сделать задачу за 6 часов? Что из них важнее и критичней. Попробуем воспользоваться 3-ей точкой зрения (см. пост ). Перед метафоричным образом "смерти" любое наше решение является самым главным. Пусть это покупка хлеба, или заключение миллиардного контракта. Конечно можно выбрать другую стратегию, например преуменьшения данных обязательств (ведь всё равно все там будем) - но будет ли от этого мир лучше? Наверное нет.
Поэтому я выбираю равенства даваемых обещаний и каждое из них бесценно.

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

Петр 1 говорил: Кто хочет у него тыща возможностей, кто не хочет тыща оправданий.

PS. Но не забываем адаптивность никто не отменял, но мы должны стремиться к идеалу.

Study Group Community: Нас слушают!

Созданное недавно сообщество постепенно расширяется. Первый месяц (дата регистрации домена - 20.10.2008, а первой встречи - 28.10.2008) работы сообщества уже дал приятный фидбэк: знания растут, сеть знакомств увеличивается и главное нас слушают! И появляется неутомимая жаждая создавать новые группы.


График скачивания подкастов сообщества: http://study-group.rpod.ru

А что ждёт нас впереди? Уже через месяц работы участники сообщества решили сделать проект Study Group Portal, который покроет нужды сообщества для организации комфортных встреч, работы и просто социальной сети профессионалов.

Даже страшно загадывать, что нас ждёт впереди! :)

Как тестировать приватные функции класса?

Знакомый вопрос? И какие у нас есть решения
1. Использовать рефлекшн
2. Директивы компиляции #if DEBUG - ужас
3. friend и его альтернативы
4. Возможности встроенного xUnit фреймвока в IDE который делает чёрную магию (см VS.Net)
5. Ваше любимое :)

Если первое решение смерть всему поколению поддержки, а второе ужас на крыльях ночи, то стоит вопрос - а чего делать-то?

TDD нас учит - пишите тесты и всё будет пучком. Действительно будет, но жизнь не идеальна. И появляются приватные методы и конечно же возникает желание их потестить.

Почему многие бьются, но не находят решения? А потому как мы находимся в такой парадигме программирования, которые не предполагает решения. Там его просто нет. Спросите, а что не так с нашей парадигмой? Да всё просто - мы со своей теорией знания ООП лезем в бизнес-разработку. Теория ООП - это академически дисцеплина. А наш код - это бизнес-реальность.

Что говорит теория - инкапсулируй, скрывай и т.п.

А что говорит бизнес? Гони нам качественное и дешевое решений! А почему же теория делает нам решение не дешёвым? А все просто - нету тестов, запутанный код, неясная логика, неадекватные называния и огромная связанность даёт прибавки в стоимости нашего кода в части поддержки и развития. Мы платим огромные сумма за поддержку и развитие кода, нежели его создания. Пусть икает тот разработчик, который первый породил тот или инной класс. И получил свои 10$ за него. Теперь мы дни тратим понимая, почему он вызывает отъезжание в другом месте и днями на пролёт эксперементируем как к этому делу прикрутить чуть больше функций. И платим за это сотни, а может быть даже тысячи баксов.

То есть задача бизнес кода - получить дешевое решение. Которое легко развивать, сопровождать, читать, анализировать и оно обладает минимальной связанностью. Конечно же TestFirst, TDD, Refactoring, Patterns, Continuous Integration здесь наше спасение. Но вернёмся к приватам.

Парадигма "бизнес разработки" такова, что нужно посмотреть, кто является клиентами нашего кода. Кто использует продукт нашего творчества? Мы должны сделать все возможное и невозможное, нарушая теоретические полёты мысле теоретиков от ООП, с целью удешевления поддержки и развития.

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

Итог. Клиенты кода - это заказчик + разработчики. Причем последний в большей мере. Так какого мы тресёмся за теоретическую инкапсуляцию и забиваем на тесты открывая нужные функции, делая их protected (шунтируя для теста класс, например) или даже public? Кончайте голову себе и другим пудрить! Делайте дело и используйте всё многообразие подходов, чтобы качество кода было 101% и его цена минимальна!

Я выделил 3 парадигмы разработки, который порождает рассматриваемый случай
1. "Теоретическая" (когда неуклонно следуем ООП и придумываем обходные манёвры о которых в ООП ничего не говорится и считаем их хорошими — см. п.1-п.5 выше). Максимальное количество private.
2. TDD — уже смещает парадигму мышления и на выходе получаем изолированные модули. Но и там проскакивает приват. Который приводит к одному из п.1-п.5
3. "Бизнес-программирование". Используем TDD + открываем (protected|public) методы для нужд тестирования. Так как я являюсь пользователем своего кода и мне важно его качество выраженное через 1) покрытие тестами, 2) простоте чтения.

Я работаю по методу 3.

Выбранный мною подход разработки делает мой код дешевле и качественнее.

Почему мы используем Story Points?

Ответ простой. Посмотрим на альтернативы.

А альтернатива - это идеальные часы, дни или что-то другое со вренем.

Кстати, проясню, идеальный день равен 6 идеальным часам. Сами ведь понимаете, что нужно и по нужде сбегать, и с коллегами поговорить, и звонки могут быть, да и просто мой блог почитать и на курс ко мне сходить :)

Story Points - это трудоёмкость оцениваемая командой во время планирования. Это не время, очень большая ошибка перейти на оценку в идеальных часах. Почему?

Расказываю.

Вариант 1. Идеальные дни.
Напомню, функциональные требования (User Stories) оцениваются в идеальных днях. А задачи, на которые разбиваются требования в идеальных часах.

Итак у нас команда из 5 разработчиков. Итерация 2 недели. Сколько мы наберём работы? Посчитаем - 5 разработчиков x 2 недели x 5 дней x 6 идеальных часа в день = 300 часов. Ну мы собственно и набираем задач. В конце итерации выясняется, что мы сделали работы на 200 часов.

Стоит вопрос - нужно переоценить требования? или укоротить идеальный час? или набирать теперь часов не 300, а на 200 в следующий раз? А что делать с новыми задачами? Их сразу домножать на коэфициент? или ввести термин "идеальная итерация" состоящая из 200 часов. Куча вопросов и у меня нет на них ответа. Потому что это не Agile ;) А заниматься классическими расчётами, как учат нас книги по менеджменту и придумывать теории производительности - крайне неэффективно.

Поэтому рассмотрим вариант 2.

Вариант 2 (по Agile). Меряем User Stories (функциональные требования) с помощью Story Points.

Во время обучения меня срашивают, что такое Story Points? А я отвечаю
1) это сипульки
2) прошу понаблюдать за игрой слов - User Stories -> Story Points
3) мера трудоёмкости
4) мера не времени, а бизнес-значимости, так как бесполезные вещи для бизнес не оцениваются в Story Points. график убывания (burndown) показывает как значимые вещи реализуются в коде.

А теперь вернёмся к нашей команде в 5 человек. После планирования они поняли, что трудоёмкость итерации 150 Story Points. Итерация. Результат - 100 сделали.
А теперь магия корректировки скорости.
фокус фактор = сделанные Story Points / ресурс в идеальных часах = 100 / 300 = 33%

Что значит 33%? Это соотношение стори-поинтов к идеальному времени. В следующий итерации один разработчик ушёл в отпуск. Как вы посчитаете сколько вы за итерацию осилите? берём идеальные часы (ресурс) - 240 часов и множим на 33% - получаем нужно набрать требований на 80 Story Points.

Причем заметьте:
1) нам не нужно адаптировать свои оценки сложности
2) мы не задумываемся о своей неверной оценке одного требования, как впрочем и целого набора
3) 1 проработанный час не всегда равен 1 выработанной Story Point. Банально много много времени бесполезно сидеть, а бизнес-выхлопа никакого. Если ежедневно считать, сколько осталось Story Points сделать до конца итерации. То можно заметить - время течёт, а бизнес стоит. Сразу можно оперативно реагировать.
4) если каждую итерацию мерить свою скорость в story point можете увидеть очень интересную картинку. особенно меня радует, когда команда занимается рефакторингом, тогда просест графика в ноль гарантирован :) хуже, когда график проседает в итерации, где добавляются полезные фичи.

А дальше обширное поле игры с фокус-фактором. Хотим время на стабилизацию - делаем цифирку поменьше. Хотим поработать по выходным - побольше :)

Продолжение: http://denismiller.blogspot.com/2009/02/story-points.html

Планирование продукта в Agile

Agile - это хаос, никакого планирования и т.п.

Это ложь и происки демонов!

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

Как выглядят требования? Их можно представить в виде треугольника. Вершина самые высокоуровневые требования. Основание… предпред-последний слой это многочисленные документы, детальные требования, SRD, BRD, TRD. Предпоследний слой большое количество документации инженерной и самый нижней слой - код проекта. Код проекта тоже документация  Такую схему можно использовать это не запрещается, но мы ищем эффективные пусти.

Сделаем два предположения:
1. Документация делится на документированную и недокументированную
2. Участники проекта участвуют достаточно продолжительное время, чтобы их можно было считать носителями знания и не страдают амнизией :)

Теперь вспомним, что является средней частью. Большая стопка мукалатуры. Вязкая документация, наводящая Такие предположения позволяют более эффективно построить пирамиду требований вырезав среднюю часть (детальные требования и тонны архитектурной документации). Правда приятно сэкономить тонны времени на написания этой муккалатуры? А сколько времени сэкономили на поддержания её? :)

Но такой подход вызывает изменение процесса разработки
1. Все участники должны быть в курсе высокоуровневых требований
2. Код программы должен быть качественным.

"Все участники должны быть в курсе высокоуровневых требований" это означает, каждый должен въехать в видение продукта, видение релиза, итерации и понимать все требования, которые отражаются в кратких заметках-маркерах (User Story Index Card). Почему маркеры? Да потому, что они нужны лишь для игры в покер и должны служить напоминанием о той или иной хотелке клиента. А когда дойдём до планирования хотелки - у него и спросим :)

Про качественный код здесь говорить нечего. Код программы является самым низкоуровневым, детальным требованием. Поэтому он должен быть таким, что квалифицированный разработчик его будет читать как документ. В общем эффект самодокументированного кода здесь имеет место быть. Каждый Agile-разработчик должен обладать навыками TDD, Refactoring, шаблонами и т.п. Ну и конечно моей любимой альтернативой "конвенции наименования" - Implementation Patterns.

Теперь какова анатомия верхней части пирамиды. Тут вариантов туча. Очень хорошая практика из RUP. Но по мне главное в этом деле, чтобы клиенты, менеджеры и т.п. вне-командные личности смогли договориться в самых крупных своих ожиданиях, выраженном в видении продукта и релизов. И другой важный момент – видение является критериями выбора приоритетов клиентом первоочередных функциональных требований (User Stories). Видение становится картой, используя которую мы движемся в нулевой итерации сбора и анализа требований при составлении Product Backlog’a. И эти видения помогают понять, что нужно в самое ближайшее время. Во время подготовки достаточно понять видение на 2-3 релиза и это будет достаточно.
После того как мы договоримся о целях (видении) релизов. Нам уже легче отсортировать требования пользователей. Самый важный конечно же, это ближайший для разработки релиз. Там нужно быть очень внимательным. К остальным тоже внимательность не помешает. Но нужно участь, что после первого релиза может все изменится. Второй и третий нам интересен лишь для тенденций. О четвертом не имеет смысла вообще говорить. И его можно называть «всё остальное» 

А затем набрав первый релиз. Применяем ту же практику с выделением видения, но относительно итераций релиза. На этом уровне видение каждой итерации называется цель итерации. И мы опять же применяем хитрость практики «видение», чтобы клиенты договорились  Ну и нам разработке стало понятно чего же хотят. Как происходит планирование на этом уровне расскажу в другой раз. Итак получилось выше крыши 

Соберём всю пирамидку требований от видения до ежедневных задач:
1. Видение продукта - управляем метафорами
2. Планирование релизов - управляем features
3. Планирование итераций - управляем user stories
4. Планирование дня - управляем задачами

Extract Superdirectory (Configuration Refactoring)

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

build
- Release
- Debug

Но как всегда возникает проблема, что нужно копировать одни и теже файлы в обе папки. Это досадно и неприятно. Получается дублирование файлов. А это зло, так скажет любой нормальный Agile-разработчик.

Для этого рекомендую применить рефакторинг:
Extract Superdirectory
You have two directory with similar files.
Create a superdirectory and move the common files to the directory.

В результате получаем несоколько папок:
build
- Common
- Release
- Debug

Другой вопрос, если в файлах папки Common нужно кастомизировать часть файла исходя из типа сборки. Ну тут чуть сложнее, используем Configuration Adapter паттерн. Который в зависимости от сборки вырезает и заменяет секции файла исходя из типа сборки. Реализация совсем проста - это исполняемый файл, который натравливается на, например, конфигурационный файл, он ищет секции заключённые в нужные теги (@Release@, например), а остальные стерает (@Debug@).

О конструировании социальной реальности

Что такое реальность? На этот вопрос никто из живущих на земле ответить не может. От реальностью мы отделены нашими органами. Мы испльзуем их, чтобы в голове отобразить. Лишь отобразить картину реальности. Это с одной стороны. С другой стороны мы выстраиваем внутреннюю реальность - убеждения, ценности, свои правоты и истины. Эта конструкция строится в нас с помощью улицы, двора, садика, школы, университета и даже работы. Из нас делают биороботов для работы. Нам прописывают как мы должны работать и кому подчиняться. Так было всегда.

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

Тут я отойду в другую сферу. Сферу не ИТ, а других реальностей. Других реальностей построенных людьми, которые небыли посажены на рельсы подготовки инженеров-программистов. Людей, которые были отделены от мира штамповки биороботов, своими недостатками. Я хотел бы рекомендовать вам интересную историю одной девочки - http://rodon.org/other/vmitssh/

Чтобы заинтересовать читающих блог приведу две цитаты девочки:
Наука – система знаний, основанных на сомнении (Соня, 10 лет)

Кто знаком с науками изнутри, удивится точности слов. Сомнение – один из методологических столпов науки (другой – вера. Речь, конечно, не о религиозной вере)

Что заставляет уходить в бессмертье
Мельчайшие частички бытия?
Их разделяют звезды и столетья,
И вместе с ними исчезаю я.

Но исчезая, во Вселенской книге
Я оставляю четкие черты.
И в каждом атоме, и в каждом миге
Меж мной и Вечностью наведены мосты
(Соня, 13 лет)

Мои выводы. У девочки хорошо поставлен слог. Она хорошо передаёт другой вкус... другой социальной реальности. Которая возможно ближе к той, реальной реальности. Она не проходила процесс штамповки граждан государства. Но судя по её творчеству она теряет свою исходную модель... Её "учат" нашей социальной реальности.

Другая жизнь – вторая Я

Другая жизнь, вторая Я.
Ваш мир мне видится иначе.
Вторая Я у вас своя,
А первая в нём горько плачет.
Мне вскоре радость надоела
От похвалы моих стихов.
Я жду не слов, мне нужно дело –
Молитвы дело и трудов.
Вторая я – как есть малышка,
Почти что девяти годов.
И в жизни, и во всяких книжках
Портрет её давно готов.
Другая жизнь работать заставляет
Не столько сердцем, сколько головой.
Вторая Я прекрасно это знает,
Но аутизм не даст быть деловой.
Мне дан талант слагать слова.
Зачем – я это понимаю.
Вторая Я обычно не права,
Когда меня другой быть призывает.

Он чувствует, что её меняют. И она сопративляется этим измененям.
Но похоже она проигрывает игру. Её первоначальная картина мира изменяется мужами истинной реальности :)

Не верь, не гадай и не бойся
В крови уже есть ответ.
Чужие неясные свойства –
Откуда и чей привет?

Так странно смешалось и глупо –
Готовый взорваться вулкан.
Не кот на цепи у дуба –
Сошедший с ума ураган.

Но так уже прежде бывало
Рвалось полотно пелён
И я из себя прорастала
Сбегая из плена времен.

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

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

Всегда ли прав клиент?

Часто звучит лозунг "клиент всегда прав!". Но насколько эффективен такой лозунг? Позволит этот лозунг писать качественный код и гордиться массовостью использования хорошего решения?

Давайте взглянем подробнее. Когда кто-то "прав", то кто-то значить "не-прав". Если прав клиент, то не права команда разработки. Но кто же создает продукт? Конечно же команда разработке. А в голове этой команды своя "правота", которая отличается от "правоты" клиета, а по сути является "не-правотой" клиента. Стаёт вопрос ребром - насколько я качественно сделаю продукт, если я считаю одно, а должен делать другое? Создаётся шизофреническая ситуация: думаю одно (истинное я), говорю второе (ну раз заказчик всегда прав - то буду говорить его же словами), а делаю третье. Что же такое третье? Симбиоз. Сибиоз, который готов взорваться. Некая субстанция, которая насильно скована контрактными обязательствами и деньгами. Проект может быть будет сделан. Но вы будете гордиться таким проектом? Будет ли каждый день работы приносить удовольствие от работы над ним? Я бы не стал так работать - жизнь одна, чтобы её портить на такую мелочную постановку задачи.

Но что же будет взамен "правоты". А взамен будет "партнёрство", в котором клиент и разработка суть партнёры. Партнёры, которые делают один проект, которые заинтересованы в его успехе. "Правота" вызывает механизм соподчинения я начальник - ты дурак. "Партнёрство" - это творчество равных. А если мы равны и мнение каждого важно, как своё. И мы руководствуемся продвижением продукта за счёт наших совместных усилий. То... Наступает сказка. Команда вовлекается в проект, клиент получает хороший продукт, пользователи летают на седьмом небе от счастья. Наступает мир и любовь! :)

Вывод: В общем для меня критерий "правоты" это неверный критерий. И вообще зло. И в этом я на 100% прав :)

Касательно верификации требований или немного о кризисе

Для оценки, что происходит вокруг нас есть несколько вариантов.

1. Я оцениваю с точки зрения своей точки зрения. Своей правоты.
К сожалению этот уровень очень подвержен влиянию внешних и внутренних факторов. Внешний - нам навязали те ценности, которые не являются важными и нужными. Например см. предудыщий пост касательно "штрафов". Когда я придумываю что-то, мне сложно отказаться от своего решения. Чувство важности (я же автор решения) не позволяет мне адекватно оценить ситуацию. Если работать по оценки на этом уровне мы получим много криков, обид и все будут расстроены. Только мудрецы могут изменять своё мнение и поскупиться авторством ради лучшего решения на этом уровне.

Что делать нам? простым разработчика?
2. Оценивать с точки зрения другого человека.
Представьте, что вы тот человек, которому вы хотите донести своё решение. Ну как?
Думаю у нас достаточно хорошо работает абстрактное мышление и все хорошо можем дебажить, чтобы продебажить свои ощущения к такой позиции №2.

Но есть ещё круче
3. Примените глобальную точку зрения. Глобальность подразумевает точку зрения: продукта, клиентов, коллектива, общества и самое мощное глазами собственной смерти :)
А смерть всегда говорит одно и тоже, не парься, получай удовольствия от жизни. Хуже меня ничего нет. И твои проблемы сегодня или религиозные войны в обуждениях по поводу стиля программирования или архитектуры лишь пустая трата времени и твоей энергии. А этой энергией питаются деструктивные личности твоей души. Тебе это нужно? Ну если нужно - то корми их :)

Цитата: "обращайтесь к смерти за советом, чтобы избавиться от бездарной мелочности, свойственной людям, которые живут так словно смерть их никогда не коснётся" (Your death will tell you that you’re wrong; that nothing really matters outside its touch. Your death will tell you, ‘I haven’t touched you yet’.)

Ты с другой стороны, чувствуешь, что ты бессмертен. А решения бессмертного человека могут быть изменены, или о них можно сожалеть или подвергать их сомнению. Время имеется только для того, чтобы делать решения. (“You, on the other hand, feel that you are immortal, and the decisions of an immortal man can be canceled or regretted or doubted. In a world where death is the hunter, my friend, there is no time for regrets or doubts. There is only time for decisions.”)

(С.Castaneda, Journey to Ixtlan)


Как связано с кризисом? Примените третью точку зрения к нему

Позитив vs Негатив в User Story. Проверка качества продукта на социльную ценность.

Сейчас подготавливаются функциональные требования к новому продукту. Я там выступаю как product owner (и заодно коучером) и поэтому пытаюсь ценность нового продукта сделать как можно больше. Клиентом является команда разработки. Поэтому мы периодически играем в роле "клиент". В разговорах с "клиентами" показалось очень интересным одно обсуждение. Сегодня поговорили по поводу отрицательной мотивации как следствие работы нескольких фич продукта. Я отрицательное неприемлю на корню. И считаю, что осознанная личность выше этого. Может это называется позитивная психология. Так иногда озвучивают мою точку зрения знающие люди. Я не знаю. Я знаю одно эффективность и кайф от работы превыше всего 

4 юзер-стори и мои комментарии

Я как ведущий группы хочу иметь возможность отмечать пропуски участниками SG (например один пропуск - "шарик" пропуска в статус или его половинка) для того чтобы давить на сознательность

Денис: какая ценность пункта "для того чтобы"? зачем давить на сознательность? для чего это? мотивация от негатива - очень плохая мотивация.
зачем ведущему группы давить на участников? с какой целью?
Автор: ведущий только ведет статистику, сознательность у каждого своя.
Денис: зачем ведущему статистика?
Автор: чтобы я меньше хотел пропускать, когда ситуация может быть разрешена как в пользу участия, так и в пользу пропуска. "зачем - мне видеть возле своего ника в списке - 3 черных шара, когда у других их нет?"
Денис: зачем мне отрицательная мотивация?
Автор:- см. ниже
Денис: зачем тебе нужна отрицательная мотивация? она отпугнёт участника от ресурса или привлечёт?
Автор: для привлечения новых людей - она будет просто прикольной фичей. так что скорее положительный момент. для уже учавствующих - повод не пропускать, а то "чтот я забросил это дело, и етц...". тоже вроде нет вреда.
Денис: я бы перестал бы участвовать в сг, если на весь интернет будет известно, что я её пропускаю - и ещё бы в блоге написал бы за плохую систему привлечения.
Автор: :-) весь инет пошел бы посмотреть что же это за система и вот новые пользователи - каждый сам оценит что это такое и надо ли ему это.
Денис: очень сомневаюсь. тебе нравится, если бы о твоих не очень хороших качествах узнали бы все знакомые? как бы ты относился бы к такому ресурсы, который это делает?
Автор: мои знакомые меня знают :) чем не повод не пропускать, раз тебе это не нравится - выбор же есть.
Денис: знают все плохие твои качества?
Автор: скорее всего даже больше чем вижу я сам, со стороны виднее.
Денис: в общем я бизнес-ценности такого решения не вижу. хоть убей. делать сайт для подчёркивания плохих качеств участников с целью мотивирования посещения этого сайта. я бы за деньги бы на такой сайт не ходил бы. жуть :O
Автор: ок. нет так нет. я изложил свое видение.
Денис: я не говорю, что нет. но я хотел бы понять, почему тебе это так важно. этот проект в том числе коуч-сессия для лучшего понимания Agile... нужно искать что-то общее, что помогает работать эффективно в том числе и конечному пользователю с нашим продуктом

Я как участник группы хочу видеть свой статус по пропускам каждой конкретной SG (количество "шариков" пропуска) для того чтобы давить на сознательность

Денис: участник мазахист? :)
Автор: дело пользователя
Денис: зачем пользователю это?
Автор: а если у меня группа из одних злостных прогульщиков набирается - я должен это знать. предупрежден =вооружен.
Денис: а ты это разве не заметишь? И что тебе даст это знание? что ты с ним будешь делать? санкции?
Автор: например увеличу число участников для старта чтобы хоть с кем то работать
или заложу более длительный срок на работу группы, раз будут слайды.
Денис: люди приходят, когда ты не вводишь репрессии, а своим примером показываешь, что это интересно. для старта группы достаточно 1 человека. проверено. уже две группы начавшиеся в 1 человека - привлекли участников.

Я как пользователь портала хочу видеть количество пропусков у другого пользователя для того чтобы давить на сознательность

Денис: пользователь онанист? :)
Автор: дело пользователя

Я как пользователь портала хочу видеть список топ-прогульщиков портала для того чтобы давить на сознательность

Денис: цель топ рейтинга отрицательных качеств не понятна. происходит культивация культа "прогульщиков", вместо развития заинтересованности и вовлечения в полезное дело саморазвития
Автор: так а кто сказал что нельзя сделать механизм уничтожения этих шаров - вот и положительная мотивация.
Денис: зачем придумывать механизм уничтожения негатива, когда можно получить непосредственный позитив от участия? С какой целью я прихожу на сайты? За удовольствием или за негативом?
Автор: в SG есть определенные правила - например, обязательная подготовка одно из них. появление на встречах - думаю тоже. если ты для удовольствия прийдешь на SG неподготовленным или сорвешь встречу - это вред группе.
Денис: право поддерживать своё "обязательство" это право давшего обязателство - это раз. это же относится к неподготовшимся. А встречу можно провести и одному -- мы активны, позитивны и нам ничего не мешает самообучаться :) как ты думаешь - почему люди сейчас приходят и участвуют? боятся пропусков или есть другие мотивы? Почему не использовать другую систему мотивации - позитивную? причем, чтобы её реализовать ничего не нужно. просто поднять портал - а там сами потянутся.
Автор: мне нравится аналогия с SG=agile проект. Есть цель к которой стремимся, есть митинги, на которые все дали обещание появляться вовремя и вообще, есть опоздавшие/пропустившие, с которых взимается штраф.
Денис: штраф в Agile - никогда не взимается. Такой практики никогда не было. То что придумывают некоторые люди - это их дело. Штраф - это не Agile.
Автор: см. "Dealing with latecomers " Henrik_Kniberg_-_Scrum_And_Xp_From_The_Trencheson
Денис: я этот источник знаю. Вопрос в другом - если у тебя есть два вида мотивации: положительная и отрицательная? зачем ты хочешь развить отрицательную? а не приложишь усилия развить положительную? не понимаю
Автор: не вижу как можно развить положительную мотивацию в подобном ключе. если есть такая US - давайте ее развивать.
Денис: создать другие US - которые привносят положительную мотивацию посящения ресурса, нежеле отрицательную мотивацию... типа я пошёл на каторгу, иначе будут считать прогулы.
Автор: как автор US не могу придумать позитивную US подобной силы эффекта разве что IPODы раздавать.
Денис: как ты думаешь люди с радостью пойдут на сайт, где их отрицательно оценивают?
Автор: людей оценивают объективно, по прогулам :) сорри, аут оф тайм нау.
Денис: вопрос а зачем оценивать людей?
Автор: людей оценивают объективно, по прогулам :) сорри, аут оф тайм нау.
Денис: вопрос а зачем оценивать людей?
Автор: оценок людям никто не дает, отмечаются пропуски.
Денис: а это не оценка ли? было действие: участника не было. а вот интерпретация уже другого человка в виде оценки - количество пропусков. кстати, наличие пропусков вызывает другую оценку... допущу о надёжности этого человека. вот так много мыслей возникает на пустом месте. зачем?
Денис: повторю вопрос: ты с радостью пойдешь на сайт, где считаются твои прогулы и сообщается это всем? а ещё есть шанс, что тебя могут исключить?
Автор: я пойду. радости мне это не доставит, горя тоже. гугл собирает мои поисковые запросы, одноклассники знают что я учил. это всего лиш фича, не больше.
Денис: а если этой фичи бы небыло - уже удовольствия от посещения было бы больше? а может если оценивались бы твои активности - например плюсами твои цитаты и ты попадал бы в рейтинг самых-самых с присваиванием статуса гуру и рекомендаций коллегам как эксперта в области? (кстати щас запишу US)
Автор: нет. надо?
Денис: не понял. если бы не было этой фичи, ты бы больше удовольствия от сайта получал бы?
Автор: эээ, мне фичи сайтов удовольствия не приносят. я работаю с тем что есть. оно может быть удобным или нет. если неудобно - это досадно. если удобно - значит так и должно быть.
Денис: как ты понимаешь, что тебе что-то удобно или нет? когда тебе удобно тебе приятней? или приятней когда неудобно?
Денис: да, ещё один нюанс. юзер стори пишется от первого лица. то есть ты реально этого хочешь? это реальное пожелание или выдуманное, а может кому нужно? формируя список требований к системе мы являемся её пользователями - свойство нашего проекта. то есть ты реально хочешь этим пользоватся и тебе важно наличие такого функционала?
Автор: я ж придумал это исходя из вопроса - "что надо сделать чтобы я всегда старался учавствовать в группе или хотя бы предупреждал владельца вовремя"
Денис: ну так реальную потребность нужно писать :) а там уже решения сами прийдут :) И это правильно - когда мы осознаем, что же реально мы хотим - это очень эффективно.

Стирание личной истории с точки зрения Agile

В Карлос Кастанеда - Путешествие в Икстлан (1972) говориться, что практика стирания личной истории очень полезная штука. Суть её в том, что ожидания других людей по отношению к моим действиям и бездействия уже запрограммированы в их головах. А если так, что мне из раза в раз нужно объяснять то или иное мое поведение/решение. Чтобы программы в головах у людей синхронизировались и поддерживались up-to-date. Это стиль "почему?".

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

Это классический пример показывает разницу работы в классическом стиле и в стиле Agile. В классической разработке мы планируем, строим ожидания, расстраиваемся, что мир меняется, и меняется неадекватно по отношению к нашим ожиданиям. Но если мы изменим модель мышления на стиль с "почеме?" на "зачем?". То всё срастётся и мы будем получать удовольствие, освободившись от энергозатратного предумывания и оправдения стиля "почему".

Кстати, для программиста желания обладать личной истории грозит психологическим заболеванием (или просто пофигистическим отношением к работе). Например программер набедокурил, что-то отъехало. Что мы делаем? Обвиняем - то есть используем историю. Лучший вариант разобраться в истинных причинах и самое главное выработать стратегию поведения, чтобы в следующий раз работать эффективней.

Кто что выбирает?

ЗЫ. На этот счёт есть русская пословица - "кто старое помянет, тому глаз долой".