Terabit Security launched DDoS Protection System 2.0

Terabit Security launched DDoS Protection System 2.0

We are proud to present our product – DDoS Protection System 2.0

In recent years, severity and complexity of DDoS attacks has been increasing significantly. Even low volume attack is capable of shutting down the internet connection in the Company. Consequently, protection from DDoS attacks has become a business requirement. Realising the business risks and costs associated with DDoS, Terabit Security has developed DPS (DDoS Protection System) to resolve these issues. Effective solution to DDoS attacks addresses 2 main problems. First, full automation of the detection and tracking process. Second, availability of adequate contingency plans and technical resources.

Our system offers significant technical and financial advantages. DPS functions at the network edge and conducts automatic traffic analysis to identify and eliminate malicious traffic. Malicious traffic is evaluated under multiple criteria (Destination Prefix, Source Prefix, IP Protocol, Source or Destination Port, Destination Port, Source Port, ICMP Type, ICMP Code, TCP flags, Packet length, DSCP, Fragment Encodins, traffic-rate, traffic-action, traffic-marking, etc.) and subsequently sent to the edge router for further filtering.

DPS is an effective solution for DDoS attacks which supports any cloud traffic filtering system. Furthermore, it greatly reduces costs associated with bandwidth expansion. Finally, DPS allows to use services more efficiently and focus on technical enhancements rather than manual mitigation of DDoS attacks.

Go to the product page and Learn more

Кто такой Product Owner?

product-ownerВладелец продукта ответствен за то, чтобы результативная командная работа превратилась в результат, приносящий прибыль. Можно выделить четыре основные требования к владельцу продукта.

  1. Владелец продукта должен обладать всей полнотой знаний о том, что входит в круг его обязанностей. Подразумевается следующее: во-первых, он должен быть абсолютно компетентен во всем, что делается в процессе разработки, и уметь оценивать возможности команды —то есть с чем она справляется, а с чем не очень; во-вторых, довольно хорошо разбираться в сути продукта и понимать, как довести разработку проекта —до результата, имеющего действительную стоимость. Кроме того, владелец продукта должен великолепно знать рынок, чтобы уметь анализировать его состояние: какая продукция имеет значение сегодня и как может измениться ситуация завтра.
  2. Владелец продукта должен быть наделен полномочиями для принятия решений. Дирекции компании не следует вмешиваться в действия владельца продукта (как она не вмешивается в действия и решения группы). Напротив, руководителям, отвечающим за проект, полагается оказывать ему всяческое содействие, когда он трудится над концепцией продукта и когда в процессе разработки выполняет свои обязанности, помогая команде добиваться нужной цели. Помощь со стороны управленческого аппарата —весьма ценный фактор, поскольку владелец продукта испытывает давление со стороны многочисленных заинтересованных групп, как внутренних, так и внешних. Перед лицом такого мощного натиска он не мог бы сдерживать удар без административной поддержки. Надо добавить, что владелец продукта несет ответственность за результат, отбирает и формулирует для команды все требования на текущий спринт, при этом он не вправе давать задания отдельным участникам и вмешиваться в решения команды.
  3. Владелец продукта должен быть всегда доступен для команды, поскольку в любой момент может потребоваться его объяснение, почему то или иное задание нужно делать в первую очередь. По сути, владелец продукта несет полную ответственность за ведение бэклога, по этой причине необходим налаженный обмен мнениями между ним и командой. Бывает так, что участники группы в силу своего опыта и квалификации советуют владельцу продукта, какие требования наиболее важны в данный момент. Владелец продукта должен быть надежным, последовательным и доступным. Не имея возможности связаться с ним, команда может принять неверное решение. Участники группы целиком полагаются на владельца продукта: на его концепцию продукта и знание ситуации на рынке. Поэтому нужна постоянная взаимосвязь владельца продукта и команды, иначе весь рабочий процесс может развалиться.
  4. Владелец продукта должен нести ответственность за полезность продукта. Если речь идет о бизнес-структуре, в рамках которой работает скрам-команда, —значит показателем полезности является прибыль. Таким образом, деятельность самого владельца продукта соответственно оценивается из расчета, сколько прибыли приносит один выполненный пункт из его списка требований.

