Рубрика «управление разработкой» - 91

В связи с тем, что относительно большая (и очень громкая) часть IT живёт в очередном пузыре доткомов (теперь уже стартапов), у некоторых представителей этого племени, а в особенности у всяких евангелистов и даже HR появилась иллюзия следующего свойства.

Мол, какой-то девайс, фреймворк или способ работы резко поднимает успешность предприятия. Например, «мы все используем MacBook, и у нас уже третий раунд инвестиций». Или «мы решили открыть travel-агентство, и нанимаем только тех программистов, которые не вылезают из путешествий; мы хотим, чтобы все сотрудники разделяли наши ценности, и у нас уже оборот 100 млн долларов». Или «как только мы внедрили React + Vue + Angular, наши дела пошли в гору, и нас купил Google». И так далее.

На первый взгляд кажется абсурдом? — Да, но признаем: хайп и гвалт есть несомненные сопутствующие элементы современного IT-мира. Любое явление, находящееся на острие общественного внимания, а IT, безусловно, из таких, не может не впитать в себя характерные черты социума своего времени. В частности, тенденцию к превалированию формы над содержанием.

image
Читать полностью »

Несколько лет назад примерно с такой фразой ко мне пришел один из ведущих программистов. Давайте назовем его Иваном (все персонажи вымышленные, а любые совпадения случайны). Он собирался переехать жить за город и каждый день ездить в офис ему стало неудобно. У Ивана был приличный послужной список, несколько лет работы в компании и большой вагон доверия. Тогда мы договорились, что Иван будет работать удаленно понедельник и пятницу, а вторник-четверг он приезжает в офис с утренним графиком.
Читать полностью »

Добрый день, уважаемые читатели. Ранее я рассказывал, что основная деятельность Банка в части ИТ процессов, была организована на ITIL. Исключением стал только процесс управления изменениями. Вторая (и заключительная) часть посвящена внедрению элементов гибких методологий в Банке в процессах управления изменениями в ИТ.

Описание проблемы

Я столкнулся со следующими проблемами при анализе существовавшего процесса:

• 80% задач поступает ad hoc
• приоритеты задач постоянно меняются
• нет возможности осуществлять планирование работ
• отсутствует гармоничность в развитии систем
• нет «установленных правил игры» при реализации изменений

image
Читать полностью »

Избегайте этой ловушки, не следует придавать антропоморфные черты Ларри Эллисону.
Брайэн Кантрилл

Похоже, что в Oracle приняли решение окончательно избавиться от трудовых ресурсов, составляющих костяк Sun Microsystems. Массовые увольнения затронули около 2500 сотрудников, работающих над операционной системой Solaris, платформой SPARC и системами хранения данных ZFS Storage Appliance.

Oracle фактически ликвидирует Sun - 1

Это не рядовая трансформация — оптимизация, а настоящая бойня. По мнению создателя системы динамической отладки Dtrace Брайэна Кантрилла (Bryan Cantrill) на сей раз нанесен непоправимый ущерб, в результате потери 90% производственных кадров подразделения Solaris, включая все руководство.

Читать полностью »

  1. Менеджмент некой компании уделяет большое внимание мотивации сотрудников.
  2. Для поощрения высоких результатов было решено выдавать премии командам по результатам соблюдения сроков и бюджетов проектов.
  3. Решение было доведено до сотрудников.
  4. Одна из команд занималась доработками зрелого и стабильного проекта, успешно выполнила все условия, получила премию.
  5. Другой команде достался новый сложный проект, люди работали над ним с неподдельным энтузиазмом.
  6. К сожалению, и запланированные сроки, и бюджет оказались превышены в разы.
  7. Получившийся в результате продукт дал компании рекордную прибыль.

Читать полностью »

«Почему ж всё так плохо?» — каждый раз я задаюсь этим вопросом, когда приходится иметь дело с очередным кодом, продуктом или API, созданными для внутренних нужд в непрофильной организации.

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

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

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

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

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

Читать полностью »

Продолжение статьи, где мы рассказываем об этапах процесса разработки портала на примере одного из наших заказчиков.

image
Читать полностью »

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

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

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

Что удалось получить в результате:

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

Давайте расскажу, как мы этого добились.

Ланнистеры всегда платят свои долги! (и технические тоже) - 1

Читать полностью »

image Ивар Якобсон, почти легенда — основоположник UML, RUP, SEMAT — неугомонен, продолжает попытки навести порядок в индустрии разработки ПО. И на вопрос: «Что помогает оставаться таким активным» отвечает: «Having fun!» :)Читать полностью »

Деловая игра Kanban-пицца в офисе Туту.ру - 1

Приглашаем всех желающих 14 сентября поучаствовать в деловой игре под названием Kanban-пицца! Мы в игровой форме расскажем о принципах и правилах Kanban, обсудим аспекты применения методологии и ее преимущества для ИТ-отрасли, а также поделимся опытом реального построения процессов.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js