Несколько месяцев назад на работе у одного из моих коллег была отличная идея создать инженерный книжный клуб. Я буду честен и признаю, что в то время я никогда не читал ни одной книги о технике или программировании. Конечно, я много читал о предмете, но не совсем в форме книги. Я ошибочно предположил, что более постоянный характер книг сделал информацию внутри быстро устаревшей в постоянно меняющемся ландшафте разработки программного обеспечения.
Хотя обе эти вещи верны, книги являются постоянными, и развитие программного обеспечения быстро изменяется, знания, которые записаны в книги, — это не те знания, которые быстро выходят из моды. Более длинный формат книг делает их великолепными для распространения теорий, принципов и идей. Идеи о человеческой природе, о том, как люди работают вместе, принятие решений, общение, лидерство … все они так же актуальны для разработки программного обеспечения, как и для любой другой области.
Вернувшись на работу, книжный клуб начинает И я думаю, что это звучит как отличная идея, поэтому я регистрируюсь. Первая книга «Проект Феникса» Анкет
К сожалению для меня, когда дело дошло до «чтения назначенной книги по определенной сроке срока», я быстро попал в старую привычку колледжа откладывать ее до прошлой ночи, а затем попытался просмотреть ее в надежде получить достаточно полезной информации, чтобы получить A короткий разговор об этом.
Конечно, это действительно не сработало, и когда пришло время для встречи книжного клуба на следующий день, я только что пропустил ее. А потом я пропустил остальные встречи, потому что я уже был позади, за пенни за фунт и все такое.
После того, как клуб был закончен с этой книгой и выбрал другую, я сожалел о том, что он не серьезно участвовал, и решил сделать ее лучше на этот раз. Следующая книга, которую мы проголосовали за прочитание, была «Справочник DevOps» (Очевидно, мы действительно хотим узнать о DevOps). Это продолжение «Проекта Феникса», и, поскольку я теперь полностью преданный, я должен вернуться назад и выпить первую книгу, прежде чем я смогу начать вторую … так что я это делаю.
Вот мои выводы из «Проекта Феникса».
Результаты — это то, что имеет значение
«Помните, что результаты — это то, что имеет значение, а не процесс, а не элементы управления, или, в этом отношении, какую работу вы выполняете. » 1
Исходя из книги, которая много говорит о процессах, я чувствую, что это большое утверждение. Но это напоминание о том, что процессы полезны только в том случае, если они создают хорошие результаты, которые еще больше достигают целей компании.
Некоторые общие процессы команды Dev и инженерные организации включают в себя:
- Методология работы (Scrum vs Kanban)
- Создание/уход за проектом (собрания Discovery, создание билетов, уход за отставанием)
- Изменение/создание билетов и приоритетов.
Эти процессы важны, и это здорово оптимизировать их для того, что лучше всего работает с организацией, но акцент всегда должен быть на достижении цели компании. Надеемся, что может быть следом хлебной крошки, чтобы следовать непосредственно от процесса до достижения цели.
«Помните, это выходит за рамки уменьшения WIP. Возможность взять безумную работу из системы важнее, чем способность вкладывать больше работы в систему. Для этого вам нужно знать, что имеет значение для достижения бизнес -целей, будь то проекты, операции, стратегия, соблюдение законов и положений, безопасности или чего -то еще ». 2
Эта цитата просто восстанавливает важность достижения бизнес -целей. Мне понравились аналогии между полом растения, упомянутым в книге, заводской MRP-8 и организацией IT/DEV. Бизнес -цели сравниваются с вывозом готовой продукции с завода. Если бизнес никогда не достигает своих целей, то это так, как будто фабрика никогда не отправляет готовый продукт, и все, что вам остается, — это несчастный клиент, который хочет вернуть свои деньги.
Каждому нужно время.
«… всем нужно простоя или провести время. Если никого не хватает времени, WIP застрял в системе. Или, точнее, застрял в очереди, просто ожидая. » 3
Слабые время важно по многим причинам … сокращение когнитивной перегрузки, предотвращение выгорания и облегчение баланса работы/жизни. Эта цитата помогает подключить время для достижения целей компании.
Личный пример этого для меня — когда моя команда разработчиков смотрит на нашу скорость спринта. Скорость спринта — это измерение того, сколько работы мы смогли выполнить с увеличением двухнедельного. До начала двух недель мы все согласны с суммой, определенным числом работы. Мы всегда сравниваем этот объем работы с нашими предыдущими спринтами (2 -недельные приращения) и стараемся судить, является ли это соответствующей суммой или нет.
Допустим, мы обычно выполняем 40 очков в спринте. Когда мы согласны с тем, сколько работы мы хотим взять на себя в нашем предстоящем спринте, мы учитываем знания, что мы в среднем 40 очков и что нам также нужно слабые время. В этом случае мы, вероятно, согласились только на 32 балла работы. Это позволяет нам иметь некоторое встроенное время и пространство, потому что иногда работа не так гладко, как вы ожидаете.
Иногда, по разным причинам, мы решили согласиться на ровно 40 очков работы на предстоящий спринт, и в каждом случае я могу думать, что это обычно не оказалось, как мы надеялись. Мы изо всех сил пытаемся достичь этой цели в 40 очков, работа не выполняется вовремя, и все продолжает повлиять на время будущих проектов.
Слабые время важно.
Постоянно сосредотачиваться на обучении и улучшении
«Улучшение ежедневной работы даже важнее, чем ежедневная работа». Третий способ — это обеспечение постоянного напряжения в системе, чтобы мы постоянно усиливали привычки и улучшаем что -то. 4
Это мой любимый вывод из книги, который очень важен для меня. Рост является основной ценностью в моей жизни, и это то, что постоянно находится на переднем крае моего ума.
Что касается книги и команды разработчиков, этот рост может выглядеть как многое. Команда может на самом деле изучать новые вещи, такие как использовать новый инструмент, язык программирования или как работает определенная функция продукта.
Это также может выглядеть как небольшие изменения в процессах, общении или рабочих процессах, которые делают команды и отдельных лиц немного более эффективными, чем раньше.
Ключевая концепция заключается в том, что команда всегда итерации в себе и своих идеях, поэтому они стараются постоянно улучшаться, даже если это просто крошечное количество. Как говорится, если вы не двигаетесь вперед, тогда вы движетесь назад. Это мышление роста происходит не только естественным образом, его необходимо преднамеренно воспитывать.
В целом, я обнаружил, что эта книга является легкой чтением и хорошей историей о достоинствах гибких практик и о том, как лучше работать как команда и компания. Будучи уже знакомым с Agile и некоторыми из ловушек, с которыми может столкнуться ИТ -отдел, он стал очень предсказуемым и повторяющимся в точках. Но я думаю, что это было интересное чтение, тем не менее.
——
Ким, Джин. Проект Феникса (стр. 212). Это революция пресса. Kindle Edition. ↩
Ким, Джин. Проект Феникса (стр. 212). Это революция пресса. Kindle Edition. ↩
Ким, Джин. Проект Феникса (стр. 304). Это революция пресса. Kindle Edition. ↩
Ким, Джин. Проект Феникса (стр. 273). Это революция пресса. Kindle Edition. ↩
Оригинал: «https://dev.to/collinmesser/3-takeaways-from-the-phoenix-project-59ln»