Если все трое работают вместе, т.е. они — команда, то и ответственность у них общая, поэтому все поровну. Естественно, наивно полагать, что сразу все заработает как надо, но со временем команда достигнет баланса. Например, они все вместе поймут, что не существует безбажного кода и надо писать больше тестов, а Васю надо обучать и не оставлять один на один со сложными задачами.
Вы, наверное, не туда ответили, я тоже не фанат работы из дома. Понятие свободного графика — это такое расплывчатое понятие, которое часто воспринимают, как обязанность отработать 40 часов в неделю, но в любое время.
В статье речь идет о том, что человек НЕ обязан работать 40 часов и при этом он не теряет зарплату, если не падает эффективность его работы.
В Facebook как раз целый зоопарк технологий. Если у вас куча legacy-кода, то ничто не мешает писать новые сервисы на чем угодно и интегрировать их в legacy. SOA для этого и придумали. Упорствовать в использовании 1го устаревшего языка для меня свидетельство того, что кто-то крепко сидит на своем стуле и не хочет его отпускать.
мамонтов Perl… Насколько я знаю, ежики колются, плюются, но продолжают жрать кактус.
На самом деле, они тупо тормозят развитие, потому как очень трудно нанимать людей, когда пишешь на экзотических языках. В зоопарке технологий нет ничего страшного. Для каждой задачи есть подходящие инструменты и появляются новые инструменты, которые лучше старых. Как вы верно заметили, все зависит от людей.
Тут проблема не столько в том, что Decimal, а что валюты нет. Денег не бывает абстрактных.
У Money должен быть конструктор, который не работает без валюты.
Offtopic: О, всегда спорим с коллегами, а чего букинг так вцепился в Perl.
Моя версия была, что там сидят несколько тяжеловесов с первых времен, которые, мягко говоря, узколобы. Как оно на самом деле?
Про опыт с «политиками» это сложно. Я не думаю, что тут есть универсальные рецепты.
Но, в целом, чем прозрачнее процессы принятия решений, тем меньше пространство для маневров.
С наймом ничего интересного не придумали, все интервьювят, как хотят. По алгоритмам не гоняют, все больше прикладные технологии. Бывают удачные наймы, бывает не очень, но тут рынок довольно дохлый, поэтому очень трудно нанимать.
Про культурные коды придется отдельную статью писать.
Могу сказать по себе, что адекватно воспринимать чужое мнение — это скилл, который сложно прокачивать.
Не всегда люди выражают себя так, что можешь абстрагироваться от, так скажем, формы и понять содержание.
Но в разработке коммуникации — это половина успеха.
У нас все, даже самые опытные девелоперы не садятся за большие задачи, не обсудив с коллегами.
Я бы даже больше сказал, если я не могу удержать в голове цельную картину, я открыто попрошу еще кого-то поработать вместе.
Это ok и не воспринимается никем, как слабость.
Лучше вначале потратить немного времени и выработать верный подход, чем потом переделывать.
Нет, это не страх, это такой дискомфорт, когда вы сами понимаете, что делаете что-то неправильно.
Например, вот у вас посуда не помыта.
Вы ее моете, потому что боитесь, что жена/подруга вынесет вам мозг, когда ее найдет.
Или вам просто не нравится, когда дома непорядок?
«Разумных» наказаний, к сожалению, не бывает, есть просто наказания.
Это как раз ложное представление, что бардак и гибкость — это одно и тоже.
Суть гибких методологий в том, что команда соглашается брать задачи, для которых нет формалированного описания и прорабатывает их сама через общение с заказчиком, а не через документы типа пресловутого ТЗ.
В процессе анализа задачи (да, планирование — это часть процесса, почитайте про backlog refinement) и в процессе работы над задачей требования могут меняться и это OK, но меняться не так, что сегодня мы пишем виджет для сайта, а завтра внезапно какой-то web-service. Это будет уже другая задача. То, что она появилась — это OK, но мы не берем ее сразу в работу.
Заставлять команду брать задачу посередине Спринта — это значит нарушать ту самую внутреннюю мотивацию, когда команда сама выбирает над чем ей работать.
Я не писал, что я поддерживаю опоздания. Я писал, что с ними борятся контр-продуктивно.
Страх и наказания — не лучшие мотиваторы.
У нас это решалось тем, что стэндап — это обязательный митинг и всех просят на нем быть.
Первое время народ опаздывал, но постепенно ситуация выравнялась.
На эксперимент решились, потому как бизнес идет вниз и перемены назрели.
Поэтому перешли от component-teams к feature-teams, а заодно поменяли процесс.
На самом деле, очень смелый эксперимент и хороший кейс, но об успехах пока рано говорить.
Тут около 200 человек только в 1м офисе, а есть еще разработка в 2-3х разных странах.
Про распределенный скрам можно отдельную статью писать.
Да, вы правы и это абсолютно нормальное решение. Если команда против, то не нужно ничего впиливать.
Понимаете, все эти «срочно впилить фичу» проистекают от недостатка планирования, в том числе на этапе анализа задач. Поэтому до планирования делают PBR, где рассматривают задачи и пытаются ответить на вопрос: «нет ли разницы между тем, что написано и что заказчик действительно хочет».
В любом случае команда должна напрямую работать с тем, кто ставит требования.
Мне очень симпатичен Milfgard и все, что он делает.
Думаю, что он намного лучше меня знает, как управлять командами(результаты налицо), поэтому я его и не критиковал, а просто написал про свой опыт.
Первое время безусловно, но я бы не сказал, что все было по нулям.
Вначале все испытывают легкую эйфорию, как если бы камень упал с плеч.
Потом как-бы осторожно тестируют границы возможного.
Потом уходит какое-то время, чтобы научиться эффективно коммуницировать друг с другом.
Без оров и эго.
Удовлетворение от работы понемногу растет и это влияет на производительность, но не напрямую.
Тут надо понимать, что плохой дев не станет хорошим только потому, что ему дали свободу.
Но, при наличии открытой среды, где можно не бояться признавать свои ошибки и просить помощи, можно реально расти. А это уже приведет к росту результатов.
Ну, это, по сути, монархия, когда во главе стоит мудрый царь.
Я не спорю, это, пожалуй, самая эффективная схема, но, если хороший царь меняется на плохого, то все рушится.
За примерами можно обратиться к истории.
Если же правила игры установлены, то система продолжит быть довольно сильно устойчивой.
А откуда возьмутся эти изменения?
Если сверху, то это на самом деле — микроменеджмент, когда руководитель начинает влезать в детали, которые можно оптимизировать.
В 99% случаев это не срабатывает и приводит к недовольству.
В конце концов, кому виднее, что надо поменять — вам с коллегами или начальнику?
Если вам, то вам нужна свобода принимать решения самостоятельно.
На начальном этапе такая свобода приводит к хаосу, это неизбежно.
Но, если вы решили что-то сами, внутри команды и пусть даже сфакапили, то это психологически лучше, чем когда чужое навязанное решение приводит к проблемам.
Компания сыпалась до этого, иначе эти изменения не стали бы проводить просто так, по фану.
Мне кажется, это какой-то слишком громкий эпитет — «человек-катастрофа».
Прямо Омен какой-то, обычно люди не такие односторонние.
Если есть прозрачность и все знают, кто что делает и кто что не делает, то пространство для маневра маленькое и не получится сильно вредить.
Ну и в принципе, Scrum-мастер — это и есть сервисный инженер программерских душ. Его задача — налаживать общение в команде и помогать, но он не руководит.
В статье речь идет о том, что человек НЕ обязан работать 40 часов и при этом он не теряет зарплату, если не падает эффективность его работы.
На самом деле, они тупо тормозят развитие, потому как очень трудно нанимать людей, когда пишешь на экзотических языках. В зоопарке технологий нет ничего страшного. Для каждой задачи есть подходящие инструменты и появляются новые инструменты, которые лучше старых. Как вы верно заметили, все зависит от людей.
У Money должен быть конструктор, который не работает без валюты.
Моя версия была, что там сидят несколько тяжеловесов с первых времен, которые, мягко говоря, узколобы. Как оно на самом деле?
Как у вас с интеграцией с Jenkins? Можно ли распараллелить запуск test-suits на разных машинах?
Но, в целом, чем прозрачнее процессы принятия решений, тем меньше пространство для маневров.
С наймом ничего интересного не придумали, все интервьювят, как хотят. По алгоритмам не гоняют, все больше прикладные технологии. Бывают удачные наймы, бывает не очень, но тут рынок довольно дохлый, поэтому очень трудно нанимать.
Про культурные коды придется отдельную статью писать.
Не всегда люди выражают себя так, что можешь абстрагироваться от, так скажем, формы и понять содержание.
Но в разработке коммуникации — это половина успеха.
У нас все, даже самые опытные девелоперы не садятся за большие задачи, не обсудив с коллегами.
Я бы даже больше сказал, если я не могу удержать в голове цельную картину, я открыто попрошу еще кого-то поработать вместе.
Это ok и не воспринимается никем, как слабость.
Лучше вначале потратить немного времени и выработать верный подход, чем потом переделывать.
Например, вот у вас посуда не помыта.
Вы ее моете, потому что боитесь, что жена/подруга вынесет вам мозг, когда ее найдет.
Или вам просто не нравится, когда дома непорядок?
«Разумных» наказаний, к сожалению, не бывает, есть просто наказания.
Суть гибких методологий в том, что команда соглашается брать задачи, для которых нет формалированного описания и прорабатывает их сама через общение с заказчиком, а не через документы типа пресловутого ТЗ.
В процессе анализа задачи (да, планирование — это часть процесса, почитайте про backlog refinement) и в процессе работы над задачей требования могут меняться и это OK, но меняться не так, что сегодня мы пишем виджет для сайта, а завтра внезапно какой-то web-service. Это будет уже другая задача. То, что она появилась — это OK, но мы не берем ее сразу в работу.
Заставлять команду брать задачу посередине Спринта — это значит нарушать ту самую внутреннюю мотивацию, когда команда сама выбирает над чем ей работать.
Страх и наказания — не лучшие мотиваторы.
У нас это решалось тем, что стэндап — это обязательный митинг и всех просят на нем быть.
Первое время народ опаздывал, но постепенно ситуация выравнялась.
На эксперимент решились, потому как бизнес идет вниз и перемены назрели.
Поэтому перешли от component-teams к feature-teams, а заодно поменяли процесс.
На самом деле, очень смелый эксперимент и хороший кейс, но об успехах пока рано говорить.
Тут около 200 человек только в 1м офисе, а есть еще разработка в 2-3х разных странах.
Про распределенный скрам можно отдельную статью писать.
Понимаете, все эти «срочно впилить фичу» проистекают от недостатка планирования, в том числе на этапе анализа задач. Поэтому до планирования делают PBR, где рассматривают задачи и пытаются ответить на вопрос: «нет ли разницы между тем, что написано и что заказчик действительно хочет».
В любом случае команда должна напрямую работать с тем, кто ставит требования.
Думаю, что он намного лучше меня знает, как управлять командами(результаты налицо), поэтому я его и не критиковал, а просто написал про свой опыт.
Вначале все испытывают легкую эйфорию, как если бы камень упал с плеч.
Потом как-бы осторожно тестируют границы возможного.
Потом уходит какое-то время, чтобы научиться эффективно коммуницировать друг с другом.
Без оров и эго.
Удовлетворение от работы понемногу растет и это влияет на производительность, но не напрямую.
Тут надо понимать, что плохой дев не станет хорошим только потому, что ему дали свободу.
Но, при наличии открытой среды, где можно не бояться признавать свои ошибки и просить помощи, можно реально расти. А это уже приведет к росту результатов.
Я не спорю, это, пожалуй, самая эффективная схема, но, если хороший царь меняется на плохого, то все рушится.
За примерами можно обратиться к истории.
Если же правила игры установлены, то система продолжит быть довольно сильно устойчивой.
Если сверху, то это на самом деле — микроменеджмент, когда руководитель начинает влезать в детали, которые можно оптимизировать.
В 99% случаев это не срабатывает и приводит к недовольству.
В конце концов, кому виднее, что надо поменять — вам с коллегами или начальнику?
Если вам, то вам нужна свобода принимать решения самостоятельно.
На начальном этапе такая свобода приводит к хаосу, это неизбежно.
Но, если вы решили что-то сами, внутри команды и пусть даже сфакапили, то это психологически лучше, чем когда чужое навязанное решение приводит к проблемам.
Мне кажется, это какой-то слишком громкий эпитет — «человек-катастрофа».
Прямо Омен какой-то, обычно люди не такие односторонние.
Если есть прозрачность и все знают, кто что делает и кто что не делает, то пространство для маневра маленькое и не получится сильно вредить.
Ну и в принципе, Scrum-мастер — это и есть сервисный инженер программерских душ. Его задача — налаживать общение в команде и помогать, но он не руководит.