Владелец продукта, должен регулярно обновлять бэклог, распределяя по порядку все, что должно быть создано. Когда у вас несколько сотен задач, процесс расстановки приоритетов может оказаться довольно сложным. Следует найти способ максимально быстро рассортировать задания и требования по степени их важности для продукта. Существует множество подходов к организации бэклога, но вам потребуется тот, который с максимальной скоростью даст 20 процентов предложений, интересующих потребителя. Ваша первая попытка угадать порядок задач в первом спринте почти наверняка не увенчается успехом, но на тот момент она будет лучшим вариантом. Однако это всего лишь попытка. После первого спринта, как только вы закончите первый цикл OODA и предоставите некоторую часть продукции клиенту, вы измените порядок, осознав, что другое расположение, возможно, лучше. Вы и дальше продолжите этим заниматься, постоянно меняя приоритеты и порядок бэклога после каждого спринта, постепенно приближаясь к той последовательности, которая позволит получать ценность максимально быстро. Абсолютного совершенства вы, должно быть, не достигнете никогда, но нужно идти к нему шаг за шагом, спринт за спринтом. Главное, что нужно запомнить, —порядок меняется постоянно. Правильный порядок для нынешней недели уже не подойдет для следующей. Внешние факторы изменятся. Вы узнаете много нового. Вы поймете, что делать проще, а что —труднее. Такое постоянное движение внутри бэклога происходит во время каждого спринта. Суть в том, чтобы признать неопределенность, полностью Итак, приоритеты расставлены. Вы знаете, где у вас находится 80 процентов ценности. Когда вы выпустите продукт? Методология Scrum поможет вам существенно ускорить достижение результата. Всегда, когда вы что-то делаете, необходимо, чтобы ваш продукт как можно быстрее оказался в руках тех, кто им будет пользоваться. Лучше сделать это еще до того, как будут готовы 20 процентов функций, —за счет той части продукта, которая принесет хотя бы крупицу ценности. Назовем эту часть минимально жизнеспособным продуктом. Это то, что вы в первый раз показываете людям. Насколько он должен быть эффективен? Он действительно должен работать, несмотря на то что человеку, создававшему его, может быть даже неудобно демонстрировать такой продукт. Минимально жизнеспособный продукт следует представить публике как можно раньше! Это даст вам обратную связь, которая необходима для поддержания вашего цикла принятия решений и расстановки приоритетов. Версия 0.5. Фотоаппарат, который умеет снимать, но еще не научился фокусироваться. Набор мебели для столовой, состоящий из двух стульев. Вакцина, которой хватит лишь на пятерых пациентов, а всего у вас сто африканских селений, которым вы пытаетесь помочь. Все эти версии до нелепости недоделаны. Однако минимально жизнеспособный продукт обеспечивает вас обратной связью. Корпус фотоаппарата на самом деле неудобно держать в руках, потому что кнопка спуска затвора находится в странном месте. Дерево, из которого сделан стул, по фактуре резко отличается от дерева, из которого сделан стол. Вы проявили бестактность при распределении пяти доз вакцин и ухитрились обидеть деревенских старейшин. Но когда вы начнете официальный выпуск продукта или вывод на рынок сложной программы, у вас уже будут исправлены все недочеты и внесены все нужные функции. Возьмем, скажем, фотоаппарат. Сначала клиенты хотели, чтобы у него были функции панорамной съемки и выкладывания снимков в Facebook. Когда они опробовали первую версию, то выяснилось, что панорамой они не пользуются, но постоянно выкладывают снимки в Facebook. Это позволяет вам в первую очередь создавать те функции, которые люди ценят, и выпускать продукт тогда, когда будет готово около 20 процентов работы. Вы знаете, что продукт несовершенен, но он почти близок к совершенству. Каждый час, проведенный за полировкой яблока, —это потерянная возможность получить ценность.

И на закуску знаменитый ролик «Agile Product Ownership in a nutshell» на русском. Автор — Henrik Kniberg (from the Crisp Consultants on Agile and Lean practices). https://www.youtube.com/watch?v=loVd5MTCBWI

 

Scrum: Революционный метод управления проектами

344c2baa9a32d290915b355886113900

Отличная книга Джеффа Сазерленда, Scrum: Революционный метод управления проектами. The Art of Doing Twice the Work in Half the Time. Следуя изложенным правилам, вы сможете реализовывать проекты в несколько раз быстрее и эффективнее. Должен отметить что Скрам – это не только про разработку софта. На примерах из жизни автор объясняет философию подхода и рассказывает, как применять его для самых разных задач – от ремонта в доме и организации свадьбы до обучения и ведения бизнеса.

Слово scrum («схватка») взято из регби и обозначает метод командной игры, позволяющий завладеть мячом и вести его дальше по полю, а для этого нужны слаженность, единство намерений и четкое понимание цели. «Схватка» представляет собой идеальную модель полного взаимодействия игроков.

