Идеальная методология ведения проекта должна никак себя не проявлять в процессе. Она должна быть настолько естественной и непринужденной, на сколько это вообще возможно. Чтобы этого добиться, нужно помнить, что человек очень ленив от природы. Любой без исключения. И мозг наш устроен таким образом, что мы самым естественным образом придумывает как достичь желаемого с минимальными усилиями. Конечно же, очень важно что считается тем самым «желаемым», но говорим мы сейчас о разработчиках, а у них целью по определению стоит решение поставленной задачи. И проектные менеджеры с завидной регулярностью пытаются решить эту проблему.

(Продолжение следует…)

Итак, задача.

Дано: разработчику нужно решить поставленную перед ним задачу с минимальными усилиями (для разработчика).
Цель управляющего: ввести систему учета и оценки задач для грамотного планирования.

И самое время вспомнить об аджайле. Пусть разработчик прежде чем делать задачу сначала потратит время на ее оценку и описание способа решения. Потом защитит свою позицию на совещании перед коллегами и управляющими. Потом каждый день будет писать отчет о проделанной работе в вольной форме, отмечать прогресс задачи. Само собой попутно у него возникают куча проблем и вопросов, на которые разработчик хочет получить ответы. И разработчик ищет самый простой способ получить ответы на свои вопросы. И тут самое интересное: что конкретно он делает? Идет общаться лично (если это возможно, конечно же), звонит по аудио-видео связи, если он любит общаться или же пишет в чат, если наш подопытный — интроверт. После получения всех ответов можно было бы и к решению задачи приступить, но вот незадача, нужно же еще тикет поправить, внести в отчетность все разговоры и статус тикета еще же обновить! Само собой, все, что необходимо сделать разработчику после того, как решение уже известно, воспринимается разработчиком как лишние действия и все естество человека идет против того, чтобы это делать. Найдется тысяча причин по которой редактирование тикета ну просто необходимо отложить на потом, а статус задачи тоже катастрофически важно не изменять прямо сейчас. Конечно же разработчик делает задачу, правильно все оформив в кодовой базе, а вот на остальное сил и энтузиазма уже не остается.

Возможное решение: нанять специального человека, выдать ему плеть и полномочия постоянно проверять актуальность бюрократической машины. За проступок разработчик получит десять ударов плетью. Цель достигнута, разработчик совершенно не желает прочувствовать всю мощь хлыста на себе.

Проблема: наш разработчик резко меняет приоритеты. Главное — правильно заполнять все в джире, а задачу сделать, собственно, не главное. Само собой, интерес к проекту и к работе над ним резко угасает, руководство пытается компенсировать это денежными бонусами, что, собственно, не помогает. Толковые разработчики, которые пишут хороший и правильный код, уходят и остаются те, которые хотят больше денег и согласны заполнять тикеты. От того и планерки утренние такие скучные и затянутые.

(Продолжение следует…)

​Давайте с вами вместе подумаем над более правильным решением вчерашней проблемы (см. два поста выше) в рамках большинства существующих компаний и организаций. Решение должно быть вполне выполнимо, не требовало бы расстрелять всю старую команду и набрать молодую кровь или сделать так, чтобы менеджерам вместо плёток выдавали электрошокер. Напишите мне личным сообщением (@aratak) как вы видите решение такой повсеместной проблемы. Или быть может проблемы нет вовсе? Расскажите мне как у вас устроен процесс. Если вас тоже долгое время гложет этот вопрос, напишите мне сообщением что-то вроде «правильного ответа не знаю, но очень хочу узнать». Мой никнейм в телеграмме @aratak. Его же можно найти в описании канала. Только не обижайтесь, если я вам не отвечу или отвечу односложно. Конечно, я буду стараться ответить всем, но не уверен, что у меня это физически получится. Жду!

​​Ребята, спасибо всем, кто написал весточку в личку. Вроде бы ответил всем, никого не упустил. Как и предполагалось, многие видят описанную проблему, но железной стратегии не нашли. Были и решения, с которыми я лично не согласен, но универсальной пули для такой глобальной проблемы быть не может, поэтому постараюсь сформулировать и опубликовать все присланные решения, тем более, что они вполне себе легко систематизируются. Встречайте с понедельника на волнах нашего канала рубрику #полныйаджайл.

