Я прочел не только Дао Тойоты, но еще и основополагающую литературу по тем принципам, которые сейчас модно называть Lean. Уверен, что вам известно, о ком/чем я говорю.
За сцылу спасибо, почитаю Андерсена.
Успех любой методологии познается в сравнении с другими методологиями, а не «реальными делами».
И уж если говороть о методологиях, то нет «методологии Канбан», есть «инструмент канбан», наряду с такими инструментами, как — «пока-ёке», «хансей-кайзен», «джидока» и ряда других. Только проблема ИТ в том, что мы схватились только за «канбан» и пытаемся обернуть 1 процесс производственного цикла в него, упуская все остальные. А это идет в разрез в принципами Lean, которые направлены на создание «value» на протяжении всего жизненного цикла продукта.
Благодарю за совет с работой — это в процессе, но, к сожалению, организаций с матричной структурой, а тем более проектной — очень и очень мало.
П.С. Я прочитал пост вашего начальника. Думаю, что вы должны объяснить ему, что Continuous Delivery пагубно сказывается на качестве кода, что, судя по комментам ИТТ у вас и так страдает.
1. "… конструктивное русло"
2. «Я не знаю, как спросить конкретнее.»
3. «Черт, вы можете ответить конкретно хоть на один вопрос?»
4. «никаких лулзов мы не словим»
толстячка не покормили?
Зато могу припомнить, сколько лулзов словили мы, когда в конце 2010го года сотрудники вернулись с конференции и рассказали, что спикер от вашей конторы сказал, что вы не используете свой же продукт для разработки.
Похоже в ДНК вашей конторы уже заложено, что вы будете просто «кодить» чьи-то готовые модели и следовать очередному тренду моды, нежели стараться понять суть вещей и улучшить их.
вы глубину своей мысли раскройте, а то никак не могу понять взаимосвязь кол-ва персонала в компании и подходом к управлению производством. Случай «сам себе начальник» не рассматриваю.
В попугаях, как это принято в agile/scrum.
Если вы о механизме, то в рамках текущей компании — никак, ибо не дозволено руководством. А в своей компании я бы использовал стат.методы и 6Sigma, например.
Может есть что-то еще, но я пока самообразовался только до нее.
Какие вам «конкретные примеры»нужны? Что мы создавали систему постоянного повышения квалификации или что реюзали компоненты, для повышения стандартизации и снижения вариабельности? Такими примерами можно пару скроллов исписать и к каждому можно еще анализ приложить что на что влияет, как связано и как формализовать использование.
Поэтому были сделаны обобщения на уровне подсистем.
Что я хотел от Вас услышать, что вы не еще одна жира, редмайн или очередное поделие Джоела Спольски. Что вы понимаете, что творится не только внутри software production, но и как оно происходит в других отраслях и готовы создавать уникальный и целостный продукт для индустрии. Похоже я этого не дождусь. Жаль, что компетенции вашей компании ограничиваются только 1/14 от того, что наука управления производством уже достигла (но для IT, как я уже говорил, этого, увы, хватает).
В виду того, что вы похоже не потрудились понять, что я написал выше, я, честно говоря не понимаю, каким вам языком объяснить, как я их применяю (или хотел бы применять).
Как минимум упомянуто две подсистемы (из трех), которые частично были применены в постановке производственного процесса.
Хоть и объяснение было довольно общим, но человеку, который знаком с основами оно дает представление о том, что базовые принципы управления пр-вом кросс-индустриальны.
Похоже Вам выгоднее форма дискуссии, чем «конструктивное» русло, которым вы прикрылись в посте ранее. Увы, ничем тогда не могу помочь.
Сколько сарказма в трех строчках. Это такой завуалированный уход от скользкой темы с канбан? Давайте я Вам поведаю о моей ситуации, а Вы в ответ расскажите о Вашем отношении к TPDS и как Вы видите развитие управления производственными процессами в ИТ и какую роль вы отводите вашему инструменту в этой эволюции.
К сожалению, ПМ не главное лицо в функционально-ориентированной организации, поэтому я не могу самостоятельно определять политики даже внутри очередного проекта (или направления). Еще более прискорбно, что высший менеджмент не понимает всей ценности управления по методологиям scrum, agile, а тем более Lean (что, имхо, привело к уходу 60% квалифицированного персонала за последний год). Если бы соблюдались концепции TPDS из правил подсистемы работы с людьми (что в свое время я пытался наладить) этого не произошло бы.
В свою очередь хочу сказать, что в какой-то степени мне и тем, кому не было пофиг, удалось ввести в производственный процесс инструменты, которые попадают под описание подсистемы «инструменты и технлогия», но опять-таки, при попустительстве руководящих лиц им не был присвоен статус обязательных.
Итого: ИМХО — управление производственным процессом в ИТ больше hype и marketing-driven, чем какая-то глобальная научная задача. Местами есть светлые пятна, как-то же самый scrum или xp, но в целом не хватает системного подхода. А что самое интересное — можно реализовать ПО для ведения и контроля за ходом ИТ проектов, переняв методы из тех отраслей, где это уже обкатано и доказало свою эффективность.
Надеюсь, я увижу в скором будущем продукт, который будет не реализовывать еще один таск-трекер, а предлагать более умный подход к упр. производством в ИТ, что поможет снижать риски и повысит гибкость управления.
Извиняюсь за много букв и сумбурность изложения.
Вы понятия не имеете, какие остальные 13 принципов, поэтому решили, что они не масштабируются на другие отрасли. На самом деле, по-моему 7-летнему опыту ПМства в ИТ, отрасль по подходу к управлению произведственным процессом находится если не в жопе, то где-то очень рядом.
В то время как экспертиза в этом домене в других отраслях уже давно впереди.
Вот этот момент меня удивляет. Канбан это ОДИН из 14 (!!!) принципов управления производственным процессом той же TOYOTA.
Я представляю, как были бы удивлены менеджеры, которые управляют «бережливым» производством, когда бы им сказали, что за из всех принципов контроля за процессами и качеством мы за 4 года научились использовать только один.
Да вам и сейчас udp имхо не сильно нужен. Надо только сделать tcp hole punching или протестить соединение с клиентом после закрытия коннекции.
А в облако заведите модуль, который будет выполнять роль stun сервера (ну или полноценный стороннюю реализацию stun) — возврат клиенту его global routable ip и определения типа nat и дополните его TURN сервером, который будет релеем, когда у клиентов symmetric NAT.
Будет все канонично, как это принято.
У меня по поводу udp hole punching вообще такое мнение, что он нужен только для быстрого пиринга на предопределенные порты с минимальным задействованием рандеву сервера.
Тип NATa как раз таки определяется (не)возможностью соединения с портом и/или адресом. Это вместе и называется «тип NATa».
А алгоритм работы TCP hole punching — не сильно сложнее такового для udp. Он как раз есть по второй ссылке.
Кроме того, можно попробовать реализовать соединение через закрытие соединения, когда бинды к клиенту за натом еще должны быть открыты в течение пары минут. Бонус будет в упрощении логики работы системы.
Либо вы с темой NATa разобрались не до конца, либо недописАли статью.
1. STUN-серверы используются прежде всего для того, чтобы опеределить тип NAT (простой ликбез по NAT здесь: aoz.com.ua/2009/01/26/nat-types/ ), а только после этого решается требуется ли использовать релей для соединения.
2. UDP-punching не панацея, при Symmetric Cone NAT работать не будет. Лучше сделать нормальное определение типа NAT и при попадании в SC NAT делать соединение через релей.
3. Из первых двух пунктов вывод, что логически UDP Hole punching и STUN вещи разные. Просто STUN сервера обычно используют также как рандеву-сервера
3. Если я все правильно понимаю, схему после слов «В теории все просто. Как все это выглядит на практике?» можно упростить, если работать через TCP и держать коннект к облаку с keep-alive и а в базе сохранять тип ната у клиента и его «внешний» ip на каждую сессию — тогда не надо будет каждый раз делать операции 3 и 4.
Еще один RTFM, как раз про STUN, UDP hole punching и TCP hole punching: www.brynosaurus.com/pub/net/p2pnat/
мы делали POC на обычной usb демо борде от атмела.
Эмулировался композитный usb девайс (диск+hid). В буфере hid лежала последовательность кейкодов, которая искала драйв и с определенного места пускала бинарник (через консоль).
Минус: с заблокированного экрана не работало, без прав админа тоже не айс.
А вообще усб протокол спроектирован был не очень дальновидно — оч. много возможностей вогнать систему в бсод, но написать работающий poc на исполнение произвольного кода за вменяемое время не получилось.
если есть интерес, могу видео процесса куда-нить положить (посоветуйте видео хостинг без регистрации).
чтобы просто программировать в локал бранч — железка не нужна, охотно соглашусь. Но только не пытайтесь эти поделия потом релизить в паблик — огребете от юзеров.
За сцылу спасибо, почитаю Андерсена.
Успех любой методологии познается в сравнении с другими методологиями, а не «реальными делами».
И уж если говороть о методологиях, то нет «методологии Канбан», есть «инструмент канбан», наряду с такими инструментами, как — «пока-ёке», «хансей-кайзен», «джидока» и ряда других. Только проблема ИТ в том, что мы схватились только за «канбан» и пытаемся обернуть 1 процесс производственного цикла в него, упуская все остальные. А это идет в разрез в принципами Lean, которые направлены на создание «value» на протяжении всего жизненного цикла продукта.
Благодарю за совет с работой — это в процессе, но, к сожалению, организаций с матричной структурой, а тем более проектной — очень и очень мало.
П.С. Я прочитал пост вашего начальника. Думаю, что вы должны объяснить ему, что Continuous Delivery пагубно сказывается на качестве кода, что, судя по комментам ИТТ у вас и так страдает.
2. «Я не знаю, как спросить конкретнее.»
3. «Черт, вы можете ответить конкретно хоть на один вопрос?»
4. «никаких лулзов мы не словим»
толстячка не покормили?
Зато могу припомнить, сколько лулзов словили мы, когда в конце 2010го года сотрудники вернулись с конференции и рассказали, что спикер от вашей конторы сказал, что вы не используете свой же продукт для разработки.
Похоже в ДНК вашей конторы уже заложено, что вы будете просто «кодить» чьи-то готовые модели и следовать очередному тренду моды, нежели стараться понять суть вещей и улучшить их.
П.С. Ответственность за коммуникацию несет коммуникант (теория коммуникации).
Если вы о механизме, то в рамках текущей компании — никак, ибо не дозволено руководством. А в своей компании я бы использовал стат.методы и 6Sigma, например.
Может есть что-то еще, но я пока самообразовался только до нее.
Поэтому были сделаны обобщения на уровне подсистем.
Что я хотел от Вас услышать, что вы не еще одна жира, редмайн или очередное поделие Джоела Спольски. Что вы понимаете, что творится не только внутри software production, но и как оно происходит в других отраслях и готовы создавать уникальный и целостный продукт для индустрии. Похоже я этого не дождусь. Жаль, что компетенции вашей компании ограничиваются только 1/14 от того, что наука управления производством уже достигла (но для IT, как я уже говорил, этого, увы, хватает).
Как минимум упомянуто две подсистемы (из трех), которые частично были применены в постановке производственного процесса.
Хоть и объяснение было довольно общим, но человеку, который знаком с основами оно дает представление о том, что базовые принципы управления пр-вом кросс-индустриальны.
Похоже Вам выгоднее форма дискуссии, чем «конструктивное» русло, которым вы прикрылись в посте ранее. Увы, ничем тогда не могу помочь.
К сожалению, ПМ не главное лицо в функционально-ориентированной организации, поэтому я не могу самостоятельно определять политики даже внутри очередного проекта (или направления). Еще более прискорбно, что высший менеджмент не понимает всей ценности управления по методологиям scrum, agile, а тем более Lean (что, имхо, привело к уходу 60% квалифицированного персонала за последний год). Если бы соблюдались концепции TPDS из правил подсистемы работы с людьми (что в свое время я пытался наладить) этого не произошло бы.
В свою очередь хочу сказать, что в какой-то степени мне и тем, кому не было пофиг, удалось ввести в производственный процесс инструменты, которые попадают под описание подсистемы «инструменты и технлогия», но опять-таки, при попустительстве руководящих лиц им не был присвоен статус обязательных.
Итого: ИМХО — управление производственным процессом в ИТ больше hype и marketing-driven, чем какая-то глобальная научная задача. Местами есть светлые пятна, как-то же самый scrum или xp, но в целом не хватает системного подхода. А что самое интересное — можно реализовать ПО для ведения и контроля за ходом ИТ проектов, переняв методы из тех отраслей, где это уже обкатано и доказало свою эффективность.
Надеюсь, я увижу в скором будущем продукт, который будет не реализовывать еще один таск-трекер, а предлагать более умный подход к упр. производством в ИТ, что поможет снижать риски и повысит гибкость управления.
Извиняюсь за много букв и сумбурность изложения.
В то время как экспертиза в этом домене в других отраслях уже давно впереди.
Вот этот момент меня удивляет. Канбан это ОДИН из 14 (!!!) принципов управления производственным процессом той же TOYOTA.
Я представляю, как были бы удивлены менеджеры, которые управляют «бережливым» производством, когда бы им сказали, что за из всех принципов контроля за процессами и качеством мы за 4 года научились использовать только один.
умеет более аккуратно тереть файло.
А в облако заведите модуль, который будет выполнять роль stun сервера (ну или полноценный стороннюю реализацию stun) — возврат клиенту его global routable ip и определения типа nat и дополните его TURN сервером, который будет релеем, когда у клиентов symmetric NAT.
Будет все канонично, как это принято.
У меня по поводу udp hole punching вообще такое мнение, что он нужен только для быстрого пиринга на предопределенные порты с минимальным задействованием рандеву сервера.
А алгоритм работы TCP hole punching — не сильно сложнее такового для udp. Он как раз есть по второй ссылке.
Кроме того, можно попробовать реализовать соединение через закрытие соединения, когда бинды к клиенту за натом еще должны быть открыты в течение пары минут. Бонус будет в упрощении логики работы системы.
1. STUN-серверы используются прежде всего для того, чтобы опеределить тип NAT (простой ликбез по NAT здесь: aoz.com.ua/2009/01/26/nat-types/ ), а только после этого решается требуется ли использовать релей для соединения.
2. UDP-punching не панацея, при Symmetric Cone NAT работать не будет. Лучше сделать нормальное определение типа NAT и при попадании в SC NAT делать соединение через релей.
3. Из первых двух пунктов вывод, что логически UDP Hole punching и STUN вещи разные. Просто STUN сервера обычно используют также как рандеву-сервера
3. Если я все правильно понимаю, схему после слов «В теории все просто. Как все это выглядит на практике?» можно упростить, если работать через TCP и держать коннект к облаку с keep-alive и а в базе сохранять тип ната у клиента и его «внешний» ip на каждую сессию — тогда не надо будет каждый раз делать операции 3 и 4.
Еще один RTFM, как раз про STUN, UDP hole punching и TCP hole punching: www.brynosaurus.com/pub/net/p2pnat/
Эмулировался композитный usb девайс (диск+hid). В буфере hid лежала последовательность кейкодов, которая искала драйв и с определенного места пускала бинарник (через консоль).
Минус: с заблокированного экрана не работало, без прав админа тоже не айс.
А вообще усб протокол спроектирован был не очень дальновидно — оч. много возможностей вогнать систему в бсод, но написать работающий poc на исполнение произвольного кода за вменяемое время не получилось.
если есть интерес, могу видео процесса куда-нить положить (посоветуйте видео хостинг без регистрации).