Здравствуйте, Gaperton, Вы писали:

G>наличием приоритетов по срочности работ (что приводит к "грязным решениям")

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

Здравствуйте, ironwit, Вы писали:

G>>наличием приоритетов по срочности работ (что приводит к "грязным решениям")

I>перечитывал старую тему, с целью вырости над собой и увидел оставленную фразу. не сможете более подробно её прокомментировать? что имели в виду когда писали одновременно приоритетность срочности и грязные решения? заранее спасибо.

Пример из реальной жизни №1. Приходит дефект, приоритета 1, северити feature failure (полная неработоспособность фичи). До релиза — день. Разбирательство показывает, что год назад неправильно исправили другой дефект, который породил два новых. Они были найдены, и их закрыл другой человек, у него это почти получилось, но в одном неочевидном, однако — распространенном сценарии, случается задница.

По хорошему, надо все безобразие откатывать, и исправлять правильно. Однако, времени нет, и мы серьезно рискуем сорвать релиз. Собрали консилиум. Приняв во внимание все факторы, решили хирургически хачить поверх, и доказать корректность поведения формально. Операция заняла примерно 3 часа, два человека (я и Дима Осовский) "накладывали швы", внимательно следя, что учтены все побочные эффекты. Баг закрыли.

Пример номер два.

Делали одну штуковину, при ее дизайне упусти один юзкейс. Вспомнили о нем тогда, когда все было написано, и проверено, и пришло время его добавлять. Он был такой неудобный, при внешней безобидности, что пришлось бы все выбрость, и переписать — он менял весь дизайн радикально, и ничего "порефакторить" просто не получится.

Приняли решение делать "грязно". Сделали.

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

Здравствуйте, EM, Вы писали:

G>>Далее — в течени полугода Ян МакФэйден быстро, четко, без истерик и лишних движений, комплексом мер эффективно решил проблемы с качеством клиента CQG — проблема тогда была, что темп появления дефектов превышал темп их исправления, и никто не знал, что делать.

EM>Выделенное глубоко верно, но это и так все знают.
EM>Более интересно, какими именно мерами он "эффективно решил проблемы с качеством клиента CQG" ?

Ввел и наладил работу...
1) ...схемы приоретизации дефектов и планирования релизов. Дефекты начали сортировать по принципу value-cost, для этого собирался специальный triage meeting. Его МакФэйден вел лично.
2) ...а также улучшения маршрутизации дефектов и простейшей схемы контроля качества. МакФейден ввел код-ревью — все чекины, в которых не прописана фамилия проверяющего, отклонялись. Проверяющий был всегда компетентен в тех модулях, к которым относились исправления(была собрана матрица компетенции, которая применялась при назначениях). Это снизило количество дефектов, которые вносились исправлениями других дефектов.

Вот и все. Умница МакФейден. Как-то тихо все через полгода все забыли о проблемах с дефектами, когда схема заработала.

Я не так давно повторил этот фокус на последнем месте работы. Комания никак не могла выпустить maintenance release в срок, и каждый раз это было дикое напряжение и аврал — по 4 месяца задержки были. И вдруг через несколько месяцев — о чудо . Как-то незаметно и без напряжения все вдруг с удивлением обнаружили, что очередной maintenance release к выпуску готов . Странно, никто задницу на британский флаг не разрывал. Одна проблема — как-то слишком быстро и незаметно как-то все получилось, и customer support не успел поставить предыдущий release всем клиентам

А всего-то надо было делать несколько простых вещей. 1) code freeze — не подбрасывать в релиз, который проходит системный тест исправлений новых дефектов, просто потому, что "он все равно сломался" 2) Исправлять дефекты каждую неделю, не забивая на них полный болт. Скажем, по одному дню в неделю выделить на них каждому программерут 3) Иметь четкую отсечку по времени по выпуску каждого релиза. 4) разделить "зоны ответственности" между программистами, чтобы равномерно размазать по нима нагрузку по maintenance 5) и аккуратно управлять приоритетами, постоянно имея в виду всю эту схему — чтобы в первую очередь исправлялись критичные для кастомеров дефекты.

