Управление разработкой *

/ фото Alexandre Dulaunoy CC

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

/ фото Steven Tyler PJs CC

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

Некоторые юзкейсы довольно просты (например, размещение сайта или веб-приложения), тогда как другие – достаточно сложны (вспомните историю об инфраструктуре Netflix).

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

Я написал свои первые несколько строчек кода почти 32 года назад, когда мне было 6. Я развил очень сильные инстинкты программирования и мог смотреть на любую проблему, сразу зная, как ее решить — просто интуитивно.

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

Но одной интуиции недостаточно. Я столкнулся со стеной. И никакой инстинкт кодировщика не помогал мне сквозь нее пробиться. Далее Bill Sourour поделится с нами информацией о том, как не останавливаться на достигнутом. Кому-то эти рассуждения, безусловно, покажутся очевидными. Ну, а кому-то — пригодятся.

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

Но случается и так, что мы беремся за работу над большими проектами. Под «большими» я понимаю композицию следующих факторов:

1. Более 50 проектов в solution’е. Назначение не всех из них вы знаете
2. Билд и выкладка длятся более 5 минут
3. Над кодом работают десятки или сотни человек в разных офисах (возможно и странах)
4. Существует четкое разделение труда и область ответственности каждой команды
5. Существуют строгие регламенты, стандарты оформления кода, прохождение ревью является обязательным критерием выполнения задачи
6. Учет рабочего времени производится позадачно, анализируются причины расхождения оценок и реальных трудозатрат

Бюрократия в этом случае – необходимое зло, тем ни менее, действующее на нервы. Чтобы избежать потерь драгоценных клеток я советую сразу подготовиться к тому, что придется поменять свой привычный workflow. Хорошая новость состоит в том, что, переучившись, вам не составит труда поступать также и на небольших проектах. Скорее всего, ваши коллеги будут приятно удивлены такой педантичностью

В минском офисе Wargaming регулярно проходят встречи, на которых сотрудники компании делятся опытом и обсуждают насущные вопросы, волнующие разработчиков, менеджеров, дизайнеров, продюсеров, художников – словом, всех тех, кто работает в IT и геймдеве. Эти митапы мы называем WG Talk и проводим в закрытом формате, только для сотрудников компании.
Но есть темы и знания, которыми нельзя не поделиться с широкой аудиторией. Поэтому мы организуем Open WG Talk.

Сегодня мы хотим поделиться с вами видеозаписями выступлений последнего Open WG Talk, темой которого стало продуктовое управление и внедрение новых процессов. Под катом вы найдете доклады Сергея Бережного, директора разработки Wargaming, и Ярополка Раша, руководителя медиасервисов Wargaming.



Приятного просмотра!

/ фото Juhan Sonin CC

Постоянно меняющиеся требования, предъявляемые к облачной инфраструктуре, ведут к необходимости проработки новых бизнес-моделей и создания архитектурных решений. Это позволяет постоянно повышать уровень защищенности и управляемости данных.

В нашем блоге на Хабре мы уже писали о решениях и сервисах для управления данными и организации резервного копирования в облако IaaS-провайдера.

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

/ фото Dennis van Zuijlekom CC

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

Они обращают внимание только на обещания (зачастую на словах) IaaS-провайдера снять с компании груз ответственности за работоспособность и стабильность ее IT-инфраструктуры. Несмотря на распространенность такого подхода, хотим предостеречь вас – если вы рассчитываете делегировать часть ответственности по столь критичным вопросам облачному сервису, подумайте дважды, а лучше трижды»

Такой совет на последней конференции «Data Summit» в Нью-Йорке дали Дон Салливан (VMware)» и Майкл Кори (Ntirety), пропагандирующие осторожное отношение к обещаниям IaaS-провайдеров взять на себя заботу о технических нуждах клиентов.

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

В дополнение к этим тезисам представители индустрии виртуализации составили список вопросов, на которые следует получить аргументированные ответы до того, как подписывать договор с провайдером IaaS. Этот список призван помочь вам в отделении «зерен от плевел». Мы, команда провайдера виртуальной инфраструктуры 1cloud.ru, решили сразу ответить эти на вопросы в рамках самопроверки.

