всегда будет достаточно рутинных задач. В крайнем случае ничего страшного, пусть ищут себе место где размеренность и покой. В хорошем проекте не должно быть покоя, а должна быть динамика и драйв.
>Вместо того, что бы заниматься реализацие задачи, которая уже горит заказчику «художники» будут вдумчиво курить новую версию фреймворка.
И получат по шапке за срыв сроков. А это не в интересах художников, поэтому этого не будет. В крайнем случае хороший менджмент, взвесив все за и против, выделит на новый фреймворк время и одного разработчика, без остановки основного процесса. А вот таджики на новый фреймворк никогда внимания не обратят вообще ни при каких условиях.
>А нормально протестировать проект — лень
Этим должны заниматься тестеры. При этом художник уже давно использует юниттесты, а прогон тестов происходит каждую ночь автоматически, с рассылкой на мыло. Естетсвенно таджики даже не знают что такое тдд, дато тратят, прилежно кучу времени на тестирование. хорошие мальчики.
>Это постоянное желание «творцов» — переписать с нуля.
Это желание не следствие художников, а следствие того что над проектом работали таджики под управлением таджиков, и им насрать на заказчика, потому все сделано тяп ляп. Вот об этом и написана статья. Если заказчик изначально возьмет художников, то у новых художников желания переписать проект не возникнет.
художники вполне могут обеспечивать стабильность и отсутвие перекосов. не надо думать что это всегда фанатики. но в терминах статьи таджик и художник это вещи прямо противоположные. нельзя быть одновременно плюсом и минусом.
это должен делать тот кто работает в ветке. а не кто-то другой. я вообще никогда мержи не рассматривал в качестве нагрузки. это часть работы над задачей. я вообще никак в толк не возьму как это может вызывать проблемы. все проблемы с мержами были всегда виной менеджмента или разработчиков.
У меня в трудовой есть работы продолжительностью год и более. Но в любом случае это может говрить о том что человек просто не нашел пока своей компании. Это может говрить об исключительно быстром прогрессе этого человека, и о том что компании в которых он работал не смогли его знания использовать.
Естественно. Но их может быть разное количество, и баги бывают мелкими и крупными. Задача менджмента так поставить процесс разработки, что бы багов было немного, и они были мелкими. Вот тогда никто не будет убегать
>как только он сталкивается с трудностями, он бросает эту задачу
Это неверно. Наоборот трудности мотивируют. А если это не так то это никакой не художник.
не понял… это 15 секунд делов, как можно успеть соскучится? )))) Дайте ему, в конце концов звдвчу автоматизации процесса, что бы сократить время до 5 секунд. Задача интересная, времени займет не много, зато сэкономите его 10 сек. Шутко)))
если багов немного, и они занимают небольшое количество времени то никто никуда не убежит. если убегают значит баги занимают много времени, значит они являются проблемой.
>каким образом вменяемый менеджмент, по-вашему, поможет расправиться с багами в такой ситуации?
В чем то согласен, но не совсем. Мы горим же что и менеджмент не таджики. То есть в их собственных интересах делать так что бы заказчик был доволен. Это главная мысль статьи. И почему менеджер сразу представляется как чувак с кнутом? Ведь есть и другие способы управления, чем тотальный контроль. Это даже скорее зависит не от контроля, а от созданной атмосферы в команде. Ну например, если менеджмент не терпит новых задач, и всяких улучшений, их постоянно отбрасывает, программист будет делать их тайно, не афишируя. Но если менеджмент открыт к рацпредложениям, мало того сам иногда корректирует процессы, вносит идеи, контролирует архитектуру, то программист всегда пойдет со своим предложением в начальству, ну что бы его хотя бы по головке погладили. И тут менеджмент может с легкостью контроллировать все творческие процессы, находя золотую середину.
Надеюсь понятно расписал. Это я к тому что не надо все сваривать на программистов. Чаще всего любые проблемы проекта — недоработка менеджмента.
Мой опыт показывает что поделить можно. Опыт немаленький. Опыт работы во многих компаниях, в больших и малых командах. Статья не из пальца высосана, она полностью отражает мой опыт, и основана на нем.
если сроки срывались, это может говорить о неверном планировании. Есть такое дело, программисты любят переоценивать свои силы. С другой стороны сжатые сроки позволяют мне держать себя в тонусе, стремится к может быть изначально невозможному. Выходом из этого является измерение и подсчет реальной скорости каждого программиста, и корректировка его прогноза. Этим редко кто занимается, обычно просто умножая сроки надва.
Можно сказать и так. То есть я не против конкретных геев. Ну это все равно что выступать против больных язвой желудка. То есть можно не любить саму болезнь, при этом нормально общаться с больными этой болезнью. Так и здесь. Я вполне нормально могу общаться с геями, но сама по себе эта зараза вызывает у меня резкую неприязнь. И потому я конечно же гомофоб. Я считаю что мужеложство это болезнь, которую надо лечить. И у нормальных людей гейкультура не может вызывать положительных чувувств, хотя бы потому что это грех, в крайнем случае жалось к этим людям. При этом всячески, в том числе и законодательно, должна быть запрещена пропаганда гейкультуры. Вопрос о принудительном лечении дискуссионный, я думаю что эта практика должна применяться для особо оголтелых геев, выставляющих свой порок на показ.
И получат по шапке за срыв сроков. А это не в интересах художников, поэтому этого не будет. В крайнем случае хороший менджмент, взвесив все за и против, выделит на новый фреймворк время и одного разработчика, без остановки основного процесса. А вот таджики на новый фреймворк никогда внимания не обратят вообще ни при каких условиях.
>А нормально протестировать проект — лень
Этим должны заниматься тестеры. При этом художник уже давно использует юниттесты, а прогон тестов происходит каждую ночь автоматически, с рассылкой на мыло. Естетсвенно таджики даже не знают что такое тдд, дато тратят, прилежно кучу времени на тестирование. хорошие мальчики.
>Это постоянное желание «творцов» — переписать с нуля.
Это желание не следствие художников, а следствие того что над проектом работали таджики под управлением таджиков, и им насрать на заказчика, потому все сделано тяп ляп. Вот об этом и написана статья. Если заказчик изначально возьмет художников, то у новых художников желания переписать проект не возникнет.
Естественно. Но их может быть разное количество, и баги бывают мелкими и крупными. Задача менджмента так поставить процесс разработки, что бы багов было немного, и они были мелкими. Вот тогда никто не будет убегать
>как только он сталкивается с трудностями, он бросает эту задачу
Это неверно. Наоборот трудности мотивируют. А если это не так то это никакой не художник.
не понял… это 15 секунд делов, как можно успеть соскучится? )))) Дайте ему, в конце концов звдвчу автоматизации процесса, что бы сократить время до 5 секунд. Задача интересная, времени займет не много, зато сэкономите его 10 сек. Шутко)))
>каким образом вменяемый менеджмент, по-вашему, поможет расправиться с багами в такой ситуации?
Надо просто такой ситуации не допускать.
Надеюсь понятно расписал. Это я к тому что не надо все сваривать на программистов. Чаще всего любые проблемы проекта — недоработка менеджмента.
Если у проекта нормальный менеджмент, баги никогда не станут его проблемой.
Это не может не радовать. Значит картина точно удалась)))