А вы, мои дорогие, присылайте личным сообщением описание процесса управления проектом в вашей команде и мы опубликуем самые интересные анонимно или публично. Такое сакраментальное знание не должно таиться, им обязательно нужно делиться.

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

Я мог бы написать о своем крайне негативном отношении первичного размещения монет («ПРМ» получается), но делать этого на этом канале не буду. Уверен, большинство читателей и так весьма осторожно относяться к ICO и подобным ни к чему не обязывающим инвестициям, как и я. Разве что найдутся такие, которые путем размещения монет пытаются привлечь инвестиции к своим собственным проектам. В таком случае, ай да хитрецы! Но не пытайтесь нас, обычных пользователей, обмануть! Мы-то знаем, что большинство ICO-проектов по своей сути являются аферой, лучше уж купить пачку биткоинов, чем таким вот методом приумножать свой капитал с помощью сомнительных инвестиций.

Канал «Экстраполяция IT» — отдушина от мира криптовалютных криптовалют. Именно поэтому тему блокчена и биткоинов оставляю остальным каналам.

​​

Сегодня в ленте пилотный выпуск рубрики «Полный Аджайл». Напоминаю, что в ней публикуются различные заметки по техпроцессам разработки и в первую очередь не от редакции, а от вас, дорогие читатели. Присылайте ваши мысли и описание ваших техпроцессов мне личным сообщением, ведь такие ценные знания должны быть общим достоянием.

О снижении гибкости управления проекта

Можно желать упростить рабочие процессы программиста до того, что ему ничего не нужно будет делать. Но ведь все проблемы контроля и определения сроков исходят из требований гибкости и постоянного изменения требований. Ведь при каскадной модели мы относительно точно знаем сколько людей с какими навыками нужно для выполнения проекта, так как все процессы делятся на этапе подготовки проекта. С этим в теории просто и понятно.

А когда требования меняются каждый день, то программист должен понимать общую архитектуру проекта, покрывать тестами, рассказывать что да как коллегам. Внедряются новые фреймворки, и хорошо если не нагрузили девопсом. Фронтендеры пишут не только браузерный джаваксрипт, но и серверный слой на nodejs, верстают, работают с моделями баз данных и прочее прочее. То, что по-правильному таких разработчиков нужно назвать «гибридные разработчики» и наверняка вы помните статью об этом.

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

Мы стали заложниками того, что проекты запускаются, тестируются и меняются без стратегии, одна тактика.

#полныйаджайл

​​Ребята, доброе утро!
В армии существует замечательный, на мой взгляд, критерий, по которому не сложно отличить хорошего бойца от плохого. Речь о выражении «я бы с ним в разведку не пошел». И ведь действительно, когда спрашивают о состоятельности боевого товарища, то критериев может быть масса, и у каждого эти критерии разнятся в зависимости от полученного опыта и достоинств. Одному важно метко ли стреляет его напарник и быстро ли он бегает. Другому важно, чтобы напарник молчал и вкусно готовил, а третьему необходимо в напарники того, кто не боится змей и умеет управлять боевым вертолетом. Пытаться составить мало-мальски универсальный список качеств и свойств бойцов, мы очень скоро скатимся в перечисление характеристик какой-нибудь RPG вроде «Фалаута» или «Скайрима». И отличить хорошего бойца от плохого будет крайне сложно.
А вот такая субъективная оценка товарища по оружию очень легко даст понять хороший ли боец вот этот вот джаваскрипт-разработчик или не очень хороший. Согласен ли ты работать в проекте, где он будет тимлидом? Можно ли ему доверить задачу, которую потом спросят с тебя?
Если оба ответа — «нет», то такого бойца нужно срочно переводить в стройбат и не подпускать с продакшену.

Ребята, технический пост.

