Привет, Хаброжители! Любой компании хочется добиться большей эффективности разработки ПО, ведь это напрямую влияет на прибыль. Большая часть литературы по Agile ориентирована на крупные компании с высокими темпами роста, но как быть, если ваша компания находится не на переднем фланге ИТ? Хорошая новость в том, что каждая организация может улучшить производительность, и эта книга поможет найти конкретные пути и решения, позволяющие извлечь максимальную выгоду от Agile-методов. «Я не евангелист Agile. Я сторонник того, что работает, и противник того, что много обещает, но не приносит результатов. В этой книге методология Agile представлена не как движение, которое требует повышенной сознательности, а как набор специальных управленческих и технических методов, эффект и взаимодействие которых доступны для понимания любому бизнесмену или айтишнику. Энтузиасты Agile могут раскритиковать эту книгу за то, что она не пропагандирует передовые методы Agile. Но в этом и смысл — акцент на практических методах, доказавших свою эффективность. История Agile полна идей, которые удалось успешно реализовать паре энтузиастов в некоторых организациях, но которыми невозможно пользоваться всем остальным», — говорит Стив Макконнелл. Новая книга Стива Макконнелла, автора легендарных книг Code Complete и Software Estimation, объединяет реальный опыт сотен компаний. Воспользуйтесь простым и понятным руководством по современным и самым эффективным методам Agile.

Привет! Меня зовут Катя, и я работаю тестировщиком мобильных приложений более пяти лет. Последние три года я тружусь в iOS-команде Badoo, и еженедельно мы релизим от трёх до семи новых фич, от трёх до пяти технических тасков и от пяти до 13 багфиксов. Как вы понимаете, приложение меняется с такой скоростью, что поддерживать классическую тестовую документацию (test cases) неэффективно: почти всегда она будет устаревшей.

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

В этом случае визуализация позволяет сэкономить кучу времени, поэтому мы решили попробовать использовать mind maps (или «ментальные карты»), которые так же удобны в использовании, как чек-листы, но более наглядны за счёт визуального формата.

Сегодня мы подробненько разберём созданную мной mind map для тестирования iOS-приложения (далее именуемую «моя прелесть»), а также пройдёмся по ресурсам, которые можно использовать при построении mind map для мобильного приложения, чтобы покрыть максимальное количество важных сценариев.

Перевод статьи Vincent Driessen: A successful Git branching model

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



В качестве инструмента управления версиями всего исходного кода она использует Git.

Аббревиатуру MVP можно интерпретировать по разному, но в статье речь пойдет не о спорте.

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

В статье я постараюсь описать ситуации, с которыми очень часто сталкиваются мобильные разработчики на реальных проектах, и когда действительно стоит задуматься о переходе на архитектурный паттерн более сложный чем “One UIViewController (Activity) to rule them all”. Или лучше сказать, когда нам это будет выгодно. Далее речь пойдет о компромиссе между временем и сложностью разработки в реалиях “обычных” проектов, которые в основном приходят на оценку и разработку.

— Не понимаю, почему люди так восхищаются этим Карузо? Косноязычен, гугнив, поёт — ничего не разберешь!
— А вы слышали, как поёт Карузо?
— Да, мне тут кое-что из его репертуара Рабинович напел по телефону.

Детектив по материалам IT. Часть первая

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

Проект мы переписали, уже без MVC, просто руководствуясь принципами – код перестал быть похож на клубок спагетти и сократился наполовину (об этом позже, в обещанной статье про то, как мы применяли «принципы» в своем проекте). Но хотелось понять, что же мы сделали не так, в чем была ошибка? И в течении долгого времени изучалось все, что содержало аббревиатуру MVC. До тех пор пока не встретились исходные работы от создателя – Трюгве Реенскауга…

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

Более 30 лет собранные в MVC идеи и решения остаются наиболее значимыми для разработки пользовательских интерфейсов. Но как ни странно, несмотря на существующую путаницу и обилие противоречивых трактовок, разработчики продолжают довольствоваться информацией «из вторых рук», черпая знания о MVC из википедии, небольших статей в интернете и фреймворков для разработки веб-приложений. Самые «продвинутые» читают Мартина Фаулера. И почему-то почти никто не обращается к первоисточникам. Вот этот пробел и хотелось бы заполнить. И заодно развеять некоторые мифы.

Детектив по материалам IT. Часть вторая

В этой части я покажу как изначально выглядело деление пользовательского интерфейса и что из себя представляли Вид и Контроллер. Попробую рассказать почему в современных GUI библиотеках используется их объединение и какие вообще интересные решения можно найти в этой области на сегодняшний день. Ссылки на первоисточники приведены в начале первой части.

Начну с Вида. Не смотря на то, что Вид определяется как модуль, отображающий Модель – "а view is a (visual) representation of its model", на практике к Виду, как правило, просто относят все графические элементы GUI, то есть Видом считается все то, что мы видим на экране ЭВМ.

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

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

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

Вид тестовой документации также зависит от ситуации на проекте и ожиданий заказчика.

Часть 1: точки, векторы и базовые принципы

Современные трёхмерные игровые движки, используемые в крупнейших проектах — это тонкая смесь математики и программирования. Многие программисты игр признают, что всецело понять их очень непросто. Если вам не хватает опыта (или профессионального образования, как мне), эта задача становится ещё более сложной. Я хочу познакомить вас с основами графических систем 3D-движков.

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

В конце июня завершился международный фестиваль рекламы «Каннские львы». Высшей награды «золотого льва» в отдельных номинациях удостоились 18 роликов.
Невероятным успехом пользовались видео компании Nike — пять из них были признаны победителями по версии критиков.

Сделай это «просто»​