И все. Эти простые правила не напряжны для всех, и воистину творят чудеса Пункт 6) про code review — чтобы снизить количество неверных исправлений, я не смог до конца претворить в жизнь как непреложное правило (для этого нужна была новая инфраструктура билдов-VCS-issue tracker), но зоны ответственности уже положительно повлиял и на количество неверных исправлений.

EM>Кстати, я за этим чудо продуктом трейдил еще 9 лет назад и до сих пор этот ужас не забыл.

Не такой уж и ужас. Впрочем, было бы любопытно узнать, что именно вам не нравится в этом продукте — я это с удовольствием передам своему бывшему коллеге, который сейчас директор свой собственной конторы, и делает конкурента CQG . Заодно, расскажу, что из этого мы исправили с 1999 до 2005 года .

G>Через несколько месяцев, на последнем этапе тестирования (угроза срыва релиза), тестеры нашли маленький, но жутко неприятный дефект. Класса feature failure. Я заглянул в код, и понял, что наше "грязное решение" содержит ошибку — оно целиком полагалось на побочные эффекты, и мы кое-что пропустили. Я это быстро заткнул, и отправил исправление. На протяжении последующих двух недель ко мне пришло еще 4 подобных дефекта по этому же коду. Я понял, что надо было сразу переписать, и зарядил одному из программеров его переписывание. Однако, когда я затыкал его в пятый раз, и на код ревью корректность работы кода была доказана формально, я не стал чекинить новый "чистый" код, оставив старый. Новый код был отложен. Понятно почему?

Это важно, и требует пояснения. Этот модуль, который был "грязный", и из него перли баги, был очень хорошо изолирован от остального кода, и я не ожидал в нем никаких правок в ближайшие несколько лет с вероятностью 99,9%. Мы закрыли дефекты в нем с высокой вероятностью быстро, подняв "хрупкость" этого кода и цену внесения изменений в него до невообразимых высот. Но штука в том, что в него не будет внесено изменений в ближайшие несколько лет! А за очередную багу в этом релизе тестеры с дельмом съедят, они были в бешенстве.

Таким образом, принятые нами меры на каждом отдельном этапе были оправданы. Ну, а на тот невероятный случай, если вдруг в него будет вносится правка (типа риск), мы запланировали его рефакторинг, и в загашник был отложен новый код, который менее "хрупок" (типа mitigation plan). Вот так в реальной жизни и живем.

И не надо мне говорить, что надо предварительное проектирование лучше делать . Сам знаю . Это, во-первых, ошибки молодости, на которых я учился, во-вторых, именно о важности предварительного проектирования я и говорю во всей этой теме . Так что, можно считать это еще одним аргументом против agile в понимании XP и scrum.

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

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

Здравствуйте, Аноним, Вы писали:

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

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

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

Курилка пишет:

> 1. Необходима большая вовлечённость пользователя в процесс разработки

да, ублюдкам, которые "хочу что-то, сам толком не знаю что" это не
подходит

> 2. Требования меняются и развиваются (не подходит, как минимум, для
> "fixed price" проектов)

как компромисс — рассматривать fixed price на итерацию, естественно
после согласования входящих в нее фич и договоренности ничего не менять
до выпуска версии.

> 3. Требования создаются минимально достаточными (легче отрефакторить
> решение, чем спроектировать всё детально заранее)

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

> 4. Тестирование задейстовано в течение всего процесса разработки.

дык это даже плюс, имхо

> 5. "Частые поставки" (Frequent delivery), которые могут быть достаточно
> накладными

