Архивы: Заметки

eao197: Нежданная засада с оценкой затраченного времени

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

Читать дальше
21.02.2022 skynin 0

Работать надо не головой, а компьютером

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

Читать дальше
19.05.2021 skynin 0

Симптоми стресу

Як мінімізувати стрес під час віддаленої роботи

Окрім вищезгаданих проявів, що характерні для вигорання, є низка ознак і поведінкових патернів, які можуть свідчити про високий рівень хронічного стресу.

Емоційні ознаки:

  • підвищена дратівливість або спалахи гніву;
  • уникання контакту з іншими людьми;
  • надмірне занепокоєння або почуття смутку чи відчаю.

Фізіологічні ознаки:

  • почуття втоми або пригніченості;
  • головні болі, болі в животі або запаморочення;
  • погіршення якості сну, безсоння.

Когнітивні ознаки:

  • проблеми з концентрацією та погіршення функцій пам’яті;
  • почуття невпевненості, тривоги або роздратування;
  • стрибки ідей — надзвичайне прискорення та обривистість думок.

Поведінкові ознаки:

  • підвищене споживання алкоголю та тютюну, зміна апетиту;
  • постійне занепокоєння тим, чи достатньо ви працюєте, чи робите забагато або замало для вашої команди;
  • пасивність, прокрастинація, уникнення відповідальності.
09.03.2021 skynin 0

Как PHP превращается в Java/C#

что было добавлено
(на подходе дженерики, асинхронщина аля Node.js и JIT компиляция)

Hack, PHP-подобный язык программирования общего назначения со статической типизацией, не стал популярным, несмотря на авторов: Facebook

PHP 8

Добавлена поддержка атрибутов (аннотаций)

Добавлена поддержка типов union
public function setNumber(int|float $number): void

Добавлены WeakMap
С WeakMaps ссылки на объекты автоматически собираются сборщиком мусора, когда объект становится недоступен.
$this->cache = new WeakMap();
…
return $this->cache[$obj] ??= $this->computeSomethingExpensive($obj);

Новое исключение ValueError

При определении функций можно использовать вариативный аргумент
public function method(int $many, string $parameters, $here)
extends A {
public function method(…$everything) {

Возвращаемый тип static
public function doWhatever(): static {
return $this;
}

Литерал имени класса для объекта
Теперь можно извлекать имя класса объекта с помощью $object::class. Результат будет такой же, как в случае с get_class($object).

Настройки синтаксиса переменных
New и instanceof теперь можно использовать с произвольными выражениями: new (выражение)(…$args) и $obj instanceof (выражение).
$class = new (collect([‘Foo’, ‘Bar’])->random());

Интерфейс Stringable
В PHP 8 появился новый интерфейс Stringable, который добавляется автоматически, как только класс реализует метод __toString

Трейты могут определять абстрактные приватные методы
trait MyTrait {
abstract private function neededByTheTrait(): string;

throw можно использовать как выражение
Выражение throw теперь можно использовать там, где допускаются только выражения: в стрелочных функциях, coalesce-операторах тернарных условных операторах (ternary/elvis).
$callable = fn() => throw new Exception();
$value = $nullableValue ?? throw new \InvalidArgumentException();

В параметрах списка допускается опциональная висящая запятая
function method_with_many_arguments($a, $b, $c, $d, )
method_with_many_arguments(1, 2, 3, 4,);

Обработка исключений без сохранения в переменной
} catch (\InvalidArgumentException) {

Добавлена поддержка типа mixed
В PHP 8 появился новый тип mixed. Он может быть эквивалентен типам array, bool, callable, int, float, null, object, resource, string.

Добавлена поддержка продвижения свойств конструктора
public function __construct(
public int $id,
public string $name,
) {}

Добавлена поддержка выражения match
Предложено добавить новое выражение match, которое аналогично switch, только с более безопасной семантикой и возможностью возвращать значения.

Добавлена поддержка оператора nullsafe (?->)
$country = $user?->getAddress()?->country?->iso_code;

Добавлена поддержка именованных аргументов
array_fill(start_index: 0, num: 100, value: 50);
https://habr.com/ru/company/mailru/blog/525614/

PHP 7.3

Добавлен новый оператор объединения с null

Объявления скалярных типов

Объявления типов возвращаемых значений

Интерфейс Throwable

Обнуляемые типы

Ничего не возвращающие функции

Синтаксис квадратных скобок для деструктуририрующего присваивания в массиве

Видимость констант класса

PHP 7.2

Новый тип object
function test(object $obj) : object

Разрешено переопределение абстрактных методов
abstract function test(string $s);
extends A
{
abstract function test($s) : int;

Sodium теперь является основным модулем
Добавлено хеширование пароля с помощью Argon2

PHP 7.1

Обнуляемые типы
function answer(): ?int

Ничего не возвращающие функции
function shouldreturnnothing(): void

Псевдотип Iterable

Closure из callable
public static function fromCallable(callable $callable) : Closure

Синтаксис квадратных скобок для деструктуририрующего присваивания в массиве
[$a, $b, $c] = $array;
[“a” => $a, “b” => $b, “c” => $c] = $array;

Видимость констант класса

Перехват нескольких типов исключений

PHP 7.0
Повышение производительности
PHP 7 почти вдвое быстрее, чем PHP 5.6.

Значительное сокращение использования памяти
PHP 7.0 стал громадным шагом вперед с точки зрения производительности и использования памяти. Для страницы с запросами к базе данных версия 7.0.0 более чем в 3 раза быстрее, чем 5.6 с включенным opcache в 2.7 раза быстрее без opcache! С точки зрения использования памяти разница тоже существенная!
https://habr.com/ru/company/otus/blog/524270/

Интерфейс Throwable

Поддержка анонимных классов

Добавлен новый оператор объединения с null – «??»
$x[“a”] ?? $x[“b”] ?? $x[“c”]

Добавлен новый оператор – spaceship (космический корабль) (<=>)
return $a <=> $b; // return ($a < $b) ? -1 : (($a > $b) ? 1 : 0);

Объявления скалярных типов
add(float $a, float $b): float

Объявления типов возвращаемых значений
Добавлена ​​возможность возвращать типы помимо скалярных – классы, включая наследование

Групповые объявления use

Делегация генератора
В теле функций генераторов разрешен следующий новый синтаксис
yield from

Синтаксис кодирования Unicode — “\u{xxxxx}”

Чувствительный к контексту лексер
С этим нововведением глобально зарезервированные слова стали полу-зарезервированными

Выражения return в генераторах

Единый синтаксис переменных https://wiki.php.net/rfc/uniform_variable_syntax

30.10.2020 skynin 0

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

Аджайл – не работает если:
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-мем на злобу дня

24.03.2020 skynin 0

Тимлид – это сержант

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

Читать дальше
03.12.2019 skynin 0

Немного рефлексии на тему неспособности работать в больших компаниях

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

Читать дальше
17.09.2019 skynin 0