Я с приятелями люблю спорить о всякого рода гуманитарной фигне. Так, например, я с пеной у рта доказывал, что называть человека “ресурсом” нельзя, мы же люди, у нас есть чувства и все такое.

В конторе у нас Скрам. Это, кто не знает, одна из самых популярных реализаций этих ваших Agile.
Скрамят у нас все и вся: от дизайнеров и контент-менеджеров до архитекторов и прогеров. Единственные отделы, где скрама нет - техподдержка, hr и бухгалтерия (хотя я уверен, и им пытались это втюхать).

Как так вообще получилось? Несколько лет назад генеральный решил, что контора станет пионером технологий и методологий.
По такому поводу на ютубе до сих пор висит бородатый видос, где наш, тогда еще чисто голландский, ИТ департамент говорит о преимуществах Скрам (https://youtu.be/FHHSlJQS5nY).

Тут надо еще сказать про компанию: начинаясь как маленький интернет магазин mp3 плееров, контора начала активно и быстро расти, благо ее рассвет пришелся на бум доткомов. Таким образом компания до сих пор, имея все отличительные черты махрового энтерпрайза, ведет себя как стартап. И как любой уважающий себя стартап она примеряет на себе все новое, не боясь никаких последствий. Одним из таких нововведений и стал Скрам, на который посадили всех.

Что у нас это в принципе представляет: есть продукт (или несколько продуктов) и есть команда из разных специалистов (в моем случае инженер-линуксоид, мультифункциональный скрам-мастер и мужик, который на SCCM собаку съел). Продуктов у нас несколько, начиная от всего, что связано с автоматизацией рабочего места (почта, программы по умолчанию, да даже как вам компьютер приготовить), заканчивая системами для collaboration (JIRA, Confluence, Slack, Google Apps и так далее).

Каждый продукт - это один большой проект длиной в бесконечность и каждое требование, называемое user story, идет в беклог (список историй от людей). Специально обученный проджект менеджер, именуемый product owner, расставляет приоритеты историям, планирует будущие спринты (о них чуть позже), общается с потенциальными заказчиками и помогает перевести запрос с человеческого на итшнический.

Когда набор историй готов, вся команда дружно собирается и разговаривает. Разговаривает много, с толком и без, со смыслом и без, но в итоге договаривается какие задачи можно сделать, а какие нет.
Все подтвержденные задачи формируются в спринт - двухнедельный этап проекта, с задачами по приоритету сверху вниз. Задача команды - выполнить все задачи в строго отведенный двух (или более - это уже как кто практикует) недельный срок.
У каждой задачи есть story point'ы - абстрактная мера измерения, сколько "усилий" уйдет на задачу. Если слишком высокая оценка - смотрят, еще раз обсуждают, разбивают на части по возможности.

Приправьте это ежедневными планерками, "оценочными" болтальными встречами и целым днем закрытия/открытия спринта - вот вам и Скрам.

С "что это" разобрались, теперь "зачем это".

Изначально классические методологии управления проектами базировались на строгом соблюдении требований. То есть заказчик подписывает бумажку со списком задач к реализации, а исполнитель обязуется выполнить все в срок.
Ничего плохого в этом нет, но заказчик нет-нет да откажется от какой-то из фич, а другие нужны будут ему раньше.
Из этого родился Agile Manifesto (http://agilemanifesto.org/), люди видели во всем этом большую проблему и пришли с манифестом - мол вот как надо и давайте все вместе будет так делать.

Разница в том, что Agile - это не методология, а культура разработки, на основе которой и появились методологии. Scrum, Kanban, XP и прочие - все это результат внедрения культуры в процесс.
У каждой "гибкой" методологии есть свои преимущества и недостатки. Я не буду покрывать все, так как мы говорим только о Скрам.

Скрам безусловно подойдет командам разработки, которые делают продукт для массового пользования. Когда ваш условный клиент это любой пользователь интернета, объем хотелок может быть просто огромным, и в этом плане Скрам с "беклогом" подходит как нельзя лучше.
Что так же важно, работая по гибкой методике, будучи готовыми перелопатить весь продукт с нуля, вы пишете приложение, взяв за основу правило: "продукт должен быть максимально гибким и расширяемым."
Другим преимуществом является скорость доставки. Вы доставляете не 10 фич через год, а по 2-3 фичи каждый месяц (в зависимости от сложности).

Но у Скрама есть и недостатки. Так, например, ваша команда должна быть кросс-функциональной, что с одной стороны хорошо, но с другой - недостижимо. У вас не может быть разработчика с навыками сисадмина, дизайнера и тестироващика одновременно. Он может "что-то понимать" в этом, но экспертную оценку дать не может по умолчанию. Другой недостаток - строгое соблюдение всех процессов - все без исключения митинги должны быть вовремя, на них должны присутствовать все без исключения. Поверьте, поначалу это кажется нормальным, но в какой-то момент вечные болталки утомляют (разрабы интроверты меня поймут).

Но это уже условности, да и несерьезно жаловаться на календарь полный митингов и синков. Реальная проблема Скрама - не все можно под него подстроить, особенно когда речь идет об инженерном внедрении, а не о разработке.
Скрам хорош, когда у вас маленький продукт, и вы не знаете, что из него вырастет. Другое дело, когда вы внедряете готовый коробочный продукт. Вот, например, SCCM как в нашем случае. Наша проблема была в том, что первые спринты у нас были чистые итерации по установке, настройке и пусконаладке. Итог спринта Скрам - появляется что-то, чем можно пользоваться. У нас же 4 спринта (2 месяца) заняло эту махину собрать, поставить и хоть как-то запустить. Ни о каких deliverables речи и не могло быть.

И в принципе мы не одни такие. Другие инженерные группы (ребята по мониторингу, инженеры-инфраструктурщики, админы баз данных) страдают не меньше нашего, поскольку показывать буквально нечего.

- Что вы сделали?
- Мы обновили прошику роутеров ядра.
- Что мы от этого получаем?

Да ничего вы не получаете, аптайм больше будет. :)

Хотя если вы спросите меня, гибкие методики лучше чем классика, хотя я терпеть не могу Скрам (мне больше Канбан по душе).

И если вы думали, что в западных конторах некомпетентный менеджмент отсутствует в принципе, то вы ошибаетесь.

https://www.ucheba.ru/article/5115?utm_referrer=https%3A%2F%2Fzen.yandex.com

Обожаю такие статьи. Про ИТ все как всегда, ИТшник он интроверт, но вот это добило.

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

Во-первых, системный администратор (который отвечает за серверы) с людьми общается редко (я об этом в своем самом первом посте писал), а тот кто общается много, это хэлпдеск, и к системному администратору он не имеет никакого отношения.
Во-вторых, большинство программистов сейчас так или иначе работает по модным методикам и разговаривает много. Очень много. Причем не только друг с другом, но и с руководителями проектов, тимлидами, пользователями и прочими.
В-третьих, конечно программист может работать по индивидуальному графику, удаленно по ночам и т.д. (таких в мире аж целых пара процентов, все остальные работают по классике с 9 до 18), но каким образом это зависит от его интраверсии - непонятно. Прогер такая же творческая личность и пашет тогда, когда припрет, и точно так же работают дизайнеры, писатели, журналисты и художники.

Мария Рамзаева, зачем вводите молодежь в заблуждение?
Запомни, студент, мир ИТ полон не только модных рюшечек и сложных задач с неадекватными сроками, но и людьми, которым очень интересно, почему у тебя на одном экране вКонтакте, а на другой буквы какие-то непонятные.

Вчера имел удовольствие поиграться с такой прекрасной штукой, как "Машина морали" - проект МИТ (http://moralmachine.mit.edu/), в котором пользователю предлагаются разные сценарии с участием беспилотных авто, эмулирующие катастрофу.
В каждом вопросе показывается два сценария аварии, где кто-то гарантированно погибает, и пользователю предлагается выбрать, кто должен умереть. Создатели проекта заявляют, что собранные ответы будут использованы для ИИ автопилота.

Вопрос решения, которое принимает беспилотный автомобиль в случае гарантированной аварии, рассматривается давно и мучает немалое количество ученых и инженеров со всего мира. Кого сбивать? Ребенка или женщину? 10 женщин или 10 мужчин? Богатого или бедного? На такие вопросы и нужно отвечать пользователю.

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

Но я, как инженер, не понимаю риторики.

Когда я проектирую решение, я в первую очередь рассматриваю различные риски и способы их ликвидации, но помимо этого - как сделать так, чтобы решение не ломалось в принципе. Если я буду проектировать беспилотное авто, первое, на чем я буду фокусироваться - это недопущение подобных дилемм .

Задача беспилотного автомобился не определять, кто должен жить, а кто нет. Его задача - не допускать смертей в принципе.

Сейчас вспомнил одну историю про гигантский факап компании Amazon Web Services (провайдер облачных услуг).

У Амазона есть сервис под названием S3 (Simple Storage Service) - облачное хранилище с неограниченным объемом данных. Люди используют его, чтобы держать там файлики, с которыми предстоит работать людям или системам. Особенность этого сервиса с его очень приличной отказоустойчивостью в том, что данные хранилища реплицируются (читай синхронизируются) между разными датацентрами на территории так называемого региона (будь то страна или континент).

То есть если ударить бомбой по целому городу, где есть датацентр Амазона, на работе это не отразится совсем.

Круто, да? Вот ради такого стоит любить свою профессию.

Однако в 28 февраля 2017 года сервис перестал работать в регионе Северная Вирджиния, что привело к отказу огромного количества систем. Среди именитых пострадавших такие персонажи как Snapchat и Razer.

Я уже молчу про множество Internet of Things продуктов, которые критично зависели от Амазона. Дошло до абсурда, что люди не могли сменить dpi рейзеровской мыши, а у других товарищей не работал пульт от умного телевизора.

Вы просто вдумайтесь - вы не можете поменять настройки мыши, потому что в нескольких сотнях километров от вас отвалился ЦОД, да еще и не один.

Я уже говорил, что в Скрам люди должны совмещать несколько ролей, и чтобы достигнуть этого, каждый член команды посещает несколько тренингов, чтобы его знание было сбалансированно с остальными.

Так, когда я начал работать в конторе, я прошел внутренние тренинги по управлению проектами и несколько тренингов по Windows Server.
Каждому сотруднику полагается на выбор доступ в Pluralsight или LinuxAcademy (или даже на оба портала), что позволяет в кратчайшие сроки набраться знаний.

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

Не то чтобы mastering этих двух скиллов гарантирует место большой шишки в среднесрочной перспективе, но без них не стоит даже и пытаться. Максимум что светит - захудалый админ на 100 человек в конторе среднего пошиба.

Ты же не этого хочешь, русский ИТшник Иван?

Как-то раз заспорился с приятелем про разработку ПО. Он утверждал, что написать с нуля приложение проще, чем переписать уже имеющееся, а я, наоборот, с пеной у рта доказывал обратное ("Да там пару вещей поправить, коннекты к апишке переписать, делов-то").
2 недели к ряду я бился на рефакторингом питонвской программы для торгового робота. Логика у робота простая (как и у спекулянтов на бирже в принципе) - купи подешевле, продай подороже. Парень, который написал альфа-версию движка, занимается программированием логический контроллеров на производстве. То есть его код будет гарантированно работать без ошибок (иначе слесарю-механику руку оторвет на производстве) и его упорству в плане надежных работающих систем реально можно позавидовать.

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

Что я могу сказать? После 2 недель отчаянной борьбы переделанный код так и не заработал. То тут, то там проскакивали новые косяки, а когда количество ошибок стало равно 0, движок все равно не работал. Теперь с ребятами будем ставить движок как есть (то есть как парень его написал), запустимся, а когда парень вернется из Австралии будем писать все с нуля.

Леша Зорин, прости дуру грешную, я был неправ! Писать с нуля проще.

Сегодня нарвался на увлекательную новость (http://vm.ru/news/405550.html).
Я искренне хочу верить, что это не попытка распила (разработка нейронных сетей очень дорогостоящее удовольствие), но допустим, что проект реальный и живой.
По сути что нужно - чтобы человек сфотографировал свой чулан или пространство под раковиной, выложил фотографию на сайт, и волшебная нейросеть прочитает фотографию (это, кстати, называется computer vision) и занесет данные счетчиков на сайт. Очень круто (нет серьезно), это очень и очень круто.

Что хотелось бы сказать по этому поводу. Здесь (в Нидерландах) мне приходилось пару раз отправлять фотографию своего ID, чтобы зарегестрироваться на местных госуслугах. Я фоткаю на телефон, прикладываю картинку на сайт, и далее "внутренний" сканер анализирует документ и заносит в анкету мои имя, дату рождения и т.д.

Приблизительно такой же модели, я подозреваю, хотят придерживаться и коммунальщики. Что в принципе здорово, только голландцы для этой задачи используют не дорогущую нейронную сеть, а обычный аналог FineReader. Если же русские хотят под такое дело запилить свой аналог Prisma (приложение на телефон, переделывающее ваши фотографии под стиль разных художников), то я на 10% думаю, что это очень круто (а там глядишь Медведев придет, и снова будут инновации, модернизация и нанотехнологии), и на 90%, что это попытка распила.

Кстати, не рассказал про еще одну интересную составляющую модных и трендовых ИТ команд и депртаментов - чатики.

Все помнят IRC? Протокол под названием Internet Relay Chat; люди, у которых были "районные" провайдеры интернета помнят локальные чатики, в которых можно было пообщаться в рамках одного провайдера.

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

Но психологический момент ИТшника (не люблю говорить ртом, люблю много печатать) остался и стал неплохой идеей.
Так появились такие продукты, как Slack и Hipchat - системы мгновенного группового обмена сообщениями.

Почему же продукты так выстрелили? (Hipchat был куплен конторой Atlassian, принесшей миру такого монстра как JIRA, а Slack занимает лидирующие позиции на рынке) Да просто классические мессенджеры, будь то Телеграм или Воцапп, на тот момент присутствовали только на мобильных устройствах, Скайп воспринимался как голосовая звонилка, а его бизнес-версии (Skype for Bunsiness, он же Lync, он же Office Communicator) подходили опять же только для голосовых звонков с презентациями.

Но более того - что Слак, что Хипчат в скором времени стали поддерживать так называемых ботов - программ, способных читать и отправлять сообщения в чаты. Из этого выросли разные боты, которые могут выложить в чат смешные картинки по запросу, выложить "мудрую" цитату и прочее.

Поскольку продукт, повторюсь, был сделан ИТшниками для ИТшников, у него соответственно появился API (этакий интерфейс для взаимодействия с приложением на уровне программ), и люди стали писать своих ботов. Админы же стали писать ботов для управления и контроля за серверами.

Из этого появился новый модный культурный тренд - ChatOps.

Все-таки голландцы невероятно смешные существа.

Парень потратил 3 недели чтобы написать торговый движок. Я потратил неделю, чтобы написать обшивку вокруг продукта (всякие маленькие подсистемы управляющие торговым ботом в целом), настроить серверы и адаптировать движок.
Другой парень в процессе написания сайта для бота.

Если собрать воедино количество трудочасов, выйдет что весь продукт написан за 2-3 недели - это невероятно быстро.

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


Фантастические все-таки существа.

https://habrahabr.ru/post/335010/

Кто не переваривает много буков: парень написал приложение для телефона Электронный дневник с доп. функционалом, оказался круче официальных конкурентов, конкуренты, используя свои связи в ДИТ, его продавили, а потом вообще убили возможность работать с бэкендом Электронного дневника. В итоге и парень, и конкуренты вылетели.

Грустно все это, на самом деле.

Была бы у парня вышка и несколько лет опыта работы, я ему переезд предложил.
Зачем таким мозгам пропадать.

Но не будем о грустном.

Итак, ChatOps (далее ЧО) - подход, подразумевающий использование чатиков для совместной работы и процессов разработки, внедрения и администрирования.
Вся идея в том, что в чат идут сообщения не только от пользователей (разрабов и инженеров), но и от ботов.

Так, например, популярный облачный продукт для мониторинга Datadog имеет интеграцию со Slack и может отправлять туда уведомления, если установка новой версии сломалась или один из серверов упал.
Другой вариант ботов - боты-администраторы (такие как HuBot или ErrBot). Незаменимая вещь в ЧО, если вам нужно что-то сделать на машине, но нет возможности (или желания) подключаться к ней напрямую.
Пишете сообщение "HuBot start service Web-Server on myweb.example.com", и бот сделает всю работу за вас и радостно отчитается.

Другой момент ЧО - человеческий фактор. Если у вас распределенная команда (т.е. люди сидят не в одном офисе, а то и не в одном городе/стране), то пытаться устроить с ними конф-колл задача не из простых. Для такого создаются определенные комнаты (будь то по продуктам или по системам), в которых люди могут общаться на узкоспециализированные темы: строго веб разработка, бекэнд, администрирование и тд.

У нас есть канал под названием #war-room: когда случается инцидент (что-то с громким свистом падает), инженеры и разработчики дружно забегают в чат и вместе решают проблему.
Да, печатать долго, но практика показывает, что это быстрее и эффективнее, чем найти всех и каждого чтобы посадить в одно помещение.

К слову о DevOps, слышал как ребята рассказывали: "У наших разрабов есть доступ к серверам, они могут туда зайти и срелизить если надо или логи посмотреть, если что-то не так, у нас же DevOps"

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

У меня нет 90% прав делать что-то на серверах (я на минуточку на Ops стороне баррикад), и в последний раз когда мне пришлось это сделать - через непосредственный интерфейс виртуализации, когда у нас кругом сеть упала.

Еще раз - DevOps это не технология, а подход.

Кстати, еще одной отличительной чертой западных ИТшников - они рассказывают о своих планах на будущее, когда покидают компанию.

Сегодня я получил письмо от, уже бывшего, руководителя разработки. Она поблагодарила всех за 4 года, пожелала удачи, но самое интересное - в конце пишет, что не знает о своих планах на будущее, и где она будет работать после.

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

Честно говоря, этот культурный момент я понять пока не могу.

Тут друзья пояснили, что люди так делают, чтобы оставаться на связи и сотрудничать в будущем, если что.

Ну ладно.

У меня есть мечта идиота - хочу написать портал "vindjemoeder.nl" (или findyourmom.com или даже найдисвоюмамку.рф).

Человек заходит на портал и забивает имя и, например, дату рождения. Платформа ищет профили человека с соцсетях - инстаграме, контакте, фейсбуке и выводит их на экран, с например, датой и местов.
Вот и представьте - 2030-ый год, школьник заходит на портал и ищет свою маму. Находит кучу контента, где его мамка, пьяная в хламину, висит на шее у чернокожего качка в каком-то клубе. Умора же. :) Достойный ответ на "а вот я в твои годы!".

С другой стороны, родитель будет усердно чистить свои соцсети, когда его чадо доберется до интернета. В таком случае можно статично выкачивать вообще все фотографии отовсюду.
Все бы здорово, но тогда нужно иметь вычислительные мощности больше чем у Вконтакте, Фейсбука и Инстаграма вместе взятых.

Несбыточная мечта. 😩

Вот не понимаю.

Ходил в школе в театральный кружок, боязни сцены нет, экстраверт, с людьми общаться умею.
Но каждый, зараза, КАЖДЫЙ раз нервничаю во время презентации продукта. Каждый, мать его раз, приходится потом 15 минут пить успокаивающий чай и приходить в себя.

Почему - вообще не понимаю.

Сегодня была комедйиная ситуация.

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

Я всегда ожидаю такого поведения от коллег из бизнес департаментов, они не ИТшники на работе (только дома), и все равно пытаются козырить своими знаниями в операционных системах. К таким всегда отношусь с состраданием и терпением, хотя и натерпелся за время работы в техподдержке.

Но от коллег-технарей такое поведение каждый раз, как ведром холодной воды на голову.