«Манифест…» Скрама провозглашает следующие ценности: люди важнее процессов; фактическая работа продукта важнее документации, фиксирующей, что и как продукт должен делать; сотрудничество с заказчиком важнее обсуждения условий договора с ним; реакция на изменения важнее следования первоначальному плану.

  1. Меняйте производительность команды. Это даст гораздо больший эффект —больший на несколько порядков, —чем продуктивность отдельных сотрудников. Преодолевать границы возможностей. Великие команды стремятся к цели, которая намного больше, чем устремления отдельной личности. Дайте команде свободу принимать самостоятельные решения, возможность действовать по собственному усмотрению —уважайте высочайших профессионалов. Суть в способности работать не по стандартным схемам в любой ситуации —и неважно, идет ли речь об организации сбыта или о репортажах из революционного Каира.
  2. Многофункциональность. Команда должна иметь такой набор специалистов, которые обладают всеми навыками, необходимыми для завершения проекта, какая бы ни была поставлена задача —разработать программное обеспечение для сервиса фирмы Salesforce.com или захватить террористов в Ираке. Побеждать малым количеством. Малочисленные команды работают быстрее, чем многочисленные. Правило номер один —семь участников плюс-минус два. Довольствуйтесь малым. Обвинять глупо. Не ищите дурных людей, ищите вредные системы —системы, которые стимулируют ненадлежащее поведение и вознаграждают за плохую работу.  Теперь вспомните все проекты, над которыми вы работаете. Готов спорить, вам нечасто приходится выслушивать профессиональные мнения об их достоинствах и недостатках до момента их завершения —на что уходят месяцы, а порой и годы. Вы можете месяцами работать в совершенно неправильном направлении и даже не подозревать об этом. Таким образом, вы как частное лицо тратите впустую свою бесценную жизнь, а как деловой человек рискуете деньгами и успехом. Я постоянно наблюдаю подобные вещи: компания тратит годы на работу над проектом, который вначале казался отличной идеей, но к моменту, когда он подходит к финишной черте, рынок претерпевает существенные изменения. Чем раньше вы начнете показывать продукты заказчикам, тем быстрее они сообщат вам, делаете ли вы то, в чем они заинтересованы.
  3. Время конечно. Обращайтесь с ним бережно. Разбейте вашу работу на части, которые могут быть выполнены за равные, жесткие и короткие промежутки времени, самое лучшее —от одной недели до четырех недель. И если вы уже подхватили вирус Scrum, называйте эти промежутки спринтами. Демонстрируйте или умрите. В конце каждого спринта у вас должно быть что-то сделано —что-то, что можно использовать (чтобы летать, ездить, вычислять). Выкиньте свои визитки. Должности и звания —это лишь ярлычки вашего статуса. Пусть вас знают за то, что вы делаете, а как к вам будут обращаться —не суть важно. Все всё знают. Информационная насыщенность ускоряет работу. По собранию в день. Что касается командных встреч, одного раза в день будет достаточно. Собирайтесь все вместе ежедневно на пятнадцать минут. Смотрите, что можно предпринять для увеличения скорости и качества, —и делайте это.
  4. Многозадачность отупляет. Если делать одновременно несколько дел, получится и медленно, и плохо. Не поступайте так. Если вы считаете, что вас это не касается, то вы ошибаетесь —это относится и к вам. Сделанное наполовину —не сделано. Наполовину собранная машина отбирает большое количество ваших ресурсов, которые могли бы быть использованы для создания ценности или экономии средств. Все, что не закончено, стоит денег и энергии, не принося никакой практической пользы. Делайте все правильно с первого раза. Совершив ошибку, исправляйте ее сразу. Отложите все другие дела и займитесь ею. Устранение дефекта спустя некоторое время займет в двадцать раз больше сил и часов, чем немедленное исправление ошибки. Если слишком усердно трудиться, работы становится больше. Если работать сверхурочно —это не значит, что успеешь больше. Слишком усердный труд приводит к усталости, которая в свою очередь приводит к браку в работе, и его приходится сразу устранять. Чем трудиться допоздна и еще по выходным, лучше работать в будни в постоянном ритме. И не забывать об отпуске. Не будьте неразумны. Амбициозные цели —лишь мотиваторы, которыми пользуются ваши руководители. Недостижимые цели только вызывают депрессию. Без героизма. Если для выполнения работы вам нужен герой —у вас проблема. Героическое усилие следует рассматривать как признак ошибки при планировании. Довольно с нас глупых концепций. Любая политика, кажущаяся смехотворной, с большой вероятностью таковой и является. Глупые формуляры, глупые совещания, глупые утверждения, глупые стандарты —все они просто глупы. Если ваш офис напоминает офис Дилберта, значит есть что исправлять. Никаких засранцев. Не будьте им сами и не позволяйте другим. Любой человек, создающий эмоциональный хаос, внушающий страх и ужас, унижающий людей, должен получить по заслугам. Его не должно быть в вашем коллективе. Попасть в поток. Выбирайте самый легкий, самый простой путь к выполнению всех задач. Scrum поможет вам попасть в такой поток.
  5. Карта —еще не живая местность. Не обольщайтесь своим планом. Почти наверняка он неверен. Планируйте только то, что нужно. Не пытайтесь предусмотреть все на многие годы вперед. Планируйте ровно столько, сколько нужно, чтобы ваши команды были всегда заняты. Какая это собака? Не оценивайте в абсолютном выражении, например в часах, —уже не раз доказано, что люди не умеют этого делать. Оценивайте относительно, например в собако-единицах или по размеру футболок (S, M, L, XL, XXL), либо —что самое надежное —используйте последовательность Фибоначчи. Спросите у оракула. Используйте анонимный метод, вроде дельфийского, чтобы не подвергнуться влиянию чужого мнения; избегайте эффекта ореола, эффекта стадности и группового мышления. Планируйте с помощью покера. Используйте покер планирования, чтобы быстро оценить работу, которую нужно сделать. Работа —это история. Сначала подумайте о человеке, который получит пользу от той вещи, которую вы делаете; потом подумайте о том, что это такое и, наконец, зачем им это нужно. Люди мыслят сюжетами и фактами, так дайте им их историю. Будучи X, I хочет Y, так что Z. Узнайте свою динамику. Каждая команда должна точно знать, сколько работы она может выполнить за один спринт. Она должна знать, насколько может повысить динамику производительности, работая разумнее и устраняя все, что встает на пути и тормозит ее работу. Динамика × время = результат. Узнав, насколько быстро вы продвигаетесь, вы сможете понять, когда окажетесь на финише. Ставьте перед собой стратегические цели. С методикой Scrum не слишком трудно удвоить производительность и в два раза приблизить время сдачи проекта. Если вы сделаете это вовремя, ваши доходы и стоимость акций удвоятся.
  6. Истинное счастье можно найти в пути, а не в его завершении. Мы обычно награждаем только за результаты, но что больше всего нужно укреплять в людях —их стремление к величию. Счастье —хит сезона. Счастье помогает вам принимать лучшие решения. Когда вы счастливы, вы становитесь созидателями, не бегаете из компании в компанию и наверняка сделаете намного больше того, чем сами рассчитывали. Измерить счастье. Просто быть счастливым недостаточно. Нужно измерить чувство счастья и полученный результат сопоставить с результатами вашей деятельности. Все традиционные показатели берутся из прошлого. Счастье —это показатель, который всегда смотрит в будущее. Становитесь лучше каждый день —и измеряйте улучшения. В конце каждого спринта команда должна выбрать маленькое улучшение, или кайдзен, которое сделает их счастливее. Это должно стать самой важной вещью, которой они добьются в следующем спринте. Секретность —яд. Ничто не может держаться в тайне. Все должны знать всё, включая финансовые данные. Запутывание следов нужно только тем, кто ищет собственной выгоды. Работа должна быть прозрачной. Сделайте доску, которая будет показывать, какую работу нужно выполнить, над чем вы сейчас работаете и что уже сделано. Ее должны видеть все и все должны обновлять информацию на ней. Счастье —это независимость, мастерство и целеустремленность. Каждый человек хочет управлять своей судьбой, совершенствоваться в том, что делает, и служить большой цели. Заставьте «пузырь счастья» лопнуть. Не становитесь счастливыми до такой степени, чтобы начать верить в придуманную вами же чепуху. Всегда измеряйте счастье результатами деятельности, и если заметите нестыковки, будьте готовы вмешаться. Удовлетворенность и самонадеянность —враги успеха.
  7. Составьте список. Проверьте его дважды. Составьте список всех заданий, которые в принципе можно было бы сделать в рамках проекта. Затем расставьте приоритеты. Поставьте вверху списка задачи с наивысшей ценностью и наименьшим риском. Владелец продукта. Превращает идею проекта в бэклог. Должен уметь осмыслять продукт, рынок и клиента. Лидер не босс. Владелец продукта решает, что должно быть сделано и почему. Каким образом достичь этого и кто будет это делать —команда решает сама. Владелец продукта. Профессионал с огромным опытом, может принимать окончательные решения. Всегда доступен для команды и готов отвечать на вопросы. Ответствен за получение ценности. Наблюдать, ориентироваться, решать, действовать (OODA). Вы должны видеть всю стратегическую картину, однако действовать тактически и быстро. Страх, неуверенность и сомнения. Лучше давать, чем получать. Проникните внутрь цикла принятия решений вашим конкурентом. Получайте деньги ни за что и вносите изменения бесплатно. Создавайте новое только в том случае, если оно имеет ценность. Будьте готовы поменять его на то, что требует такого же усилия. То, что казалось вам нужным в самом начале, никогда не бывает тем, что вам нужно на самом деле.

