Вдруг мы понимаем, что Jira превратилась в помойку. Каждый второй РП настраивал Jira как ему было удобнее бесконтрольно. А когда проект начал гореть, начал тушить пожары вручную, оставляя задачи в трекере в каком-то состоянии, далеком от завершения. Если в проекте создан полноценный CI/CD, то большая часть задач на разработку будет в правильном финальном статусе, но остальные…

Часть проектов заморозилась, часть отвалилась, РП выгнали, но задачи в Jira не почистили. У вас на руках 10-20 идущих “проектов” и нужно быстро понять где больше болит.

Сопоставив опыт участников посиделок КиФБ (клуб имени Фрэнсиса Бекона) в решении этой задачи, мы представили этот опыт в записанном виде (за что спасибо всем участникам).

Мы в Mail.ru Group вкладываем много сил в развитие продуктов компании Atlassian и, в частности, Jira. Благодаря нашим усилиям свет увидели плагины MyGroovy, JsIncluder, My Calendar, My ToDo и другие. Все эти плагины мы развиваем и активно используем внутри компании.

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

Для проведения экскурсий в офисе нужно было предусмотреть создание запросов с проверкой пересекающихся экскурсий. Для тестировщиков — сделать механизм отслеживания этапов тестирования с ответственным за выполнение. Техподдержка хотела получить автоматический доступ к базе знаний.

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

Всем привет.

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

Хоть на самом деле конвертеров уже появилось великое множество, не все могут превращать otf\ttf в woff\eot\svg. Существуют специализированные сервисы, которые работают с другими форматами(.pfb, .dfont и др.).

Современные web-приложения зачастую содержат множество "движущихся частей" и сторонних зависимостей. В процессе рефакторинга и добавления/изменения функциональности в таком приложении может произойти поломка существующих use-case сценариев и нестабильная работа в определенных браузерах.

Для своевременного обнаружения таких ситуаций и выполнения непрерывной интеграции необходимо функциональное тестирование web-приложения. В статье пойдет речь о двух бесплатных open-source решениях:

• https://devexpress.github.io/testcafe/
• http://nightwatchjs.org/
  

Как говорят иные отважные люди: «От dev до prod — всего один шаг». Люди опытные добавляют, что шаг этот называется «тестирование», причём самое разнообразное, и нам просто нет смысла им не верить.



Нагрузка имеет значение: водитель этого грузовика умудрился обрушить мост весом своего ТС, счёт за восстановление составил примерно $21.3M. К счастью, тестирование ПО обходится дешевле!

Конечно, говоря о тестировании, нужно понять, с чем и за что мы боремся. Мы сознательно ограничили себя и решили сегодня поговорить исключительно про нагрузочное тестирование и тестирование производительности: темы, полярно удалённые друг от друга, крайне интересны в самом практическом выражении. Рассмотрим инструменты для того и другого, не привязываясь к какому-то конкретному стеку технологий, так что не удивляйтесь соседству Яндекс.Танк и BenchmarkDotNet!

Сразу скажу, что сайт будет быстрее работать, если заменить Bootstrap на чистый CSS и JS. Эта статья про то, как быстро начать разрабатывать красивые web-приложения, а оптимизация это уже отдельный вопрос, выходящий за пределы этой статьи.

Для начала надо хотя бы немного разбираться в HTML, CSS, JavaScript, XML, DOM, ООП и уметь работать в терминале (командной строке).


В этой статье сделаю выжимку минимально необходимого для работы и сделаем такой таймер:

Участники:
Алексей Кривицкий, Асхат Уразбаев, Денис Миллер, Кирилл Медведев

Темы
* Scrum-команда
* Понятие ролей, соотношение с должностями
* Кроссфункциональность и узкая специализация
* Синергия команды: 1 + 1 = 11
* Тестировщик и разработчик в Team
* Менеджер проекта
* Product Owner
* Мотивация, индивидуальные поощрения
* Scrum Master – вымирающий динозавр

Алексей Кривицкий — лидер украинского Agile сообщества, тренер Scrum.

Блог Подкаста (rss for itunes)

Привет! Меня зовут Стас, я Product Owner команды «Welcome Aboard». Мы делаем удобный продукт для соискателей, желающих устроиться работать в Альфа-Банк.

Зачем нужен этот продукт? Чтобы сделать процесс общения кандидатов с банком приятнее и эффективнее на каждом шаге. Кроме того, это неслабо экономит время нашим рекрутерам, а довольный рекрутер – это всегда хорошо.

Сейчас мы сосредоточились на электронной анкете соискателя. В ней более 50-ти полей, она разделена на 6 шагов и работает на любом устройстве.



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

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

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

UPDATE 1
UPDATE 2

Думаю, что многим будет полезен мой опыт поиска работы программистом за границей. Тем более что он совершенно отличается от описанного в публикации «Как айтишнику уехать в Германию. Часть 1».

Сразу скажу, что я женат и у меня двое детей 5 и 11 лет. Это я говорю к тому, что требования к условиям переезда для семейного человека выше, чем без детей или вообще без семьи. Например, необходимо учитывать увеличение расходов на минимум 3-к квартиру, коммунальные услуги из расчета на 4 чел, платное образование и его уровень. Также важен транспорт, так как каждый день детям нужно добираться в школу и из школы. Еще одним важным критерием выбора страны для переезда является уровень медицины и экология. И наконец, расходы на содержание семьи из 4 человек на порядок выше чем на двоих и тем более — для одного. Все это ставит довольно жесткую нижнюю планку по зарплате.

