Технічний борг або Право на вибір

Дійсно правда, що наша увага фокусується сильніше на предметах і явищах які ближче до наших тактичних задач. Воно, так би мовити отримує додаткову «прив'язку» на такі об'єкти. Працюючи над поверненням технічного боргу, за останні кілька днів побачив безліч статей постів на цю тему. Таке відчуття, що тільки лінивий про це не писав:). Не буду переказувати те, що написано тут та тут , а зосереджуся на прикладному аспекті питання.

Давайте відштовхнемося від уже загальноприйнятого термального елемента - спринту .

Обговорюючи ту чи іншу задачу, у Вас є два шляхи її вирішення:

  1. «Quick Win» - частіше пропонується менеджментом, характерний швидким досягненням результату за рахунок цього самого технічного боргу, коли «латочка» краще ніж дизайн .
  2. «Long way» - на противагу першому, має місце бути, коли у Вас достатньо ресурсів і Ви змогли переконати керівництво в необхідності прототипування, UML-ювання та бла, бла, бла:)

Неможливо сформулювати правила на всі випадки життя - де краще застосовувати перший, а де другий метод. Тут, так би мовити «up to you and your project». Головне щоб рішення було зваженим і задовольняло обидві сторони на поточному етапі проекту.

Але найцікавіше попереду.

З пунктом 2 всі зрозуміло - у Вас карт-бланш і якщо Ви провалили терміни, то робимо собі харакірі down-level senior->professional і читаємо мат частину.

А ось пункт 1 і є Ваш Інь-Ян. Приймаючи його, Ви ділите завдання на дві частини: перша буде реалізована в цьому спринті, друга - колись потім. Так ось часто , дуже часто , завжди про другу частину забіваютзабивают.

«Я як би за рівність статей, але тільки не в моєму гаремі», тому виробив наступну стратегію:

  1. при виборі «Quick Win» стратегії, завдання розбивається на дві (crt.fopen vs boost.iostreams)
  2. Для обех завдань окреслюється обсяг роботи (read settings vs preferences.subsystem) та здійснюватися оцінка (1m/h vs 4m/h)
  3. Перша частина заноситься в поточний спринт друга в back-log проекту
  4. перед початком наступного спринту, аналізується можливість повернення боргів за деякими пунктами і вироблятися переоцінка за рештою боргами.

Який вихлоп:

  1. Завжди перед очима величина технічного боргу.
  2. Дисбаланс нові фічі борг на спринті використовується як параметр ризик-менеджменту
  3. І крамольна фраза «Ну я ж казав ...» вже не просто струс повітря.

Можна говорити про технічний борг, як про тезу, який досить широко поширений і висловлюється думка про необхідність постійного рефакторінгу коду. Його відлуння можна знайти і в ISO в пунктах, що стосуються постійного поліпшення ISO 9001:2008 8.2. І як частина нашого світовідчуття в побий ціна якість.

Але є проекти, мета яких повернення технічного боргу попередніх розробників і в таких випадках подвійна боргова вкладеність і як наслідок, часто «хочеться нажраться в гов .. і заграти пару старих хітів »:)

Опубліковано: 14/06/11 @ 03:42
Розділ Різне

Рекомендуємо:

Мозковий штурм в блогінгу
Бесіда Метта Катсу з Денні Саливанов про Панде 2.2
Конференція Яндекса «Новий маркетинг і змішання реальності»
Новий конкурс від webeffector "Просування неминуче" на $ 6000
Тепер і Яндекс підтримує rel = canonical