Десять шагов для внедрения SCRUM

scrum-board-example

Десять простых правил которые помогут вам внедрить SCRUM c “нуля”

  1. Выбрать владельца продукта. Это человек, обладающий видением того, что вы собираетесь делать, производить, достигать. Он принимает во внимание риски и выгоды, что нужно выполнить, что может быть сделано и что вас воодушевит.
  2. Выбрать комманду. Кто те люди, которым предстоит выполнить работу? Специалисты, входящие в группу, должны обладать всеми навыками и знаниями, необходимыми, чтобы воплотить идею владельца продукта в жизнь. Команда должна быть небольшой, от трех до девяти человек —это золотой стандарт Scrum.
  3. Выбрать Скрам-Мастера. Это человек, который следит за ходом проекта, обеспечивает проведение всех коротких собраний и помогает команде устранять мешающие ей препятствия.
  4. Создать бэклог продукта. Это список абсолютно всех требований, предъявляемых к продукту и расставленных по их приоритету. Бэклог существует и развивается на протяжении всей жизни продукта, чьим ориентиром он является. Бэклог продукта —единственная и однозначная концепция «всего, что команда в принципе может сделать, в порядке приоритетности». Существует только один бэклог продукта. Это означает, что владелец продукта должен принимать решения о приоритетности на основе всего спектра задач. Владелец продукта должен беседовать со всеми заинтересованными лицами и командой, чтобы гарантировать всю полноту обратной связи и отображать в бэклоге все требования и пожелания потребителя.
  5. Уточнить и оценить бэклог продукта. Крайне важно, чтобы участники группы, которые будут выполнять задания из бэклога, оценили, сколько усилий это потребует. Команда должна взглянуть на каждую задачу и определить, выполнима ли она в принципе. Достаточно ли информации, чтобы выполнить задачу? Достаточно ли она обозрима, чтобы ее можно было оценить? Есть ли общее понимание, каким стандартам и критериям она должна соответствовать, чтобы быть выполненной? Создается ли при этом действительная стоимость? Должна быть обеспечена возможность продемонстрировать результат выполнения каждой задачи. Не оценивайте задания бэклога в часах, поскольку люди плохо с этим справляются. Оценивайте в относительных размерах: «малый», «средний», «большой». Лучше использовать последовательность Фибоначчи и присваивать каждой задаче количество баллов: 1, 2, 3, 5, 8, 13, 21.
  6. Запланировать спринты. Это первое скрам-собрание. Команда, скрам-мастер и владелец продукта планируют спринт. Спринты всегда имеют фиксированную продолжительность, которая должна быть меньше месяца. Как правило, выбирают спринты длиной в одну или две недели. Команда смотрит в верхнюю часть бэклога и прогнозирует количество заданий, которое возможно выполнить за этот спринт. Если команда уже прошла пару спринтов, ей следует учитывать то число баллов, которое было в прошлом спринте. Количество баллов мы называем динамикой производительности. Скрам-мастер и команда должны в каждом спринте наращивать динамику. Планирование спринта —это еще одна возможность для владельца продукта и команды удостовериться, что все точно понимают, как реализация заданий служит воплощению замысла. На этой встрече все должны договориться о цели спринта и определить, что должны выполнить за спринт. Основное правило Scrum —если команда договорилась об определенном количестве заданий, которые нужно выполнить за один спринт, то добавлять новые уже нельзя. Команда должна быть в состоянии работать автономно на протяжении всего спринта и завершить то, что пообещала заказчику сделать.
  7. Визуализация работы. Прозрачность всех действий и процессов обеспечивает скорейшее достижение цели. Наиболее распространенный способ добиться этого —завести Скрам-доску с колонками: «Нужно сделать, или бэклог»; «В работе»; «Сделано». Стикеры —это пользовательские требования, которые нужно реализовать; по мере того как они выполняются, команда перемещает стикеры из одной колонки в другую. Еще один способ сделать работу видимой —создать диаграмму выгорания задач. На одной оси —количество баллов, которое команда взяла в этом спринте, на другой —количество дней. Каждый день скрам-мастер подсчитывает количество баллов за выполненные задачи и отражает это на графике. В идеале к концу спринта должен быть резкий спад до нуля.
  8. Ежедневный стендап. Это пульс всего процесса Scrum. Каждый день в одно и то же время не более чем на пятнадцать минут команда и скрам-мастер встречаются и дают ответы на три вопроса. Что ты делал вчера, чтобы помочь команде завершить спринт? Что ты будешь делать сегодня, чтобы помочь команде завершить спринт? Какие препятствия встают на пути команды? Вот и все. Вся встреча. Если на это требуется больше пятнадцати минут, значит вы что-то делаете неправильно. Суть таких встреч в том, чтобы вся команда точно знала, какое задание на каком этапе находится в текущем спринте. Все ли задачи будут выполнены в срок? Есть ли возможность помочь другим членам команды преодолеть препятствия? Никто не распределяет заданий сверху —команда самостоятельна и все решает сама. Никто не пишет подробных отчетов руководству. Скрам-мастер отвечает за устранение помех, мешающих команде продвигаться вперед.
  9. Обзор спринта. Это встреча, на которой команда рассказывает, что сделано за спринт, и демонстрирует готовые части продукта. Присутствуют владелец продукта, скрам-мастер, команда и любые заинтересованные лица: заказчик, представители руководства, потенциальные потребители. Это открытая встреча, где команда демонстрирует, что удалось переместить в колонку «Сделано» за время спринта. Демонстрировать команда должна только то, что соответствует определению «Сделано». Что полностью и окончательно готово. Это может быть полностью выполненный продукт или его отдельная готовая функция.
  10. Ретроспективное собрание. После того как команда показала, что она сделала за прошедший спринт и что может быть сдано клиенту для получения обратной связи, все садятся за общий стол и обсуждают ряд вопросов. Что прошло хорошо? Что можно было сделать лучше? Что можно сделать лучше в следующем спринте? Какое улучшение команда может внедрить в процесс немедленно? Чтобы собрание было действенным, потребуется создать атмосферу доверия и проявить необходимую эмоциональную зрелость. Главное, о чем нужно помнить, —вы никого не обличаете, а рассматриваете рабочий процесс. Почему это случилось? Почему мы это упустили? Что могло бы ускорить ход работ? Особенно важно, что люди ощущают себя командой и берут на себя ответственность за все процессы и их результаты. Решения ищут всей командой. Участники группы должны обладать определенной психологической выдержкой, чтобы их обсуждения были направлены на решение злободневной проблемы, а не на поиски виноватых. Абсолютно недопустимо, чтобы даже один член команды вынужден был занимать оборонительную позицию, —все в группе должны слышать и понимать друг друга. К концу встречи команда и скрам-мастер должны договориться о совершенствовании процесса, которое будет введено в действие в следующем спринте. Совершенствование, которое называют кайдзен, должно быть внесено в бэклог для следующего спринта, включая приемочные тесты. Благодаря скрам-доске и тестированию команда сможет понять, действительно ли они внедрили совершенствование и как оно сказалось на динамике производительности.