На днях столкнулся с таким понятием, как нативная реклама. Нет, раньше я, конечно знал что это такое и понимал как оно работает, но масштабов проблемы не видел.


В общем, предложили мне (в очередной раз) опубликовать рекламу в «Экстраполяции». Обычно в таких случаях я просто закатываю глаза к небу и отвечаю что-то вроде «нет, рекламы на канале не бывает». А в этот раз как-то настойчиво предлагали, с уверенностью, что такая реклама на канале вообще бывает. Рекламодатель сильно удивился отказу и прислал ссылку на пост с подбором различных каналов, где четко и ясно написано, что это не реклама и исключительно моё мнение. Говорит, что думал, что это «такой нейтив». Мол, купили моё мнение и рекламирую я каналы под видом независимого и неподкупного.

Вот такая она, эта нативная реклама, друзья. На каналах, где плевать на своих читателей, она подается под видом мнения автора. Читайте «Экстраполяцию», ссылки на что угодно тут появляются только потому, что это интересно и полезно, а не потому что за нее заплатили.

Ну, и чтобы два раза не вставать, хочу рассказать еще об одном канале, который я читаю с удовольствием. Возможно, вы его знаете по не очень смешному «смешному твитеру». Это Владислав Козуля и его телеграм-канал @PROprgmr. В канале появляются только авторские заметки о нелегкой судьбе фронтендера, за что и ценится.

К слову, недавно Владислав рекомендовал своим читателям «Экстраполяцию» совершенно безвозмездно и на добровольных началах. Можно с уверенностью сказать, что содержимое канала — это действительно его мнение, а не купленный «нейтив».

Читайте только самое лучшее, друзья!

​​Месяц назад в нашем уютном канале была статья о лакмусовых бумажках в программировании. В ней рассказывалось о неких критериях написания кода, по которым можно сказать, что что-то идет не так. Помните же? Сегодня будет еще одна лакмусовая бумажка от программирования. Очень похоже на то, что это прям целая рубрика будет. И назовем ее, скажем, «Две полоски», по аналогии со всеми известным процессом :-) В эту рубрику также принимаются ваши критерии и советы, пишите личным сообщением с пометкой #двеполоски.
Итак, критерий.

Временных решений не бывает.

Бывают решения, которые предпочитаются более удачным по разным обстоятельствам: меньшее время, более простой код, упрощенный дизайн и прочее. Но то решение, которое делается здесь и сейчас может просуществовать годами без изменений и переплестись с другими частями приложения настолько тесно, что заменить его будет крайне тяжело. Конечно, на компромиссы идти нужно и делать это приходиться постоянно, но тешить себя мыслью, что решение временное и можно тут слегка поступиться принципами нельзя.

​​Лайвхаки от Экстраполяции

В Макоси есть замечательная малоиспользуемая возможность добавлять правила автозамены при наборе текста. Конечно, простейшие опечатки и грамматические ошибки система исправляет автоматом, но вот слэнг и дурные привычки системе исправить очень тяжело и в общем случае невозможно. Вроде «ггг», «чо», «хз» или «ща». И эта фича операционной системы может помочь.

Пишите грамотно и пусть ваши собеседники не знают о ваших лингвистических пристрастиях!

P.S. Скриншот мой, правил много.

​​Ребята, возможность эту можно найти в системных настройках, в разделе «клавиатура». Не все нашли :-)

В телеграме работа с публичными каналами кардинально отличается от привычных площадок. В ютубе, например, все блоггеры, как один, начали просить нажимать на колокольчик, чтобы мгновенно узнавать о новой публикации, новостные ресурсы начали добавлять бесячую браузерную нотификацию о новых постах. А в телеграме же с точностью до наоборот. Пользователей просят нажимать «mute», чтобы новые посты не раздражали. Даже тем, кто не убрал звук оповещений, сообщение не приходит благодаря особому тихому режиму отправки сообщений. Попробуйте отжать «mute» на недельку на канале и убедитесь сами — появится значок непрочитанного сообщения, но форсированное уведомление приходить не будет. За другие каналы ручаться не могу :-)

