Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Про GDD, ODD, FDD и безнадежный героизм

Я часто привожу в качестве примера отсутствия «внутреннего управления» (Innere Führung в Auftragstaktik) историю из жизни, вот решил её запостить:

Есть абстрактный разработчик, у него есть задача, которую он (сам, лично) оценил в неделю работы. Вот он садится в понедельник и начинает делать. К понедельник вечер он понимает, что не укладывается, потому что задача ни разу непрозрачная и оценка явно занижена. Он начинает применять friend-driven development: «хлопцы, памагите». Френды, ессно, не помогают — с наскока задачу не решить. Тогда он решает применить google-driven development и зарывается в готовый код. К среде становится понятно, что пора применять overtime-driven development и в среду он первый раз уходит заполночь.

К четвергу масштаб катастрофы приобретает отчетливые очертания экземпляра объекта класса completeWhiteFox и начинает интенсивно применяться fuck-up-driven development, хотя понятно, что работы ещё на неделю. Но этот FDD (пусть простит меня ДеЛюка :) позволяет ему в пятницу прийти сдаваться с чувством глубокого морального удовлетворения безнадежного героизма: «казните меня, но никто не может меня упрекнуть, что я не сделал все возможное».

Вот такая история. А счастье ведь было так близко, так близко...

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

LinkedIn



30 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Коментар порушує правила спільноти і видалений модераторами.

Коментар порушує правила спільноти і видалений модераторами.

Именно поэтому в Agile и рекомендуется все задачи с оценками более 16-20 часов разбивать на более мелкие. Если это правило соблюдается, то любой «провтык» по задаче всплывет на ближайших ежедневных митингах и позволит вовремя вмешаться тим лиду.

Agile тут совершенно не причем :) Многие практики проектирования говорит о том, что если задачу нельзя разбить на тайм-юниты 30...60 мин, то «вы значит не понимаете на самом деле, что вам нужно сделать в рамках задачи».

Для того, чтобы «всплыло» — одних митингов недостаточно. Тут скорее метрики прогресса по задаче закричат сначала, на митинге можно и полуправду сказать :)

Тут скорее метрики прогресса по задаче закричат сначала, на митинге можно и полуправду сказать :)

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

Вот именно поэтому, для поделенной на более мелкие части задачи, тревога бьется в день начала задачи :) Два дня — это много :)

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

Никто и не говорит про давление на девелопера :) Давить ни в коем случае нельзя

С другой стороны, деление задачи на юниты в 30-60 минут — это ИМХО микроменеджмент в чистом виде — раз (а вы все же ратуете за Auftragstaktik, если я правильно понимаю?), и насколько оправданы накладные расходы на столь подробную декомпозицию — тоже вопрос открытый, два. Эдвард Деминг не зря вводил понятие «common cause variation», по ссылке ниже есть подробная статья на тему:

FROM CHANGE TO VARIATION PART 2

С другой стороны, деление задачи на юниты в 30-60 минут — это ИМХО микроменеджмент в чистом виде — раз (а вы все же ратуете за Auftragstaktik, если я правильно понимаю?), и насколько оправданы накладные расходы на столь подробную декомпозицию — тоже вопрос открытый, два

Микроменеджмент не обязательно делжен быть со стороны менеджера, не так ли? Разве постоянная (несколько раз в день) верификация прогресса по критериям успеха разработчиком не есть микроменеджмент? Эта та сторона Auftragstaktik, которая говорит, что исполнитель отвечает и за путь решения задачи, а не только за достижение цели :)

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

Естественно, степень декомпозиции должна быть плавающей, в зависимости от уровня сложности задачи — чем менее рисковая задача, тем грубее и интервальнее оценки, чем рисковее и непонятнее — тем точнее. Если оценить рисковую задачу нельзя — T&M с отсечкой по времени/объему работ. Но, в итоге, рисковые задачи декомпозированы как можно более детально.

Кстати, 30-60 мин — это эмпирика, привязаная к персональным тайм-юнитам :) Критерий останова декомпозиции — понятность реализации и приемки, естественно, а не неделимость :)

замечательные аббревиатуры для bullshit bingo ;)

ну типа стебаюсь над плодящимися XXX-driven :)

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

А надо было просто сделать переоценку времени.

для начала, нужно было просто сдаться :) чувство «ложной профессиональной гордости», как я его называю — отличный мотиватор заметания проблем под ковер.

не, не сдаваться нельзя :) прижатые к стене, мы обретаем точку опоры :)

