Рубрика: Разработчикам

Waterfall которого никогда не было

В 1970 году внесение изменений в код занимало 1 день: кодирование алгоритма, нанесение на перфокарту, проверка. А машинное время дорогое, там еще другой математик-алгоритмист хочет провериться, поэтому если ты ошибся -жди один день пока тебе дадут машинное время.

Таком образом весь Agile это про две цели:
– Идеальный мир для Инженера
– Сокращение затрат на поддержку ИТ-продукта.

Читать дальше

Разрабы работают медленно и дорого — и люди считают нас лентяями. Просто в разработке всё сложно

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

Читать дальше

Больше всего меня раздражает в PHP комьюнити

…это то что усредненный пхпист растет в таком порядке:
1. есть сайт, мне надо что-то добавить, изменить. Или сразу: делаю сайт!
2. лезу в код, изучаю попутно на чем он сделан (задаю вопросы уровня: а это WordPress или Laravel?)
3. изучая на чем он сделан, изучаю попутно ООП (если сайт сделан на современном фреймворке)
4. изучая ООП, изучаю попутно PHP

А надо бы – с точностью до наоборот.

Никто не умеет управлять программистами — и все придумывают костыли, вместо решений

Есть компании, где процесс разработки реально работает отлично. Я скажу вам почему — они выиграли в лотерею. У них оказалось намного больше людей, которые хотят работать — с такими, как не управляй, все будет идти хорошо. Даже манагерскую мишуру с бордами они используют для дела, а их перформанс и по джировым, и по интуитивным метрикам ясно виден. И когда их менеджеры-не-разрабы приходят мешать им, у них за спиной стоит шикарный продукт, который даёт им право посылать эти говорящие головы к черту.

Но такая команда — фантастическая удача. А обычно происходит вот что. На десять человек у тебя два, которые хотят работать. Один из них тимлид, а второй увольняется.

Читать дальше

Гугл прислал уведомление

Удалите, заархивируйте или переведите свои неактивные классические сайты на новую версию до ноября 2020 г.

Я и забыл о существовании этого сайта

Пусть войдет в историю, единственный пост на нем.
Для КПК на Windows Mobile
Писал как-то “Официанта”

NET_CFcode

// В CF .NET отсутствуют средства изменения положения SIP клавиатуры.
// Но достать их несложно:
// Управление положением SIP клавиатуры

static public class SIPTools {
#pragma warning disable 0649
static private RECT SIPOrigRect;

struct RECT {
public Int32 left;
public Int32 top;
public Int32 right;
public Int32 bottom;
}

class SIPINFO {
public Int32 cbSize;
public Int32 fdwFlags;
public RECT rcVisibleDesktop;
public RECT rcSipRect;
public Int32 dwImDataSize;
public Int32 pvImData;
public SIPINFO()
{
cbSize = Marshal.SizeOf(typeof(SIPINFO));
}
}

[DllImport("coredll.dll", EntryPoint = "SipGetInfo")] private extern static bool SipGetInfo(SIPINFO ff);
[DllImport("coredll.dll", EntryPoint = "SipSetInfo")] private extern static bool SipSetInfo(SIPINFO ff);

static public void SetLocation(int ScreenX, int ScreenY) {
SIPINFO sipInfo = new SIPINFO();

SipGetInfo(sipInfo);
sipInfo.rcSipRect.top = ScreenY;
sipInfo.rcSipRect.left = ScreenX;
SipSetInfo(sipInfo);
}
// Восстановить стартовое положение
static public void SetOrigLocation() {
SetLocation(SIPOrigRect.left, SIPOrigRect.top);
}
// Сохраняем стартовое положение.
static SIPTools()
{
SIPINFO sipInfo = new SIPINFO();

SipGetInfo(sipInfo);
SIPOrigRect = sipInfo.rcSipRect;
}
#pragma warning restore 0649
}

А вы хороший руководитель?