Ещё в телеграме напрочь отсутствуют встроенные механизмы продвижения и популяризации каналов. Тут нет вкладки «тренды», нет «мои друзья читают», нет «рекомендаций». С точки зрения пользователя это безусловный плюс. И именно поэтому масса каналов изобилует рекламой других каналов и подборками каналов. Просто это чуть ли не единственный способ рассказать о канале новым читателям. Наверняка многие из вас узнали об «Экстраполяции» через рекламу на других каналах.

Хочу попросить вас, мои любимые, рассказать о моем канале вашим друзьям. В телеграме ли, на фейсбуке ли. Может даже при личном контакте. Особенно приятно мне будет, если вы вместе со ссылкой на «Экстраполяцию» опубликуете понравившийся пост у себя на страничке. Увеличим количество

Я уверен, мы можем стать одним из лучших айтишных сообществ рунета. Попробуем?

​​

 Второй выпуск рубрики «Полный Аджайл» с заметками по техпроцессам разработки от читателей. Присылайте ваши мысли и описание ваших техпроцессов мне личным сообщением, ведь такие ценные знания должны быть общим достоянием.

О сторипоинтах

tl;dr: Sp = t • Grade

Сторипоинты это работа в физическом смысле. А умение справится с работой у разработчика — это мощность. Все мы помним из физики, что мощность пропорциональна отношению работы ко времени. Или иначе работа это мощность, умноженная время. Поэтому называть планируемое время работы над задачей можно и нужно. Только после этого нужно только приводить к работе-сторипоинтам правильно, домножая на мощность. Разработчик это в своей голове вряд ли сделает это как нужно.

#полныйаджайл

Друзья, мы совершенно пропустили тот момент, когда нас стало три тысячи. Мне очень приятно, что у нас собралась такое хорошее и активное комьюнити разработчиков. Вы самые лучшие 🎉.

Я знаю, что кнопочки с лайкодизлайками ставят далеко не все, из тех, что читает канал, а не просто на него подписан. У каждого своя причина, но сегодня я хотел бы вас попросить, в порядке исключения все-таки нажать на воздушный шарик (🎈), если вы читаете это сообщение. Нажмите на робота (🤖), если вы не читаете канал, а просто на него подписаны, а на пришельца (👽) не нажимайте вообще, пожалуйста.

Спасибо!

​​

В эфире наша уже постоянная рубрика «Полный Аджайл» с заметками по техпроцессам разработки от читателей.

О мотивации менеджеров и коллективной стратегии

В команде почти всегда есть тот, кто рвётся в менеджеры. Вот на эту здоровую голову можно и переложить со своей здоровой проблемы джиры, мотивируя это каким-то повышением. Как показывает практика, люди готовы ждать этого повышения два-три года, если их периодически хвалить и всячески словесно поощрять. За это время человек может заработать себе новое звание «за выслугу лет» или просто потому, что стал опытнее и круче. Но все это под соусом его управленческих навыков и лидерских качеств.

Если нет такого человека, назначаешь срам-мастером каждого работника по спринту. От него требуешь планирования, оценок и ретроспектив. А дальше - он уже делает все по накатанной. Но команда должна понимать, что в следующем спринте его место займёт кто-то другой. И коллективная стратегия работает лучше индивидуальной. Главное, чтобы она была направлена на тикеты, а не против твоих процессов.

#полныйаджайл

​​Сегодня мы обсудим классическую задачу на понимание ложных убеждений (false belief task).

Ребёнку показывают двух кукол, Салли и Энн; у Салли есть корзинка, а у Энн — коробка. Ребёнок видит, как Салли кладёт свой шарик в корзинку и уходит. Пока Салли нет, озорница Энн перекладывает шарик из корзинки в свою коробку и тоже уходит. Теперь Салли возвращается. Ребёнка спрашивают: «Где Салли будет искать свой шарик»?

Совершенно очевидно, что Салли будет искать шарик в корзине, потому как наблюдателю известно, что Салли не ведает о том, что Энн перепрятала шар. И очевидно это тем, кто наблюдает за наблюдателем и видит, что он видит и какой вопрос ему задают.

