Ничего не откладывать !

Из блога Радислава Гандапаса (человека, которого я чрезвычайно уважаю, но с частью взглядов которого совершенно не согласен :)). Однако в конкретном случае могу лишь горячо поддержать. Перенёс к себе из-за чертовски замечательной формулировки.

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

Отсюда следует совет, который я не устану повторять: «Никогда ничего не откладывать!» Этот рецепт перевернет жизнь любого человека, кто будет пользоваться им каждый день. Пришла мысль, пришла идея — тут же бери и делай! Тут же! Два процента участников обращаются к записям, сделанным в процессе моих тренингов! Всего два процента! Остальные довольствуются полученными впечатлениями.

Для огромного количества людей слово «потом» становится девизом. Никогда ничего не откладывать! Решил развестись — подойди к супругу или супруге и начни разговор. Как только ты произнесешь первые слова, — а они могут быть любыми, — станет легче. Нет ничего труднее, чем откладывать важный разговор на потом. Подумал позвонить маме — бери телефон и звони! А мы начинаем искать отговорки: устал, некогда, поздно и тому подобное. Захотел написать любимому человеку СМС или сделать для него что-то необычное — делай! Никогда ничего не откладывать! Это совет для читателей журнала Chief Time, это совет для людей, которые посещают мои тренинги, это совет для всех, кто хочет что-то изменить в своей жизни.

 

Как упростить себе жизнь при введении нового человека в команду

Попалась интересная статья о введении нового человека в процесс командной разработки. У Фаулера в блоге есть ссылка на неё, так что для меня это достаточно авторитетно. Ну и просто изложенные мысли показались достаточно разумными. Главная мысль в том, что agile-методы ориентированы в первую очередь на уже устоявшуюся команду, а не на время её формирования (включения нового человека). Предлагается обратить внимание на процессы, позволяющие упростить себе жизнь во время когда приходит новый человек и/или когда команда не стабильна. Как и всё в agile - просто, естественно и требует постоянства :). Вот эти методы (перевод вольный и скорее так, как отложилось у меня в голове) :  

• Preparation Email(Подготовительное письмо) - пошлите письмо счастья новому разработчику о том, что за проект, какие технологии используются, организационные моменты конкретного проекта 
  
• Big Vision Business Problem (Общее видение проекта) - объяснените новому члену команды общего взгляда на проект; что, зачем, специфика, в глобальном смысле 
  
• Visible Architecture(видимость архитектуры) - нарисуйте архитектуру проекта, чтобы все видели что с чем связано и как устроено 
• Transparent Project Debt(фокус на улучшениях) - обращайте внимание на то, что можно улучшить, на то какие вещи запланированы, на приоритетах задач  
• Tiny Tasks(крошечные задачи) - разбивайте большие таски на мелкие, чтобы (особенно) новому человеку было понятно что надо сделать без дополнительных объяснений; не забывайте объяснять, как эти маленькие задачи являются частями большого целого 
• Tech Huddles(технические тусовки) - устраивайте еженедельные тематические встречи разработчиков, чтобы они могли делиться знаниями и новыми найденными фичами
• Student to Teacher(от ученика к учителю) - дайте возможность новому члену комманды побыть в роли учителя, когда именно он будет объяснять другим членам команды как сделать что-то только ему известным способом  
• Respect Individual Needs (уважайте особенности) - усройте процесс ввода человека в комманду так, чтобы ему было удобно учиться  
• Letting Go(право на ошибку) - (!) создайте человеку среду, где он сможет учиться на своих ошибках - это очень эффективно; только эта среда должна быть ограничена так, чтобы разработчик ошибаясь не ломал кайф рабочий процесс всей команде

Заметка Мартина Фаулера о OpportunisticRefactoring

Заметка Мартина Фаулера о OpportunisticRefactoring (в моём смысловом переводе - "рефакторинг при любой возможности"). На английском, но понятно. Собственно, за простоту изложения я этого корифея очень люблю :) Основные мысли : - в любое время, когда кто-то видит "плохо пахнущий" код, он должен его улучшить, при этом не надо делать всё и сразу - лучше немного, но постоянно. - перед исправлением ошибок и внесением новых фич, сначала делайте маленький рефакторинг. - если вы в процессе изменения, и не можете сделать рефакторинг сразу, то сделайте его как только сможете после - не откладывайте далеко - максимум один-два дня.