Книга Уолтера Айзексона “Инноваторы: Как несколько гениев, хакеров и гиков совершили электронную революцию”

10

Пару слов об очередной блестящей книге Уолтера Айзексона “Инноваторы: Как несколько гениев, хакеров и гиков совершили электронную революцию”, книга о людях изобретения которых привели к созданию Силиконовой долины. Шаг за шагом рассказывается история создания компьютера. Частично перекликается с книгой The Intel, существенно дополняя последнюю. Факты которые показались интересными:

1. Великие инновации, как правило, появляются в результате суммирования идей, зародившихся в большом количестве источников. Изобретение, особенно такое сложное, как компьютер, как правило, появляется не в результате отдельного мозгового штурма, а в процессе совместного творчества.
2. Гораздо важнее к голой идее, добавить свои разработки, воплотить в жизнь свое видение машины/ продукта / сервиса с помощью собранной компетентной команды, а ещё важнее выполнить своевременное патентование.
3. Один в гараже, без команды много не наваяешь.
4. Если нет денег на создание электронного компьютера, всегда можно обратится в военное министерство с идей создания “Использование высокоскоростных ламповых устройств для расчетов стрельбы”.
5. Если ты не можешь написать книгу, поступи в армию, тогда тебя заставят её написать🙂
6. Если ты набил программу на ленту, доставай молитвенный коврик, становись на него лицом на восток и молись, чтобы работа оказалась успешной. В принципе, актуально и для современного процесса разработки😉
7. Главный программист – это всегда мужчина, даже если до этого, она была женщиной🙂
8. Лучшим стимулом для инновационного рывка при производстве компьютеров и микрочипов является система зашиты интеллектуальной собственности, поскольку крупным промышленным организациям легче привлечь оборотные средства для проведения исследований, разработки, производства и продажи таких машин.
9. Изобретение первого транзистора в Bell Labs, стало возможно только благодаря работы команды в которую входили теоретики, чувствующие квантовые явления на интуитивном уровне, искусные материаловеды, способные ввести примеси в объем кремния, умелые экспериментаторы, специалисты в области промышленной химии и производства, а также изобретательные, умелые исполнители.
10. В команде должен быть предприниматель, генератор новых идей и инженеры практики, которые превращают идеи в хитроумные изобретения. И вся команда специалистов и предпринимателей должна работать совместно, чтобы превратить новинку в продающееся изделие. Но если отличная команда лишается провидцев-энтузиастов, появление новых идей постепенно сходит на нет.
11. Для генерации творческой энергии необходима физическая близость. Работая в одном помещении и общаясь, теоретики и экспериментаторы могут вести мозговой штурм новых идей. Подобное интенсивное взаимодействие способствовует появлению идей, которые, используя аналогию с электронами, переходят на более высокие орбиты, а иногда могут и вырываться на волю, запуская цепную реакцию.
12. Если поставить задачу, собрать вместе талантливых людей, предоставить им достаточно времени для проведения опытов, рано или поздно задача будет выполнена.
13. Не важно чем ты занимался до этого, главное разглядеть возможность и взяться за её реализацию.
14. Первый карманный радиоприёмник Regency TR-I рекламировался как средство защиты от Русской атомной бомбы.
15. Лучше уйти, начать свое собственное дело и провалить его, чем прилепиться к одной компании на тридцать лет.
16. Если люди доверяют друг друга, им не обязательно подписывать многостраничные контракты, для заключегия символического соглашения, достаточно расписаться на не нескольких долоровых бумажках.
17. Когда говорят что то или иное изобретение привело к глобальной цифровой революции, стоит вспоминать анекдот что именно бобер сказал кролику, когда они стояли у подножия плотины Гувера: «Нет, я не сам ее построил, но она основана на моей идее»”.
18. Первыми бытовыми приборами, где нашли применение микрочипы, были слуховые аппараты, поскольку они должны быть миниатюрными и на них есть спрос, даже если они достаточно дороги.
19. Инновации всегда состоят из двух частей. Во-первых, надо изобрести новое устройство, а во-вторых, придумать способ его массового использования.
20. Первый калькулятор Texas Instruments мог выполнять только четыре операции (складывать, вычитать, умножать и делить), весил около килограмма и стоил $150.
21. Одно из ключевых правил которым стоит руководствоваться при инвестировании, инвестировании, сводится к тому что ставить нужно на людей, а не на идеи.
22. Для эффективного руководства не всегда требуется сильный лидер. Оно может осуществляться благодаря правильной комбинации по-разному одаренных людей, стоящих во главе компании. Это как в случае с металлическим сплавом: подбери правильный состав входящих в него элементов, и он окажется прочным.
23. Чем более открытой и менее зарегулированной будет рабочая обстановка, тем быстрее будут появляться, распространяться и находить применение новые идеи. Суть в том, что люди не должны карабкаться вверх по командной лестнице. Если вам надо поговорить с кем-то из руководителей, вы просто идете и говорите с ним.
24. Инновации могут появляться благодаря таланту инженера, но, чтобы завоевать мир, кроме таланта, требуется еще и искусство ведения бизнеса.
25. Первое RFC было выпущено 7 апреля 1969 года. Оно было разослано по почте в старомодных бумажных конвертах.
26. Во второй половине 1969 года были завершены три исторических проекта: НАСА удалось отправить человека на Луну. Инженерам из Силиконовой долины удалось найти способ разместить программируемый компьютер на небольшой тонкой пластинке, названной микропроцессором. А в ARPA создали сеть, способную связать два удаленных компьютера.
27. Настоящий спрос на продукт, это когда люди шлют банковские чеки компании, о которой никогда не слышали, в город, название которого не могут правильно написать, и надеятся, что получат коробку с запчастями, из которых можно будет спаять устройство, мигающее лампочками в ответ на команды, которые приходилось кропотливо вводить при помощи тумблеров (и это еще если все пойдет удачно).
28. Интерфейс должен быть простым и интуитивно понятным. Инструкции должны быть элементарными. Устройства должны быть понятными и без руководств.
29. Величайшими инноваторами становятся не гении инженерной мысли, а люди, которые смогли все это умело применить на практике.
30. Теперь же молодежь покупает MacBook и видит в нем обычный электроприбор, обращается с ним как с холодильником, надеясь, что внутри —только лучшее. А как он работает, никто не знает. И никто в полной мере не понимает то, что очевидно мне и моим родители: возможности компьютера ограничены лишь нашим воображением.