Виктор Шабуров — широко известный в узких кругах человек. Но на волне событий, связанных с очередной победой российских программистов из Санкт-Петербурга (СпбГУ) на чемпионате мира по программированию 2016 года, известность Виктора вновь вышла за пределы этих кругов.

Виктор не только является спонсором команд по спортивному программированию разного уровня и географии (команда СпбГУ — в том числе), он — предприниматель, инвестор и один из основателей компаний Looksery Inc., Handster Inc. и SPB Software.

Виктор Шабуров прошел путь от увлеченного математикой школьника из поселка под Екатеринбургом до технического директора компании Snapchat. Мы решили узнать о том, как это было, из первых рук.

Источник: wired.com

Считается, что первый браузер появился 25 декабря 1990 года. Его создателем был Тим Бернерс-Ли, младший сотрудник Европейской организации по ядерным исследованиям. По его словам, разработка не заняла много времени (около двух месяцев), потому что он использовал платформу со специальным конструктором приложений. Тим создал так называемый Консорциум всемирной паутины (World Wide Web Consortium, сокращенно W3C), который разрабатывал стандарты, внедряемые в программное обеспечение.

К концу 1992 года, кроме самого первого браузера под названием WorldWideWeb, на рынке появилось множество других, большинство из которых было основано на библиотеке libwww – Line Mode Browser, ViolaWWW, Erwise, MidasWWW, MacWWW и другие. Следующими браузерами, выпущенными в 1993 году, были Cello, Arena, Lynx, tkWWW и NCSA Mosaic.

Mosaic, мультиплатформенный браузер, был разработан в организации National Center for Supercomputing Applications (NCSA). В октябре 1994 года Mosaic был на пути к превращению в эталонный для всего мира интерфейс. Несколько компаний лицензировали Mosaic, чтобы создать свои собственные коммерческие браузеры, такие как AirMosaic и Spyglass Mosaic.

Аудиомания на м. Электрозаводская

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

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

В теории все эти рассказы звучат очень заманчиво – кажется, что для создания интернет-магазина нужно одно лишь большое желание и голова на плечах. На практике «долину смерти» преодолевает далеко не каждый e-commerce проект – даже если к его созданию основатели подходят со всей серьезностью, не боятся рисковать и готовы буквально жить на работе.
 
Мы в Аудиомании не только развили собственный электронный бизнес, но и за все время его существования пообщались и стали свидетелями большого количества взлетов и падений в e-commerce. И готовы рассказать о том, как делать не надо: в этом материале мы решили собрать наиболее часто встречающиеся ошибки, которые могут дорого стоить вашему онлайн-проекту еще на старте.

Надо начать, а там – как пойдет

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

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



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

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

Юрий Гурский — человек, о котором сегодня много пишут. Представитель немногочисленных белорусских предпринимателей, ныне вице-президент Mail.ru Group и человек, частично ответственный за успех MSQRD.

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

Юрий нашёл время для того, чтобы пообщаться с нами и ответить если не на все, то хотя бы на часть вопросов.

У Самата samat Галимова интересный опыт: от практики в «Яндексе», через Bookmate, до технического директора издания «Медуза». Мы задали Самату несколько вопросов, для того чтобы быстро прояснить, каково это — разрабатывать современный медиа-продукт для многомиллионной аудитории.

Текущее место работы
— Meduza.io

Должностные обязанности
— Отвечаю за всё техническое, что есть в Медузе.

/ фото ChrisDag CC

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

Здравствуйте, уважаемые читатели.

Сегодня мы хотели бы поговорить с вами о важном аспекте гибкого управления проектами, но не о чистом Agile, а о планировании проекта и итераций. Речь пойдет о жанре «Пользовательских историй», которым посвящена очень успешная на Западе книга Джеффа Паттона с предисловием Мартина Фаулера:



В статье, текст которой вас ждет под катом, мы перевели «User Story Mapping» как «визуализация функционала». Вариант взят из очень интересной книги Бориса Вольфсона "Гибкое управление проектами и продуктами", также выходившей в нашем издательстве.

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

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

Но если копнуть глубже, возникнут вопросы. О каких именно программистах речь? О тех, кто проектирует ПО? О тех, кто разрабатывает алгоритмы? О ведущих разработчиках или простых «кодерах»? В любом случае, одного мнения здесь быть не может.

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

История дружбы двух компаний: «ТМ» и Redmadrobot началась во дворе… нашего офисного центра. Кроме шуток — офисы наших компаний находятся в одном здании и, даже несмотря на такую «близость», долгое время мы друг о друге лишь слышали.

До того самого момента, когда «Роботы» (так ребята называют себя сами) первыми вышли на связь и предложили прийти к ним в офис, познакомиться и пообщаться. Так сложилось, что наше «общее» знакомство сразу стало продуктивным — Boomburum рассказал, как правильно вести блог на Хабре, а после этого разработчики «ТМ» попали на пьянку в офис Redmadrobot. Так всё закрутилось, завертелось и в один определённый момент за столом остались только я, Максим и диктофон.

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

Автор: Евгений Ефимов
QA Lead, DataArt

Моряки, самолеты и корпорации

• Н.Н. Талеб и моряки.
• Абрахам Вальд и самолеты.
• Левитт и корпорации.

Существует понятие «систематическая ошибка выжившего». Оно встречается в книгах Талеба “The Black Swan. The Impact of the Highly Improbable” («Черный лебедь. Под знаком непредсказуемости» и “Fooled by Randomness: The Hidden Role of Chance in Life and in the Markets” («Одураченные случайностью. Скрытая роль Шанса на рынках и в Жизни»). Он описывает красивую картину, на ней древнегреческие моряки молятся богам во время шторма. Богам нравится, как они молятся? и поэтому моряки спасены. Шторм превращается в штиль или слабый ветер, корабль доплывает до берега, и все остаются целы. Когда спрашивают других моряков, как удалось доплыть, они тоже говорят: «Мы молимся богам и всегда доплываем». Проблема в том, что мы не можем спросить об этом моряков, которые утонули. Возможно, что они тоже молились, но не доплыли. И вообще дело было не в этом, а, т. к. в то время почти все моряки были религиозны, можно предположить, что молились все. И есть вероятность, что это не действует.
Вторая история — про математика и статистика Абрахама Вальда и про самолеты. Действие происходит во время Второй мировой войны. Британские бомбардировщики возвращаются на базу. Задача — понять, где и как укреплять самолеты, чтобы как можно больше возвращалось и как можно меньше падало. Они смотрят на самолеты, которые вернулись, и говорят, что необходимо укреплять наиболее поврежденные попаданиями части. Поскольку в них все время стреляют, мы их укрепим, и все пули улетят обратно во вражеский самолет и всех там перебьют.

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

Стивен Левитт написал интересную книгу «Фрикономика». Он выбрал стандартные книги из серии «10 шагов к успеху» и проанализировал две книги, где рассказывалось про корпорации, использовавшие нововведения, которые привели их к успеху. Эти книги были условно написаны в 2000 году, и корпорации, используя эти наработки, побеждали остальные компании. На момент, когда Левит их анализировал оказалось, что три четверти этих корпораций закрылись. Они оказались убыточными, потому что внешняя среда поменялась, а они не изменили подход к успеху. Соответственно, все эти истории успеха не всегда и не для всех работают.

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

История знает не один десяток таск-менеджеров, которые стремятся захватить умы и завоевать сердца пользователей. Однако у последних есть достаточно аргументов «за» и «против», чтобы мотивировать разработчиков подобных сервисов на дальнейшие подвиги. Более того, кому-то не хватает существующих таск-менеджеров, и как известно, спрос рождает предложение.

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

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

Корпорация Microsoft запускает новый сервис — Planner. Он станет непосредственным конкурентом популярного таск-менеджера Trello. Сравнивая внешний вид и принцип работы двух сервисов, можно найти много общего.