Forwarded from запуск завтра
Красноречивый наброс на скрам, мол, Agile > Scrum = 💩 и у всех прорывает.
Если вы ничего не поняли — это нормально. Фраза — практически тест на то, занимались ли бизнес-программированием в последние 5 (10?) лет.
Agile — идея (учение) о том, как правильно разрабатывать программы. Вот простой для понимания первоисточник, рекомендую: 12 заповедей (принципов) Agile (русский перевод). Оцените полет мысли, это практически госпел (понимаю, почему его так любит Герман Греф).
Я капитально упорот на идее servant leadership и работал исключительно в стартапах. Даже я чувствую иррациональный страх перед идеями Agile. Уровень страха нормальных менеджеров можно сравнить со страхом фарисеев перед идеями Христа, я думаю. Поэтому авторами Agile Manifesto был придуман SCRUM.
SCRUM — четко описанные процессы, где отдельный человек и даже продукт уже не так важны. Можно стать сертифицированным коучем SCRUM, есть курсы SCRUM, можно повесить себе шильдик «успешно внедрили и следуем СКРАМ» и т.д.
Разница между Agile и SCRUM — примерно как между учением Христа и табачным бизнесом РПЦ. Поэтому в классных компаниях ценят результат и людей, этот результат достигающих, а в стремных — «процессы». Аминь.
@pmdaily, что скажешь?
Если вы ничего не поняли — это нормально. Фраза — практически тест на то, занимались ли бизнес-программированием в последние 5 (10?) лет.
Agile — идея (учение) о том, как правильно разрабатывать программы. Вот простой для понимания первоисточник, рекомендую: 12 заповедей (принципов) Agile (русский перевод). Оцените полет мысли, это практически госпел (понимаю, почему его так любит Герман Греф).
Я капитально упорот на идее servant leadership и работал исключительно в стартапах. Даже я чувствую иррациональный страх перед идеями Agile. Уровень страха нормальных менеджеров можно сравнить со страхом фарисеев перед идеями Христа, я думаю. Поэтому авторами Agile Manifesto был придуман SCRUM.
SCRUM — четко описанные процессы, где отдельный человек и даже продукт уже не так важны. Можно стать сертифицированным коучем SCRUM, есть курсы SCRUM, можно повесить себе шильдик «успешно внедрили и следуем СКРАМ» и т.д.
Разница между Agile и SCRUM — примерно как между учением Христа и табачным бизнесом РПЦ. Поэтому в классных компаниях ценят результат и людей, этот результат достигающих, а в стремных — «процессы». Аминь.
@pmdaily, что скажешь?
запуск завтра
Красноречивый наброс на скрам, мол, Agile > Scrum = 💩 и у всех прорывает. Если вы ничего не поняли — это нормально. Фраза — практически тест на то, занимались ли бизнес-программированием в последние 5 (10?) лет. Agile — идея (учение) о том, как правильно…
Наброс мне весьма близок — всегда больно смотреть, когда люди вместо того, чтобы просто пойти и сделать, бездумно следуют карго-культу — считают сторипоинты на дейли-митингах, а вечерами грумят беклог и играют в планнинг-покер.
Вон же программисты сидят: дойди ногами, объясни команде, как заработать деньги, получи MVP за пару дней. Но нет — у нас беклог, оценки-приоритеты, роадмап туда-сюда.
Оно и понятно — если твоя работа не приносит денег, вроде как появляется отмазка: все делал как в книге, старался, просто не срослось. А когда ставишь задачи по наколенной методологии, программисты работают, а денег нет — тут уж сам виноват, и не свалишь на «процессы».
В этом и разница: Agile — это способ мышления, фундамент, на котором строится быстрая и гибкая разработка. SCRUM — частный случай Agile, предельно четко описанный.
SCRUM — это не плохо. Жесткие детализированные процессы нужны большим ребятам, у которых стоят специфические для больших ребят задачи — организовать кучу в общем-то совсем разных людей, чтобы они в промежутках между оплаченным обедом и корпоративной йогой двигались примерно в одном направлении.
В стартапе все по-другому. Как только вы начинаете ценить груминг беклога больше, чем немедленный результат — вы умираете.
Так что если в вашей компании меньше 20 человек и вам приходится внедрять SCRUM чтобы их организовать — вероятно, вы наняли кого-то сильно не того.
Вон же программисты сидят: дойди ногами, объясни команде, как заработать деньги, получи MVP за пару дней. Но нет — у нас беклог, оценки-приоритеты, роадмап туда-сюда.
Оно и понятно — если твоя работа не приносит денег, вроде как появляется отмазка: все делал как в книге, старался, просто не срослось. А когда ставишь задачи по наколенной методологии, программисты работают, а денег нет — тут уж сам виноват, и не свалишь на «процессы».
В этом и разница: Agile — это способ мышления, фундамент, на котором строится быстрая и гибкая разработка. SCRUM — частный случай Agile, предельно четко описанный.
SCRUM — это не плохо. Жесткие детализированные процессы нужны большим ребятам, у которых стоят специфические для больших ребят задачи — организовать кучу в общем-то совсем разных людей, чтобы они в промежутках между оплаченным обедом и корпоративной йогой двигались примерно в одном направлении.
В стартапе все по-другому. Как только вы начинаете ценить груминг беклога больше, чем немедленный результат — вы умираете.
Так что если в вашей компании меньше 20 человек и вам приходится внедрять SCRUM чтобы их организовать — вероятно, вы наняли кого-то сильно не того.
Найм людей: лучше false negative, чем false positive
Лучше не взять хорошего специалиста, чем взять недостаточно хорошего — это особенно актуально для небольших команд в стартапах.
Самое главное в команде — общая среда, которую еще иногда называют «корпоративной культурой». Среда может развивать ответственность у новых участников (скажем, Студия Лебедева, почитайте их конституцию), а может наоборот, подавлять (как условный ЖелДорСвязьКредитБанк, где инициатива наказуема). В хорошей среде люди цветут и развиваются, в плохой — киснут.
Среда создается людьми. Пока в вашей команде один участник, вся среда — это вы: команда планирует время в точности, как вы, реагирует в случае авралов как вы, выстраивает отношения с коллегами как вы.
Когда вы нанимаете людей, вы преобразуете внутреннюю среду — команда начинает вести себя не как вы, а как вы и те, кого вы наняли. Чем меньше команда — тем сильнее каждый новый человек её меняет.
И моя мысль в том, что пока один человек может скомпрометировать всю команду, лучше ошибиться и не взять хорошего, чем ошибиться и взять плохого.
Лучше не взять хорошего специалиста, чем взять недостаточно хорошего — это особенно актуально для небольших команд в стартапах.
Самое главное в команде — общая среда, которую еще иногда называют «корпоративной культурой». Среда может развивать ответственность у новых участников (скажем, Студия Лебедева, почитайте их конституцию), а может наоборот, подавлять (как условный ЖелДорСвязьКредитБанк, где инициатива наказуема). В хорошей среде люди цветут и развиваются, в плохой — киснут.
Среда создается людьми. Пока в вашей команде один участник, вся среда — это вы: команда планирует время в точности, как вы, реагирует в случае авралов как вы, выстраивает отношения с коллегами как вы.
Когда вы нанимаете людей, вы преобразуете внутреннюю среду — команда начинает вести себя не как вы, а как вы и те, кого вы наняли. Чем меньше команда — тем сильнее каждый новый человек её меняет.
И моя мысль в том, что пока один человек может скомпрометировать всю команду, лучше ошибиться и не взять хорошего, чем ошибиться и взять плохого.
Вопрос: рост из технарей в управленцы, который я вижу вокруг себя, происходит как случайный апгрейд: уходит один управленец — и на его место просто берут какого-нибудь senior developer, который может быть даже и не хотел быть менеджером. Как лучше двигаться к управлению — в текущей компании или все же уходить в другую?
Главное, не поддавайтесь классическому искажению, что у соседа трава зеленее — уйти в другую компанию вы всегда успеете :-) К тому же, если компания берет тимлида без опыта работы, это означает, что она ОЧЕНЬ сильно в нём нуждается. Не думаю, что место, которое нуждается в вас больше, чем вы в нем — хороший выбор.
Попробуйте перейти в управленцы на текущем месте. Для начала честно ответьте себе на вопрос — почему в прошлый раз, когда освободилось место управленца, выбрали не вас, а кого-то другого? Что можно сделать, чтобы в следующий раз ни у кого не возникало сомнений по поводу вашей кандидатуры? Если придёте к решению, что не хватило репутации — просто выполняйте рекомендации из предыдущего совета.
Расскажите руководителю про ваше желание — наверняка вам дадут понятные рекомендации, или даже назовут несколько свободных проектов, которые можно было бы повести самостоятельно.
Главное, не поддавайтесь классическому искажению, что у соседа трава зеленее — уйти в другую компанию вы всегда успеете :-) К тому же, если компания берет тимлида без опыта работы, это означает, что она ОЧЕНЬ сильно в нём нуждается. Не думаю, что место, которое нуждается в вас больше, чем вы в нем — хороший выбор.
Попробуйте перейти в управленцы на текущем месте. Для начала честно ответьте себе на вопрос — почему в прошлый раз, когда освободилось место управленца, выбрали не вас, а кого-то другого? Что можно сделать, чтобы в следующий раз ни у кого не возникало сомнений по поводу вашей кандидатуры? Если придёте к решению, что не хватило репутации — просто выполняйте рекомендации из предыдущего совета.
Расскажите руководителю про ваше желание — наверняка вам дадут понятные рекомендации, или даже назовут несколько свободных проектов, которые можно было бы повести самостоятельно.
Управление командой: военное и мирное время
Важная метафора в управлении командой — военное и мирное время. Война — это время напряжения всех сил: чаты в телеграме, ежедневные планы, быстрые и грязные фиксы в коде.
В мирное время всё спокойно — планы больше растянуты по времени, коллеги не отвлекают друг-друга по пустякам. Больше внимания уделяется качеству кода и процессам, происходящим в команде.
Война — не так уж и плохо: она кратковременно ускоряет производство, объединяя команду вокруг одной конкретной задачи. На войне можно быстро получить грязный продукт, который срочно нужен.
Люди, которые пережили вместе военное время, начинают относиться друг к другу по другому. Лично я вообще не даю рекомендаций людям, не зная их поведения в военное время.
Воевать хорошо раз в пару месяцев, не чаще. Частые войны выматывают команду и продукт — копится усталость и техдолг.
Задача CTO — не начинать войны по пустякам. Если вы собираетесь занять личные ресурсы у участников своей команды (а возможно и у их близких) — уж потрудитесь убедиться, что бизнес получит от этого соответствующую прибыль.
Важная метафора в управлении командой — военное и мирное время. Война — это время напряжения всех сил: чаты в телеграме, ежедневные планы, быстрые и грязные фиксы в коде.
В мирное время всё спокойно — планы больше растянуты по времени, коллеги не отвлекают друг-друга по пустякам. Больше внимания уделяется качеству кода и процессам, происходящим в команде.
Война — не так уж и плохо: она кратковременно ускоряет производство, объединяя команду вокруг одной конкретной задачи. На войне можно быстро получить грязный продукт, который срочно нужен.
Люди, которые пережили вместе военное время, начинают относиться друг к другу по другому. Лично я вообще не даю рекомендаций людям, не зная их поведения в военное время.
Воевать хорошо раз в пару месяцев, не чаще. Частые войны выматывают команду и продукт — копится усталость и техдолг.
Задача CTO — не начинать войны по пустякам. Если вы собираетесь занять личные ресурсы у участников своей команды (а возможно и у их близких) — уж потрудитесь убедиться, что бизнес получит от этого соответствующую прибыль.
Коммуникация в удалённой команде
Вышел мой совет об организации коммуникации в распределённой команде разработки — http://bureau.ru/soviet/20190606/.
Внедрите эти простые правила в своей команде, даже если вы сидите в одном офисе.
Кстати, мы в ГдеМатериале ищем маркетолога. Если хотите на деле увидеть, что такое правильная коммуникация в распределенной команде, поработать со сквозной аналитикой с точностью до рубля, в компании, где от идеи до внедрения проходит меньше недели — напишите Арсену @iamarsenibragimov.
Вышел мой совет об организации коммуникации в распределённой команде разработки — http://bureau.ru/soviet/20190606/.
Внедрите эти простые правила в своей команде, даже если вы сидите в одном офисе.
Кстати, мы в ГдеМатериале ищем маркетолога. Если хотите на деле увидеть, что такое правильная коммуникация в распределенной команде, поработать со сквозной аналитикой с точностью до рубля, в компании, где от идеи до внедрения проходит меньше недели — напишите Арсену @iamarsenibragimov.
Ежедневный герой
Мы в ГдеМатериале придерживаемся принципа «все умеют всё», и хотим чтобы знания циркулировали между программистами максимально быстро — ситуация, при которой двое коллег независимо друг от друга решают одну и ту же задачу, для нас неприемлема.
С одной стороны, можно просто подписать всех людей на все проекты стандартными средствами гитхаба, но тогда информации становится слишком много — приходят все комменты ко всем задачам и пулл-реквестам: это уже скорее спам, чем польза.
Попробовав разные варианты, мы пришли к информационному потоку, который оказался полезен всем — мы просто каждый день рассылаем по почте списки закрытых за день задач. На этот поток подписываем всех заинтересованных, включая внешних подрядчиков — рекламному агентству очень полезно узнавать обо всех нововведениях на сайте в реальном времени.
Поток генерим с помощью API гитхаба и простого сервиса, который назвали Ежедневным Героем. Героем — потому, что закрытые задачи в списке разбиты по людям. Кто больше закрыл — тот и герой.
Сегодня мы публикуем исходный код Ежедневного Героя. Если в вашей компании пользуются issues в гитхабе — просто запустите наш докер-образ по инструкции, и получите такой же информационный поток, как у нас.
Кстати, если вы — питонист, думаете сменить работу и хотите, чтобы код, написанный на работе, добавлялся в ваше опенсорс-портфолио — напишите мне на fb@gdml.ru.
Мы в ГдеМатериале придерживаемся принципа «все умеют всё», и хотим чтобы знания циркулировали между программистами максимально быстро — ситуация, при которой двое коллег независимо друг от друга решают одну и ту же задачу, для нас неприемлема.
С одной стороны, можно просто подписать всех людей на все проекты стандартными средствами гитхаба, но тогда информации становится слишком много — приходят все комменты ко всем задачам и пулл-реквестам: это уже скорее спам, чем польза.
Попробовав разные варианты, мы пришли к информационному потоку, который оказался полезен всем — мы просто каждый день рассылаем по почте списки закрытых за день задач. На этот поток подписываем всех заинтересованных, включая внешних подрядчиков — рекламному агентству очень полезно узнавать обо всех нововведениях на сайте в реальном времени.
Поток генерим с помощью API гитхаба и простого сервиса, который назвали Ежедневным Героем. Героем — потому, что закрытые задачи в списке разбиты по людям. Кто больше закрыл — тот и герой.
Сегодня мы публикуем исходный код Ежедневного Героя. Если в вашей компании пользуются issues в гитхабе — просто запустите наш докер-образ по инструкции, и получите такой же информационный поток, как у нас.
Кстати, если вы — питонист, думаете сменить работу и хотите, чтобы код, написанный на работе, добавлялся в ваше опенсорс-портфолио — напишите мне на fb@gdml.ru.
Профессиональный сленг
Где-то читал, что для того, чтобы тебя приняли за своего в любом профессиональном сообществе, достаточно просто владеть сленгом — и никакие 10 000 часов практики не нужны.
Упомянул про юнит-экономику — и ты уже продакт-менеджер. Рассказал про отличия роторных машинок от индукционных — и ты уже тату-мастер.
Самое обидное — что люди, которых таким образом принимают в сообщество, действительно начинают себя считать профессионалами, и снижают профессиональный уровень сообщества, в которое пришли.
Если я на собеседовании замечаю программиста, который не имея глубоких знаний употребляет профжаргон, скажем много говорит о тестировании фронтенда, но не знает, как работают ассерты в Jest, или что какое TestCafé, я прекращаю такое собеседование.
Мне важнее нанять человека, который не стесняется сказать «я не знаю», чем человека, который хорошо умеет выглядеть, как будто знает.
Где-то читал, что для того, чтобы тебя приняли за своего в любом профессиональном сообществе, достаточно просто владеть сленгом — и никакие 10 000 часов практики не нужны.
Упомянул про юнит-экономику — и ты уже продакт-менеджер. Рассказал про отличия роторных машинок от индукционных — и ты уже тату-мастер.
Самое обидное — что люди, которых таким образом принимают в сообщество, действительно начинают себя считать профессионалами, и снижают профессиональный уровень сообщества, в которое пришли.
Если я на собеседовании замечаю программиста, который не имея глубоких знаний употребляет профжаргон, скажем много говорит о тестировании фронтенда, но не знает, как работают ассерты в Jest, или что какое TestCafé, я прекращаю такое собеседование.
Мне важнее нанять человека, который не стесняется сказать «я не знаю», чем человека, который хорошо умеет выглядеть, как будто знает.
Мне сказали — я копаю
В любой здоровой компании есть атмосфера критики. Кто бы ни пришёл с идеей: акционер, CEO или линейный сотрудник, его идею обязательно обсуждают и валидируют. Автору задают важные вопросы: «мы это делаем, чтобы что?», «если это не заработает, то из-за чего?» и тд. Такой фичекатинг, ещё до продакт-менеджера.
Почему-то внутри разработки такая практика обычно умирает. Какие бы странные задачи ни приходили, насколько бы очевидными упрощения в них ни были, программисты делают ровно то, что написано в требованиях. Это грустно, потому что часто программисты — самый большой центр затрат в компании. А что это за центр затрат, который не контролирует, куда он расходует ресурсы?
При этом программисты — прекрасные скептики: долгая работа с алгоритмами, которые описывают вещи из реального мира, приучает к критическому мышлению. Когда твои гениальные построения постоянно разбиваются о сложсочиненные системы в реальной жизни — скептиком становишься сам того не желая.
Давайте использовать скептицизм программистов — звать их на обсуждения, поощрять новые идеи, а самое главное — писать в задачах поменьше требований и побольше целей. Одно «чтобы что» стоит десяти «что сделать».
В любой здоровой компании есть атмосфера критики. Кто бы ни пришёл с идеей: акционер, CEO или линейный сотрудник, его идею обязательно обсуждают и валидируют. Автору задают важные вопросы: «мы это делаем, чтобы что?», «если это не заработает, то из-за чего?» и тд. Такой фичекатинг, ещё до продакт-менеджера.
Почему-то внутри разработки такая практика обычно умирает. Какие бы странные задачи ни приходили, насколько бы очевидными упрощения в них ни были, программисты делают ровно то, что написано в требованиях. Это грустно, потому что часто программисты — самый большой центр затрат в компании. А что это за центр затрат, который не контролирует, куда он расходует ресурсы?
При этом программисты — прекрасные скептики: долгая работа с алгоритмами, которые описывают вещи из реального мира, приучает к критическому мышлению. Когда твои гениальные построения постоянно разбиваются о сложсочиненные системы в реальной жизни — скептиком становишься сам того не желая.
Давайте использовать скептицизм программистов — звать их на обсуждения, поощрять новые идеи, а самое главное — писать в задачах поменьше требований и побольше целей. Одно «чтобы что» стоит десяти «что сделать».
Вопрос: какой программист более ценен — кто глубоко знает одну технологию, или тот, кто в целом имеет хороший кругозор и знает много?
Это зависит от компании. Условному банку, у которого весь код был написан 15 лет назад, конечно лучше подходят узкие специалисты. Стартапу, в котором вы можете быть единственным разработчиком, лучше подходят люди с широким кругозором.
Сам по себе подход с глубокими знаниями в одной технологии неплох — людям всегда нужно будет поддерживать легаси: до сих пор можно найти работу для таких странных вещей как Perl или Delphi. Если вам комфортно зависеть от одного работодателя чуть больше, чем коллеги из соседних стеков — это вполне решение.
С другой стороны, широкий кругозор, помимо быстрого поиска работы еще и прокачивает общее понимание «того, как работают вещи» — после третьей или четвертой технологии вы уже умеете учиться, легко воспринимаете новое, и без труда остаетесь актуальными на рынке труда.
А вообще — не учите технологии, учитесь решать задачи.
Другие ответы — #вопрос. Задать свой — @fedor_borshev.
Это зависит от компании. Условному банку, у которого весь код был написан 15 лет назад, конечно лучше подходят узкие специалисты. Стартапу, в котором вы можете быть единственным разработчиком, лучше подходят люди с широким кругозором.
Сам по себе подход с глубокими знаниями в одной технологии неплох — людям всегда нужно будет поддерживать легаси: до сих пор можно найти работу для таких странных вещей как Perl или Delphi. Если вам комфортно зависеть от одного работодателя чуть больше, чем коллеги из соседних стеков — это вполне решение.
С другой стороны, широкий кругозор, помимо быстрого поиска работы еще и прокачивает общее понимание «того, как работают вещи» — после третьей или четвертой технологии вы уже умеете учиться, легко воспринимаете новое, и без труда остаетесь актуальными на рынке труда.
А вообще — не учите технологии, учитесь решать задачи.
Другие ответы — #вопрос. Задать свой — @fedor_borshev.
Django и кластеры
Во времена, когда придумывали Django, про контейниразацию никто не думал — люди просто делали админку для сайта газеты. Несмотря на узкую направленность, архитекторы заложили достаточный запас, чтобы Django спокойно жила в современном облачном мире.
Во-первых, они сделали модульную абстракцию от системы хранения — просто подключаем любой модуль из django-storages вместо FileSystemStorage и перестаём думать о хранении файлов.
Во-вторых, Django запускается через общепринятый протокол WSGI, что позволяет как угодно настраивать мультипоточность при помощи того же UWSGI. Я рекомендую классический master mode с двумя воркерами на контейнер, и ограничение по количеству запросов на каждый, чтобы не есть память.
В-третьих, почти вся функциональность, нужная для современного девопса, в Django сделана через удобные внешние зависимости.
— Мониторинг статистики через Datadog. Просто заводим его на каждой машине в кластере и получаем в дополнение ещё и мониторинг серверов.
— Сбор статистики через statsd. Можно использовать dogstatsd из того же Датадога, либо взять оригинальный, если хотите держать значения метрик у себя.
— Мониторинг ошибок — просто ставим sentry.
— Логирование — что угодно, мы в ГдеМатериале используем Papertrail, но можно тот же datadog
— Мониторинг здоровья контейнеров — django-healtchecks.
P.S. Кстати, Django работает и с модным serverless, так что если вы модный хипстер — обязательно посмотрите Zappa.
Во времена, когда придумывали Django, про контейниразацию никто не думал — люди просто делали админку для сайта газеты. Несмотря на узкую направленность, архитекторы заложили достаточный запас, чтобы Django спокойно жила в современном облачном мире.
Во-первых, они сделали модульную абстракцию от системы хранения — просто подключаем любой модуль из django-storages вместо FileSystemStorage и перестаём думать о хранении файлов.
Во-вторых, Django запускается через общепринятый протокол WSGI, что позволяет как угодно настраивать мультипоточность при помощи того же UWSGI. Я рекомендую классический master mode с двумя воркерами на контейнер, и ограничение по количеству запросов на каждый, чтобы не есть память.
В-третьих, почти вся функциональность, нужная для современного девопса, в Django сделана через удобные внешние зависимости.
— Мониторинг статистики через Datadog. Просто заводим его на каждой машине в кластере и получаем в дополнение ещё и мониторинг серверов.
— Сбор статистики через statsd. Можно использовать dogstatsd из того же Датадога, либо взять оригинальный, если хотите держать значения метрик у себя.
— Мониторинг ошибок — просто ставим sentry.
— Логирование — что угодно, мы в ГдеМатериале используем Papertrail, но можно тот же datadog
— Мониторинг здоровья контейнеров — django-healtchecks.
P.S. Кстати, Django работает и с модным serverless, так что если вы модный хипстер — обязательно посмотрите Zappa.
Поработал? Убери!
Все знают, что улучшение любого программного обеспечения всегда приводит к его ухудшению — деградирует кодовая база. Чтобы этот процесс не нарастал лавинообразно, нужно соблюдать банальный порядок.
Делать это нужно так же, как в на верстаке в мастерской: поработал — убери. Оставляй после себя рабочее место чище, чем было до тебя. Видишь бумажку на полу — подбери и выкинь. Видишь говнокод — перепиши.
Если ваш ПР ничего не улучшает для других — это плохой ПР.
Я знаю, что многие ребята почему-то стесняются удалять чужой код, даже когда он покрыт тестами. Когда я пишу код, я, наоборот, стесняюсь оставлять некрасивый код в репозитории.
Если у вас на проекте все начнут следовать этому простому правилу, то ваша кодовая база начнёт ухудшаться гораздо медленнее.
Все знают, что улучшение любого программного обеспечения всегда приводит к его ухудшению — деградирует кодовая база. Чтобы этот процесс не нарастал лавинообразно, нужно соблюдать банальный порядок.
Делать это нужно так же, как в на верстаке в мастерской: поработал — убери. Оставляй после себя рабочее место чище, чем было до тебя. Видишь бумажку на полу — подбери и выкинь. Видишь говнокод — перепиши.
Если ваш ПР ничего не улучшает для других — это плохой ПР.
Я знаю, что многие ребята почему-то стесняются удалять чужой код, даже когда он покрыт тестами. Когда я пишу код, я, наоборот, стесняюсь оставлять некрасивый код в репозитории.
Если у вас на проекте все начнут следовать этому простому правилу, то ваша кодовая база начнёт ухудшаться гораздо медленнее.
Вопрос: расскажи, как ты находишь время на блог?
Я очень много разговариваю с людьми — с командой разработки и представителями бизнеса в ГдеМатериале, с коллегами по личным проектам, с клиентами в рамках консультационной практики.
Каждый раз, когда я объясняю что-то новое, я обязательно после разговора записываю это в специальную доску в трелло. Одна карточка — одна мысль, 3–5 карточек в неделю.
Дальше все просто — раз в неделю я сажусь в любимой кофейне и выделяю два часа, чтобы превратить накопившиеся в трелло карточки в текст. Какие-то карточки сразу становятся постами, какие-то могут ждать своей очереди месяцами.
Ключевая идея в том, что у меня разделён процесс генерации идей и написания постов. Это два разных состояния мозга — в одном я накидываю идеи и новые метафоры (лучше всего получается после разговоров с кем-нибудь), а в другом — делаю из этих идей понятные тексты.
Другие ответы — #вопрос. Задать свой — @fedor_borshev.
Я очень много разговариваю с людьми — с командой разработки и представителями бизнеса в ГдеМатериале, с коллегами по личным проектам, с клиентами в рамках консультационной практики.
Каждый раз, когда я объясняю что-то новое, я обязательно после разговора записываю это в специальную доску в трелло. Одна карточка — одна мысль, 3–5 карточек в неделю.
Дальше все просто — раз в неделю я сажусь в любимой кофейне и выделяю два часа, чтобы превратить накопившиеся в трелло карточки в текст. Какие-то карточки сразу становятся постами, какие-то могут ждать своей очереди месяцами.
Ключевая идея в том, что у меня разделён процесс генерации идей и написания постов. Это два разных состояния мозга — в одном я накидываю идеи и новые метафоры (лучше всего получается после разговоров с кем-нибудь), а в другом — делаю из этих идей понятные тексты.
Другие ответы — #вопрос. Задать свой — @fedor_borshev.
Почему я не люблю оценивать задачи
Во всех своих командах я исключаю процедуру регулярной оценки задач — эстимейт ставится только на большие и сложные проекты, с минимальным шагом в две недели.
Почему я не даю оценок маленьких задач? Во-первых потому, что если в задаче указано сколько её нужно делать, это подрывает саму основу контракта с исполнителем: ведь я же, отдавая задачу, ожидаю получить фичу на проде, а не 5 часов работы по написанию кода.
Во-вторых, работа всегда занимает все отведённое на неё время, даже когда этого времени отведено чрезмерно много. Вот приходит тебе задача, оцененная в 5 часов, и у тебя уже нет стимула придумать как сделать её за час, потом еще час потратить на улучшение кодовой базы, а три часа на поход в кино или спортзал. Ты просто садишься и 5 часов работаешь.
Для программиста любая задача — творческая. Даже если нужно поделать что-то простое, скажем прописать какие-нибудь права в группах доступа — каждое касание кодовой базы должно происходить в состоянии любопытного исследователя, который думает о том, что бы здесь улучшить, или как повеселее решить данную задачу.
А с эстимейтом получается не любопытный исследователь, а рабочий на станке: вот инструкция, вот звонок, звенит один раз — работаем, два раза — домой. Часто ли рабочие с жёсткой инструкцией приходят с инициативой, как улучшить расположение станков или загрузку производства?
Во всех своих командах я исключаю процедуру регулярной оценки задач — эстимейт ставится только на большие и сложные проекты, с минимальным шагом в две недели.
Почему я не даю оценок маленьких задач? Во-первых потому, что если в задаче указано сколько её нужно делать, это подрывает саму основу контракта с исполнителем: ведь я же, отдавая задачу, ожидаю получить фичу на проде, а не 5 часов работы по написанию кода.
Во-вторых, работа всегда занимает все отведённое на неё время, даже когда этого времени отведено чрезмерно много. Вот приходит тебе задача, оцененная в 5 часов, и у тебя уже нет стимула придумать как сделать её за час, потом еще час потратить на улучшение кодовой базы, а три часа на поход в кино или спортзал. Ты просто садишься и 5 часов работаешь.
Для программиста любая задача — творческая. Даже если нужно поделать что-то простое, скажем прописать какие-нибудь права в группах доступа — каждое касание кодовой базы должно происходить в состоянии любопытного исследователя, который думает о том, что бы здесь улучшить, или как повеселее решить данную задачу.
А с эстимейтом получается не любопытный исследователь, а рабочий на станке: вот инструкция, вот звонок, звенит один раз — работаем, два раза — домой. Часто ли рабочие с жёсткой инструкцией приходят с инициативой, как улучшить расположение станков или загрузку производства?
Где провести границу MVP
На сайте Бюро вышел мой совет о том, как тестировать даже такие сложные вещи как вход через соц. сеть без участия программистов и не тратя кучу денег.
На сайте Бюро вышел мой совет о том, как тестировать даже такие сложные вещи как вход через соц. сеть без участия программистов и не тратя кучу денег.
Вопрос: что разработчик должен знать о дизайне? А тимлид?
Если разработчик занимается интерфейсами, то базовые вещи вот такие:
— Теория близости и Закон Фиттса
— Анимация в интерфейсах
— Как писать тексты в интерфейсах
Идеально — освоить какой-нибудь дизайнерский инструмент, к примеру Фигму.
Когда закончите с технологиями, почитайте о продукте и результате:
— Понятие «боли» и «мира клиента», Джим Кэмп
— jobs-to-be-done или любая другая методика проектирования
— Психбольница в руках пациентов
— Intercom on Product Magement
Это был традиционный вопрос по понедельникам. Задать свой — @fedor_borshev, посмотреть другие ответы — #вопрос
Если разработчик занимается интерфейсами, то базовые вещи вот такие:
— Теория близости и Закон Фиттса
— Анимация в интерфейсах
— Как писать тексты в интерфейсах
Идеально — освоить какой-нибудь дизайнерский инструмент, к примеру Фигму.
Когда закончите с технологиями, почитайте о продукте и результате:
— Понятие «боли» и «мира клиента», Джим Кэмп
— jobs-to-be-done или любая другая методика проектирования
— Психбольница в руках пациентов
— Intercom on Product Magement
Это был традиционный вопрос по понедельникам. Задать свой — @fedor_borshev, посмотреть другие ответы — #вопрос
Одна задача — один ответственный
Бывает такая ситуация — делаешь задачу, а коллеги, видя промежуточные результаты (у нас же все открыто) приходят с рекомендациями — вот тут можно кнопку поярче сделать, вон там вообще надо переверстать.
С одной стороны — это очень круто: людям, похоже, не пофиг, что я делаю. С другой стороны — они знают недостаточно вводных: почему я решил делать именно такую кнопку, а не другую, почему выбрали делать автомат вместо ручной галочки и т.д.
Если соглашаться на такие замечания — скоуп вырастет так, что проект никогда не запустится. Если пытаться урегулировать их как обычные замечания — потеряете кучу врремени: с каждым автором замечаний приходится говорить, задавать вопросы.
Игнорировать мнение коллег тоже нельзя — обычно они разбираются в своей области деятельности куда лучше вас, и их советы бывают полезными.
Идеальное решение проблемы — процесс, который описал Фредерик Лалу в своих «Организациях будущего» — внутреннее консультирование. Это когда мы интересуемся мнением коллег, но финальное решение принимает один человек. Коллеги при этом с самого начала понимают, что их голос — совещательный. То есть слушаем экспертов, но эксперты заранее знают, что решение принимают не они.
Лайфхак — особо несогласному коллеге вполне можно отдать право финального решения, вместе с ответственностью за результат. Если ему важно сделать дело, а не поговорить — он легко согласится.
Бывает такая ситуация — делаешь задачу, а коллеги, видя промежуточные результаты (у нас же все открыто) приходят с рекомендациями — вот тут можно кнопку поярче сделать, вон там вообще надо переверстать.
С одной стороны — это очень круто: людям, похоже, не пофиг, что я делаю. С другой стороны — они знают недостаточно вводных: почему я решил делать именно такую кнопку, а не другую, почему выбрали делать автомат вместо ручной галочки и т.д.
Если соглашаться на такие замечания — скоуп вырастет так, что проект никогда не запустится. Если пытаться урегулировать их как обычные замечания — потеряете кучу врремени: с каждым автором замечаний приходится говорить, задавать вопросы.
Игнорировать мнение коллег тоже нельзя — обычно они разбираются в своей области деятельности куда лучше вас, и их советы бывают полезными.
Идеальное решение проблемы — процесс, который описал Фредерик Лалу в своих «Организациях будущего» — внутреннее консультирование. Это когда мы интересуемся мнением коллег, но финальное решение принимает один человек. Коллеги при этом с самого начала понимают, что их голос — совещательный. То есть слушаем экспертов, но эксперты заранее знают, что решение принимают не они.
Лайфхак — особо несогласному коллеге вполне можно отдать право финального решения, вместе с ответственностью за результат. Если ему важно сделать дело, а не поговорить — он легко согласится.
Status Hero — замена дейли-митингам, если вам уж очень надо
Мы в ГдеМатериале не практикуем дейли-митинги — гораздо проще договориться с ребятами о результатах на ближайшую неделю или две, чем каждый день проверять, что всё идёт по плану.
При этом, есть категория специалистов, которым ежедневная синхронизация все-таки важна — у нас это все, кто работает вне обычных спринтов: дизайнеры, программисты команды поддержки, сисадмины и т.д.
Каждый день собирать всю эту команду вместе было бы странно — все-таки они занимаются весьма разными вещами. Но поддерживать в команде знания о том, кто и чем сейчас занимается, всё-таки хочется: каждый должен знать, о чём болит голова у соседа.
Для таких случаев мы используем Status Hero — простой сервис ежедневных чекинов. Все что он делает — присылает в 11:00 каждого дня ссылку на форму со стандартными вопросами из скрама: что сделал вчера, что будешь делать сегодня, какие есть проблемы. В 16:00 результаты заполнения формы рассылаются всей команде.
Получаются почти все плюшки дейли-митингов, только без необходимости тратить время и слушать неинтересные вещи.
Мы в ГдеМатериале не практикуем дейли-митинги — гораздо проще договориться с ребятами о результатах на ближайшую неделю или две, чем каждый день проверять, что всё идёт по плану.
При этом, есть категория специалистов, которым ежедневная синхронизация все-таки важна — у нас это все, кто работает вне обычных спринтов: дизайнеры, программисты команды поддержки, сисадмины и т.д.
Каждый день собирать всю эту команду вместе было бы странно — все-таки они занимаются весьма разными вещами. Но поддерживать в команде знания о том, кто и чем сейчас занимается, всё-таки хочется: каждый должен знать, о чём болит голова у соседа.
Для таких случаев мы используем Status Hero — простой сервис ежедневных чекинов. Все что он делает — присылает в 11:00 каждого дня ссылку на форму со стандартными вопросами из скрама: что сделал вчера, что будешь делать сегодня, какие есть проблемы. В 16:00 результаты заполнения формы рассылаются всей команде.
Получаются почти все плюшки дейли-митингов, только без необходимости тратить время и слушать неинтересные вещи.
Вопрос: Как программисту не решать выдуманных проблем?
Выдуманные проблемы — серьезная боль для разработки: однажды написанный код, который решает никому не нужные задачи, приходится поддерживать, тестировать, рефакторить и т.д.
Выдуманные проблемы приходят и от менеджеров, и от программистов. Про первый вариант я итак много пишу, поэтому, думаю, вы спрашиваете про второй.
Пример выдуманной проблемы, которую придумывают программисты — высокая нагрузка. Вот пишете вы код и задумываетесь, а насколько он эффективен? Может его лучше асинхронно написать? Или хотя бы на генераторах вместо циклов?
Или делаете вы интеграцию с какой-нибудь внешней системой. Разбираете входящие данные и думаете — а что, если вот этого ключа не будет? А что, если тут мне передадут строку, а не цифру?
Ответ простой — возьмите каждое требование, которое вы ставите себе таким образом, и представьте, что вы его не сделали. Теперь задайте себе два вопроса:
— Помешает ли это нам запуститься и проработать две недели?
— Ухудшает ли это качество кодовой базы?
Если ответ на оба вопроса «нет» — не делайте.
Другие вопросы — #вопрос. Задать свой — @fedor_borshev.
Выдуманные проблемы — серьезная боль для разработки: однажды написанный код, который решает никому не нужные задачи, приходится поддерживать, тестировать, рефакторить и т.д.
Выдуманные проблемы приходят и от менеджеров, и от программистов. Про первый вариант я итак много пишу, поэтому, думаю, вы спрашиваете про второй.
Пример выдуманной проблемы, которую придумывают программисты — высокая нагрузка. Вот пишете вы код и задумываетесь, а насколько он эффективен? Может его лучше асинхронно написать? Или хотя бы на генераторах вместо циклов?
Или делаете вы интеграцию с какой-нибудь внешней системой. Разбираете входящие данные и думаете — а что, если вот этого ключа не будет? А что, если тут мне передадут строку, а не цифру?
Ответ простой — возьмите каждое требование, которое вы ставите себе таким образом, и представьте, что вы его не сделали. Теперь задайте себе два вопроса:
— Помешает ли это нам запуститься и проработать две недели?
— Ухудшает ли это качество кодовой базы?
Если ответ на оба вопроса «нет» — не делайте.
Другие вопросы — #вопрос. Задать свой — @fedor_borshev.
Не нравится? Разбирайся!
Сложно представить, сколько разработчиков делают фигню, которая им не нравится: работают по криво сформулированным задачам, с неудобными надстройками линтера, пишут на втором питоне вместо третьего и т.д.
Ещё более удивительно то, скольких них спасла бы пара-тройка открытых вопросов. К примеру пришла вам задача, которую, вы уверены, надо решать по другому. Скорее всего, менеджер — не идиот, и если попросить его рассказать подробнее, почему задача такая, а не другая, то задача сразу же станет стройной и понятной.
Или достал вас кривой линтер. Если подойти к тимлиду и позадавать вопросов на тему «почему так?», то с ненулевой вероятностью легаси начнет исправляться — говнокод перепишется или изолируется, линтер обновится, а питон, даже если не станет третьим, то хотя бы начнёт делать
Может конечно и нет, но задать вопрос ничего не стоит, а в ответ на открытые вопросы люди всегда делятся полезными знаниями.
Задавайте вопросы.
Сложно представить, сколько разработчиков делают фигню, которая им не нравится: работают по криво сформулированным задачам, с неудобными надстройками линтера, пишут на втором питоне вместо третьего и т.д.
Ещё более удивительно то, скольких них спасла бы пара-тройка открытых вопросов. К примеру пришла вам задача, которую, вы уверены, надо решать по другому. Скорее всего, менеджер — не идиот, и если попросить его рассказать подробнее, почему задача такая, а не другая, то задача сразу же станет стройной и понятной.
Или достал вас кривой линтер. Если подойти к тимлиду и позадавать вопросов на тему «почему так?», то с ненулевой вероятностью легаси начнет исправляться — говнокод перепишется или изолируется, линтер обновится, а питон, даже если не станет третьим, то хотя бы начнёт делать
from __future import.Может конечно и нет, но задать вопрос ничего не стоит, а в ответ на открытые вопросы люди всегда делятся полезными знаниями.
Задавайте вопросы.
Django: бить модели по файлам, а файлы — по приложениям
Как не следуй гайдлайнам, а в любом проекте на Django рано или поздно окажется файл
Не стесняйтесь бить
Ну и напоследок — не делайте слишком больших приложений. Приложение Django, которое состоит из одной модели — это абсолютно нормально. Когда вырастете в большой проект, это здорово облегчит вам жизнь — ведь такие приложения это неплохая основа для микросервисов.
Как не следуй гайдлайнам, а в любом проекте на Django рано или поздно окажется файл
models.py длиной в 1500 строк. Запускать такую ситуацию нельзя — длинные файлы неудобно читать и править, и команда начинает сама того не осознавая тратить силы на неважное: вместо размышлений о бизнес-логике, программисты вынуждены запоминать, на какой строке находится та или иная модель.Не стесняйтесь бить
models.py на файлы. Даже если у вас всего две модели, скажем, Author и Book, пусть они лежат в models/author.py и models/book.py. К сожалению, без бойлерплейта сделать это не получится, поэтому вам придётся сделать ещё models/__init.py__. Ничего страшного, новые модели добавляются редко, и 5 минут на импортирование всех моделей окупятся уже за следующую неделю.Ну и напоследок — не делайте слишком больших приложений. Приложение Django, которое состоит из одной модели — это абсолютно нормально. Когда вырастете в большой проект, это здорово облегчит вам жизнь — ведь такие приложения это неплохая основа для микросервисов.