1. Донесение своих мыслей и слов спокойно.
2. Прозрачное и понятное донесение своих мыслей.
3. Умение давать людям делать свою работу.
4. Умение слушать своих людей.
5. Умение управлять не жестко, а компетентно.
7. Принятие ответственности за результат работы команды.
8. Умение принимать решения и нести за них ответственность.
9. Понимание, что его задача нужна прежде всего ему, а не его подчиненным.

Читать дальше

Что делать, если в вашей команде появился «эффективный» менеджер?

ряд психологических лайфхаков, которые могут помочь сохранить нервы при работе с “эффективным” менеджером:

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

Читать дальше

разрабы и студенты заипали

Не, я все понимаю. Такой рынок. Разработчиков нужно больше, чем их есть. И уже они устраивают собеседования работодателям, а не наоборот. И я дипломатично лавирую между интересами заказчиков и разработчиков. Ибо заказчиков не ебет. Им нужен результат, с качеством и в срок. И их даже близко не ебет, что кто-то там почему-то чего-то не сделал. При этом разработчики тоже жгут: NDA мы подписывать не хотим, эта тематика нам не нравится, тут слишком давят, там слишком не понятны перспективы проекта. Сроки, порой, вообще не про них. Съезжают с темы. И у меня уже голова пухнет. Мне отвечать перед заказчиком, а они сваливают и ищи свищи потом.

Читать дальше

Хорошие программисты пишут код, лучшие — тикеты

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

Читать дальше

8 шишек, которые я набил, управляя удаленной командой

1. Не все слышат / читают то, что я пишу. Многие слышат / читают то, что хотят прочитать
2. Мало кто способен к самоорганизаци
3. Сорок джуниоров не то же самое, что сорок миддлов
4. Отсутствие лояльности
5. Бесконтрольность
6. У всех разная мотивация
7. Работа в разных часовых поясах
8. Невовремя заданные вопросы

Читать дальше

Монолит vs микросервис – эмпирическая диаграмма

Согласен

modules-or-microservices-45-638

Almost all the successful microservice stories have started with a monolith that got too big and was broken up
Almost all the cases where I’ve heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble.
Martin Fowler

Using the microservice architecture makes it much more difficult to iterate rapidly.
A startup should almost certainly begin with a monolithic application.
Chris Richardson

Аджайл – не работает

Аджайл – не работает если:
1. Заказчики не могут по нем работать
2. Программисты не могут по нем работать

А так в большинстве случаев соблюдаются оба условия, то все проще

Аджайл – не работает.

Scrum тоже не работает:

Скрам верит в заказчика, которому не важны сроки и деньги (Черная книга Scrum)

Почему внедрение аgile заканчивается провалом
А у проектных команд падают мотивация и продуктивность

Об авторах: Линдси Макгрегор – соавтор бестселлера Primed to Perform: How to Build the Highest Performing Cultures Through the Science of Total Motivation, CEO и одна из основательниц стартапа Vega Factor, помогающего организациям трансформировать свою культуру. Ранее вела проекты в McKinsey & Company. Нил Доши – соавтор бестселлера Primed to Perform: How to Build the Highest Performing Cultures Through the Science of Total Motivation, один из основателей Vega Factor.

Методы гибкого управления разработкой ПО, такие как agile, применяются давно и в различных формах. В основе большинства подходов лежат две вещи: формирование гипотез (например, чего можно добиться с помощью определенной функции) и совместное участие специалистов различных профилей в экспериментах, в которых они проверяют эти гипотезы и отсекают неверные варианты.

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

– люди и взаимодействие важнее процессов и инструментов;

– работающее ПО важнее исчерпывающей документации;

– сотрудничество с клиентами важнее согласования условий контракта;

– готовность к изменениям важнее следования плану.

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

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

Менеджмент

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