Уметь сдаваться — это zero skill для человека, который превращает идею в продукт :)

Признавать ошибки — да, сдаваться никогда :)

А признавать ошибки и сдаваться — не одно и то же? :)

семантика немного разная, сдаваться как-то безапелляционно и бесперспективно звучит :)

ну а если серьёзно, уметь вовремя "почувствовать"\"увидеть" точку не возврата ещё та себе нетривиальная задача. особенно в условия повышенной неопределённости, что очень характерно для разработки ПО.

Это характерно не только для ПО :) Любая область с высокой степенью неопределенности — экспериментальная физика, военное дело, инженерия массового производства и т.д.

С учетом, что систему ценностей agile породили военные, то паттерны есть :)У меня есть отдельный семинар посвященный «точкам невозврата» — все нетривиально, но реализуемо. А у военных, кстати, цена вопроса ещё выше и неопределенностей больше :) Решают же :)

Отлично, чтобы не «расплываться», просуммирую:

Почему ПО и например военное дело можно сопоставлять, но нельзя сравнивать

1. Высокая степень неопределённости: в разработке ПО она сильно меняется во времени, а для военного дела — это сложность комбинаторного пространства: топология населённого пункта, время года\суток, возможность применения того или иного вида оружия и пр. Появление новых технологий и вооружение на порядок медленне чем в ИТ. Инкубационный период накопления знаний разный.

2. Бюджеты. Тут всё понятно. Вон Nokia c 5000 разработчиков и Symbian. Военные бюджеты на много, много порядков больше любых ИТ. И это в том числе позволяет им решать свои задачи удовлетворительно.

3. ИТ персонализированная область. Человек не хочет признавать свои ошибки — это выводит его из области комфорта. В армии проще — в стенке и все дела.

Что хочу сказать:
1. Согласен, что ИТ не чем качественным не отличается от любой другой «хозяйственной» деятельности. И все задачи планирования и управления рисками решаются на ура — было бы желание.
2. Но, я не то что бы «против», я «не за» использования

(Innere Führung в Auftragstaktik)

как базового инструмента. В ИТ принцип простой: если можно удалить человека из цепочки — это нужно сделать, если можно принять коллегиальное решение — принимай.

Поэтому сетование на то что разработчики провтыкивают со сроками и оценками рисков — охолождение кондиционером улицы :)

Вон ISO тоже порождение военных и также отлично «кладётся\ложится» на разработку ПО :)

1. Высокая степень неопределённости: в разработке ПО она сильно меняется во времени, а для военного дела — это сложность комбинаторного пространства: топология населённого пункта, время года\суток, возможность применения того или иного вида оружия и пр. Появление новых технологий и вооружение на порядок медленне чем в ИТ. Инкубационный период накопления знаний разный.

как мило ты выбросил «комбинаторное пространство» для ПО, оставив ему только время :) Скажи, кстати, где можно посмотреть сравнение периодов накопления знаний. И, кстати, когда была выдвинута функциональная парадигма? И, кстати, я бы посмотрел на сравнение длительности внедрения военных и гражданских программно-аппаратных комплексов.

2. Бюджеты. Тут всё понятно. Вон Nokia c 5000 разработчиков и Symbian. Военные бюджеты на много, много порядков больше любых ИТ. И это в том числе позволяет им решать свои задачи удовлетворительно.

Мы же сравниваем факты, что разработка ПО и военная операция с точки зрения семантики — проектная деятельность с большим количеством рисков и могучим фактором неопределнности. И почему военная операция по доставке вагона снарядов из А в Б должна быть априори дороже разработки и внедрения проекта по системе управления средним предприятием?

3. ИТ персонализированная область. Человек не хочет признавать свои ошибки — это выводит его из области комфорта. В армии проще — в стенке и все дела.

Ух ты! Мы столкнулись со знатоком армейских принципов управления :) Владислав, не все так черно-бело, как ты говоришь :)

2. Но, я не то что бы «против», я «не за» использования

(Innere Führung в Auftragstaktik)

как базового инструмента. В ИТ принцип простой: если можно удалить человека из цепочки — это нужно сделать, если можно принять коллегиальное решение — принимай.

Поэтому сетование на то что разработчики провтыкивают со сроками и оценками рисков — охолождение кондиционером улицы :)

Вон ISO тоже порождение военных и также отлично «кладётся\ложится» на разработку ПО :)

Иными словами, ты против того, что:
— задача разработчику ставится не в терминах решения, а в терминах проблемы (цели, намерений)
— разработчик инициативен
— разработчик отвечает за решение задачи