BGP traffic optimization how it works?

Noction

IRP sits in the network, gets a complete copy of the traffic or a Netflow/Sflow feed from the router (depends on the mode it is configured to operate) and passively analyzes the traffic for specific protocol anomalies and also actively measures top volume prefixes for packet loss, latency and other performance metrics.
The platform gathers these metrics by active probing through all the available provider links, in parallel. It sends this actively gathered data to the platform Core, which computes a performance or a cost-improved routing policy for the network. The IRP BGPd then announces the improved route to the network’s edge routers via a traditional BGP peering session.
The IRP is non-intrusive and sits outside of the data path, so there are no worries that it will impact network throughput or performance. The platform is designed to improve the network and solve issues, not to create them. If IRP is turned off or fails, the client routers will fall back to the standard BGP routes received from the other peers.
The platform can also run in a BGP non-intrusive mode, when it only gathers data and runs active probes, without sending BGP announcements.

IRP Components.

Core – the heart of the IRP intelligence, runs all the logical operations and interconnects all the components. Handles the Performance and Cost Improvements. Chooses and sends to BGPd improvement prefixes. Processes, stores and exports data.
Collector – receives and processes all the traffic passing the network. The platform can analyse raw network traffic sourced by port mirroring (portspan) or Netflow/Sflow. Noction IRP Collector outperforms the competitors by the ability to process up to 40 Gbps of traffic per unit.
Explorer – runs all the active and passive probings. It is capable to measure metrics like packet loss, latency, jitter, link capacity and link load.
BGPd – Noction developed BGP server, fully RFC compliant, can support up to 200 BGP sessions and handle up to 12 mln records in the RIB.
Frontend – provides a powerful set of configuration and management options for the platform, in addition to its extensive set of reports detailing items such as: top destination prefixes, top volume prefixes, top improvements, bandwidth usage and cost, traffic delivery performance, route change activity, performance/usage statistics, route change logs and long-term business planning reports.

http://www.noction.com/intelligent_routing_platform

An example of the development billing system

General Overview

An example of the development billing system for Telco. Billing System is heart of any telecommunication company. And we made this heart beat. Billing System has been developed in order to solve typical tasks of telecommunication companies: charging, service fulfillment and collection. And, as a result, satisfy your customers and make a good business. Billing System is convergent multiservice enterprise level high load billing system for internet service providers and TV providers.

billing

Main Features

  • Billing and Service Management
    • Charge Processing

Charging of services consumed by customer. Supported modes: post-paid and pre-paid. Billing period: daily, monthly, annually, one-time fee.

  • Service Management

Management of services depends on balance and any other conditions. The common statuses: active, voluntary suspended, involuntary suspended, blocked, churn etc. Tariff matrix management, bundling, detailed properties for every tariff. Setting up of customer lifecycle for each service and category of subscribers. Tune-up promo period, retention options etc.

  • Invoice Generator and Sender

Generation of invoices for all or part of subscribers. Set-up algorithm of invoice calculation rules (pre-payment, post-payment). Charges predication option. Development of custom invoice templates. Output format – PDF, merged by preconfigured groups. PDF invoice sender via e-mail, SMS-invoice sender.

  • Payment Processing
    • On-line payment processing

API server interface (SOAP) for external on-line payment systems and banks. Provide transactions immediately. Ensure secure data transfer with authorization check for every transaction and encoded protocol.

  • Off-line payment processing

Upload of files with payments list in case of absence direct integration through on-line protocol. Single payments processing also.

  • Payment Verification