если проблема в ресурсоемкости самого процесса передачи версии — надо
подумать как это можно автоматизировать. На одном из моих проектов
installation manual с 2х страниц (которые программер на стороне
заказчика с 1го раза никак не мог осилить, хоть и написано было
предельно просто ) мигрировал до одного install.sh, который все
делает сам.

> 6. Судя по откликам, agile-подходы напряжённы (intense) по отношению к
> разработчикам (100% реализация фич за итерацию и неукоснительность
> итераций "накладывет отпечаток")

бодрый тонус и рабочий темп не есть плохо. гораздо напряженнее
доделывать недостающие 99% в ночь перед дедлайном

--
np: [foobar2000] not started

Здравствуйте, Курилка, Вы писали:

К>Собственно наткнулся на статью, где автор выделяет следующие недостатки agile-подходов:
К>1. Необходима большая вовлечённость пользователя в процесс разработки

Об этом очень хорошо писал Спольски (русский перевод):

Если бы можно было всверлить с помощью самой мощной дрели DeWalt только одну мысль каждому начинающему консультанту в голову, то это было бы: клиенты не знают, что они хотят. Перестаньте ждать от клиентов, что они будут знать, чего они хотят. Этого никогда не случится. Смиритесь с этим.
Вместо этого, представьте, что вы всё равно что-то сделаете, и это должно понравиться клиентам, и будет это для них маленьким сюрпризом. ВЫ должны сделать иcследование. ВЫ должны придумать дизайн, который решает проблему клиента удобным для него способом.

Поставьте себя на их место. Представьте, что вы только что продали свою компанию Yahoo! за $100 000 000 и решили, что пора сделать ремонт в кухне. Поэтому вы нанимаете профессионального архитектора и объясняете, что «это должно быть круче, чем у моего друга Васи». Вы не имеете ни малейшего понятия, как это сделать. Вы не знаете, что вы хотите: комплект Bucalossi или плитку от Marazzi – это не входит в ваш словарный запас. Вы хотите, чтобы архитектор сделал что-то хорошее, и именно поэтому вы его наняли.

Адепты Экстремального Программирования говорят, что решение – позвать к себе клиента и включить его в каждый шаг процесса разработки дизайна, сделать его членом команды разработчиков. По-моему, это слишком «экстремально». Это как если бы мой архитектор показывал мне, как они разрабатывают дизайн кухни, и просил ответной реакции по каждой мелочи. Это надоедает: если бы я хотел стать архитектором, то я бы учился на архитектора.

Другое дело — что есть множество проектов, которые не по agile вообще не могут быть решены, вот и приходится мирится с таким недостатком.

К>2. Требования меняются и развиваются (не подходит, как минимум, для "fixed price" проектов)

Не неподходит, а сложнее. Просто нужно уметь заложить не-вполне-понятно-что в стоимость. Например, оценить за сколько Вы готовы сделать то, что видется только вначале заказчику и умножить на 10, 100 или 1000.

Да и сдался этот fixed price что ли? T&M для agile — нормально.

К>3. Требования создаются минимально достаточными (легче отрефакторить решение, чем спроектировать всё детально заранее)

Это вовсе не обязательно для agile в общем случае.

К>4. Тестирование задейстовано в течение всего процесса разработки.

Да, дорого.

К>5. "Частые поставки" (Frequent delivery), которые могут быть достаточно накладными

Это зависит много от чего... и не сильно актуально, IMHO. Обычно в agile решается один раз.

К>6. Судя по откликам, agile-подходы напряжённы (intense) по отношению к разработчикам (100% реализация фич за итерацию и неукоснительность итераций "накладывет отпечаток")

Да, есть такое, но это скорее по причине плохих менеджеров. Для agile квалификация менеджера должна быть очень высокой, чтобы не потерять управляемость.

Здравствуйте, LordMAD,

хоть пост и очень спорный, но за ссылку на статью Спольского (а особенно за ссылку в конце этой статьи на Планирование программного обеспечения малой кровью) большещее спасибо.