Nike — молодая корпорация, история берет начало в 1963 году. Мир восстанавливался после второй мировой войны. Фил Найт окончил университет, недолго проработал специалистом по финансам, и отправился в Японию для заключения первой деловой сделки. Знал ли он, что ему суждено основать мировой бренд?

Идея Фила Найта была простой — заполнить американский континент недорогими кроссовками азиатского производителя, купля-продажа. Мало кто знает, но первоначально компания называлась Blue Ribbon Sports, а беговая обувь, которую она реализовывала, носила имя «Tiger», ныне известная под брендом Asics.​

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

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

Как возникла необходимость отойти от классической Каскадной Модели жизненного цикла разработки

В 2009 году мне предложили выбрать и реализовать один из «гиблых» проектов. Приставку «Гиблый» каждый получил за то, что раньше за них уже пробовали браться, но ничего не вышло.

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

Большой пример: только оказавшись под санкциями и цене нефти в 50 долларов за баррель (против 110 ранее) руководство страны перешло от рассуждений и неспешных телодвижений к активным действиям по развитию высокотехнологичной экономики.

Так и один из моих Заказчиков созрел и я взялся сделать для него проект по разработке нового функционального модуля Корпоративной Информационной Системы (ERP-системы), который должен был добавить 400 новых пользователей системе и обеспечить проверку 40 000 ипотечных кредитов в год.

Предисловие переводчика: Недавно я рассказал о том, как реализовать процедуру планирования выпуска релизов по продуктам с помощью семейства продуктов Atlassian и дал ссылки на статьи как сделать тоже самое в Team Foundation Server и Redmine.

А что делать если компания не дозрела купить JIRA, TFS или Redmine, как обойтись только Excel-ем?

И эта статья о том как это сделать.

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

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

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

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

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

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

К моему удивлению оказалось, что на вроде бы актуальный вопрос: «Как построить хорошую/красивую архитектуру ПО?» — не так легко найти ответ. Не смотря на то, что есть много книг и статей, посвященных и шаблонам проектирования и принципам проектирования, например, принципам SOLID (кратко описаны тут, подробно и с примерами можно посмотреть тут, тут и тут) и тому, как правильно оформлять код, все равно оставалось чувство, что чего-то важного не хватает. Это было похоже на то, как если бы вам дали множество замечательных и полезных инструментов, но забыли главное — объяснить, а как же «проектировать табуретку».

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

Данная статья является попыткой ответить на эти вопросы хотя бы в первом приближении.

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

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

Список составлен в хронологическом порядке* и включает, на наш взгляд, самые интересные игровые конференции, экспо, выставки и фестивали этого года. Жирным выделены мероприятия, которые являются партнерами DevGAMM — на них вы часто сможете найти скидки в нашем блоге или рассылке.

«Выступление» означает демонстрацию слайдов с текстом, изображениями и графиками. Конечно, можно обойтись и просто словами, но желательно прибегать к наглядным материалам. Визуальные элементы помогают запомнить и привлечь внимание. И сегодня у слова «презентация» есть ясный синоним — PowerPoint.

Конечно, существуют другие программы, которые позволяют создавать и редактировать презентации. Но явление, когда люди создают бессмысленные скучные наборы слайдов, называют «смертью от PowerPoint». Мы ведь не называем плохой стиль письма «смертью от Word», мы не называем ошибки в вычислениях «смертью от Excel». Программа PowerPoint стала стандартом для визуального сопровождения выступлений.

Но так было далеко не всегда. Тридцать—сорок лет назад мир не был настолько цифровым, как сегодня. Дешёвые персональные компьютеры только создавали свой рынок. Чаще всего это были машинки для бизнеса, а не домашнего использования. Компьютерная графика ещё прокладывала свой путь для повсеместного использования. На тот момент жизнь была ещё очень аналоговой.

У компьютеров были сотни килобайтов ОЗУ, а Microsoft была мелкой фирмой. Её Windows не пользовалась особым успехом, Word и Excel куда лучше продавались на Mac. Если для выступления были нужны слайды, выступающий не создавал слайды самостоятельно. Приходилось полагаться на отдел дизайна, который слабо представлял, чего от него хотят. А результат демонстрировали на кодоскопе или, реже, на 35-мм плёнке.

В этот странный период свет увидел PowerPoint, ещё не в составе пакета Microsoft Office. Но обо всём по порядку.

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

В своей статье Ник Бабич, специалист по разработке мобильных приложений и UX дизайну, рассматривает три базовых модели навигации — меню-гамбургер, Tab bar и управление жестами — и описывает их сильные и слабые стороны.

Поведенческая экономика — это потрясающая область экономики, исследующая психологию процесса принятия решений потребителями.

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

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

Scrum — достаточно простая методология. Работать же по скраму не так и просто. Точно так же происходит со многими инструментами, например с покером для планирования. Практика сама по себе вполне понятная, но продуктивно её использовать в течении длительного времени затруднительно.
В этой статье я расскажу про технику, которая упрощает процесс оценок в работе скрам команды.
Итак, в чём же сложность?
Как вы знаете, story points — это относительные оценки объёма работы в истории. Нет способа оценить одну единственную историю в story points, вы всегда сравниваете историю с другими историями через story points. Покер может хорошо сработать в начале проекта, когда команды оценивает много историй в течении короткого промежутка времени.
Но позже, во время регулярной переоценки существующих историй и оценок новых историй становится значительно труднее, потому что калибровка одного story point забывается: «что такое один story point», «что-то я не уверен, что эта история действительно в 3 раза больше нашего золотого эталона», «эти две истории размером 5 не выглядят одинаковыми в размере, с моей точки зрения». Знакомые проблемы?