— разработчик отвечает за достижение цели

И ты за то, что разработчик наказывается за неправильное действие, а не за бездействие.

Предлагаю прекратить этот спор — слишком разные у нас мировоззрения :)

С уважением

Сдатся и отступить — это немного разные вещи ;)
Хотя и выглядят похоже.

Как Вы представляете отступление? И сколько времени уйдет на этот маневр? :) А как же визибилити? И в чем стыд сдаться заказчику и признаться в том, что что-то не получилось. Главное — это сделать вовремя :)

Главное — это сделать вовремя :)

Ну эт само собой понимаетсо :)

Как Вы представляете отступление? И сколько времени уйдет на этот маневр?

Сколько надо. Есть такое понятие «риски» и кажись кусок математики который занимается их исследованием. Касательно «времени на маневр», чем раньше начать тем меньше, как правило.

А как же визибилити?

К сожалению не знаком с эти термином в контексте разговора, если можна то ссылочку на почитать.

И в чем стыд сдаться заказчику и признаться в том, что что-то не получилось.

Внутреннему руководителю (типа ПМу) можно и сдаться (передать задачу другому разработчику) и отступить (попросить больше ресурсов, например времени).

Говорить заказчику что не справляемся, то же можно, но это уже задача ПМа, а не ДЕВа. Кстати, тот же ПМ должен был заложить риски с окончательную дату сдачи, так что при его правильной работе заказчик в принципе может и не узнать что получается, а что не очень.

Ну эт само собой понимаетсо :)

Не всеми, не всеми :)

Сколько надо. Есть такое понятие «риски» и кажись кусок математики который занимается их исследованием. Касательно «времени на маневр», чем раньше начать тем меньше, как правило.

Я к тому, что лавирование может отнять драгоценное время. Чаще удобнее просто тупо сдаться и потратить время не на политесы, а на разруливание. Но, это если вы с заказчиком на одной странице :)

К сожалению не знаком с эти термином в контексте разговора, если можна то ссылочку на почитать.

Это когда заказчику доступен реальный прогресс по задачам. Ссылку влет не дам, надо поискать.

Внутреннему руководителю (типа ПМу) можно и сдаться (передать задачу другому разработчику) и отступить (попросить больше ресурсов, например времени).

Говорить заказчику что не справляемся, то же можно, но это уже задача ПМа, а не ДЕВа. Кстати, тот же ПМ должен был заложить риски с окончательную дату сдачи, так что при его правильной работе заказчик в принципе может и не узнать что получается, а что не очень.

У меня другая трактовка сдаться и отступить. Касательно ролей и кто должен говорить заказчику горькую правду — тут все зависит от проекта. Есть ситуации, когда ни ПМ, ни Дев это не делают — делает аккаунт или CTO, CEO, etc.

«Решить уравнение, значит найти все его корни или доказать, что корней нет»
© Учительница математики.
О чём говорит эта замечательная последовательность аббревиатур?
О том, что задача естимирования не решается эффективно в базисе одного индивидума.

Разделение ответственности или Planning poker спасёт отечественного разработчика.

Решается эта задача при грамотных проектировании и фреймворке принятия решений :)Касательно Planning poker — не могу пока понять, чем он может помочь в условиях отсутствия у разработчика внутреннего управления и зашитой на уровне спинного мозга необходимости верификации своей работы, сиречь «микроменеджмента задачи»?

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

иными словами — нормальную среду человеческих взаимоотношений без двойных стандартов?

бонусы не работают или работают со сбоями — нужно то самое Innere Führung для гарантии.

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

Любое обращение в внутренним составляющим разработчика(личности, воспитанию, мотивации и пр.) только добавляют неопределённости и рисковости. Демократия — зло, она закончилась вместе с Римской империей, когда действительная связь граждан и государтсва имела место быть, а сейчас это не более чем инструмент в зомбо-... (дальше по-вкусу).

Принципы

Innere Führung

как всегда с такими вещами — просты и гениальны. Но что-то мне подсказывает, что нам до них чуток дальше, чем до Гражданского Общества. Немного — парсеков 100 :)

Владислав, ты как-бы приписываешь мне вещи, которые я не говорил, или я чего-то не понял?

Я нигде не говорил, что обратная связь руководителя не нужна разработчику и достаточно только внутреннего управления :)

Также, нигде не говорилось о том, что Innere Führung — система ценностей, которая проста и гениальна :)

Підписатись на коментарі