СУВ, Aikin

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

G>Видишь ли какая штука. По секрету говорю крамольную вещь — как бывший разработчик, а теперь как менеджер. Не надо иметь для этого ни веса, ни аргументов. Разработчик всегда имеет возможность сказать, что "время исправления дефекта займет много времени, он архитектурный". И все. Менеджер проверить не может никак. А вот как только ему дадут выбор — "могу быстро, могу медленно" — угадай результат.

Да, но ведь если так рассуждать, то разработчику никак не разыграть вариант с грязным исправлением и последующим рефакторингом. Либо он делает чистое решение и не успевает, либо делает затычку в срок, но теряет всякую надежду провести рефакторинг, т.к. нет дефекта — не о чем разговаривать.

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

G>Как менеджер говрю. Не надо ставить меня, менеджера, в положении выбора, когда у менеджера объективно недостаточно информации, чтобы принять решение. Это решение — уровня тимлида, только у него достаточно информации (еще один плюс к необходимости должности тимлида, которые полупрограммеры, полуменеджеры). Оно должно подниматься выше только при серьезных случаях. Обычно, в таких случаях уже поздно .

В такое положение не надо.

Наверное, у нас в головах крутятся разные сценарии, или разное понимание ролей. У меня такой:

День до релиза (до сборки, которая должна стать релизом). Найдена проблема, которая ломает какую-то feature.
Тимлид приходит к менеджеру и на его языке кратко излагает проблему, impact, варианты, риски, оценку трудозатрат и т.д. А также свои мысли по решению.
Менеджер, пропуская это всё через своё видение ситуации, может решить
* Выпустить релиз с дефектом
— возможно, выпустить отдельную заплатку вскоре
* Отложить релиз
* Отменить релиз
* Убрать/спрятать функционал с дефектом
* Вставить ту самую временную затычку. Запланировать рефакторинг/тестирование на следующую итерацию, пересмотреть scope.
(наверняка найдутся ещё варианты)

Т.е. насколько у менеджера не хватает понимания технического контекста, настолько у тимлида может не хватать понимания внешних отношений с клиентами, обязательств, пространства для манёвров и т.д.
Потому вместе они — сила, а по отдельности — 2 силы, но послабее =)

Здравствуйте, Аноним, Вы писали:

А>Да, но ведь если так рассуждать, то разработчику никак не разыграть вариант с грязным исправлением и последующим рефакторингом. Либо он делает чистое решение и не успевает, либо делает затычку в срок, но теряет всякую надежду провести рефакторинг, т.к. нет дефекта — не о чем разговаривать.

Вовсе нет. Давай разберемся в деталях, почему именно так стоит делать.
1. Чем плох "грязный" код? Высокой ценой внесения даже простых правок, он "хрупок", его легко сломать.
2. Вот допустим, "грязный" код отлажен и работает. Его надо ни с того ни с сего брать и рефакторить? Нет, не надо — зачем лезть в работающий механизм. Это не принесет абсолютно value. Ноль.
3. А вот теперь допустим, что мы для реализации некоторой feature, которая приносит реальный value, должны внести в данную подсистему исправления. Вот здесь — мы применяем для реализации данной feature двухфазную процедуру. Первым делом — готовим наши подсистемы к добавлению новой функциональности, проведя рефакторинг, и цикл тестирования. Вторым этапом — добавляем фичу начисто.
4. Или предположим, что к нам падает примерно 5 дефектов, относящиеся к "грязному" коду. Тимлид принимает решение закрыть все пять одним рефакторингом, заодно — посоветовавшись с менеджером выбирает из wishlist список фич, которые есть хороший и удобный повод накатить после.

Вот и все. Рефакторинг всегда проводится как часть работ, приносящих value, и его необходимость рассматривается постоянно. Это решение уровня тимлида.

