Ваш опыт удаленной работы в командах

[fixxxer]

Полагаю, тут во многом еще в драйверах видеокарты дело. Наверное, если есть хорошие проприетарные драйвера, все намного лучше.

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

С докером - нативный Docker for Mac неплох. Разумеется, i/o по цепочке mac os -> linux host -> linux container штука куда менее производительная, чем прямой bind mount в контейнер, надо не тупо набросать как получится, а думать, в каких случаях volume нужен на Мак-хостноде (директория с проектом), а в каких нет (mysql datadir), какой тип consistency выставить для какого случая и все такое. Зато про несовпадение uid думать не надо

Кстати, тут было смешное.
MariaDB в докере на маке выполняла запрос минуту 10 секунд.
Оракловый MySQL в докере на маке ровно тот же запрос выполнял 4 секунды.
Настройки одинаковые настолько, насколько это возможно без сборки собственного образа.
Я даже выяснил, почему. В Марие Aria Engine для временных таблиц, их бинлоги всегда в корне datadir (в какой-нибудь /tmp унести невозможно) , и там fsync на каждый пук.

 

[grigori]

В Марие Aria Engine для временных таблиц, их бинлоги всегда в корне datadir (в какой-нибудь /tmp унести невозможно) , и там fsync на каждый пук.

Монти за любимым занятием - придумывает непонятную хрень, и люто ее пиарит. Но наливает он хорошо.

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

А если добавить в volume :cached - не помогает?

 

[fixxxer]

А если добавить в volume :cached - не помогает?

Это первое, что я попробовал. Стало на полсекунды быстрее Так и оставил, впрочем - лишним не будет.
Performance schema показала, что 96% времени тратится на удаление (!) временной таблицы, уж не знаю, что оно там делает такого со своими логами при этом. Какая-нибудь вариация на тему vacuum небось.

На самом деле абсолютно по барабану, мария или oracle mysql на деве - все равно в продакшене это AWS Aurora.
Просто взял изначально то, что было в vagrant-образе, сделанном задолго до меня. Долго не думал - просто воткнул мыскль.

Репортить не вижу смысла - Mysql 8 уже настолько Марию обогнал, что ее один фиг можно уже начинать понемногу хоронить.

 

[grigori]

Это Oracle умеет - пригнали несколько сотен индусов разработчиков, разбили на команды, и выдают фичи в таком количестве, что percona с марией не успевают их портировать. Там на квадрат гартнера все дрочат, а ibm с red hat объединились, можно и вжарить, чтобы остаться.

 

[fixxxer]

Не, ну не только фичи, там еще и нарефакторили с пониманием дела, системные словари уже не прибиты гвоздями к myisam, индусы бы не осилили. Еще немного и глядишь DDL в транзакциях заработает. Я даже удивился, как-то не ожидал, что оракл сможет.

 

[grigori]

У них 5 направлений, из которых главное внимание уделяется SAAS. Ларри когда-то решил, что будущее за SAAS, и купил все, до чего дотянулся - SalesForcы всякие. А все SAAS на MySQL. Казалось бы, внутри оракла бери да юзай любую редакцию, но никто не спешит.
У менеджмента там, в отличие от прежнего MS, нет вот этого not invented here - покупают все подряд и без разбора, и все на mysql.
Поэтому выбор у них был или вложиться в mysql, или получить зависимость от стороннего продукта, или сосать у IBM.
На всех митингах одна тема: денег в этом квартале столько-то, клиентов новых столько, и все время проблема выдержать нагрузку. Ну, и высшее руководство не совсем дебилы - у Оракла самые большие в мире премии высшему менеджменту, и вообще не бывает премий инженерам

 

[grigori]

по поводу памяти PHPStorm - включите вот эту галочку, кое-что узнаете

 

[fixxxer]

У меня включена, я даже по этой фигне жамкаю, чтобы gc подергать

 

[Heter]

Как думаете, при удаленной работе команды стоит использовать концепцию Agile https://leadstartup.ru/db/agile? По моей логике, если разбивать задачу на равномерные временные промежутки и после каждого из них получать обратную связь от клиента, то потом не придется возвращаться назад и многое переделывать, как часто бывает в наших проектах. Но руководство настаивает на том, чтобы презентовать клиенту готовый продукт, иначе клиент каждый раз будет просить что-то видоизменить или улучшить. А я считаю, что руководство просто не хочет брать на себя дополнительные задачи и коммуницировать с клиентом и постоянно выступать посредником между нами и заказчиком. Но переделывать потом придется команде, а не ему.

 