Принцип «готовность к изменениям важнее следования плану» часто ошибочно интерпретируют как «план не нужен». Например, в быстрорастущей технологической компании гибкие проектные команды даже не пытались понять общую стратегию организации. В результате они фокусировались на второстепенных задачах. Без плана команды не смогут определить приоритеты и ответственно инвестировать в них ресурсы. Если бы неправильное применение принципов повышало мотивацию и производительность сотрудников, с этим можно было бы смириться, но на практике мы обнаружили совершенно противоположное – общая мотивация сотрудников падает. Они не могут экспериментировать, управлять собственной работой и общаться с клиентами. По этой причине они не чувствуют интереса, не видят потенциала и цели, а испытывают эмоциональное и финансовое давление или действуют по инерции. Партнер венчурного фонда рассказал, как компания – разработчик видеоигр в течение года занималась игрой, которую все сотрудники считали неудачной. В конце концов все поняли, что напрасно потратили время и деньги.

Адаптивные процессы перестают работать, потому что компании, стремясь к высоким показателям, или начинают слишком много внимания уделять тактике (концентрируются на процедурах и микроменеджменте), или становятся слишком гибкими (избегают долгосрочных целей, планирования и кросс-функционального сотрудничества).

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

1. Разработка должна быть процессом сотрудничества.

Команда должна избегать процесса, когда один человек пишет требования (даже незначительные), а другой реализует их, не имея стратегического ориентира. Менеджер по продуктам и разработчики (и любые другие заинтересованные стороны) становятся партнерами от начала и до конца разработки какой-либо функции продукта.

Сначала команда, включая руководителей, должна сформулировать стратегические задачи в форме вопроса. Эти задачи всегда направлены на улучшение продукта, если смотреть на него глазами клиента. Следует считать их миссией команды. Разработку задач ведет вся команда, включая кураторов проекта (и клиентов). Каждого участника команды просят делиться своими идеями в любой момент.

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

2. Единица производительности команды – минимально жизнеспособный продукт.

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

3. В центре внимания команды должен находиться клиент.

В самом простом случае этот принцип реализуется так:

– задачи всегда должны формулироваться с учетом воздействия полученных результатов на клиента;

– собрания команды всегда должны начинаться с новой информации о клиентах, и на них следует приглашать сотрудников, работающих с клиентами;

– каждый эксперимент строится вокруг гипотезы, в центре которой находится клиент;

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

4. Используйте временные ограничения, чтобы сделать эксперименты более целевыми.

Многие руководители гибких команд не устанавливают дедлайнов для сдачи проектов, опасаясь эмоционального давления. Однако разработчик, который потратил несколько месяцев на создание бесполезного продукта, испытывает тяжелейшее разочарование: «Я всех подвел», «Зачем я этим вообще занимаюсь?». Поэтому следует заранее договориться, насколько далеко может зайти разработчик, проверяя, в правильном ли направлении он движется. Чем выше неуверенность команды в гипотезе и риск, тем короче должен быть этот путь. Ограничения по времени – это не дедлайн для сдачи проекта. Они лишь очерчивают глубину и качество эксперимента. Таким образом, ограничения по времени должны стать мотиватором для команды.
Зачем российским компаниям менять стиль управления
Многие устали от излишней бюрократии и иерархии
Менеджмент

5. Команда должна стремиться к сотрудничеству.

Чтобы члены команды не перекладывали задачи друг на друга, они должны действовать как единая кросс-функциональная команда. Ее цель – сотрудничество. В каждую такую команду должно входить необходимое для создания продукта количество специалистов, в том числе, если необходимо, руководители высшего звена. Например, в одной организации в команду разработки продуктов входит менеджер по продуктам, разработчики, дизайнер, специалист по качеству, представитель отдела по работе с клиентами и топ-менеджер, курирующий проект.

Во многих компаниях кросс-функциональные команды только называются так, а на самом деле действуют иначе. Признаки таких команд:

– эксперты работают не в одной, а в нескольких командах разработки – как «группы ускорения». Это не кросс-функциональная команда;

– команда использует методы, мешающие реальному сотрудничеству. Когда разработчиков из одной команды спросили, почему они выбрали такой-то инструмент agile, они ответили, что «этот инструмент не дает руководству вмешиваться в работу»;