Range of tools in order to confirm payments in billing system with real money on bank accounts of the company. Financial controlling function.

  • Provisioning and Fulfillment
    • Broadband Internet Provisioning

Provisioning of Internet services for subscribers. Available actions: blocking and unblocking, speed shaping, traffic limitation, setting customized Internet profile etc. System has been successfully launched and still in operation for different technologies (Ethernet, DOCSIS), different authorithation options (IPoE, PPoE) and different customers identification options (by CPE MAC address, ethernet port, account). The system is able to customize for infrastructure of provider. Very flexible settings of traffic calculations and charges: by days, by time, by direction/type etc. Supported protocols of integration with Network Management System (or Network Execution System): file-based, SOAP, REST.

  • TV Service Provisioning

Provision of digital TV services for most of technologies DVB-x and CAS such as Conax, Irdeto. Support of OTT or IPTV provisioning with different middlewares and DRM systems. Options of service management: predicted packages, a-la-carte channels and channel packages, additional services (catch-up, VOD etc.). Transaction VOD (buy content via TV) is also supported.

  • CPE Management

Item-based accounting of Customer Premises Equipment via global directory (pool) of equipment. There are history of usage, statuses, movements among warehouses for every item. Special front-end for CPE management. Ready for integration with external inventory system.

  • Network Topology Management

            Advanced functionality of network topology management for Ethernet network and Cable TV network infrastructure.

Ethernet

System of storing and management of Ethernet network infrastructure with drill down to every switch and port. There is full stack of required attributes of switches: MAC, IP, hostname, S/N, Vendor and model, SNMP community, telnet account, physical location, inventory state, monitoring option, network role, firmware etc. Flexible mechanism of topology building, supported topology: tree, ring, star or mix of them. There is functionality of group import of switches into directory.

DOCSIS/DVB-C

Storing and management of cable network for mentioned or similar technologies. Accounting of each node of the network (from Head-End to End-User access point). There is visualized front-end for all the network with cascade structure. Linking of network nodes to physical location and subscribers.

Detailed and customized reports are available as well.

Flexible settings of user’s permissions inside these modules.

Integration with Network Monitoring System is available.

  • Data Export
    • Reporting Module

Built-in reporting module, which allows to configure any kind of custom report, based on data in billing system. Supported source code: SQL and PL/SQL pipeline functions (for complicated calculations, temporary tables usage, procedural execution etc). External sources via Oracle DB links are also supported. Flexible types of report filters: date, number, string, combo-box with cascade selection, multiple selection. Default filters values are supported. Output file format: archived (zipped) XLS, archived (zipped) CSV, web-interface. Output file contains generation date and time and used filter’s values.

Other features:

  • History of report generation (incl. author, time, filter values, generated file)
  • Grouping of reports with access limitation by user permissions
  • Ordering of reports in group according to the usage
  • Limitation of quantity of simultaneously runner reports (for every report)
  • DB interfaces

All services and integration options of Oracle Enterprise DB 11g are supported.

  • Integration Services
    • API module
  • Notifications
    • E-Mail
    • Send Message Service
    • Customized Notification Channel
  • Administrative Tools
    • Administrative 
Front-End
    • System Dictionaries
    • User Action Logger & Monitoring
    • Application Server Management

Сто правил руководителей проектов NASA

Как известно бюджет NASA на 2015 год составит 18 миллиардов долларов США, что на 2% больше, чем было выделено в 2014 году. В этом контексте очень интересно посмотреть на 100 правил руководителей проектов NASA. Документ был подготовлен Джерри Мэддоном (Jerry Maddon), ассоциированным директором Директората полётов Годдартовского центра космических полётов NASA. Джерри собрал эти драгоценности мудрости за много лет из разнообразных источников.

Руководитель проекта
Правило 1. Руководитель проекта должен посетить каждого, кто делает что-нибудь в его проекте хотя бы один раз, должен знать всех менеджеров в своём проекте (как из государственных органов, так и у субподрядчиков), а также членов команды проекта. Людям нравится, когда руководитель проекта заинтересован в их работе и лучше всего
посетить их лично и увидеть самому, что они делают.

Правило 2. Руководитель проекта должен знать мотивацию участников проекта (то есть их систему премирования и штрафов, их регламенты и другие компоненты культуры этих компаний).

Правило 3. Принципы управления не изменяются. Меняются только средства. Вы по прежнему должны найти нужных для выполнения работы людей и найти путь, следуя которому они смогут выполнить её.

Правило 4. С кем бы вы не имели дело, будьте честны и справедливы. Многие области бизнеса не предоставляют слишком широкие возможности. Вы можете быть удивлены тем, насколько часто вам придётся работать с одними и теми же людьми. Пусть лучше они уважают вас, чем тащить за собой груз их недовольства вами.

Правило 5. Руководителями проектов могут быть порочные, презренные и совершенно неприятные люди. Бездушные, нерешительные копуши или болтуны – нет.

Правило 6. Подходящим руководителем проекта может быть некто, ожидающий следующего назначения или находящийся на грани неудачи. Полная безопасность не характерна для руководителя проекта.

Правило 7. Одной из проблем нового руководителя проекта является то, что все ждут от него решения своих проблем. Старым руководителям проектов старшее руководство обычно говорило «решите ваши собственные проблемы, мы вас нанимали именно для этого».

Правило 8. Текущая деятельность обычно не оставляет времени для того, чтобы вы могли думать. Вы должны выкроить время для того, чтобы понюхать розы. При вашей работе вы должны иметь время для того, чтобы понять последствия ваших действий.

Правило 9. Руководитель может не знать, как должна выполняться работа, но он знает, чего он хочет. Он лучше определит, чего он ожидает, и хочет, даже если он не знает как. Слепой лидер имеет тенденцию к движению по кругу.

Правило 10. Не все успешные менеджеры компетентны и не все потерпевшие неудачу менеджеры некомпетентны. Удача играет существенную роль в успехе или неудаче, но удача предпочитает компетентных и трудолюбивых руководителей.  Continue reading

