Трудовик в Хогвартсе
  • Почему тестировщики получают меньше?

    А 6? А 7? А 777? А теперь другой рукой? А если Марс в 9 доме Юпитера?

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

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

    Смысл в том, что здесь и сейчас бага не будет. Пример все о той же CAD-системе. Есть такой формат DWG, который поддерживается компанией Autodesk. Совершенно любой производитель CAD-систем может экспортить/импортить в него, не приобретая у Autodesk их официальных библиотек для работы с этими файлами: можно использовать спецификации Open Design Alliance, можно реверс-инжинирить файлы, сохраняемые AutoCAD (единственное, чего «нельзя» — пытаться обмануть систему валидности, которая разделяет файлы от кого угодно и от Autodesk/официальных лицензиатов. Периодически Autodesk меняет некоторые составляющие этого формата, но делает это не часто (раз в год-два), т.к. изменение форматов потребует раздачи новых версий библиотеки всем лицензиатам, а от лицензиатов — выпуска патчей/новых версий своих продуктов. Соответственно, протестировав экспорт-импорт один раз, риск потери совместимости сильно уменьшается на значительный промежуток времени.

    Под аналитиком, я подразумеваю того кто пишет спецификацию, и это явно не тест-лид.

    Спецификацию (если имеется в виду Software Requirements Specification) по-хорошему пишет очень не один человек — к ней так или иначе прикасаются и бизнес-аналитики, и разработчики, и SQA.

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

  • Почему тестировщики получают меньше?

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

  • Почему тестировщики получают меньше?

    Да, конечно. Ведь это так правильно тянуть в проект какую-то хну с не понятным поведением.

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

    Разве мок должен моделировать обект? Он вроде как должен моделировать ситуацию.

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

    Не относитсо. Я отвечал на это

    Да как же не относится, когда относится. «Проклацывание» в данном случае — это не манки-тест разной степени осознанности, нажали на ссылку — получи ошибку, но и просмотр того, что, собственно, рисуется. Не сличать же, в самом деле, скриншоты с эталоном.

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

    Ведь он не «тупой» аналитик

    У меня возникает какое-то подозрение, что под аналитиком вы подразумеваете того человека, которого часто называют Test lead, т.е. того, кто помимо всего прочего, строит стратегию тестирования, в частности — анализирует предметную область на вопрос наличия вот таких вот мест, как с принтером.

  • Почему тестировщики получают меньше?

    ЧАВО?!! Мо и ОС надо протестировать, мо там баги есть ;)

    Желание иронизировать на эту тему резко пропадает, когда одной из составляющих проекта становится какая-нибудь community-driven компонента. Под GPLv2, например, и поставляющаяся with no warranties. :) Более того, есть такой интересный этап в жизни проекта — «тестирование и уточнение требований», очень важный для тех случаев, когда заранее неизвестно, возможна ли реализация задуманного на выбранной платформе и возможно ли её сделать «прямым» методом или же придется ставить приличное количество костылей. Вот на нем зачастую приходится в каком-то смысле тестировать и ОС — точнее, те её части, с которыми придется соприкасаться.

    Почему не подходят моки/стабы?

    Потому что по сути все, что мы знаем об акселерометре/гироскопе — в каком формате он отдает данные, какой диапазон данных он в принципе способен отдавать и дискретность, с которой сенсор в принципе может эти данные получать. В итоге у нас получаются следующая проблема: Android как бы далеко не RTOS и если производитель чипа заявляет, что сенсор передает показания раз в 10 мс, это вовсе не значит, что раз в 10 мс мы гарантированно получим эти самые показания. Более того, 10 мс легко превращаются в 100-200 мс. Вдобавок к этому, нужно ещё и собрать кучу данных о реальной кинематике поворота, которые нужно предварительно намерить. Плюс проверить все терминальные случаи (самое простое — переходы через условные нули сенсора). И только собрав вот такую пачку данных для каждого из целевых устройств, уже можно говорить о каких-то моках.

    Берем компы на которых сидели (должны сидеть) тестеры и запускаем Силениум и Ко

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

    И сколько человеко-часов вы в результате потратили на то чтобы исправить баг ИЕ?

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

    Оказывается никакой тестер не гарантирует что 100% багов будут найдены, «так зачем платить больше?»

    Особой прелести ситуации придает то, что именно на этом проекте выделенных тестировщиков не было.

  • Почему тестировщики получают меньше?

    Да. Вывод: Вставляем мозг дизайнеру, шоб не придумывал всякой хны и делал простые («чистые») интерфейсы. И пользователь выиграет и тестить проще.

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

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

    (по телехвончикам не спец, так что уточните где проблема

    Проблема в том, что единственный способ получения изменяющейся информации от акселерометра/гироскопа — физически крутить телефон, эмулятор не позволяет подать ему команду «а ну-ка поверни девайс на 40 градусов по оси y». Строить манипулятор о шести степенях свободы на сервомоторах с программным управлением — идея, бесспорно, крутая, но не слишком дешево- и быстрореализуемая.

    Это, БЛ...!, их (то есть наша) прямая обязанность! Снова привет ТДД, БДД.

    Это может быть хорошим подходом в том случае, если целевая платформа одна (либо адаптации под каждую из целевых платформ значительны). Вернемся к тем же веб-приложениям: положим, у нас в требованиях корректное отображение в ФФ, Хроме и Сафари на 3 последних мажорных версии назад. Опять же — положим, что время, затрачиваемое на тестирование одной из комбинаций занимает N часов. Что эффективнее — провести developer test на основных направлениях силами разработчика (положим, по одной из комбинаций «браузер-версия»), а остальное — отдать тестировщику, если зарплата оного в полтора раза ниже разработчицкой?

    говорить «я шас наговняю, а они найдут» — не эффективно.

    Сложно переоценить влияние умолчаний в требованиях. Одним из источников возникновения таких умолчаний является то, что не так часто разработка представляет собой реализацию некоего ISO или RFC в абстрактной среде, а разработчики не ознакомлены со всеми особенностями всех возможных окружений. Приведу прекрасный пример из жизни: жила была АРМ-система, которая представляла из себя веб-сайт. Одной из её функций была скромная кнопочка «напечатать страницу», каких-то дополнительных требований к этой функции не предъявляли — она должна была работать на тех Windows-системах, где принтер в системе установлен стандартным образом. И вот внезапно начинают поступать жалобы от пользователей — печатает, дескать, в искаженном виде, все сжато по вертикали. Фокус оказался в следующем: веселые разработчики IE8 решили, что у всех существующих на планете принтеров DPI по вертикали и горизонтали — одинаковый, например, 300×300. При этом нигде (в релиз-нотах или на мсдн-ах) об этом не уведомили. А принтера у пользователей отличались крайней матричностью и имели три установки DPI, из которых «квадратного» не было ни единого. Предупредить такую ситуацию можно было бы исключительно имея огромную базу тестовых конфигураций, на которых нужно было бы провести (и проанализировать результаты выполнения) приличного количества тестов, при этом эта работа совершенно не требовала бы квалификации разработчика.

  • Чи це Реально: Project Manager без програмістського бекграунда?

    Зависит от
    а). Проекта(тов), которыми предполагается управлять.

    б). Собственно, предыдущего опыта.

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

    Во-втором играет опять же несколько факторов:
    а). был ли опыт, собственно, управления командой (роль PM-а — это не только общение с заказчиком)?

    б). насколько хорошо потенциальный PM представляет себе то, что он передаст команде на входе и заберет от неё на выходе?

    А так — принципиальных проблем, в общем-то нет. Впрочем, возникает дополнительный вопрос: если такой переход связан с переквалификацией из чего-то иного в IT, то в чем, собственно, смысл (кроме «лежит душа») — специалист, способный эффективно управлять командой в 20-30 человек, вполне себе востребован в очень многих областях, а использовать его как «трамплин», не слишком эффективно — приобретенные навыки могут оказаться довольно специфичными.

  • Почему тестировщики получают меньше?

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

    И затем, что некоторые вещи практически невозможно автоматизировать малой кровью (классический пример задачи — получение информации с акселерометра/гироскопа на Android).

    И затем, что, например, в системах, связанных с безопасностью, было бы неплохо делать penetration testing.

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

  • Почему тестировщики получают меньше?

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

    Весь вопрос в том, что те тестировщики, которые способны реально выполнять весь спектр SQA-обязанностей, включая автоматизацию и аналитику для создания адекватного тест-плана по требованиям, ценятся ничуть не ниже. А test monkeys, вся задача которых сводится к прохождению готовых тест-сценариев/написанию простых тест-скриптов, суть которых выплывает из UI, действительно стоят ощутимо дешевле, т.к. готовятся из кого угодно за пару недель.

  • О пользе и вреде детального планирования

    Тут два взаимодополняющих ответа.
    1. Часто ли вы пишете библиотеки на продажу?

    Точно так же, как и часто мы пишем ПО для космических кораблей или майкрософт-офис.

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

    Оптимальное приложение получается только и только тогда, если первый код пишут прямым

    Что такое «прямой код»? Если под этим понимается «код, реализующий заявленные требования, при этом написанный без использования заведомо неоптимальных конструкций и не содержащий нетривиальных конструкций, целью которых является оптимизация под конкретную целевую платформу», то этот код я бы счел для первого раза как раз оптимальным. Фокус в том, что зачастую, на этапе прототипирования есть смысл создать именно proof-of-concept, т.е. нечто, что в целом реализует заявленный функционал, но после подлежит не рефакторингу, а выбросу и созданию наново, учитывая полученные от создания прототипа знания.

    оптимальное, но непростое и нечитаемое.

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

  • О пользе и вреде детального планирования

    Память ничем особо не отличается от любого другого доступного ресурса, в общем-то, за исключением того, что (на первый взгляд) с ней вообще проще — в отличии от ресурсов процессора, её потребление можно померить только объемом. Весь фокус в том, что выделение памяти под данные тоже не бесплатное и, в зависимости от ситуации, может быть выгодно забить больше памяти, но сэкономить на аллоках в конкретный момент. С оценкой по процессорному времени хуже — грубо говоря, чем более целевая платформа не похожа на x86 (условно — на CISC/гибридный процессор), тем больше шансов получить адекватно работающий алгоритм на ПК и неприемлимо медленно работающий, например, на ARM (самый простой пример — алгоритмы, использующие много деления на ARMv7-A, где деление не является процессорной инструкцией).

  • О пользе и вреде детального планирования

    начиная от того, что у самого заказчика нет единого человека, который бы отвечал за требования, а есть куча заинтересованных лиц, которые ведут себя как лебедь, рак и щука из известной басни,

    И включая в себя тот известный факт, что четкие и детализированные требования — главный враг любимого аттракциона «а можно ещё вот что сделать».

  • О пользе и вреде детального планирования

    Пользователю глубоко по барабану, 2 миллисекунды отрабатывает нажатие на кнопку или 70.

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

    Всё это давно решено и тривиально.

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

  • О пользе и вреде детального планирования

    Они обычно все уже есть. Нужно только изучить опыт. Далее оценить сложность алгоритмов.

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

    Я вообще с трудом понимаю, почему большинство программистов в критерии оценки кода вносят его производительность

    Лично я могу это объяснить тем, что есть ряд задач, в которых производительность дает больше итоговой выгоды, нежели экономия на времени дальнейшего рефакторинга/расширения. Не во всех проектах есть необходимость в постоянных доработках и расширениях.

    Тут больше религия, тяжело сказать без замеров. Но личное ощущение в том, что вообще нет никакого выиграша в планировании.

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

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

    В вопросах микроменеджмента я с Вами согласен, хотя в принципе не вижу проблемы в том, чтобы иметь глобальный план реализации, например, функциональных требований (не конкретной таски, а «фичи», которая может включать в себя десятки и сотни тасков разной степени приоритетности). В подобном подходе есть только один минус — при достаточно больших командах (обычно — от 10-15 человек в рамках одного модуля) и ощутимом разбросе уровня навыков/знаний внутри команды могут возникнуть ситуации, когда тот, от кого ВСЕМ нужны ответы, причем разлогие, не имеет на это времени, либо же возникает подобие дэдлока, когда по двум связанным задачам одновременно нужен ответ двум людям друг от друга и ни один из них до получения ответа не может продолжать работу;соответственно, нужно вводить механизмы их разруливания, обычно в виде каких-либо точек синхронизации.

  • О пользе и вреде детального планирования

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

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

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

    Что делать в том случае, если выражение мысли без хитрости получается заведомо неудовлетворительным в ключе производительности, устойчивости или потребления ресурсов?

    А я и не утверждал обратное. Иногда надо. Но тогда ЮМЛ-диаграмы должны быть не подробными, а выражать только суть. С описанием. По каждому пункту. Но заметьте, это совершенно другое, чем использовать диаграммы «до кодирования», чтобы распланировать «что кодировать».

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

    Да проще простого. Потому, почему и в большинстве контор у нас. Люди ленивы и тяжело учатся.

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

  • О пользе и вреде детального планирования

    Нелогичное. Каждый баг имеет высокую информационную ценность.

    Имеет, кто бы спорил — я не буду. Только вот обобщать опять же не стоит: очень хорошо, если процесс «посмотреть, в чем именно баг» занимает три минуты, а если для этого нужно минут пятнадцать компилить-линковать и час деплоить?

    недостаток требований

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

    Это оптимизация? Чтобы писать оптимальные программы, нужно не оптимизировать. Оптимизация как раз всегда делается после того, как код написан. Принцип известен, как избегание преждевременной оптимизации.

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

    Никакие кишки и в этом случае не нужны. Если на уровне библиотеки — только интерфейсы.

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

    И вот, в предварительном проектировании часто и случаются ситуации, когда «надоело» и «хочется с нуля переписать».

    И я по-прежнему не понимаю, почему заказчик должен платить за провтыки на этапе проектирования? Есть зафиксированные требования к тому, что должно быть предоставлено, есть конечный срок, когда это должно быть предоставлено — почему этот срок должен быть сдвинут из-за того, что на этапе проектирования, собственно, проектированию не было уделено достаточно внимания?

    это искусство уметь проектировать «на гребне волны».

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

    А вот, люди, которые воображают, что они расчитывают что-то — не пользуются никакими объективными правилами.

    :устало: ну да, ну да. Навыки человечества по управлению проектами, идущие чуть ли не с Древнего Рима, куча работ по Software development effort estimation, созданных на основе реальных проектов — это все воображение. Объективных правил, которые можно установить и которые действительно улучшают ситуацию на проекте — предостаточно, другое дело, что применять их на проекте длиной в два-три человекомесяца — стрельба из пушки по воробьям, но мы же не обобщаем, правда?

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

    dou.ua/...ovaniya/#196731 — вот ровно в этом комменте (в п.1) я написал про одну из двух основных причин, почему срываются сроки fixed-all предварительно планируемых проектов — исполнитель понимает, что он это сможет сделать за год, но знает, что заказчика срок больше 6 месяцев не устроит — и желание кушать заставляет принимать предложение и в дальнейшем тянуть волынку. Вторая причина — банальное незнание — незнание скорости работы своей команды, незнание особенностей выбранных технологий: нет, серьезно — я наблюдал, как люди подписывались на проект на Ruby и декларировали какие-то планы и сроки, при том, что реально в команде не было ни единого рубиста и первым делом они планировали «месяц учить язык».

  • О пользе и вреде детального планирования

    Отличный пример неоправданной индукции :)

    Оговорюсь, все ниженаписанное я считаю справедливым для одного типа: fixed-all, в котором изменение в требованиях вызывает реэстимейт сроков и затрат заказчика.

    Мир динамичен. Т.е. непредсказуем.

    Не все работают на заказчиков, для которых fixed-all не включает в себя fixed requirements. В случае же, если требования жестко зафиксированы, то основная предпосылка для крупного срыва плана — нестабильность в архитектурных решениях, либо из-за ошибок в этой самой архитектуре, либо из-за того, что её решают менять по ходу (что, вообще-то говоря, может быть оправдано только в случае изменения требований). В обеих случаях за ошибку разработчиков платит заказчик. Если привести пример из жизни: представьте себе, что Вы заказали такси, но попросили предупредить, если она будет более, чем через 15 минут. Вам пообещали машину через 10 минут. Машина приехала через 25 и просит дополнительно плату за простой 15 минут, т.к. «добираться к вам далече и пробки в городе». Вот, собственно, так и видит ситуацию заказчик. Если развивать пример с такси, то прогнозируемость сроков — это не некая абстрактная сущность, это вполне себе численная метрика и в любом бизнесе эта метрика играет свою роль при выборе подрядчика (которым Вы, в данном случае, и являетесь); если Вы не можете назвать срок, в который работа с текущим объемом требований будет гарантированно закончена — у Вас нет конкурентного преимущества, а рынок разработки ПО намного более конкурентен, нежели кажется. Более того, если учесть в «цене» Вашего продукта не только прямые издержки, но и косвенные (например, упущенную прибыль от задержек внедрения), то цена эта возрастет ещё сильнее. А рынок разработки ПО, между прочим, отличается эластичностью по спросу выше единицы.

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

    Логичное решение, между прочим. Собрались люди обсудить демо. Демо в каком-то моменте ломается, при этом поломка воспроизводима (т.е. подразумевается, что steps to reproduce вполне ясны). Если эта ошибка — showstopper, т.е. мешает обсудить и показать остальные части демо — все, расходимся, чиним. Если же нет — заканчиваем разговор о том, что показать/обсудить можно и идем чинить.

    Планирование просто враг программирования и проектирования.

    Здесь и далее по тексту пункта 2 Вы смешиваете две несколько несмешиваемых вещи: планирование и архитектуру. По поводу планирования и аналогий на его тему в программировании — попробуйте, как-нибудь, интересу ради, написать метод, в которой нужно оперировать объемом памяти, большим, нежели доступен в системе в целом: что Вы выберете для управления памятью — ручной вызов деструкторов или сборщик мусора, взлетающий по одному ему ведомому расписанию?

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

    Кроме того, наличие плана разработки минимизируют возможность ситуации (условно)"нам надоел этот фреймворк, давайте перепишем на другом, он моднее/удобнее нам" — вот, собственно, тот случай, когда заказчику кишки вроде бы и не нужны, но дополнительным стимулом выступают — решили что-то сделать вне плана — удачи, все дополнительные эксперименты, к сожалению, не оплачиваются.

    Некоторые люди думают, что «правильно» лучше качества и скорости. Что ожидаемый результат через полгода, лучше, чем через неизвестно сколько — месяц или полтора.

    Обычно в реальности цифры получаются в ключе «через четыре месяца лучше, чем неизвестно сколько — месяц или полгода».

    Напоследок — занятное наблюдение: многие из тех, кто являются ярыми противниками детального планирования, считают, что создание ПО — «is an art». Так вот, «programming art’а» в большинстве нынешних проектах — не более, чем в сборке машин на конвейере: проектов высокой алгоритмической сложности и новизны в нынешнем IT явно не 99%, наоборот, хорошо, если 1% наберется; ещё процента 3% накинем на значительную адаптацию неких общих алгоритмов к предметной области и на проекты, требующие максимальных оптимизаций по ресурсам из-за ограничений целевой платформы. Все остальное — вполне укладывается в рамки manufacturing или craft — т.е. обычного производства. И никаких причин не применять к этой сфере деятельности традиционные для производств практики, за исключением человеческого желания выделиться, нет и особо быть не может.

  • Цена на рынке труда

    а це звідки взялось?

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

  • Цена на рынке труда

    Ну и нафик тогда им заниматься?

    А почему бы и нет, если эта работа нравится и позволяет зарабатывать достаточные для жизни деньги без особого напряжения?

    Ну вот я и хочу стать весьма высокоуровневым специалистом.

    Отлично, а что делать молодым специалистам? И что делать, например, Вам, если до того момента, как это случится, Вы таким специалистом не станете? :)

  • Цена на рынке труда

    Программирование в развитых странах само по себе вообще нечасто является высокооплачиваемой профессией, уровень «несколько выше среднего», не более. И если у датчан возникнет вопрос о том, что необходимо аутсорсить/аутстаффить за пределами ЕС (к слову говоря, когда работал на датчан, в фирме был довольно большой процент шведов — ездить из Мальмё в Копенгаген на работу считалось вполне себе обычной практикой), то их будет интересовать вопрос того, сколько составят в сумме:
    — общие операционные издержки на то, чтобы иметь работников в другой стране (офис, налоги и т.д.)
    — затраты на каждого конкретного работника

    — затраты на интеграцию труда этих работников в общий продукт.

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

  • О пользе и вреде детального планирования

    андерэстимейты нередко возникают из-за прессинга сейлзов/менеджмента.
    Это да, но мысль о том, что прессинг возникает из-за андерэстимейтов была, скорее, о том, что люди, находящиеся в заведомом цейтноте, гораздо более нервозно реагируют на любой контроль и мониторинг, нежели те, у кого такого цейтнота нет, т.к. коэффициент «сделано работы,%/прошло времени, %» у них практически до конца проекта будет ниже единицы и переломить ситуацию можно либо авралом в начале проекта, что в свою очередь, далеко от общепринятых правил — аврал как-то традиционно случается в конце, либо постоянным оверворком до выравнивания ситуации, что, в свою очередь может отразиться либо на качестве, либо на мотивации, что опять-таки не снизит градус напряженности.
← Сtrl 1234567 Ctrl →