Коллеги, внимание!
Форум переехал в Facebook в нашу группу «Фокусировка на главном».
Прошу задавать свои вопросы и открывать новые темы в группе, там вы сможете оперативно получить ответы.
Перейти в группу
- В этой теме 26 ответов, 5 участников, последнее обновление 8 лет назад сделано
.
-
Сообщения
-
Спасибо за список, такого я еще не встречал. Обычно все более размыто как-то.
Да сейчас мы и хотим переосмыслить ключевую функциональность и ее приоритеты, а главное привязать к проблемам пользователей, которые она решает.
Я бы еще к Виктору добавил про это НЖЯ:
Ресурсов на работу с техническим долгом выделяется крайне мало
Не очевидно в чем негативность этого явления. Ну мало и что… Видимо что-то от этого страдает — вот что страдает и есть НЖЯ. Данное явление может быть частью ДТР, но не НЖЯ. И слово «крайне» я бы исключил из формулировки. Это оценка и завуалированное решение.
2-е НЖЯ вполне такое НЖЯ если границы системы не залезают на финансы.
И опять добавлю к Виктору про 3-е НЖЯ:
У команды нет понимания, какую пользу приносит продукт
Опять же не очевидно в чем негативность. Им сказали сделать, они сделали. Не понимают в чем польза продукта, но продукт пользу приносит — не понятно в чем негативность.
То плохое следствие из этих двух явлений не является гарантированным — есть еще исходные посылки в совокупности с которыми в последствии получается НЖЯ.
Я довольно много сил и времени потратил на построение этого ДТР и меня результат устраивает
Смотря что было целью:
* Если научиться инструментам ТОС — Вы не использовали правильную методологию. Подход, который Вы использовали не гарантирует надежного результата.
* Если найти причину — тоже не очень. Потому что есть серьезное ощущение, что Вы шли уже к известной Вам причине, а не анализировали ситуацию.
* Если визуализировать свою интуицию — тут другое дело. Вы интуитивно нашли решение и отразили его с помощью дерева. Впринципе это возможно, только это не ТОС.Технический долг (также известный как долг кодинга) — это метафора-неологизм, обозначающая плохую продуманность структуры системы, непродуманную архитектуру программного обеспечения или некачественную разработку ПО.
Век живи — век учись ))). Я хоть и программист, но впервые слышу термин. Не признал сходу о чем речь.
В новом понимании негативность явления усилилась, но тут все зависит от границ рассматриваемой системы. Если мы целью видим разработку качественного ПО, то технический долг будет НЖЯ. Если мы целью видим реализацию проектов в срок — не всегда не оптимальная архитектура или структура будут НЖЯ. Так как если технический долг не вызывает отклонений от требований заказчика и сроков выполнения — он не проблема.Если визуализировать свою интуицию — тут другое дело. Вы интуитивно нашли решение и отразили его с помощью дерева. Впринципе это возможно, только это не ТОС.
Да, мне кажется именно это я и построил. Мы обсудили ДТР командой и многие замечания в этой ветке оказались верны, например:
-Часть НЖЯ звучат, как обвинения и у нас были споры на эту тему, видно, что задело кого-то.
-Корневая проблема очевидной показалась лишь программистам, остальные не смогли опровергнуть, но видно, что дереву не очень верят.Но разговор был очень полезный, все же визуализация помогает, пускай и моего личного видения ситуации.
Хочу попробовать метод 3-х тучь, кажется есть понимание, как начать, осталось время выкроить.
Вот тут еще нашел описание метода, более подробное:
CCRT 3 Cloud MethodДело не в тучах! Не важно строите ли вы ДТР (хотя этот метод практически всеми признается самым спорным по результативности и самое главное повторяемости) или используете систему 3-х туч. Может быть еще какие то методы, суть не в этом.
Пока вы не поймете что именно и для решения каких задач вы делаете, пока ваши действия не обретут осмысленность вы обречены на поиски не самых рациональных решений. Вы не в силах скорее всего заранее описать всё в деталях о вашем программном продукте, каким он будет на выходе и сколько времени это займет, но вам вполне о силам включить в разработку людей, которым предстоит это использовать. Чтобы с их помощью вы поняли какой функционал жизненно необходим, а что может подождать. В общем для разработки ПО более умных методов чем scrum пока не придумали. Сколь бы не обижались последователи ТОС )
Дело не в тучах! Не важно строите ли вы ДТР (хотя этот метод практически всеми признается самым спорным по результативности и самое главное повторяемости) или используете систему 3-х туч. Может быть еще какие то методы, суть не в этом.
Николай, не разгоняйтесь. Метод 3НЖЯ не отменяет построение ДТР. Изначально (начало 90-х) тосовцы строили сразу ДТР — в итоге дерево либо отражало интуицию как у Филиппа, либо расползалось черте знает куда. Поэтому был формализован метод, которым пользовались опытные консультанты ТОС.
1. В его основе лежит понимание, что менеджмент не желает чтобы в системе были НЖЯ. Он прекрасно понимает что они есть. Он прекрасно знает как их убрать. Но не может. Вот тут и зародилось понимание конфликта. Если НЖЯ есть в системе — значит менеджмент находится в конфликте. К НЖЯ находится такой конфликт через построение тучи НЖЯ.
2. Вторая важная опора этого метода — исходная посылка что существует конвергенция. Т.е. сходимость причин. Поэтому на основании одного НЖЯ нельзя сделать вывод что мы охватили существенную область. Было принято решение брать 3 НЖЯ и строить для них тучи (хотя можно брать и 5).
3. И последний важный столп — повышение уровня абстракции. Именно он вызывает сложность принятия. Три полученные тучи берутся и консолидируются в одну. Чтобы получить общую причину мы вынуждены поднять уровень абстракции. Это метод интуитивный, однако достаточно жесткие требования к туче позволяют получить достаточно точную тучу. 3 НЖЯ были выбраны, потому что 5 явлений много сложнее обобщить чем 3. Чтобы получить ключевую тучу (проблему) — включены должны быть все НЖЯ. Если тучи никак не консолидируются — возможно у нас несколько корневых туч (не путать с ключевой тучей).
И уже после консолидации строится ДТР с корневыми тучами в основании. Оно опять же проверяется на логику. В итоге мы получаем очень сфокусированное дерево, с конфликтами в основании, надежно приводящее к НЖЯ.
Предсказать что будет ключевой проблемой до такого анализа практически не возможно (особенно в таких нетипичных случаях как этот). Именно поэтому мы с Виктором по-рекомендовали пойти этим путем. Уверен, что Филлип еще не нашел ключевую проблему.
PS Есть подход, предложенный Деттмером, без 3НЖЯ через построение IOM (карту промежуточных целей). Я пробовал оба — на мой взгляд IOM хорош для выбора НЖЯ, а ДТР надежнее с 3НЖЯ получается.
В общем для разработки ПО более умных методов чем scrum пока не придумали. Сколь бы не обижались последователи ТОС )
Мне кажется бравировать термином SCRUM или Agile перед человеком, знающим термин технический долг несколько не осмотрительно… 😉 Более чем уверен что их команда работает по agile-технологии.
Похоже, я не знаю, что такое технический долг. Интуитивно я думал, что ранее было что то важное пропущено в разработке и теперь, поскольку все время надо двигаться вперед, нам все время некогда наверстать упущенное. Как в производстве — мы запустили изделие в производство, но не разработали до конца техническую документацию или оснастку. Я не прав? Чувствую, что я что-то опускаю важное…
Виктор, очень близко. Команда с разрешения Заказчика берет долг улучшить систему и реализует заплатку на первое время, что позволяет выдерживать сроки. Но долг впоследствии должен быть устранен. Это исходное понимание. Но термин разросся и под ним стало пониматься также отступление от правильной архитектуры. Т.е. то чего Заказчик не видит (если глубоко не контролирует разработку). Вместо какого то блока архитектуры лепится простая «заплатка под текущую ситуацию». С точки зрения кодеров — это плохо. Однако с точки зрения Заказчика не всегда… Как пример: Заказчику VW предложил бы подождать его автомобиль еще пару лет, пока они добьют чтобы движок выдавал требуемые параметры по СО2, либо сделают заплатку, определяющую подключение и включающую спецрежим работы, чтобы показатели замера удовлетворяли власти. Заказчику в основном пофигу на эти замеры — он предпочтет получить автомобиль быстрее, хоть внутри он и не совсем правильный с точки зрения разработчика.
Проблема технического долга такого рода в том, что эти заплатки накапливаются и разработчик вынужден больше бороться с устранением глюков («протечек сквозь заплатки») чем с реализацией новой функциональности. Обычно наступает коллапс, когда принимается решение и система перерабатывается полностью.
Нашел очень подробную презентацию, как применять метод 3-х туч. Прямо с примерами. Буду пробовать. Вроде понятно, как это работает.
Уверен, что Филлип еще не нашел ключевую проблему.
Да, мне тоже так кажется.
Буду строить тучи для:
НЖЯ1. Внесение изменений в продукт требует больших трудозатрат
НЖЯ2. Полное тестирование продукта возможно только на площадках клиентов.
НЖЯ3. Пользователи не могут дать обратную связь.Спасибо за обсуждение, очень полезно для меня оказалось.
PS В термине технический долг, очень важно, что он выплачивается с процентами (technical debt). И если залезть в кредиты слишком сильно, то огромное количество ресурсов начнет уходить на обслуживание этого долга. Вообще в разработке ПО, главная проблема — это экспоненциальный рост стоимости разработки со временем (с увеличением функциональности продукта). Чем более пологой сможет сделать команда эту самую кривую, тем дольше можно будет развивать продукт.
[quote quote=9140]PS В термине технический долг, очень важно, что он выплачивается с процентами (technical debt). И если залезть в кредиты слишком сильно, то огромное количество ресурсов начнет уходить на обслуживание этого долга.[/quote]
В термине «технический долг» заложена еще и скрытая угроза. Фактически вы не знаете сколько времени займет закрытие ТД, более того с течением времени он самопроизвольно растет. Не знаю замечали ли вы в вашей работе, что исправление ошибок занимает тем больше времени, чем больше времени прошло с момента завершения данной работы.
То, что сегодня могло бы быть исправлено на несколько минут, через неделю займет уже час и более, а через месяц может занять весь день. Причина в той куче сопроводительной информации, которая хотя и не формализована, но необходима для качественного решения конкретной задачи. Пока вы в теме (вся инфа еще в головах) — исправления максимально быстры, проходит время и вы уже что-то упустили, а потом и вовсе забыли, все уже поменялось и в головах инфа от других задач.
Трудоемкое это занятие, может из-за нехватки опыта. Пока получилось, то что в атаче. Не все места мне там нравятся, но есть в основании конфликт, который более менее понятен.
Не знаю замечали ли вы в вашей работе, что исправление ошибок занимает тем больше времени, чем больше времени прошло с момента завершения данной работы.
Да это точно есть. Мы один компонент очень долго стабилизировали, буквально ходили по кругу, т.к. этап тестирования его занимал несколько дней. Программисты слишком поздно узнавали о том, что исправив одно мы сломали другое. Было противоречие в требованиях, но мы его не могли отследить, т.к. за неделю пока к нам прилетят баги, мы уже в контексте других задач. Когда поняли, что ограничение для нас в данной работе — это время тестирования, написали приемочные тесты. Эта работа заняла недели 2, но после этого проблемный компонент перестал быть проблемным, т.к. программисты узнавали о внесенных ошибках еще на этапе разработки.
- Форум «Теория ограничений: инструменты и практика» закрыт для новых тем и ответов.