Как создать каталог сервисов ИТ?

it serviceВ соответствии с определением ITIL, каталог сервисов – это база данных или структурированный документ с информацией о всех используемых (live) IT сервисах, включая сервисы, предлагаемые для внедрения (available for deployment). Каталог сервисов – это только часть портфеля сервисов, публикуемая для заказчиков и используемая для продажи и предоставления им IT сервисов. Каталог сервисов включает в себя информацию о поставщиках, ценах, точках контакта, порядке и требуемых процессах поддержки.

Каталог сервисов для пользователей, дает ответы на следующие вопросы:

  1. Какие услуги мне доступны?
  2. Что я могу получить от ИТ?
  3. Чем занимается ИТ?
  4. Время реакции?
  5. Качество доступных услуг?
  6. Когда предоставляются услуги?
  7. Время работы сервиса?
  8. К кому/как/когда обращаться?

Каталог сервисов для ИТ, дает ответы на следующие вопросы:

  1. Какие сервисы мы предоставляем?
  2. Время реакции?
  3. Чем занимается ИТ?
  4. Кто может обращаться?
  5. Объем услуги в рамках сервисов?
  6. Регламентные работы по сервису?
  7. Кто за какой сервис отвечает?
  8. На что влияет сервис?
  9. Кто заказчик сервиса?

Цели внедрения каталога сервисов:

  • Обеспечение “прозрачности” ключевых функций подразделения ИТ.
  • Определение зон ответственности подразделения ИТ, идентификация всех предоставляемых сервисов.
  • Поддержка прочих процессов управления ИТ и переход к сервисно-ориентированной модели управления ИТ.
  • Повышение эффективности коммуникаций с бизнесом.

Иными словами, создание понятного списка услуг (сервисов) описаный на доступном для пользователей языке.

10 шагов, которые необходимы для разработки каталога сервисов:

  • Определение перечня сервисов.
  • Определение заказчиков.
  • Определение категорий сервисов.
  • Определение критичности сервисов.
  • Определение пользователей сервисов.
  • Определение зависимостей сервисов.
  • Определение OLA.
  • Определение SLA.
  • Управление каталогом сервисов.
  • Тренинги и коммуникации.

На выходе, для пользователей, будет опубликован следующий список сервисов:

  • Таблица – список сервисов и атрибутов, матрица зависимости сервисов.
  • Документ – «Каталог сервисов ИТ».
  • Положение о процессе «Управление Каталогом Сервисов».

Пример трехдневного маршрута по Карпатам

imageДень1.

Прибытие в 6:00 из Киева на ЖД вокзал Ивано-франковска. Посадка в арендуемый микроавтобус, везет в с.Ясыня в самом сердце Карпат. В селе есть возможность докупить ряд мелочей, но особенно рассчитывать на ассортимент местных магазинов не стоит. От Франковска до Ясыней ехать 2-3 часа, по прибытию небольшой перекус-завтрак, подгонка снаряжения и распределение веса и начало похода.

Выдвижение от ЖД станции по пологому гребту на склон горы Петрос. Гора более 2 тыс.метров, поэтому на самую верхушку, в первый день идти не стоит. Остановка на полоныне Шесса. Там есть вода и горизонтальные участки где поставить палатки. Поход занимает весь день, суммарное растоянние более 10км и подьем на уровень 800м. На первый день этого достаточно. В вечерней программе костер, вино, басни, шутки, танцы и что душе угодно.

День 2.

Подъем не позднее 8:00. Кофе, завтрак, сборы и выход не позднее 10:00. Покорение вторую по высоте и первую по красоте вершину Карпат – г.Петрос. По дороге встречаеться черника, коровы, овцы и гуцулы, собирающие грибы. Черники очень много, рекомендую собирать, чтобы вечером можно было сварить компот. Покорив Петрос и вдоволь намиловавшись видами На Говерлу и Черногорский хребет, двигаемся вниз. Говерлу и Петрос соединяет небольшой перешеек, который сверху кажется очень крохотным. Но до него ещё нужно дойти. На подступах к Говерле, с правой стороны от дороги, есть хорошее место, с пологой площадкой и родником для стоянки.

День 3.

Подъем не позднее 8:00. Кофе, завтрак, сборы и выход не позднее 10:00. Дольше тянуть нельзя иначе на Говерле будет уже столько народу, что на Крещатике бывает и меньше. Это портит впечатление.  Подъем на Говерлу не такой затяжной и сложный как на Петрос. На вершине, если позволяет время и силы, можно выбрать следующие варианты: 1. Сбегать к озеру Несамовитому и уже от туда спускаться к базе Заросляк. 2.  Прямо в Заросляк, где ждет тот же самый микроавтобус и отвезет в Ивано-Франковск к поезду. Стоит учесть что спуск занимает часа два. Перед поездом вы можете посидеть в уютном баре-ресторане, выпить по кружечке пива и обменяться впечатлениями.

Примечания:

Погода в горах – явление загадочное и переменчивое. Она может меняться по 4 раза в день. Не смотря на прогнозы метестанции, нужно быть готовым к любой погоде, от жары и солнечных ожогов, до дождя с грозой, пронзительным ураганным ветром и температурой ниже 10 градусов.
Вода – как вы понимаете, киосков с водой в горах нет. Колодцев тоже никто не копал. Вода, которая береться с собой в первый день в Ясынях, закончится на первой ночевке. На второй день, набирается водв из родника на полоныне. Второй и третий день – аналогично. Родниковая вода после кипячения на 100% пригодна для всех, но в сыром виде у некоторых бывает реакция. Для каждого это вопрос индивидуальный, зависящий от кишечной стабильности. Пожалуйста, учтите этот нюанс J
Душ – не всё так страшно, как многие представляют. Гигиену в горах соблюдают. Душ выглядит как горная река с температурой 8 градусов или как пластиковая бутылка с предварительно подогретой водой.