[fixxxer]

А причем тут удаленная работа? Тут явно речь не об удаленной работе, а об аутсорсинге.

В скраме есть роль product owner:

a Scrum Product Owner is responsible for maximizing the value of the product resulting from the work of the Development Team.

И тут вопрос в том, с чьей точки зрения maximizing the value. С точки зрения заказчика или аутсорсера?

Agile, кстати, в любом случае будет работать.

 

[Heter]

Согласен, удаленно или на аутсорсе - вообще не суть важно.

Agile, кстати, в любом случае будет работать.

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

И тут вопрос в том, с чьей точки зрения maximizing the value. С точки зрения заказчика или аутсорсера?

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

 

[fixxxer]

Я имею в виду, что maximizing the value разный.

Если это аутсорс вида fixed price, то задача аутсорсера - потратить минимум средств на разработку. Тогда product owner внутренний, и на каждой итерации он следит за тем, чтобы разработчики делали минимальную работу, необходимую для формального удовлетворения документально зафиксированных требований заказчика. Этот подход сработает, когда проект делается "для галочки", и заказчика не особо волнует конечный результат.

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

А тебе же я советую подумать о том, нафига тебе эта галера

 

[Heter]

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

 

[grigori]

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

 

[fixxxer]

не особо жалуют тех, кто прыгает с места на место

От культуры зависит. Скажем, в Японии да, там вообще идеал если всю жизнь проработал в одной компании. А в Калифорнии это вообще нормально, только опционами удерживают.

 

[scorpion-ds]

Если это аутсорс вида fixed price, то задача аутсорсера - потратить минимум средств на разработку. Тогда product owner внутренний, и на каждой итерации он следит за тем, чтобы разработчики делали минимальную работу, необходимую для формального удовлетворения документально зафиксированных требований заказчика. Этот подход сработает, когда проект делается "для галочки", и заказчика не особо волнует конечный результат.

Я так работал в прошлой компании (фиксит прайс), очень обидно когда приходиться откровенно гавнокодить, а когда ПМ жалуется на тебя, тебя вызывают на разборки, типа обоснуй свои завышенные эстимейты перед техлидом компании, а техдид слушает и говорит, что-то вроде "да, ты правильно говоришь, но данный проект не требует качества, делай как быстрей, главное выполнение ТЗ, о тестах даже не думай", причем если клиент откровенно лажает с постановкой задачи, ему никто это не подскажет, типа потом сошлемся, вы же сами так просили, а за правки возьмем денег.

Еще СТО выступал о перспективах fixed price и что компания будет двигаться в этом направлении. В общем продержался 1,5 года и свалил, проекты унылые ни какого роста.

Сейчас тоже на аутсорсе (один проект фултайм), но тут хоть серьезней требования к качеству, обязательные тесты, кодревью, большая команда, где все примерно одного уровня. Немного странным казалось сначала, что на задачи излишние время дают, по сравнению с моим прошлым опытом, но и требования к мелочам больше. Ушло наверно с месяц, что бы научится нормально эстимейтить и не занижать сроки, вместо 4-8 часа, "типовая задача" теперь занимает 2-4 дня.

 

[fixxxer]

данный проект не требует качества

С таким подходом все проекты "не требуют качества". Причем таких проектов действительно навалом - когда "для галочки", "освоить бюджет" и т.д. Думаю, где-то 50 на 50 таких и "заказчик - лох". Бизнес-схема понятна, но нафига в такую галеру вообще соваться?

что бы научится нормально эстимейтить

Да тут просто, выводишь эмпирическим образом свою константу, выражающую отношение между изначальным estimate и фактическим временем, и на нее умножаешь. Начать можно с 4.

 

[whirlwind]

Аджайл sprint-by-spring великолепен, но...

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

