вы будете держать на доске все когда-либо выполненные задачи на случай вдруг потребуется, что-то посмотреть?
Доска электронная она сама держит n последних задач. Если мне не хочется видеть, я эту колонку сворачиваю
Каждая колонка — это конкретная группа исполнителей, выступающая для одной соседней колонки потребителем, а для другой — провайдером.
Вы поделитесь источником этих сведений? Я, например, слышал наоборот, что это не личности а роли по отношению к конкретной задаче и команда может быть кроссфункциональной и, в частности, узкие места могут быть устранены тем что команда перераспледеляется между работами (программисты начинают тестировать, если тестировщиков в конкретный момент не хватает)
Это у вас не "готово" на самом деле, а "приём работы". Карточкам, по которым никаких работ больше не предполагается, делать на доске нечего. А если предполагаются, то так и должно быть написано, какие именно работы, а не абстрактное "готово".
Оно готово, но, например надо посмотреть какие-то детали для выполнения следующей задачи.
В контексте данного топика, отдел — это группа работников, решающая одного рода задачи.
Если один человек занимается разными колонками в канбане он меняет отделы в зависимости от текущей колонки?
Вы ранее, если я не путаю, писали что есть еще заявки от пользователей — или им занимается не ваш отдел?
Например, может быть такое, что с инфраструктурой что-то не так, а алерт не прилетел? Или алерт прилетел, но надо посмотреть что происходит в системе и приходится узнавать зачем пользователь Х запустил Y можно ли его сейчас прервать для перезагрузки и так далее.
Что до инцидентов, то обычно это идет или от мониторинга (тогда есть алерт и он является триггером), либо это приходит извне в виде тикета. В первом случае тикет скорее всего будет заведен уже сильно постфактум, ибо не до того
То есть инцидент есть, а в систему он не заведен. Его как бы нет. А зачем так? Почему не создавать инцидент автоматически при возникновении триггера? По крайней мере, будет общая очередь и понятно, что после чего делать и кто чем занимается.
По остальному — лично я не смогу через неделю уже сказать точно, чем я занимался и сколько времени потратил. Либо вы не такой как я и все очень хорошо помните, либо какие-то детали со временем теряются.
Чтобы понять кто раньше это делал, у кого можно узнать детали — ну, есть два варианта: либо я, либо мой коллега :)
А не может это еще быть пользователь, для которого важно решение инцидента, его руководитель и так далее?
Это бессмысленность части бюрократии. Бессмысленность бюрократии можно было бы показать если бы рядом было Адмиралтейство такого же размера и настолько же успешное но вообще без бюрократии.
И никто не сказал, что канбан-то не про то, как организовать работу в вашем отделе,
Можно ссылку на источник этих сведений?
Мне, например удобно видеть "Готово" потому, что иногда по недавно сделанным задачам возникают какие-то вопросы и если на электронной доске есть последние сделанные карточки их просто найти.
Также мне непонятно, почему, анализ / проектирование/ дизайн должны быть обязательно разными отделами.
Инцидент должен быть представлен, в какой-то форме, например в электронной. Если он просто сообщается в устной форме то потом трудно будет искать какие-нибудь детали по нему.
Если он представлен в электронной форме, его можно называть "карточкой".
Кроме того, чтобы решить инцидент можно использовать карточку:
чтобы посмотреть текущий статус и не отвлекать инженера от этого
чтобы посмотреть как подобные инциденты были решены ранее
чтобы понять кто раньше это делал, у кого можно узнать детали
чтобы агрегировать данные по инцидентам, посмотреть какие области наиболее подвержены инцидентам и с цифрами предложить какие-то решения по предотвращению дальнейших инцидентов
А вот отсутствия «менеджера по карточкам» никто и не заметит.
Я не знаю, кто такой "менеджер о карточкам". В вашей команде наверное все играют его роль, так как она небольшая?
Еще раз: откуда взялись три дня? Это на заполнение карточки с надписью "Авария" столько уходит?
когда она уже устранена — вносить ее в канбан просто нет смысла.
Это если вы знаете только одну вещь которую можно сделать с аварией — ее устранить. Если с карточкой аварии можно сделать, что-то еще то оно может приобрести смысл.
Канбан это немножко не то. Представьте, что у вас та система где вы учитываете заявки будет визуализировать их в том числе в виде доски. Будет установлен четкий лимит сколько вы можете брать заявок в работу, а если их будет больше вы будете не брать новые пока их число не уменьшится.
Возможно, потому, что Растом пока не пользуются уж очень сильно как совсем прикладным языком?
Для подобных задач достоинства Раста менее важны чемегонедостатки.
Обратите внимание, что в исходном примере на Delphi динамика скорее мешает
По сравнению с гипотетической отсутствующей системой, которая включает генерацию типизированной обертки по TLB, да. Но реально этой системы не существуют, возможно, потому, что ее сложнее делать чем просто вызвать метод IDispatch.Invoke пор строчке. При этом система на основе TLB будет работать только с теми приложениями, которые предоставляют наружу TLB а не всеми для которых работает OLE automation.
Отсутствие проверок типов это и достоинство и недостаток. Как и почти что угодно.
Например, возможность допускать неконсистентность в программе но при этом позволять быстрые изменения.
существование генераторов прямо сейчас я не проверял
Для прикладного программиста существование генераторов прямо сейчас может быть гораздо важнее, чем какие-то принципиальные возможности.
Например, представьте что вам прямо сейчас надо сделать простой отчет на Excel, сохранить его в PDF и отослать кому-то. Решение будет работать ровно в одной конторе для одного пользователя — бухгалтера Марии Васильевны, что вы выберете?
Интересно, что в интервью Андрея Бреслава, автора, Котлин "королю программирования" первый сказал, что какие-то возможности динамической типизации есть везде, причем в собственном стартапе они только сейчас доросли до того, чтобы начать применять typescript — cейчас все на JS.
Тем что никак не надо описывать нигде отдельно интерфейс Excel компонентов. И этот код можно скомпилировать на машине без установленного Excel.
Я не говорю, что этот подход во всем лучше чем Rust. Возможно, где-то есть библиотека, которая содержит макросы, которые реализуют type provider для библиотек типов COM, но это по своим свойствам будет отличаться от динамики — надо будет извлекать типы из excel, где-то их сохранять и так далее.
Почему?
Доска электронная она сама держит n последних задач. Если мне не хочется видеть, я эту колонку сворачиваю
Вы поделитесь источником этих сведений? Я, например, слышал наоборот, что это не личности а роли по отношению к конкретной задаче и команда может быть кроссфункциональной и, в частности, узкие места могут быть устранены тем что команда перераспледеляется между работами (программисты начинают тестировать, если тестировщиков в конкретный момент не хватает)
Источник вы не сообщили.
Оно готово, но, например надо посмотреть какие-то детали для выполнения следующей задачи.
Если один человек занимается разными колонками в канбане он меняет отделы в зависимости от текущей колонки?
Вы ранее, если я не путаю, писали что есть еще заявки от пользователей — или им занимается не ваш отдел?
Например, может быть такое, что с инфраструктурой что-то не так, а алерт не прилетел? Или алерт прилетел, но надо посмотреть что происходит в системе и приходится узнавать зачем пользователь Х запустил Y можно ли его сейчас прервать для перезагрузки и так далее.
То есть инцидент есть, а в систему он не заведен. Его как бы нет. А зачем так? Почему не создавать инцидент автоматически при возникновении триггера? По крайней мере, будет общая очередь и понятно, что после чего делать и кто чем занимается.
По остальному — лично я не смогу через неделю уже сказать точно, чем я занимался и сколько времени потратил. Либо вы не такой как я и все очень хорошо помните, либо какие-то детали со временем теряются.
А не может это еще быть пользователь, для которого важно решение инцидента, его руководитель и так далее?
Это бессмысленность части бюрократии. Бессмысленность бюрократии можно было бы показать если бы рядом было Адмиралтейство такого же размера и настолько же успешное но вообще без бюрократии.
Можно ссылку на источник этих сведений?
Мне, например удобно видеть "Готово" потому, что иногда по недавно сделанным задачам возникают какие-то вопросы и если на электронной доске есть последние сделанные карточки их просто найти.
Также мне непонятно, почему, анализ / проектирование/ дизайн должны быть обязательно разными отделами.
Инцидент должен быть представлен, в какой-то форме, например в электронной. Если он просто сообщается в устной форме то потом трудно будет искать какие-нибудь детали по нему.
Если он представлен в электронной форме, его можно называть "карточкой".
Кроме того, чтобы решить инцидент можно использовать карточку:
Я не знаю, кто такой "менеджер о карточкам". В вашей команде наверное все играют его роль, так как она небольшая?
Еще раз: откуда взялись три дня? Это на заполнение карточки с надписью "Авария" столько уходит?
Это если вы знаете только одну вещь которую можно сделать с аварией — ее устранить. Если с карточкой аварии можно сделать, что-то еще то оно может приобрести смысл.
А почему вы решили что канбан этого требует?
Насколько я знаю, там просто живая очередь работ (в отличие, от, например, скрама, где есть спринты).
Почему?
Насколько я понял они по факту выбрали сами пользоваться досками в итоге — т.е. заполнять их вручную или автоматически.
А зачем вообще нужен канбан? С точки зрения его сторонников?
Канбан это немножко не то. Представьте, что у вас та система где вы учитываете заявки будет визуализировать их в том числе в виде доски. Будет установлен четкий лимит сколько вы можете брать заявок в работу, а если их будет больше вы будете не брать новые пока их число не уменьшится.
Возможно, потому, что Растом пока не пользуются уж очень сильно как совсем прикладным языком?
Для подобных задач достоинства Раста менее важны чемегонедостатки.
Разумеется, к Мак ОС не подходят обновления от винды. Наверное, потому и раньше проблем не было.
IDispatch только
По сравнению с гипотетической отсутствующей системой, которая включает генерацию типизированной обертки по TLB, да. Но реально этой системы не существуют, возможно, потому, что ее сложнее делать чем просто вызвать метод IDispatch.Invoke пор строчке. При этом система на основе TLB будет работать только с теми приложениями, которые предоставляют наружу TLB а не всеми для которых работает OLE automation.
Отсутствие проверок типов это и достоинство и недостаток. Как и почти что угодно.
Например, возможность допускать неконсистентность в программе но при этом позволять быстрые изменения.
Для прикладного программиста существование генераторов прямо сейчас может быть гораздо важнее, чем какие-то принципиальные возможности.
Например, представьте что вам прямо сейчас надо сделать простой отчет на Excel, сохранить его в PDF и отослать кому-то. Решение будет работать ровно в одной конторе для одного пользователя — бухгалтера Марии Васильевны, что вы выберете?
Интересно, что в интервью Андрея Бреслава, автора, Котлин "королю программирования" первый сказал, что какие-то возможности динамической типизации есть везде, причем в собственном стартапе они только сейчас доросли до того, чтобы начать применять typescript — cейчас все на JS.
А, наоборот — клиента на Раст, который работает с чем-то через COM? Поддержка использования библиотек типов и так далее?
Тем что никак не надо описывать нигде отдельно интерфейс Excel компонентов. И этот код можно скомпилировать на машине без установленного Excel.
Я не говорю, что этот подход во всем лучше чем Rust. Возможно, где-то есть библиотека, которая содержит макросы, которые реализуют type provider для библиотек типов COM, но это по своим свойствам будет отличаться от динамики — надо будет извлекать типы из excel, где-то их сохранять и так далее.