G>>Как менеджер говрю. Не надо ставить меня, менеджера, в положении выбора, когда у менеджера объективно недостаточно информации, чтобы принять решение. Это решение — уровня тимлида, только у него достаточно информации (еще один плюс к необходимости должности тимлида, которые полупрограммеры, полуменеджеры). Оно должно подниматься выше только при серьезных случаях. Обычно, в таких случаях уже поздно .

А>В такое положение не надо.

А>Наверное, у нас в головах крутятся разные сценарии, или разное понимание ролей. У меня такой:

А>День до релиза (до сборки, которая должна стать релизом). Найдена проблема, которая ломает какую-то feature.
А>Тимлид приходит к менеджеру и на его языке кратко излагает проблему, impact, варианты, риски, оценку трудозатрат и т.д. А также свои мысли по решению.
А>Менеджер, пропуская это всё через своё видение ситуации, может решить
А>* Выпустить релиз с дефектом
А> — возможно, выпустить отдельную заплатку вскоре
А>* Отложить релиз
А>* Отменить релиз
А>* Убрать/спрятать функционал с дефектом
А>* Вставить ту самую временную затычку. Запланировать рефакторинг/тестирование на следующую итерацию, пересмотреть scope.
А>(наверняка найдутся ещё варианты)

А>Т.е. насколько у менеджера не хватает понимания технического контекста, настолько у тимлида может не хватать понимания внешних отношений с клиентами, обязательств, пространства для манёвров и т.д.
А>Потому вместе они — сила, а по отдельности — 2 силы, но послабее =)

Я в такой ситуации четко поставил тимлиду цель, разъяснил приоритеты, объяснил ответственность, и предложил принять решение самому. Он объясняет мне схему принятия своего решения, почему оно будет таким, какие альтернативы он рассмотрел, и если мне это кажется разумным, я его утверждаю. Пусть учится.

А рефакторингов планировать заранее не надо. Это решение каждый раз принимается при реализации полезных работ, и привязано к ним. Так — правильно.

Странно, а от куда может браться грязный код при адекватном менеджменте?

G> Рефакторинг всегда проводится как часть работ, приносящих value, и его необходимость рассматривается постоянно. Это решение уровня тимлида.

А что ты подразумеваешь под рефакторингом?

Здравствуйте, Аноним, Вы писали:

А>Странно, а от куда может браться грязный код при адекватном менеджменте?

Объяснил выше, в том числе и с конкретными примерами.

G>> Рефакторинг всегда проводится как часть работ, приносящих value, и его необходимость рассматривается постоянно. Это решение уровня тимлида.

А>А что ты подразумеваешь под рефакторингом?

http://ru.wikipedia.org/wiki/Refactoring

Gaperton пишет:

> А рефакторингов планировать заранее не надо. Это решение каждый раз
> принимается при реализации полезных работ, и привязано к ним. Так —
> правильно.

+1
Если конечно проект не в ж**е и рефакторинг не грозит затянуться на пару
месяцев

--
np: [foobar2000] not started

G>Я в такой ситуации четко поставил тимлиду цель, разъяснил приоритеты, объяснил ответственность, и предложил принять решение самому. Он объясняет мне схему принятия своего решения, почему оно будет таким, какие альтернативы он рассмотрел, и если мне это кажется разумным, я его утверждаю. Пусть учится.

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

G>А рефакторингов планировать заранее не надо. Это решение каждый раз принимается при реализации полезных работ, и привязано к ним. Так — правильно.

Для описанного (в предыдущем посте) примера это имеет смысл. Границы рефакторинга, его стоимость и риск не меняются со временем.

Если же проблема такова, что она гарантированно "всплывёт" позже, и задержка рефакторинга приводит к его удорожанию (новый код попадает под рефакторинг; тестирование после оного необходимо проводить заново), то не стоит откладывать.
Если обстоятельства позволяют сделать его сразу, лучше сделать сразу. Если же нет — запланировать наряду с другими задачами.