Agile это не про "не придется возвращаться". Agile - это про адаптивный подход под изменяющиеся на ходу требования заказчика. Для того, что бы держать процесс под контролем необходимы артефакты и их характеристики (типа фиксированного размера спринта). Это такие условия процесса разработки/внедрения/эксплуатации, с которыми согласны все участники. Хотят готовый продукт - склоняйте, что результат спринта = готовый продукт. Демо (артефакт) = приемка. Коммуницировать с клиентом должна вся команда. Через продакт овнера. Пинать и команду, и заказчика лучше всего скрам-мастером. Это все работает и крупные софтверные корпорации давно этим пользуются. Другое дело, если это бизнес типа аутсорс и бабки зарабатываются на разнице ставок. Таких ушлых индусов/китайце полон апворк. И если над вами стоит такой "индус", то никакие методологи вам не помогут. Ибо цели и горизонты планирования у такого руководителя совсем другие. Если хотите серьезной разработки по аджайлу/скраму - смело идите в международную компанию типа делла, нокии, нвидии. Они не нужнаются в рекламе, но там вы 100% получите нормальный аджайл. Чем меньше компания, тем выше издержки на аджайл. Аджайл это способ решать организационные проблемы в крупных компаниях. Разделять и властвовать. Но если у вас одно подразделение, то выхлоп будет просто неощутим. Это примерно как юзать аджайл для команды из 1-2 человек. Оверхед убьет все. Нивелировать это можно только очень длинным проектом.

А насчет эстимейта. Просто пара кейфраз: планнинг покер + последовательность фибоначи. Решает проблему estimate на 99%. Если у тебя есть с кем поиграть в покер. Чем больше игроков, тем выше точность. А иначе: ноль камней = ноль ящиков (c) 5 элемент.

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

 

[AmdY]

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

У вас какое-то странное понятие процесса. Задача бьётся не на временные промежутки, а на отдельные независимые задачи, чтобы в конце каждой итерации иметь работающий продукт. Работающий продукт даёт нормальное тестирование, контроль работы, ресурсов и т.д. Его ж не обязательно показывать клиенту, если у вас чёткие критерии и фиксид прайс. Итерационный подход это не обязательно аджайл и скрам, если вы привыкли работать по водопаду, то и там он применим https://web.archive.org/web/20160318002949/http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf

Тупо резать задачу на временные куски и показывать клиенту недоработанный продукт, по которому нельзя безбоязненно кликать - чертовски хреновая идея.

 

[whirlwind]

У вас какое-то странное понятие процесса. Задача бьётся не на временные промежутки, а на отдельные независимые задачи, чтобы в конце каждой итерации иметь работающий продукт. Работающий продукт даёт нормальное тестирование, контроль работы, ресурсов и т.д. Его ж не обязательно показывать клиенту, если у вас чёткие критерии и фиксид прайс. Итерационный подход это не обязательно аджайл и скрам, если вы привыкли работать по водопаду, то и там он применим https://web.archive.org/web/20160318002949/http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf

Тупо резать задачу на временные куски и показывать клиенту недоработанный продукт, по которому нельзя безбоязненно кликать - чертовски хреновая идея.

Вот тут то и фишка. Надо резать, что бы сделать процесс предсказуемым. Предсказуемый процесс = процесс, который можно выразить в $$$. Если процесс непредсказуем, вы не можете выразить его стоимость и тем болеене можете прогнозировать. Это только часть ответа на вопрос. Процесс надо резать до тех пор, пока он не станет предсказуемым. Это почему в agile обычно нет тасков дороже 12-13 (13 если фибо) поинтов. Если таска дороже, то на планинге она режется пополам. Agile учитывет интересы всех участников процесса. Это конечно о_буенно скинуть с больной головы на здоровую. Например, сказать, что разрабы не успели. Или сказать, что product owner неправильно сформулировал задачу. Но истина будет в том, что вы не разбили задачу 13 на 2, когда это было необходимо. Вы не смогли адекватно оценить затраты на разработку. И виноваты в завимисости от похода либо PO/TM либо SM. Грубо говоря, в PO/TM виноват кто-то крайний, а в SM виноват скрам-мастер. Если у вас одна продакт команда, то вариант виновника PO/TM работает. А если субпродакт команд -10, то разбираться никто не будет. Ну как это вообще может выгляядеть? А спринт 120 поинтов на команду до 7 человек - эта стата работает почти всегда.