Чтобы усложнить пример, можно наблюдателя интегрировать в систему и заставить взаимодействовать с Энн и Салли. Например, выдать несколько коробок и разрешить менять положение шара после Энн так, чтобы и Энн и Салли точно знали где находится шар. Или заменим существительные в этом эксперименте на что-нибудь айтишное.

Например, тестировщица Шьямала нашла в системе баг и хочет рассказать программисту Раджешу и менеджеру Кумару о нем. Молодая и неопытная Шьямала вполне в состоянии сказать «ребята, у вас сайт не работает», более опытная скажет «У вас в профиле пользователя баг» и только матёрая кюэйщица напишет по шагам как воспроизвести этот баг.

Многие могут подумать, что это достаточно очевидно и любая шьямала уже давно не делает глупостей таких вот глупостей. Но достаточно вспомнить случаи, когда хотелось взять в руки сарумановский шар, чтобы понять что же коллега пытается донести, как все становится на свои места. Эксперимент Салли и Энн, к слову, в большинстве своем дети до четырех лет пройти не могут. Пятилетки практически все отвечают правильно.

​​#личностноеразвитие

Про повышения. Большинство наемных сотрудников считает, что руководство его заметит, оценит и повысит зарплату. Это большое заблуждение. Ни один руководитель в здравом уме не будет увеличивать расходную часть, тем самым уменьшая доходную. Если вы встречали компанию в которой происходит периодическая оценка персонала и сама компания инициирует повышения, то это заслуга HR департамента и им удалось "продать" руководству эту необходимость. Например, еще лет 5 назад, в IT был бурный рост ставок и дабы гребец не сбежал, его повышали. С тех пор ставки доросли до своего максимума, рынок немного стабилизировался.

Как же получить повышение? Ответ очевиден и прост, только вот признавать его мало кто желает... Надо показать свою ценность. Больше и усердней работать? Нет. Нужно решать задачи бизнеса. Тут возможны разные сценарии. Можно прийти с анализом, мол, такой-то процесс неэффективен, эта система работает недостаточно быстро, там затраты можно снизить, а тут можно малой кровью сделать продукт лучше. Это, безусловно, лучше чем не делать ничего или ныть о том как все плохо. У этого подхода есть недостаток: то что сотрудник считает важным, может таким не являться для руководителя. При отказе же, сотрудник демотивируется и может впасть в депрессию.

Самый верный вариант - это поговорить с руководителем и выяснить какие задачи стоят перед руководителем, чем можно ему помочь, какие есть финансовые и временные ограничения. Затем стоит тщательно проанализировать полученные данные и идти на повторную встречу с предложениями по решению задач. Помните про ценность? Ценность в том, чтобы предложить наиболее эффективное решение, продумать все до мелочей, быть готовым взяться за реализацию и решить проблему бизнеса. Если решения нет, то лучше прямо об этом сообщить, а не пытаться придумать хоть что-то. Если уже браться, то обязательно доводить до конца, а то второго шанса может и не выпасть.

@noTieinIT

Интересное дело, все вот знают о существовании определений «говнокод» и «костыль». Эти два термина существуют отдельно друг от друга, что не удивительно, ведь означают они разные вещи. Хотя же можно подумать, что говнокод — это набор костылей с примесью ещё чего-то. Но костыль в коде далеко не всегда является говнокодом. И наоборот, далеко не каждый говнокод можно смело классифицировать, как костыль. Очень похоже на то, что нужно срочно устроить ликбез. Я предлагаю основательно разобраться в этом вопросе.

Уверен, что подавляющее большинство подписчиков канала мастерски умеют определять говнокод, особенно чужой, ведь это самый первый навык, которым овладевает разработчик в нашей профессии. Что для вас говнокод? Что такое костыль по вашему мнению? Присылайте личным сообщением мне (@aratak) с пометкой #айтермин ваше определение этих замечательных определений.

Свою версию вместе с вашими присланными можно будет почитать по тегу ближайшие недели.