Сказ о том, как мы мобильное приложение писали. Часть 3. Организация процесса разработки

Рассказываем об организации разработки мобильного приложения.

Мы продолжаем делиться опытом разработки Контейнера (Google Play и App Store)  простого приложения для мобильной торговли на платформе 1С. В предыдущих сериях:

Часть 1. Двойной заголовок
Часть 2. Обработка долгого нажатия

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

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

Наша команда состоит из трех человек – Вадим (автор статьи), Александра и Снежана. Да, у нас работают девушки, и уж поверьте мне – они дадут фору любому бородатому программисту в растянутом свитере. 🙂

Когда разработчиков больше одного, сложно обойтись без инструмента для распределения задач и отслеживания их выполнения. Сначала для этих целей мы использовали Гугл таблицы (аналог Excel, только в облаке), однако скоро поняли, что этого не хватает и занялись поиском системы для управления проектами. Мы остановились на Basecamp.

Basecamp – это онлайн система управления проектами, у которой главная особенность – простота. В ней нет приоритетов, подзадач, статусов и прочих атрибутов, присущих другим системам. Основной элемент управления – это список (to-do list), который состоит из задач (to-do). У каждой задачи можно указывать исполнителя и срок. Всё. 🙂 Задачи можно перетягивать, комментировать, прикладывать скриншоты или файлы. Если задача выполнена, возле нее ставится галочка и она исчезает из списка.

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

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

Было решено, что пора искать другую систему. Мы перешли на Atlassian Jira.

Atlassian – это компания, которая объединяет под своим названием целое семейство продуктов. Например, Atlassian Jira – это система отслеживания ошибок, Atlassian Hipchat – чат для командной работы, Atlassian Bitbucket – сервис для хранения репозиториев и контроля версий и т.п. Эти продукты можно связывать друг с другом, а также расширять встроенный функционал различными плагинами (платными и бесплатными), которые представлены в Atlassian Marketplace, а при желании написать свой.

Мы подключили себе плагин Jira Agile, который превращает Жиру в полноценную систему управления проектами. Так что теперь наше рабочее место выглядит так:

 

 

Жирная Жира. 🙂
Еще один плагин Enterprise Mail Handler for JIRA Cloud избавил нас от постоянной проверки почты, куда пользователи пишут свои пожелания. Теперь письма сразу приходят в нашу систему, и на каждое письмо автоматически создается задача. Далее, если это сообщение об ошибке, то мы создает подзадачу и включаем ее в один из спринтов. Если это вопрос – прямо там же можно ответить.

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

Интерфейс

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

В процессе создания приложения около 80% времени занимает проектирование интерфейса и адаптация его к экрану мобильных телефонов. Серьезно. Само приложение с точки зрения бизнес логики совершенно простое – приход, расход товара, кассовые документы, переоценка, инвентаризация, меньше 10 отчетов – и всё. На настольной 1С это можно написать за неделю. На мобильной платформе у нас ушло более полугода.

Как и для управления проектами, для проектирования интерфейса существует множество программ. Но в контексте разработки под мобильную платформу они практически бесполезны, так как 1С жестко ограничивает разработчиков в области рисования форм. Двойной заголовок, светло-желтый фон – с этим ничего нельзя сделать. Не говоря уже о том, что элементарно нельзя разместить кнопку по центру (статья писалась до выхода мобильной платформы 8.3.6).

Но мы нашли выход, и для проектирования разработали достаточно серьезную систему под названием “Ручка и бумага”.

Так выглядит мыслительный процесс создания формы оплаты товарной накладной. Почему столько итераций? Потому что очень непросто нарисовать форму со следующим функционалом и уместить всё это на экране телефона:

  1. Возможность принимать платеж в разных валютах и давать сдачу;
  2. Возможность предоставить скидку;
  3. Если по контрагенту уже есть долг, то: 
    а) Показывать долг/аванс контрагента; 
    б) Возможность развернуть долг/аванс с точностью до товарной накладной; 
    в) Возможность зачесть долг/аванс в текущей оплате;
  4. Сделать так, чтобы это было понятно пользователю.
А вот и результат:

Коснемся разработки отчетов. Сначала мы использовали табличный документ, однако созданные отчеты не адаптировались к ширине экрана, из-за чего на больших и слишком маленьких телефонах они выглядели убого. Нас это совершенно не устраивало, поэтому мы решили использовать html.

Так как в платформе нет инструментов для работы с html, то мы используем отладчик, встроенный в Google Chrome. В связи с этим процесс создания отчетов выглядит несколько нетипично для обычного 1С-ника:

Да, пришлось изучить другую технологию. Но оно того стоило.

Тестирование

Нарисовали красивый интерфейс? Протестируйте его на всех устройствах! К тестированию мы относимся очень ответственно:

Внешний вид может отличаться не только на разных ОС (например, в iOS одна из кнопок формы перескакивает в заголовок), но и на разных телефонах. Одна из проблем – мобильная платформа странно ведет себя на устройствах с высокой плотностью пикселей. Например, на Samsung Galaxy S4 с экраном в 5 дюймов форма может не поместиться на экран (и появляются полосы прокрутки), а на Samsung Galaxy Win с диагональю 4,7 дюймов всё хорошо. Бред? Нет, 1С. 🙂 Решение было найдено абсолютно случайно – ширина элементов на форме должна быть… Нечетной! Если у группы указать ширину 28, то форма не помещается, а 29 – помещается. Так и живем…

В процессе тестирования обнаруживаются не только ошибки разработчиков, но и мобильной платформы. Мы регистрируем все найденные ошибки в 1С (на момент написания статьи – более 80-ти), и что особенно радует – 1С их исправляет. Как оказалось, большинство разработчиков не знает, как это делать, поэтому мы опубликовали статью на тему регистрации ошибок.

Вот так организована разработка нашего приложения Контейнер. 

Отметим, что нам очень пригодился курс по мобильной платформе – автор статьи является выпускником первого потока, и полученные знания сэкономили уйму времени благодаря подробному описанию особенностей разработки под мобильные устройства. Также мы позаимствовали оттуда несколько идей для Контейнера – в частности, заполнение демо базы помогло начинающим пользователям быстрее разобраться в программе.

Пожалуй, на этом мы закончим. Качественных вам приложений и отличных отзывов! И конечно же мы будем рады, если вы в комментариях расскажете про организацию разработки у себя. 🙂

 

Вадим Невзоров
ХВОЯ интегра, Одесса

 

16 Comments

  1. flyer

    Ребята то что вы сделали это реально круто! некоторые ваши идеи я возьму себе на заметку. Жду еще от Вас интересных программ и материалов!

    Reply
  2. _Z1

    (0) Добрый день

    а можете более побробно в след статье описать как именно Вы разрабатывете мобильный интерфейс

    Reply
  3. vadnevzorov

    (1) flyer, спасибо! Очень приятно читать подобные отзывы, они мотивируют нас писать дальше. 🙂

    (2) _Z1, а что именно вас интересует? На самом деле там особо нечего рассказывать — я беру тетрадку и рисую в ней форму, бывает по несколько раз (как с формой оплаты), и когда мне всё нравится — иду и разрабатываю ее в конфигураторе.

    Reply
  4. _Z1

    (3) То что нарисовали как потом переносите на устройства.

    Ведь вся сложность и заключается что на разных устройствах

    все выглядит визуально совсем по разному.

    Reply
  5. FSerg

    ИМХО, добавьте к ней такой же простой и красивый бэк-офис на «большом» компе и будет просто отличный продукт!

    Reply
  6. vadnevzorov

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

    (5) FSerg, всё в будущем. 🙂

    Reply
  7. mzelensky

    Доброго времени суток! Тоже разрабатываю небольшое мобильное приложение. Версии платформ последние на текущий момент (официальные, не бетта). Столкнулся со следующей проблемой:

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

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

    Сталкивались ли с такой проблемой? НАшли ли решение?

    Reply
  8. gigapevt

    Про нечетную ширину элементов …. не знал. СПАСИБО ! (а приложение у вас интересное. Интерфейс качественно продуман + !)

    Reply
  9. vadnevzorov

    (7) mzelensky, мы сталкивались с проблемой, когда клавиатура перекрывает кнопки Провести и Удалить. Чтобы такого не было, разместите все элементы внутри страницы, а кнопки управления — снаружи. Тогда они пропадать не будут.

    А вообще я вам советую пользоваться как раз бета версиями — там исправлено большинство ошибок, и они вполне стабильно работают. Также сегодня вышла 8.3.5.101, попробуйте ее — я читал описание изменений, там исправлена проблема с полосами прокрутки на форме.

    Reply
  10. baha2772

    Как справились с активизацией элементов формы? ТекущийЭлемент() вроде не работает?

    Reply
  11. vadnevzorov

    (10) baha2772, никак не справлялись — у нас он тоже не работает. 🙂

    Reply
  12. Prometeus2011

    Ребят, а на что вы живете-то??? Тут чтоб заработать кодингом и поддержкой на кусок хлеба приходится пырять днем и ночью до синих кругов под глазами. А тут… фундаментальные исследования. Че-то надо менять в своей жизни…

    Reply
  13. Byrabyk

    Добрый день, может знаешь в чем беда, разрабатываю мобильное, сделал поле HTML документа, на устройствах андроид 4.4 работает отлично на андроид 5.1 белый экран

    Reply
  14. Stan

    Ребят, вы молодцы. А можно для «типичных 1с-ников» по подробнее описать процесс создания отчетов в html? Как говорил Семен Альтов: «размеры моей благодарности будут безграничны в пределах разумного». :))

    Reply
  15. SvoyakMartin

    В начале статьи ссылка на вторую часть ведёт на первую, исправьте, пожалуйста!

    Reply
  16. Darklight

    Ссылка на Часть 2. ведёт на Часть 1.

    Вот правильная ссылка Часть 2. Обработка долгого нажатия

    Reply

Leave a Comment

Ваш адрес email не будет опубликован. Обязательные поля помечены *