Не, нифига. Настоящее рабство давно закончилось. Да даже если человек и раб юридически, у него все равно даже в этом статусе довольно много свободы.
Не могу понять как вы решили селекцию организовать?
Человек сам себе селекцию организует. Приглашаешь в проект: «смотри, такая штука классная, будет вот то-то и то-то. Присоединяйся». Он смотрит и соглашается. Или не соглашается. Все.
Безусловно. Только разница в том, что вы их сами себе делаете. Если нога, как правило, ломается по воле обстоятельств, то психологические вы себе сами организуете.
И стресс не обязательно означает психологические боли. Просто бодрость духа.
Например выбор архитектурного решения A и B. Когда сеньор топит за A и два мидла за B. И у обоих сторон есть доводы.
Ну, это не конфликт, а нормальная рабочая обстановка. До тех пор, пока, конечно никто по голове другому не стучит.
Это решается просто: выложили «на стол» все факты, все доводы, предпосылки, рассмотрели, и собрали из них вариант, который всем нравится. Это просто обычная работа.
Конфликт — это когда кто-то все равно остался не доволен. Это значит, что он просто не все «на стол» выложил и что-то осталось в рукаве.
А если у всех задач DoD удовлетворяется только в применением третьей стороны (например соседней команды, которая доставляет код в продакшен)?
Это значит, что команда недоукомплектована и не может браться за проект.
Нужно или доукомплектовать команду нужными компетенциями, или принять тот факт, что продукт, над которым работает команда — внутренний. И клиент у нее тоже внутренний — другая команда. И требования выставляет та самая команда, для которой делается продукт. Это неизбежно повлияет на DoD, но не в смысле качества, а в том смысле, что продукт просто не тот, который вы ожидали.
Так и что с ним делать, если одна команда считает качество допустимым, а вторая считает это огромным добавленным куском технического долга, который многократно затратит время, не уделенное ему изначально, причем сразу же в следующих спринтах?
Надо разбираться в конкретном случае что происходит.
А почему это проблема нанятого работника?
Потому что вы не «нанятый работник», а живой человек.
У меня впечатление возникло, что вы на аутсорсе работаете. Что значит «вписались»?
То и значит. Вам же не господь бог этот проект назначил, вы его сами выбрали. Могли выбрать другой. Могли вообще не выбирать. Даже если в вашем городе проектов мало и вам ни один не нравится, всегда есть другие города. Другие страны. И вы всегда можете начать свой проект. Если вам даже свой проект не будет нравится, ну тогда не знаю вообще. Начните другой.
некоторые люди не хотят делать что-то не потому что они это не умеют, а потому что не должны (по трудовому договору) и не желают это делать (по личным убеждениям) одновременно
Ну тогда живите с грязными полами. Не вижу проблемы, на самом деле.
Вы путаете. Физическая боль она безусловная. Любому человеку ногу сломай — будет больно.
А вот психологическую боль вы себе сами организуете, особым образом сжимая внутренние органы и лицевую мускулатуру.
Вообще-то есть люди, которые с любой жизненной ситуацией справляются без психологической боли.
И, да, если им сломать ногу — им тоже будет больно. Но это не вызовет психологических проблем. Они быстро адаптируются к новой ситуации и будут действовать так, как будто бы с ногой все в порядке в тех ситуациях, которые не будут требовать на нее опереться.
Талеб просто немножечко груб, и, видимо, еще и перевод посредственный, поэтому вам кажется что он что-то ужасное пишет. Но, на самом деле, он прав.
Как это должно решаться в рамках самоорганизации команды?
Вы сами и ответили. Как команда сама с собой организуется — так и будет.
Смотрите. Тут вообще принципиально другая модель работы: обычные проекты как делаются. Берутся «рабы» и кидаются на амбразуры. А «рабы» и рады быть рабами — ответственности зато никакой. В скраме по-другому. За работу берутся свободные ответственные, добросовестные люди. Это как масоны против древнеегипетских рабов. И те и те камни складывали, но масоны до сих пор существуют.
Ок, если другие тоже пишут про боли скрама, мне это не запрещено я надеюсь?
Поправил: «Если другие тоже пишут о моих болях, когда я пытался начать работать по скраму, мне это не запрещено я надеюсь?»
Не запрещено. Пишите. Просто не называйте это болями скрама.
Нет, если проблема не организационная, а касающаяся технических навыков.
Например?
Не так же, у отдельной команды в скраме нет возможности выполнить доставку кода, DoD не может быть достигнут только силами этой команды.
Если вы взяли задачу, DoD которой не можете удовлетворить — об этом надо было сказать на планировании и не брать задачу.
Если вы вообще все задачи не можете поставить — о чем тогда разговор?
Фраза из серии «делайте хорошо, не делайте плохо» без объяснения, что такое «хорошо», а что такое «плохо». У специалистов в разных командах разные навыки и разные представления о качестве. И эти команды между собой не взаимодействуют, скрам скрамов не про них.
Популярное решение — отдельная архитектурная команда, занимающаяся качеством. но работающая, внимание, не по скраму.
У разных команд разные представления о качестве. В рамках скрама подход такой, что им жертвовать нельзя. Качество на самом высоком уровне — это технический долг. Технический долг — это объем работ, оставшийся до достижения цели спринта. То есть, в начале итерации у команды нет ничего, один технический долг. В конце — этого технического долга должно быть 0 в идеале. Но иногда так не происходит — остаются задачи, которые не доделаны. Что с ними делать — решается после. Скрам говорит лишь о том, что нельзя помечать задачу как выполненную, если по-факту она не выполнена.
Вот это означает «хорошо» и «плохо» в рамках скрама.
А полы помыть? А сортир? Человека берут выполнять определенные должностные обязанности, продиктованные его профессией.
Нет. В скраме нет подразделений на «профессии». Более того, человек сам берется делать продукт, который ему нравится. И который он, как ему кажется, он сможет лучше всего сделать благодаря своим навыкам.
Конечно же могут заставить
Вообще, смешная, конечно, проблема. Обычно вопрос с полами решается как-то сам собой: в бизнес-центре, офис в котором снимает команда обычно есть какой-то клининг, который все прибирает, это вопрос нескольких тысяч плюсом к аренде, свету и интернету.
Но если команда сильно бюджетная и не может себе позволить клининг — кто за нее будет мыть полы? Пушкин? Вы же сами эту команду выбрали и вписались в этот продукт.
Или вы предлагаете изначально набирать фуллстек-разработчиков без явной специализации, которые умеют всего понемногу?
Не имеет смысл браться за проект, который команда не может сделать. Если для проекта достаточно одних фуллстэков — не вижу проблем. Но если в команде никто мыть полы не умеет и не хочет учиться, то или придется смириться с грязными полами, или разбегаться.
Полы мыть тоже учиться?
Все умеют мыть полы с детства. Кроме детдомовцев. И у вас действительно есть проблема с полами, только если все в команде — детдомовцы. Это само по себе довольно причудливо и маловероятно, но даже если вся команда — детдомовцы — есть еще видеоуроки на ютубе, которые учат мыть полы. Блин. Это вообще смешно такой вопрос на серьезных щщах обсуждать.
Невроз — это застарелые неразрешенные противоречия. На самом деле, как раз таки стресс — и есть комфорт. Только именно стресс, а не невроз. Вы, увы, не можете выбрать и «достигать крутых результатов» и при этом, «не напрягаться».
Когда вы видите богатых челах на майбахах — они в свободное от позирования время напрягаются как кони ломовые. А на майбахах и приватных бизнес-джетах «на сдачу» катаются от основных обязанностей. Вы, конечно, можете пять минут почувствовать комфорт. Но это будет последний комфорт в вашей жизни.
И это скрам-мастер. Ему не нужно быть экспертом, потому что спорщики — сами эксперты. Они вполне могут друг с другом договориться.
Очень сложно составить такую цель, чтобы все максимальные 9 человек команды работали для её достижения.
Наоборот. Пока у членов команды нет скрытой повестки дня, они все будут ориентированы на эту цель и работать в соответствии с ней.
Как готовить релиз?
А как вы до этого готовили? Так же и тут.
Как разбирать конфликты в качестве кода?
Не жертвовать качеством.
Как найти еще пару лишних десятков часов в сутках у PO?
Зачем? У всех самый обычный 8-ми часовой рабочий день, как и везде.
Если оунер взял на себя обязательств больше, чем укладывается в его день, то ему это или очень надо, или ему придется отказаться от чего-то.
Как насчет потестировать код за другим разработчиком, когда QA зашивается?
Не вижу проблем. Ну возьми да протестируй. Руки отсохнут?
Может еще и полы помыть?
Тоже не вижу проблемы. Дома ведь моете и нормально. Ничего не смущает.
Многие члены команды демотивированы подобным и их производительность сильно снижается.
Если они берут обязательства выше своих скиллов, то понятно почему — приходится учиться.
В остальных случаях не понятно, почему.
навязав свой способ достижения цели
Никто никого не навязывает. Синьор вполне может пользоваться своими способами достижения цели. Наоборот, в скраме это даже лучше регулируется, чем обычно: синьор, благодаря своим навыкам достигает цель более эффективно и у него остается время на то, чтобы научить джуниоров писать код.
То есть, смотрите. В обычной ситуации задачи просто идут сплошным потоком, а в скраме в пределах итерации объем не меняется. То есть, синьор будет иногда запаздывать относительно изначальной оценки, а иногда сдавать задачу раньше срока. И ошибки планирования не влияют за пределами итерации, то есть, даже если одну итерацию все задачи сданы с опозданием, на следующую итерацию это не повлияет. Это-то время и можно употребить на подтягивание джуниоров. В обычной ситуации даже если он сделает задачу раньше, ему просто поставят новую.
Приходится выполнять не только свою роль, не только роль других членов команды, но и роль менеджмента (Self-Organizing Teams).
Смотря что вы называете «ролью менеджера». У менеджера обычно две сферы ответственности: пинать свою команду и пинать менеджеров других команд. Другие команды в скраме пинает мастер. А себя… ну вы же сами себя пинаете каждый день. Чтобы с утра встать и позавтракать вам не нужен менеджер. И чтобы встать со стула и спросить у коллеги важный для вас вопрос вам тоже менеджер не нужен. Та часть менеджмента, которая заключается в пинании своей команды — это по-сути, воспитатель в детском саду. Вам это не нужно самим.
Что делать с техническим долгом (возьмем для примера бекенд), который есть в проекте, но PO его не видит?
Вы видите. И честно говорите: «вот это задача не сделана, ее нужно в следующей итерации доработать».
Это же вам же нужно, а не оунеру. Смотрите. Если эта итерация последняя и вы наверняка знаете что больше не будет — можно отрываться по-полной. Но если предвидятся следующие — вы же сами с этим самым долгом столкнетесь. Вы столкнетесь с ним одним из двух способов: или это повлияет на оценку какой-то задачи на планировании итерации (вы знаете, что там ТД и знаете, что нужно будет переписать), и это лучший случай. Или вы столкнетесь с ним в момент релиза — тогда у вас будет два пути: или организовать аврал и весь долг быстро-быстро выплатить. Или выпустить «как есть», тогда с ТД столкнутся ваши клиенты. И этот путь для вас самый плохой: во-первых, будут недовольны клиенты, во-вторых, будет недоволен оунер, ну и в-третьих, будете недовольны вы, потому что все будут знать что «комадна А (ваша) релизит говно». И это несмываемый позор. Так что в ваших же интересах ТД не допускать и разбираться по мере появления сразу же.
У вас есть ответы на все эти вопросы?
Блин. Надо было это в самом начале написать. Я ответил только на те, которые мне интересны, не думал, что надо на все. Ну, надеюсь, кто-то еще подключится и ответит на все остальные.
Потому что не правильно его готовите.
Да, больно, но это сладкая боль — за ней следует протрезвение.
Затягивают встречи — не надо убеждать ничего. Пускай затягивают. Завалят итерацию — вспомнят всех, кто опаздывал и убедят не опаздывать.
Команда не просто берет задачи, а берет обязательство их сдать в конце.
Если уводят задачи — значит, делаете неправильно оценку. На оценке тот, кто более компетентный покажет меньший балл, чем тот, кто менее компетентный и сможет убедить окружающих в том, что его оценка правильная. Если они одинаково компетентны, но одному хочется больше, то договоритесь, что следующую задачу возьмет тот, кто получил более вкусную сегодня.
Скрам-мастер не несет ответственность за команду. Он ей помогает убирать препятствия, которая сама команда не может. Ну, помимо, проведения митингов и всего остального.
Про стратегию. Владелец видения — не мастер, а оунер. В чем проблема зашедулить даже двух-трех часовой митинг с разъяснением видения — не понимаю.
Ответ прост: родители работают и не имеют возможности самостоятельно обучать всему детей.
Ровно ради того же нужны и детские сады.
Если мы посмотрим на определение социализации в вики, мы увидим, что она, в конечном итоге, «позволяет ему успешно функционировать в обществе[1].»
Но, давайте честно, кто действительно успешно функционирует в обществе? Большинство людей заняты весьма низкоинтеллектуальным трудом, а свободное время проводят перед телевизором или компьютером, потребляя простой для освоения контент.
Я не могу назвать это успешным функционированием ни с какого бока.
Или я чего-то не понимаю, или социализация не работает как должна.
Что? Зачем? Меня не смущают ни реклама, ни трекинг.
Меня смущает, что гугл завтра пидумает гуглоизм (ну, они не будут называть это гуглоизм, они будут называть это «этическая политика» или типа того) и никто ничего не сможет по этому поводу сделать.
То есть, в разработке ПО независимые подрядчики над одним проектом не работают? Все то же самое. И мы эти проблемы более-менее умеем решать. Вам бы изучить для начала как мы работаем, а не отмахиваться.
Вы в самом начале упомянули VCS-ы, но мы не используем их для «совместной работы». Есть такое понятие, как Quality Gates и на базе VCS-а организуется прохождение инкремента проекта через эти самые Quality Gates. Никто не использует gitlab для того, чтобы качать с него код, или загружать в него код. Это было бы супер-глупо и неэффективно.
Всё добро — это не только исходный код, но и сотрудников и сервера передать в общественное достояние? Хм.
Да. Исходный код — это хорошо, но не достаточно. Типа, конечно я могу его форкнуть и сделать свой. Но кому он нужен будет? Никому. В хром каждый день попадают десятки коммитов. Просто чтобы их догнать мне потребуется толпа разработчиков на фуллтайме. Это не реально.
Поэтому, да. Чтобы называть хром «обычным» нужно передать не только код, но и все остальное: каналы дистрибуции, бренд, рабочую силу и т.д.
Смотрите.
Я скачиваю файл из этой системы.
Он попадает в папку «Загрузки» на моем компьютере.
Мне нужно открыть эту папку в проводнике и перенести только что скачанный файл куда мне удобно.
А удобно мне будет в папку «Проекты»/[название проекта] и там дальше по обстоятельствам.
И с загрузкой точно также. Мне нужно будет найти этот файл у себя, и загрузить в вашу систему.
Нафига тогда вообще вся система нужна, если все то же самое делается гораздо удобнее через гуглодрайв/яндекс.диск/дропбокс? В последнем есть и версионирование (в остальных не знаю — не пользуюсь).
Задачи ставить — это, конечно, хорошо, но так никто не работает. Нужен бэклог и его нужно грумить постоянно, из него в начале итерации набираются задачи, а перед следующей грумят. Просто так никто задачи не назначает — это лишняя бюрократия.
Проблема в том, что этот «обычный браузер» — Chrome и принадлежит он компании Google. И не просто принадлежат права на IP, а его разрабатывают сотрудники Google, он распространяется с сайта Google, обновляется Google, и все остальное тоже делает Google. Кроме расширений, но они тоже загружаются и скачиваются с сайта, принадлежащего Google. И Google может не разместить неприятное для себя расширение на этом сайте.
Вот если бы компания Google все это добро передало в общественное пользование и пускала бы к себе других вендров, можно было бы говорить об «обычном» браузере.
Получается, чтобы работать с системой, человеку придется или у себя на компьютере держать все файлы в одной куче, или воссоздавать структуру каталогов из проекта?
Браузеры качают файлы в папку «Загрузки», откуда ее потом надо куда-то перенести. И если там, куда ее надо перенести еще нет каталога, его придется создать.
В общем, не слишком пока что продумано.
Те же git/hg работают в первую очередь с ФС, а потом уже для них сделали веб-интерфейс. Причем, этот интерфейс нужен только ради автоматических мержей. Вообще-то в гите мержи делать скучно и трудно, по сравнению с тем, чтобы просто нажать на одну кнопку в гилтабе. А у вас принципиально мержи не могут быть поддержаны: Word — бинарный формат. Там внутри самого ворда есть механизм сравнения и правок, но он у вас все равно не поддержан.
Я так понимаю, надо смотреть в сторону AD/LDAP и тех средств, которые предлагает компания Microsoft для решения ваших задач.
Как часто вы прибегаете к чтению спецификации JavaScript, выясняя особенности функционирования неких языковых конструкций?
Вообще не прибегаю. Познаю все на собственном опыте.
А что касается модулей, то мне повезло и я видел развитие этой темы с самого начала. Вначале не было никаких модулей, потом появился AMD, потом common-js формат в node, который вместе с browserify перетек во фронтенд, потом UMD, а потом пришел комитет и стандартизовал вот эти вот модули. Поэтому, для меня модули работают также, как и всегда работали. Только немного синтаксис поменялся и все.
Человек сам себе селекцию организует. Приглашаешь в проект: «смотри, такая штука классная, будет вот то-то и то-то. Присоединяйся». Он смотрит и соглашается. Или не соглашается. Все.
Я не читал. Перескажите своими словами.
Безусловно. Только разница в том, что вы их сами себе делаете. Если нога, как правило, ломается по воле обстоятельств, то психологические вы себе сами организуете.
И стресс не обязательно означает психологические боли. Просто бодрость духа.
Ну, это не конфликт, а нормальная рабочая обстановка. До тех пор, пока, конечно никто по голове другому не стучит.
Это решается просто: выложили «на стол» все факты, все доводы, предпосылки, рассмотрели, и собрали из них вариант, который всем нравится. Это просто обычная работа.
Конфликт — это когда кто-то все равно остался не доволен. Это значит, что он просто не все «на стол» выложил и что-то осталось в рукаве.
Это значит, что команда недоукомплектована и не может браться за проект.
Нужно или доукомплектовать команду нужными компетенциями, или принять тот факт, что продукт, над которым работает команда — внутренний. И клиент у нее тоже внутренний — другая команда. И требования выставляет та самая команда, для которой делается продукт. Это неизбежно повлияет на DoD, но не в смысле качества, а в том смысле, что продукт просто не тот, который вы ожидали.
Надо разбираться в конкретном случае что происходит.
Потому что вы не «нанятый работник», а живой человек.
То и значит. Вам же не господь бог этот проект назначил, вы его сами выбрали. Могли выбрать другой. Могли вообще не выбирать. Даже если в вашем городе проектов мало и вам ни один не нравится, всегда есть другие города. Другие страны. И вы всегда можете начать свой проект. Если вам даже свой проект не будет нравится, ну тогда не знаю вообще. Начните другой.
Ну тогда живите с грязными полами. Не вижу проблемы, на самом деле.
А вот психологическую боль вы себе сами организуете, особым образом сжимая внутренние органы и лицевую мускулатуру.
Вообще-то есть люди, которые с любой жизненной ситуацией справляются без психологической боли.
И, да, если им сломать ногу — им тоже будет больно. Но это не вызовет психологических проблем. Они быстро адаптируются к новой ситуации и будут действовать так, как будто бы с ногой все в порядке в тех ситуациях, которые не будут требовать на нее опереться.
Талеб просто немножечко груб, и, видимо, еще и перевод посредственный, поэтому вам кажется что он что-то ужасное пишет. Но, на самом деле, он прав.
Вы сами и ответили. Как команда сама с собой организуется — так и будет.
Смотрите. Тут вообще принципиально другая модель работы: обычные проекты как делаются. Берутся «рабы» и кидаются на амбразуры. А «рабы» и рады быть рабами — ответственности зато никакой. В скраме по-другому. За работу берутся свободные ответственные, добросовестные люди. Это как масоны против древнеегипетских рабов. И те и те камни складывали, но масоны до сих пор существуют.
Поправил: «Если другие тоже пишут о моих болях, когда я пытался начать работать по скраму, мне это не запрещено я надеюсь?»
Не запрещено. Пишите. Просто не называйте это болями скрама.
Например?
Если вы взяли задачу, DoD которой не можете удовлетворить — об этом надо было сказать на планировании и не брать задачу.
Если вы вообще все задачи не можете поставить — о чем тогда разговор?
У разных команд разные представления о качестве. В рамках скрама подход такой, что им жертвовать нельзя. Качество на самом высоком уровне — это технический долг. Технический долг — это объем работ, оставшийся до достижения цели спринта. То есть, в начале итерации у команды нет ничего, один технический долг. В конце — этого технического долга должно быть 0 в идеале. Но иногда так не происходит — остаются задачи, которые не доделаны. Что с ними делать — решается после. Скрам говорит лишь о том, что нельзя помечать задачу как выполненную, если по-факту она не выполнена.
Вот это означает «хорошо» и «плохо» в рамках скрама.
Нет. В скраме нет подразделений на «профессии». Более того, человек сам берется делать продукт, который ему нравится. И который он, как ему кажется, он сможет лучше всего сделать благодаря своим навыкам.
Вообще, смешная, конечно, проблема. Обычно вопрос с полами решается как-то сам собой: в бизнес-центре, офис в котором снимает команда обычно есть какой-то клининг, который все прибирает, это вопрос нескольких тысяч плюсом к аренде, свету и интернету.
Но если команда сильно бюджетная и не может себе позволить клининг — кто за нее будет мыть полы? Пушкин? Вы же сами эту команду выбрали и вписались в этот продукт.
Не имеет смысл браться за проект, который команда не может сделать. Если для проекта достаточно одних фуллстэков — не вижу проблем. Но если в команде никто мыть полы не умеет и не хочет учиться, то или придется смириться с грязными полами, или разбегаться.
Все умеют мыть полы с детства. Кроме детдомовцев. И у вас действительно есть проблема с полами, только если все в команде — детдомовцы. Это само по себе довольно причудливо и маловероятно, но даже если вся команда — детдомовцы — есть еще видеоуроки на ютубе, которые учат мыть полы. Блин. Это вообще смешно такой вопрос на серьезных щщах обсуждать.
Когда вы видите богатых челах на майбахах — они в свободное от позирования время напрягаются как кони ломовые. А на майбахах и приватных бизнес-джетах «на сдачу» катаются от основных обязанностей. Вы, конечно, можете пять минут почувствовать комфорт. Но это будет последний комфорт в вашей жизни.
И это скрам-мастер. Ему не нужно быть экспертом, потому что спорщики — сами эксперты. Они вполне могут друг с другом договориться.
Наоборот. Пока у членов команды нет скрытой повестки дня, они все будут ориентированы на эту цель и работать в соответствии с ней.
А как вы до этого готовили? Так же и тут.
Не жертвовать качеством.
Зачем? У всех самый обычный 8-ми часовой рабочий день, как и везде.
Если оунер взял на себя обязательств больше, чем укладывается в его день, то ему это или очень надо, или ему придется отказаться от чего-то.
Не вижу проблем. Ну возьми да протестируй. Руки отсохнут?
Тоже не вижу проблемы. Дома ведь моете и нормально. Ничего не смущает.
Если они берут обязательства выше своих скиллов, то понятно почему — приходится учиться.
В остальных случаях не понятно, почему.
Никто никого не навязывает. Синьор вполне может пользоваться своими способами достижения цели. Наоборот, в скраме это даже лучше регулируется, чем обычно: синьор, благодаря своим навыкам достигает цель более эффективно и у него остается время на то, чтобы научить джуниоров писать код.
То есть, смотрите. В обычной ситуации задачи просто идут сплошным потоком, а в скраме в пределах итерации объем не меняется. То есть, синьор будет иногда запаздывать относительно изначальной оценки, а иногда сдавать задачу раньше срока. И ошибки планирования не влияют за пределами итерации, то есть, даже если одну итерацию все задачи сданы с опозданием, на следующую итерацию это не повлияет. Это-то время и можно употребить на подтягивание джуниоров. В обычной ситуации даже если он сделает задачу раньше, ему просто поставят новую.
Смотря что вы называете «ролью менеджера». У менеджера обычно две сферы ответственности: пинать свою команду и пинать менеджеров других команд. Другие команды в скраме пинает мастер. А себя… ну вы же сами себя пинаете каждый день. Чтобы с утра встать и позавтракать вам не нужен менеджер. И чтобы встать со стула и спросить у коллеги важный для вас вопрос вам тоже менеджер не нужен. Та часть менеджмента, которая заключается в пинании своей команды — это по-сути, воспитатель в детском саду. Вам это не нужно самим.
Вы видите. И честно говорите: «вот это задача не сделана, ее нужно в следующей итерации доработать».
Это же вам же нужно, а не оунеру. Смотрите. Если эта итерация последняя и вы наверняка знаете что больше не будет — можно отрываться по-полной. Но если предвидятся следующие — вы же сами с этим самым долгом столкнетесь. Вы столкнетесь с ним одним из двух способов: или это повлияет на оценку какой-то задачи на планировании итерации (вы знаете, что там ТД и знаете, что нужно будет переписать), и это лучший случай. Или вы столкнетесь с ним в момент релиза — тогда у вас будет два пути: или организовать аврал и весь долг быстро-быстро выплатить. Или выпустить «как есть», тогда с ТД столкнутся ваши клиенты. И этот путь для вас самый плохой: во-первых, будут недовольны клиенты, во-вторых, будет недоволен оунер, ну и в-третьих, будете недовольны вы, потому что все будут знать что «комадна А (ваша) релизит говно». И это несмываемый позор. Так что в ваших же интересах ТД не допускать и разбираться по мере появления сразу же.
Блин. Надо было это в самом начале написать. Я ответил только на те, которые мне интересны, не думал, что надо на все. Ну, надеюсь, кто-то еще подключится и ответит на все остальные.
Талеб написал целую книгу про «шкуру на кону».
Вам шашечки, или ехать?
Да, больно, но это сладкая боль — за ней следует протрезвение.
Затягивают встречи — не надо убеждать ничего. Пускай затягивают. Завалят итерацию — вспомнят всех, кто опаздывал и убедят не опаздывать.
Команда не просто берет задачи, а берет обязательство их сдать в конце.
Если уводят задачи — значит, делаете неправильно оценку. На оценке тот, кто более компетентный покажет меньший балл, чем тот, кто менее компетентный и сможет убедить окружающих в том, что его оценка правильная. Если они одинаково компетентны, но одному хочется больше, то договоритесь, что следующую задачу возьмет тот, кто получил более вкусную сегодня.
Скрам-мастер не несет ответственность за команду. Он ей помогает убирать препятствия, которая сама команда не может. Ну, помимо, проведения митингов и всего остального.
Про стратегию. Владелец видения — не мастер, а оунер. В чем проблема зашедулить даже двух-трех часовой митинг с разъяснением видения — не понимаю.
Ровно ради того же нужны и детские сады.
Если мы посмотрим на определение социализации в вики, мы увидим, что она, в конечном итоге, «позволяет ему успешно функционировать в обществе[1].»
Но, давайте честно, кто действительно успешно функционирует в обществе? Большинство людей заняты весьма низкоинтеллектуальным трудом, а свободное время проводят перед телевизором или компьютером, потребляя простой для освоения контент.
Я не могу назвать это успешным функционированием ни с какого бока.
Или я чего-то не понимаю, или социализация не работает как должна.
Меня смущает, что гугл завтра пидумает гуглоизм (ну, они не будут называть это гуглоизм, они будут называть это «этическая политика» или типа того) и никто ничего не сможет по этому поводу сделать.
То есть, в разработке ПО независимые подрядчики над одним проектом не работают? Все то же самое. И мы эти проблемы более-менее умеем решать. Вам бы изучить для начала как мы работаем, а не отмахиваться.
Вы в самом начале упомянули VCS-ы, но мы не используем их для «совместной работы». Есть такое понятие, как Quality Gates и на базе VCS-а организуется прохождение инкремента проекта через эти самые Quality Gates. Никто не использует gitlab для того, чтобы качать с него код, или загружать в него код. Это было бы супер-глупо и неэффективно.
Почему оно должно самоуничтожиться? Что мы проходили в истории? Вы говорите загадками, я вас не понимаю.
Да. Исходный код — это хорошо, но не достаточно. Типа, конечно я могу его форкнуть и сделать свой. Но кому он нужен будет? Никому. В хром каждый день попадают десятки коммитов. Просто чтобы их догнать мне потребуется толпа разработчиков на фуллтайме. Это не реально.
Поэтому, да. Чтобы называть хром «обычным» нужно передать не только код, но и все остальное: каналы дистрибуции, бренд, рабочую силу и т.д.
Я скачиваю файл из этой системы.
Он попадает в папку «Загрузки» на моем компьютере.
Мне нужно открыть эту папку в проводнике и перенести только что скачанный файл куда мне удобно.
А удобно мне будет в папку «Проекты»/[название проекта] и там дальше по обстоятельствам.
И с загрузкой точно также. Мне нужно будет найти этот файл у себя, и загрузить в вашу систему.
Нафига тогда вообще вся система нужна, если все то же самое делается гораздо удобнее через гуглодрайв/яндекс.диск/дропбокс? В последнем есть и версионирование (в остальных не знаю — не пользуюсь).
Задачи ставить — это, конечно, хорошо, но так никто не работает. Нужен бэклог и его нужно грумить постоянно, из него в начале итерации набираются задачи, а перед следующей грумят. Просто так никто задачи не назначает — это лишняя бюрократия.
Проблема в том, что этот «обычный браузер» — Chrome и принадлежит он компании Google. И не просто принадлежат права на IP, а его разрабатывают сотрудники Google, он распространяется с сайта Google, обновляется Google, и все остальное тоже делает Google. Кроме расширений, но они тоже загружаются и скачиваются с сайта, принадлежащего Google. И Google может не разместить неприятное для себя расширение на этом сайте.
Вот если бы компания Google все это добро передало в общественное пользование и пускала бы к себе других вендров, можно было бы говорить об «обычном» браузере.
Браузеры качают файлы в папку «Загрузки», откуда ее потом надо куда-то перенести. И если там, куда ее надо перенести еще нет каталога, его придется создать.
В общем, не слишком пока что продумано.
Те же git/hg работают в первую очередь с ФС, а потом уже для них сделали веб-интерфейс. Причем, этот интерфейс нужен только ради автоматических мержей. Вообще-то в гите мержи делать скучно и трудно, по сравнению с тем, чтобы просто нажать на одну кнопку в гилтабе. А у вас принципиально мержи не могут быть поддержаны: Word — бинарный формат. Там внутри самого ворда есть механизм сравнения и правок, но он у вас все равно не поддержан.
Я так понимаю, надо смотреть в сторону AD/LDAP и тех средств, которые предлагает компания Microsoft для решения ваших задач.
Вообще не прибегаю. Познаю все на собственном опыте.
А что касается модулей, то мне повезло и я видел развитие этой темы с самого начала. Вначале не было никаких модулей, потом появился AMD, потом common-js формат в node, который вместе с browserify перетек во фронтенд, потом UMD, а потом пришел комитет и стандартизовал вот эти вот модули. Поэтому, для меня модули работают также, как и всегда работали. Только немного синтаксис поменялся и все.