Как стать автором
Обновить
311.14

Управление проектами *

Как заставить всё работать

Сначала показывать
Период
Уровень сложности

Как прогнозировать время выполнения задач

Уровень сложностиСложный
Время на прочтение20 мин
Количество просмотров35K

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

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

Читать далее
Всего голосов 63: ↑61 и ↓2+66
Комментарии57

Новости

Что такое GitOps и почему он (почти) бесполезен

Уровень сложностиСложный
Время на прочтение9 мин
Количество просмотров17K

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

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

Одна из свежих популярных тенденций — это концепция GitOps, которая была представлена в 2017 году на ставшем уже легендарным «Кубконе» Алексисом Ричардсоном — СЕО компании Weaveworks.

Weaveworks — это большая взрослая компания, которая в 2020 году привлекла больше 36 миллионов инвестиций под развитие своего GitOps.

Сейчас я попробую рассказать о тех неочевидных проблемах, которые могут вас ждать при принятии этой концепции. Если коротко, то GitOps не является «Серебряной пулей». Вполне вероятно, что спустя какое-то время вы закончите реорганизацию с ворохом велосипедов и костылей, которыми очень сложно управлять. Мы сами изрядно походили по этим граблям и хотим показать наиболее неприятные проблемы, которые не видны при чтении красивых статей.
Читать дальше →
Всего голосов 43: ↑35 и ↓8+35
Комментарии55

Что такое GitOps и почему он (почти) бесполезен. Часть 2

Уровень сложностиСложный
Время на прочтение13 мин
Количество просмотров8.4K

Одной каноничной синей изоленты может не хватить

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

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

Какие ещё потенциальные сложности могут встретить вас при следовании пути GitOps и какие могут быть альтернативы? Давайте разберёмся вместе.
Читать дальше →
Всего голосов 28: ↑26 и ↓2+34
Комментарии140

Проектируйте правильно

Уровень сложностиСложный
Время на прочтение11 мин
Количество просмотров18K

Проект это сложная история. Обычно это относительно сложное и длительное мероприятие, создать программный продукт и провести его через стадию активной разработки до первой реальной коммерческой эксплуатации. Лично я видел как этот путь, в среднем, занимал от 2 до 5 лет на проекте с большой командой разработчиков.

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

Под катом наблюдения и личные выводы почему это происходит.

Читать далее
Всего голосов 22: ↑20 и ↓2+26
Комментарии5

Истории

Как я делал внутренний cookbook по тому, как писать код (и результат можно скачать)

Уровень сложностиСложный
Время на прочтение16 мин
Количество просмотров16K

Авокадо с зубами подсказывает, что так код легче поддерживать, дописывать и рефакторить. Мы всё теперь пишем только так.

Привет, Хабр! У нас была проблема: каждый писал код как хотел. Было очень тяжело это поддерживать и ревьюить. Мы сначала думали, что достаточно написать стандарт кода. Оказалось, недостаточно, ему ещё надо обучить. Чтобы обучить, мы открыли для ревью эталоны кода, чтобы покрыть ими самую частую логику взаимодействия с компонентами. Тоже не хватило. А заодно я узнал, что мои же «золотые» образцы противоречили моему же стандарту кода (сначала было смешно, а потом пришлось переписывать).

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

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

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

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

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

Посвящается всем, кто коллекционирует элегантные решения без привязки к языку, фрэймворку, Фаундлингам и Software Craftsmanʼам.

Погнали.
Читать дальше →
Всего голосов 19: ↑18 и ↓1+19
Комментарии4

От идеи к развертыванию: искусство современной разработки программного обеспечения

Уровень сложностиСложный
Время на прочтение19 мин
Количество просмотров4.3K

Только мировые Best-Practice's. Примеры.

Делюсь опытом о процессе разработки программного обеспечения используя Agile, начиная со сбора требований и заканчивая развертыванием.

Читать далее
Всего голосов 2: ↑1 и ↓1+2
Комментарии6

Путеводитель по оценкам задач и котики

Уровень сложностиСложный
Время на прочтение11 мин
Количество просмотров11K

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

Читать далее
Всего голосов 16: ↑9 и ↓7+2
Комментарии24

Вклад авторов

Работа