Учитывая все вышеописанное, может показаться что переезд за границу с семьей находится на грани нереального. Но это не так! И хоть я не стану опровергать, что холостяку намного проще перемещаться по миру, но подчеркну, что мой опыт показал, что эта простота заключается исключительно в отсутствие забот, присущих семейным людям (я описывал их выше). К еще одному преимуществу холостяков (теоретически) можно отнести то, что они могут соглашаться на более низкие зарплаты чем хотели бы, но с перспективой роста.

В общей сложности поиск работы мне занял 9 мес. Страной назначения я выбрал Германию, так как IT там на высоком уровне, огромное количество стартапов, особенно в Берлине, высокий уровень бесплатного образования и сильная медицина. К тому же я более менее знал немецкий.

Мировой рынок IT стремительно развивается. С каждым годом профессия разработчика софта становится все более востребованной — уже в 2017 году в мире насчитывался примерно 21 миллион программистов различных направлений.

К сожалению, русскоговорящий рынок IT находится еще на начальной стадии развития — уже есть крупные и успешные проекты, но рынок еще долго не сможет сравняться с европейским и американским, которые производят до 85% всех IT-продуктов мира.

Когда я прочитал: «Agile is much more than just Scrum» — в описании сертификационного курса Certified Agile Professional компании ScrumTrek, то первое, о чем я подумал: почему ScrumTrek, тогда уж нужно было назваться AgileTrek? После прохождения этого обучения я вернулся к этому утверждению с более серьезным настроем. Так что же я вынес с тренинга? Записи, раздаточный материал и сертификат Certified ICAgile Professional? А как же понимание, что такое Agile? В чем заключается концепция Agile-подхода? Что такое Agile mindset?

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

"Глупый учится на своих ошибках, умный на чужих".

Всем доброго дня. В этой статье я намереваюсь разобрать ошибки произошедшие и досконально описанные в топике Обратная сторона Agile. Это ни в коей мере не holywar, ни тем более какой-либо blame. Мне лишь интересно препарировать эти вопросы со стороны исследования и отчасти восстановить доброе имя SCRUM'a.

Привет, хабрадруг. Считаешь ли ты, что waterfall (каскад) при разработке ПО — это единственный расово-верный подход? Да или нет — спеши под кат.

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

Работая более 20 лет в IT-индустрии, каждую новую разработку я начинал строить с проектного офиса. Более того, несколько раз мне приходилось объяснять руководству, зачем нанимать пиэмов. При наличии руководителей отделов, не так просто объяснить людям, которые не принимают непосредственного участия в разработке софта, что же именно будут делать менеджеры проектов. Приходилось преодолевать заметное сопротивление.

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

Привет!

Меня зовут Александр, и я руковожу ИТ разработкой в УБРиР!

В 2017 году мы в центре развития сервисов информационных технологий УБРиР поняли, что пришло время глобальных изменений, а точнее — agile-трансформации. В условиях интенсивного развития бизнеса и быстрого роста конкуренции на финансовом рынке два года – внушительный срок. Поэтому пришло время подвести итоги проекта.

Самое сложное – менять свое мышление и постепенно культуру в организации, где принято рассуждать: «а кто будет начальником в этой команде?», «начальник лучше знает, что нам нужно делать», «мы здесь работаем уже 10 лет и знаем лучше наших клиентов, знаем, что им нужно».

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

• Страх потерять власть и “погоны”;
• Страх стать не нужным для компании.

Встав на путь трансформации, мы выбрали первых «опытных кроликов» — сотрудников retail-направления. Первым делом провели редизайн неэффективно работающей структуры ИТ. Придумав целевой концепт структуры, приступили к формированию команд разработки.

Негибкий “Энтерпрайз” и гибкие методологии

Существует устоявшееся мнение, что IT-специалист в крупных компаниях — это маленький “винтик” в огромном механизме, призванный выполнять какую-то конкретную функцию. А механизм, в свою очередь, беспощадно эксплуатирует ресурс своих “винтиков”.

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



Я расскажу, как у нас в Лаборатории выстраиваются процессы работы. Мы опираемся на концепцию Agile. В качестве основного фреймворка мы выбрали Scrum, модель производства — командно-центричная.

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

Бум интереса к этой методологии прошел, однако до сих пор многие молодые команды легко очаровываются теоретической магией scrum, обещанием щелкать новые требования, как орешки, и не морочиться по ТЗ, бросаются внедрять на своем производстве и тут же натыкаются на трудности. Scrum вообще родился как методология разработки ПО, если вдруг кто забыл, и для успешного использования в web-разработке требует некоторой настройки. Это отдельный вопрос, в этой заметке я хотел бы затронуть другую тему и предостеречь от очевидных, в общем-то, ошибок, связанных с формированием требований к проекту. В любом описании методологии по запросу в Google говорится про важность роли scrum master'a и изложении требований к проекту в виде историй, но никто не говорит о том, откуда берутся требования, и нужно ли вообще их реализовывать. Без понимания этого момента сделать что-то путное вряд ли получится, и методология тут ни при чем.

Про то, что такое Scrum и с чем его едят написаны миллионы статей. Однако большинство из них предполагают, что до скрама существует некий вакуум, либо наоборот жесткая среда с ведением процессов по PMBOK и др. Множество авторов пишут про «нулевой спринт» в начинающимся проекте, про подбор идеальной команды, про выбор длины спринта, однако в свое время я не нашел большого количества статей про внедрение Agile методологий в существующую среду, в которой до этого не было методологий, но уже были сложившиеся традиции.

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

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

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

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

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

А главная задача — это сделать поиск работы простым и полезным занятием.