И хорошо! Тогда главное не начинать развлекаться с утра, а отдыхать и приводить себя в рабочее состояние( зарядка, душ, прогулка, дела по дому, которые не напрягают мозг, прогулки). А на развлечения заложить выходные.
За те линейки и возможности которые были в предыдущих вариантах устройств, возможно и не будут готовы( с другой стороны, функциональность бензина и не меняется, но цены на него растут — пример из другой области, но тем не менее...).
Когда производителей станет мало, то каждый из них сможет предоставить уникальный набор параметров, который будет защищен на уровне патентов и не может быть легко повторен, то здесь может быть много чего интересного в ценообразовании.
В конце концов мы уже проходили различные подходы как к функционалу мобильных устройств, так и к оптимизации их по разным параметрам: вспомните, как сначала уменьшался размер аппарата, потом вернулся к средне-удобной величине. Аналогичный процесс произошел с нетбуками, которые сначала соревновались по ценнику, но потом все же повернули обратно, когда стало ясно, что на совсем дешевых решениях не обеспечить необходимый функционал, а соответственно и массовость, необходимую для окупаемости разработки.
На часть продукции цены снизятся, но потом, когда слабые игроки будут вымыты с рынка и порог входа будет достаточно высок, оставшиеся смогут частично вернуть цены на место по мере выхода новых линеек устройств.
Опять же зависит от платформы и политики компании. Иногда бывает полезно разнести разные пути воспроизведения в разные записи. Возможно они инициированы разными проблемами в коде и исправление одной на другие не повлияет — проверять придется все.
Ага, теперь увидел. При первом прочтении как то проскользнуло.
Еще хорошо бы написать что делать если ошибка не воспроизводится, или воспроизводится статистически( т.е. конкретного алгоритма как ее получить — нет, но в течении некоторого времени она проявляется). Конечно это индивидуально для каждой компании, но мы такого рода ошибки собирали, потом помогало понимать что может еще рухнуть.
Ну это распространенное пожелание к тестировщикам. Во времена работы в Cybiko на одном из совещаний был высказан тезис, что хороший тестировщик, должен уметь находить ошибки кода, архитектуры и дизайна, качественно описывать их и предлагать работающее исправление. На что было предложено тогда уволить всех программистов и дизайнеров. Начальнику отдела — бросать тестировщикам ярлык для проверки, чтобы потом они исправлением ошибок доводили продукт до ума ;-)
И не забывайте о конфигурации тестового стенда!
Возможно в этом посте это подразумевалось под шагами, но обычно она указывается отдельно и может включать в себя( в зависммости от типа тестируемого ПО:
1. Версия тестируемой программы.
2. Версия окружения( система, браузер, специальные библиотеки).
3. Версия железа на котором происходит ошибка( если РС, то процессор, память, видео. Для мобильных устройств — тип мобильного устройства).
Ну влагозащита имеет пределы. Например, если его с открытой заглушкой micro-USB топить, то думаю, что гарантия не поможет. Или опять же на глубину метров 20 и часик там подержать — опять же негарнтийный случай. Поэтому проверяется факт попадания, а дальше интересный вопрос — как она туда попала…
Для МСФО есть настройки типа Финграда. Они и будут использоваться, а вот операторов переучивать — это большая и трудная задача. Так что вряд ли МСФО изменит баланс.
Здесь скорее вмешивается ваш опыт. Действительно документацию разумно хранить в отдельном репозитории. Автор пишет нам, что:
Именно поэтому я настоятельно рекомендую, чтобы разделы I, II и III были включены в репозиторий исходного кода проекта, где они могут быть проверены и отредактированы кем угодно.
И именно проблемам с хранением раздела III в репозитории проекта и был посвящен мой комментарий.
Разумный подход может заключаться как раз в том, чтобы иметь в репозитории проекта краткий readme с описанием возможностей программы, основных изменений в текущей версии и ссылками на документацию.
Статья хороша для понимания того, что код пишется для людей и дает первичное понимание того, что должно быть в документах. Сейчас, когда программ стало много, хорошая документация — это конкурентное преимущество.
При этом проблема плохой документированности скорее социальная, нежели техническая. Создание документа может оказаться задачей сравнимой по трудозатратам с написанием кода и требующей сравнимой квалификации исполнителя. При этом она не добавит функциональности продукту. Поэтому мотивация на написание документации у разработчика низка( людям интереснее самовыражаться через развитие возможностей ПО, чем через написание технических текстов). А потом автор обычно и сам знает как работает программа: часто изначально программа пишется «для себя», при этом мотивация написать есть, а документировать уже не важно( кому надо — сам разберется).
К другим идеям из этой статьи. Включение документации в репозиторий с кодом — очень спорное решение. И этому есть 2 причины:
а. изменение документации будет влиять на версию продукта.
б. часто документация включает в себя значительный объём бинарных данных( изображения например), включение их в репозиторий может привести к значительному увеличению объёма хранимых данных.
Предложенный автором Wiki способ хранить документацию кажется более реальным.
Стандарты для технических писателей обычно содержатся в ГОСТах или внутрикорпоративных гидах по стилям. Обычно они специально разрабатываются для определенного класса систем на основе реального опыта использования.
Создание же универсального шаблона может оказаться затруднительным, блоки критически важные для одних приложений( в рамках статьи это может быть, например, API для web-приложений) могут оказаться совсем ненужными в других( в игре API может вообще не содержаться, зато будет критически важно красочное описание GUI).
Так что по сути останутся первый и второй разделы. Третий же может как отсутствовать( для драйвера), так и быть огромнейшим документом.
Данная идея с регулярностью пол-года — год возникает на разных ресурсах. Народ начинает бурно обсуждать и сходится обычно на том, что писать про других хотят многие, а вот читать про себя — увольте. И вот придумать почему люди захотят читать про себя ну никак не выходит.
Так что здесь, кажется, фундаментальная проблема в сценарии использования, а не в технологиях.
Вот сетевой то интерфейс и смущает… сети 4G в РФ еще довольно редкая штука( насколько я знаю Казань и Москва пока похвастаться могут), а обратной совместимости с 3G, насколько я понимаю эти технологии, не будет…
Поздравляю! Кажется итогом вашей подстройки треккера под реальные процессы стало создание электронной имплементации Scrum dashboard.
С одной стороны можно было бы посмотреть методику ее ведения и вы бы сэкономили время на модификацию проекта, с другой стороны вы создали еще одно подтверждение работоспособности методики :)
1. Не глядя на клавиатуру
2. Не глядя на экран :-)
Когда производителей станет мало, то каждый из них сможет предоставить уникальный набор параметров, который будет защищен на уровне патентов и не может быть легко повторен, то здесь может быть много чего интересного в ценообразовании.
В конце концов мы уже проходили различные подходы как к функционалу мобильных устройств, так и к оптимизации их по разным параметрам: вспомните, как сначала уменьшался размер аппарата, потом вернулся к средне-удобной величине. Аналогичный процесс произошел с нетбуками, которые сначала соревновались по ценнику, но потом все же повернули обратно, когда стало ясно, что на совсем дешевых решениях не обеспечить необходимый функционал, а соответственно и массовость, необходимую для окупаемости разработки.
Еще хорошо бы написать что делать если ошибка не воспроизводится, или воспроизводится статистически( т.е. конкретного алгоритма как ее получить — нет, но в течении некоторого времени она проявляется). Конечно это индивидуально для каждой компании, но мы такого рода ошибки собирали, потом помогало понимать что может еще рухнуть.
Возможно в этом посте это подразумевалось под шагами, но обычно она указывается отдельно и может включать в себя( в зависммости от типа тестируемого ПО:
1. Версия тестируемой программы.
2. Версия окружения( система, браузер, специальные библиотеки).
3. Версия железа на котором происходит ошибка( если РС, то процессор, память, видео. Для мобильных устройств — тип мобильного устройства).
милицииполиции, зафиксировавшему правонарушение в протокол» :-(И именно проблемам с хранением раздела III в репозитории проекта и был посвящен мой комментарий.
Разумный подход может заключаться как раз в том, чтобы иметь в репозитории проекта краткий readme с описанием возможностей программы, основных изменений в текущей версии и ссылками на документацию.
При этом проблема плохой документированности скорее социальная, нежели техническая. Создание документа может оказаться задачей сравнимой по трудозатратам с написанием кода и требующей сравнимой квалификации исполнителя. При этом она не добавит функциональности продукту. Поэтому мотивация на написание документации у разработчика низка( людям интереснее самовыражаться через развитие возможностей ПО, чем через написание технических текстов). А потом автор обычно и сам знает как работает программа: часто изначально программа пишется «для себя», при этом мотивация написать есть, а документировать уже не важно( кому надо — сам разберется).
К другим идеям из этой статьи. Включение документации в репозиторий с кодом — очень спорное решение. И этому есть 2 причины:
а. изменение документации будет влиять на версию продукта.
б. часто документация включает в себя значительный объём бинарных данных( изображения например), включение их в репозиторий может привести к значительному увеличению объёма хранимых данных.
Предложенный автором Wiki способ хранить документацию кажется более реальным.
Создание же универсального шаблона может оказаться затруднительным, блоки критически важные для одних приложений( в рамках статьи это может быть, например, API для web-приложений) могут оказаться совсем ненужными в других( в игре API может вообще не содержаться, зато будет критически важно красочное описание GUI).
Так что по сути останутся первый и второй разделы. Третий же может как отсутствовать( для драйвера), так и быть огромнейшим документом.
Так что здесь, кажется, фундаментальная проблема в сценарии использования, а не в технологиях.
С одной стороны можно было бы посмотреть методику ее ведения и вы бы сэкономили время на модификацию проекта, с другой стороны вы создали еще одно подтверждение работоспособности методики :)
Желаю успехов в дальнейшей работе!