Встречал достаточно команд которые активно начинали визуализировать функционал, но, повыкладывав пару недель красочные стены своего кабинета в Инстаграм, завязывали с этим делом.
Мы как-то тоже попробовали, но, увы, не полетело.
Я не хочу сказать, что подход плох, просто есть достаточно много мелких, казалось бы, несущественных моментов, которые препятствуют оклеиваюнию рабочего пространства стикерами. Из не очевидных, вроде отсутствия подходящего помещения, на ум сразу приходят:
— На раннем этапе истории (желтые листки) часто дублируются. Причем какая-нибудь авторизация пользователя может, пусть и формально, присутствовать во всех задачах/действиях;
— Не всем нравится заниматься этим делом и, лично я считаю, что привлекать команду разработки стоит только на этапе историй, иначе планирование затянется и превратится в процесс обсуждения бизнес-целей с тестерами и фронтендерами;
— Очень слабый контроль за зависимостями задач (пользовательских историй) и, как следствие, практически полное «переобдумывание» некоторых постановок при переносе в онлайн;
— Иногда проще просто описать проект каскадным списком (условно приняв, что без отступа — это «идеи», отступ первого уровня — это «действия» и т.д.), чем расклеивать стикеры;
П.С. Ну и, конечно, плохой почерк участвующих в процессе — ой как мешает сосредоточиться, временами :)
Есть подозрение, что «кнопочное мышление» — это отголоски подхода «сверху вниз» (от дизайна к данным), проповедуемому в Getting Real от 37signals, и гибких методологий разработки.
Собственник или гендир, как человек действительно заинтересованный в глубоком анализе проблем и фундаментальном их решении, чаще всего на уровень конкретного проекта не погружается, а менеджеру гораздо проще поменять цвет кнопки и увеличить щрифток, показать положительные результаты на А/Б тестах начальству и получить премию.
Проблема, на мой взгляд, не в кнопочном мышлении, а в, зачастую, низкой заинтересованности принимающих решение лиц и нежелении погружаться в проблему/задачу.
Спасибо за статью, полагал, что переводится всё чуть ли не в блокноте.
Подготовленное к локализации iOS-приложений имеет несколько файлов Localizable.strings (для каждого языка) условно такого содержания:
/* Надпись на кнопке алерта, при нажатии на которую осуществляется открытие определенного URL-а в Safari */
"openUrlButtonTitle" = "Перейти на сайт";
/* Надпись на кнопке алерта, при нажатии на которую происходит отмена перехода на сайт */
"alertCancelButtonTitle" = "Отмена";
В используемой вами TM-программе MemoQ я не увидел, чтобы выводились какие-либо комментарии к переводимым строкам. Возникает вопрос: насколько вообще актуально писать развернутые комментарии? Если ли в этом смысл или при переводи их всё-равно никто читать не будет?
P.S. Насколько я понимаю, если необходим перевод на несколько десятков языков, то сначала всё переводится на английский, а потом уже с английского осуществляется перевод на суахили и клингонский. Как в этом случае передать специфику выражений, сохранить общую стилистику текста?
Предложенная вами методика, calendar-driven development, реализуема на практике далеко не всегда. У меня на работе, например, используется достаточно распространенная схема с ветками master-develop и форком основного репозитория. Задачи достаточно крупные, логически и функционально законченные, в большинстве случаев выходящие за рамки 2-3 дней.
Как бы мне не хотелось стимулировать себя закрашиванием квадратиков, если я начну отправлять мелкие PR-ы, то уже через полчаса будет «ай-йа-йа-й» от человека ответственного за кодревью — проверять достаточно больший, законченные по смыслу куски кода значительно проще.
Да, моя работа — не оупенсорс, но, во-первых, многие проекты с открытыми искодниками придерживаются подобной схемы разработки, а, во-вторых, большинство хабравчан, я полагаю, всё-таки занято на ниве разработки коммерческого ПО с очень похожими требованиями к PR.
Интуиция подсказывает, что задача не тривиальная, много подводных камней. Вообще, проблема с мерджем сториборда стоит действительно остро и подобный инструмент был бы многим полезен.
Совсем недавно GitHub обновил дизайн, сосредоточившись, как это сейчас принято, на контенте. В контексте гихаба (а им, я уверен, пользуются многие хабровчане), именование коммитов в прошедшем времени выглядит гораздо логичнее, чем в настоящем:
Найти работу в ИТ без высшего образования станет практически невозможным, так
как информационные технологии уйдут далеко вперед.
Исходя из личного опыта — возможности трудоустройства в IT-сфере практически не связанны с наличием высшего образования. Адекватные наниматели прекрасно понимают, что реальные навыки связанны, большей частью, с увлечённостью человека и его стремлением к самообразованию, а не с наличием диплома.
Каким образом наличие вышки страхует от чрезмерной скорости развития информационных технологий и вовсе непонятно. Современное высшее образование даже в хороших вузах, увы, зачастую не говорить вообще ни о чём.
Не знаю у кого как, но у меня накопители 5.25" и 3.5" прочно ассоциируются с дисководами для соответствующего размера дискет. В вашем случае корректней было бы подписать позиции как оптический привод и кард-ридер.
Кто-то ведь приложением «юрекуру кору» пользуется, стало быть не всегда оно опаздывает с предупреждениями, помогает кому-то…
Небольшой вопрос по бытовым японским телефонам — как осуществляется рассылка/прием уведомлений? Нечто вроде услуги «Хамелеон» от Билайна, но со звуком?
Мне кажется, если бы была реальная техническая возможность скинуть всем какое-нибудь сообщение без спроса, этой возможностью пользовалось бы не только правительство с целью оповещения о землетрясениях :)
Я правильно понимаю, что уведомление осуществляется по факту землетрясения?
В чём тогда его смысл? Разница в 10-30 секунд не должна оказывать никакого влияния на пользу сообщения — за это время просто выйти из дома не всегда возможно, не говоря уже о «эвакуации» в безопасное место.
Да и не важно сколько реальных людей будет пользоваться оповещениями о землетрясениях — Apple часто задаёт тон, после чего уже тысячи сторонних разработчиков создают свои приложения, полезные заведомо долее широкому кругу пользователей.
Ход мыслей до шестого шага, в общем-то, верный, однако стоит учитывать тот факт, что предлагаемые потребителю устройства будут отличаться от нынешних не только большим количеством камер, они будет совершеннее во многих других аспектах (другие технологии передачи данных, экраны с большим разрешением и т.п.). За совокупность таких вот улучшений и будет платить пользователь.
Седьмой шаг очень спорный. Предполагаемые вами сценарии использования весьма специфичны и, на мой взгляд, будут реализованы только в единичных устройствах, не затронув мэйнстримовые девайсы.
Заголовок манил обещанием рассказать о возможности повлиять на генерацию гугло-сайтшота, на деле же вырисовывается пост аля «Как сделать сайт который бы неплохо смотрелся в превьюшкой в выдаче Гугла?»…
Мы как-то тоже попробовали, но, увы, не полетело.
Я не хочу сказать, что подход плох, просто есть достаточно много мелких, казалось бы, несущественных моментов, которые препятствуют оклеиваюнию рабочего пространства стикерами. Из не очевидных, вроде отсутствия подходящего помещения, на ум сразу приходят:
— На раннем этапе истории (желтые листки) часто дублируются. Причем какая-нибудь авторизация пользователя может, пусть и формально, присутствовать во всех задачах/действиях;
— Не всем нравится заниматься этим делом и, лично я считаю, что привлекать команду разработки стоит только на этапе историй, иначе планирование затянется и превратится в процесс обсуждения бизнес-целей с тестерами и фронтендерами;
— Очень слабый контроль за зависимостями задач (пользовательских историй) и, как следствие, практически полное «переобдумывание» некоторых постановок при переносе в онлайн;
— Иногда проще просто описать проект каскадным списком (условно приняв, что без отступа — это «идеи», отступ первого уровня — это «действия» и т.д.), чем расклеивать стикеры;
П.С. Ну и, конечно, плохой почерк участвующих в процессе — ой как мешает сосредоточиться, временами :)
Собственник или гендир, как человек действительно заинтересованный в глубоком анализе проблем и фундаментальном их решении, чаще всего на уровень конкретного проекта не погружается, а менеджеру гораздо проще поменять цвет кнопки и увеличить щрифток, показать положительные результаты на А/Б тестах начальству и получить премию.
Проблема, на мой взгляд, не в кнопочном мышлении, а в, зачастую, низкой заинтересованности принимающих решение лиц и нежелении погружаться в проблему/задачу.
Подготовленное к локализации iOS-приложений имеет несколько файлов Localizable.strings (для каждого языка) условно такого содержания:
В используемой вами TM-программе MemoQ я не увидел, чтобы выводились какие-либо комментарии к переводимым строкам. Возникает вопрос: насколько вообще актуально писать развернутые комментарии? Если ли в этом смысл или при переводи их всё-равно никто читать не будет?
P.S. Насколько я понимаю, если необходим перевод на несколько десятков языков, то сначала всё переводится на английский, а потом уже с английского осуществляется перевод на суахили и клингонский. Как в этом случае передать специфику выражений, сохранить общую стилистику текста?
Как бы мне не хотелось стимулировать себя закрашиванием квадратиков, если я начну отправлять мелкие PR-ы, то уже через полчаса будет «ай-йа-йа-й» от человека ответственного за кодревью — проверять достаточно больший, законченные по смыслу куски кода значительно проще.
Да, моя работа — не оупенсорс, но, во-первых, многие проекты с открытыми искодниками придерживаются подобной схемы разработки, а, во-вторых, большинство хабравчан, я полагаю, всё-таки занято на ниве разработки коммерческого ПО с очень похожими требованиями к PR.
Исходя из личного опыта — возможности трудоустройства в IT-сфере практически не связанны с наличием высшего образования. Адекватные наниматели прекрасно понимают, что реальные навыки связанны, большей частью, с увлечённостью человека и его стремлением к самообразованию, а не с наличием диплома.
Каким образом наличие вышки страхует от чрезмерной скорости развития информационных технологий и вовсе непонятно. Современное высшее образование даже в хороших вузах, увы, зачастую не говорить вообще ни о чём.
Небольшой вопрос по бытовым японским телефонам — как осуществляется рассылка/прием уведомлений? Нечто вроде услуги «Хамелеон» от Билайна, но со звуком?
В чём тогда его смысл? Разница в 10-30 секунд не должна оказывать никакого влияния на пользу сообщения — за это время просто выйти из дома не всегда возможно, не говоря уже о «эвакуации» в безопасное место.
Да и не важно сколько реальных людей будет пользоваться оповещениями о землетрясениях — Apple часто задаёт тон, после чего уже тысячи сторонних разработчиков создают свои приложения, полезные заведомо долее широкому кругу пользователей.
Седьмой шаг очень спорный. Предполагаемые вами сценарии использования весьма специфичны и, на мой взгляд, будут реализованы только в единичных устройствах, не затронув мэйнстримовые девайсы.
Вы о чём говорите, товарищ? Простота, не в ущерб функционалу — одна из ключевых особенностей техники Apple…