– отделы имеют разные цели. Руководители отделов пользуются своей властью, чтобы заставить подчиненных ставить цели отдела выше всех других целей, в том числе целей кросс-функциональной команды. Эти конфликты мешают настоящей командной работе.

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

6. Команда должна постоянно критически оценивать свою работу.

Аксиома проектирования, известная как закон Конвея, гласит: организация, проектирующая информационную систему, производит продукт, который копирует структуру и связи в самой организации. Если у вас сплоченная организация, вы произведете монолитный продукт. Если компания разобщена, продукт будет таким же. Чтобы преодолеть закон Конвея, нужно сделать структуру команды простой и потом постоянно ее оценивать и настраивать.

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

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


В своей статье на Hacker Noon, John Cutler рассказывает о базовых понятиях, без которых Agile не будет работать.
Вольный перевод Почему «Agile» не работает?.
оригинал (Why Isn’t Agile Working?)

Scrum-мем на злобу дня
хабр Scrum-мем на злобу дня

Как закаляется сталь

И, вот, ты остался один. Тебе не с кем посоветоваться по проблемам, которые тебе волнуют. Нет, конечно, ты можешь о чём-то поговорить с другими одиночками, они даже попробуют тебе чем-то помочь, но по факту – ты один на один с твоей областью проблем.

Читать дальше

Опыт тимлида: 17 советов самому себе на будущее

1. Все начинается с требований
2. Планируй техническую часть
3. Твои планы не высечены в камне
4. Убедись, что все понимают план
5. Минимизируй зависимость от других людей (отделов)
6. Приложи дополнительные усилия, чтобы разделить задачи на части
7. Всегда будь как минимум на шаг впереди
8. Следи за тем, чтобы собрания не уклонялись от темы
9. Командная культура важна, и ты играешь важную роль в ее создании
10. Проводи личные встречи
11. Делегируй полномочия и доверяй людям
12. Будь тем, кто расчищает путь
12+1. Не пытайся геройствовать
13. Сначала слушай других. Свои идеи высказывай в конце
14. Откажись от подхода «Сделаем это позже». Скорее всего, не сделаете.
15. Знай, что нужно тестировать
16. Используй парное программирование как способ распространения знаний
17. Меньше обещай, делай – больше

Читать дальше

20 вещей, которые я вынес за 20 лет в программировании

– Не боритесь с инструментами — библиотеками, языками, платформами — чем бы то ни было. Старайтесь использовать присущие им конструкции
– Вы пишите код не для машин.
– Технический долг как фастфуд: допустим в умеренных количествах, но если войдёт в привычку, не успеете оглянуться, как он убьёт продукт, и это будет больно.
– Хороший код не требует документации, но отличный код задокументирован по определению.
– Никогда не начинайте кодить (разрабатывать какое-то решение), полностью не вникнув в суть задачи.

Читать дальше

Почему шансы на найм у кандидата с 5+ лет опыта ниже, чем 2+?

ПМ, который нанял в команду 10 джунов по 500 баксов, а клиент платит за них по 20 баксов в час — дает компании 80% прибыли! А тот, кто нанял 10 синьоров за 4К баксов и продал клиенту по 50 баксов в час — только 50%

Читать дальше

Программирование — не тяжелый физический труд, но все равно отстой

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

«Шо за нах?» — восклицаете вы и начинаете отлавливать проблему. Выясняется, что однажды один идиот решил, что раз другой идиот решил, что 1/0 равно бесконечности, он может использовать это как условное обозначение для «бесконечности» для упрощения своего кода. Затем не-идиот справедливо решил, что это идиотизм, то, что должен был решить первый идиот, но поскольку он этого не сделал, не-идиот решил стать козлом и сделать это ошибкой компиляции. Затем он решил никому не говорить, что это ошибка, потому что он козел, и теперь все ваши снежинки — моча, а вы даже не можете найти кошку.

Читать дальше