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

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

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

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

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

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

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

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

Бизнес в России учится делать не только скучные проекты по автоматизации бизнес-процессов, но и создавать IT-решения, способные помочь в борьбе с конкурентами. Например, проекты по предсказанию спроса, real-time offer management, оптимизации логистики, микротаргетированию. Такие сложные задачи отличаются от типовых внедрений CRM или выбора CMS. Надо иначе искать разработчиков, иначе мотивировать, думать об IT-архитектуре и методологии управления.

Шпаргалка — навигация по темам, которые стоит знать руководителю компании и топ-менеджеру, чтобы грамотно реализовать IT-проекты нового уровня сложности. По каждой теме будет много ссылок на статьи, интервью, обзоры и видео.

За свои 12 лет работы в сфере разработки ПО, мне посчастливилось поработать в команде только два раза. Хотя я сменил порядка десяти мест работы. Но попробовав раз, ем и сейчас… Т.к. я не жадный, и готов своими достижениями делиться с сообществом, то решил я предпринять попытку вывести из равновесия неумных руководителей, которые до сих пор не осознали важность команды, а также тех руководителей, которые профессионально занимаются самообманом — мол, они строят команду, а на деле — тьфу, а не команда.

Вступление

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

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

Это последняя статья из моего цикла. В ней будет много о менеджерской и организационной сторонах разработки.

При старте проекта многие задаются вопросом «Где вести тестовую документацию?».
В этой статье мне хотелось бы рассказать вам об инструменте Test Management for JIRA (в данном случае плагин рассматривается как инструмент) для того, чтобы удобно, эффективно и качественно составлять и управлять тест дизайном проекта.

Почему нам стоит обратить внимание к этому инструменту? Потому что он:

— Удобно устанавливается, поддерживается
Установка происходит через раздел управление плагинами в JIRA

— Есть связь с JIRA
Да, поначалу этим не удивишь, но фишка в том, что он идет как плагин к JIRA и не нужно отдельно интегрироваться с другими инструментами тест менеджмента.

Как это улучшит мою работу?

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

Это не только улучшит вашу работу, но и ускорит ее.

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

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

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

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

Одной из основных отличительных черт являются принципы внедрения Канбана: «Начните с того, что имеете, визуализируйте процесс, договоритесь об эволюционном изменении процессов».

Заметьте, что речь идет не о том, чтобы громогласно объявить о внедрении Канбана, а лишь о том, чтобы эволюционно менять процессы в сторону улучшения. Наверное, вы подумали: «Звучит не страшно. Кто же от такого откажется?». И тем не менее, добиться заметных результатов с точки зрения бизнеса без серьезных изменений не выйдет.

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

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

Выгоды внедрения

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

Однажды техдепу в HeadHunter сделали толстовки с принтом на спине «hh и в продакшн». Вроде бы и забавно, но меня всё время смущала эта надпись, т.к. в оригинале это не то, чем стоит гордиться. Это натолкнуло меня написать пост, что же на самом деле означают буквы hh.

Я хочу рассказать о том, как рождается фича в HeadHunter на примере команды API, в которой я тружусь. Какой путь ей предстоит пройти от идеи до выхода в продакшн. Затрону как технические, так и менеджерские аспекты.

Ниже представлен перевод руководства Google re:Work — Guide: Set goals with OKRs. Я решил не писать с нуля еще один общий обзор по OKR, а просто перевести это, на данный момент, наиболее авторитетное руководство по OKR, и дополнить его ссылками и своими материалами по OKR, которые включают в себя несколько конспектов приложенного видео Google Ventures на русском языке.

Дополнение: В ноябре 2017 года Рик Клау написал серию твитов, где существенно поправляет некоторые моменты из своей презентации 2012 года, видео которой представлено ниже: Google OKR Video пять лет спустя — обзор опыта Google Ventures по внедрению OKR (2012-2017)

Введение

Исследования показали, что приверженность цели помогает повысить производительность труда. Если посмотреть более глубоко, исследования обнаруживают, что постановка вызывающих и четко определенных целей может еще более повысить вовлеченность сотрудников в достижении этих целей. Google часто использует “цели и ключевые результаты” –  “Objectives and Key Results” (OKRs), стараясь поставить амбициозные цели и отследить продвижение к ним.

OKR – краткий обзор

• Цели амбициозны и могут ощущаться несколько некомфортными
• Ключевые результаты измеримы и должны быть легко оцениваемы числом (Google использует шкалу от 0 до 1.0)
• OKR являются общедоступными, так, что каждый внутри организации может видеть, над чем работают другие
• “Попаданием в яблочко” для предварительной оценки OKR является достижениие 60-70% от нее. Если кто-то раз за разом полностью достигает своих целей, значит их OKR недостаточно амбициозны, и им нужно думать более масштабно.
• Низкие оценки следует рассматривать как данные для уточнения дальнейших OKR.
• OKR не являются синонимом оценки сотрудников.
• OKR не являются коллективным списком следующих дел.

Негибкий “Энтерпрайз” и гибкие методологии

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

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



Я расскажу, как у нас в Лаборатории выстраиваются процессы работы. Мы опираемся на концепцию Agile. В качестве основного фреймворка мы выбрали Scrum, модель производства — командно-центричная.

Управление проектом в любой сфере предполагает наличие дедлайнов. Есть главный, венчающий собой всю работу и говорящий о его завершенности/незавершенности. Как правило, планы включают в себя и другие дедлайны для этапов поменьше.

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

1. Что такое качество в разработке ПО?
2. Во сколько нам обходится некачественное ПО?
3. Кто отвечает за качество?

Для меня поводом задаться этими вопросами стала встреча с компанией в которой 3 месяца в году всё подразделение разработки (около сотни человек), занято устранением ошибок и дефектов, а остальные 9 месяцев они пишут ошибки софт для Заказчиков.

Ниже результаты моих теоретических и практических исследований в поисках ответов. Постарался изложить их просто, без «мозговзрыва» присущего этой теме.

Данный материал — перевод статьи за авторством Matthew Heusser, Managing Consultant в Excelon Developmen. Редактура — Ирина Махмутова.

Почему руководство не принимает agile и что вы можете с этим сделать

Первый в моей практике переход в agile имел полную поддержку высшего руководства компании. Топ менеджмент обеспечил финансирование всех необходимых тренингов, инструментов и консалтинга.

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

Наши топы часто тратят уйму времени и денег на agile, но при этом дискредитируют инициативы, которые продвигают. Это не просто частая проблема; это практически всеобщая проблема, а всеобщие проблемы склонны иметь системные причины.

Я приведу пять самых распространенных причин, почему топы не получают agile — и что с этим делать.

Enterprise Agile: Поторопитесь ускориться быстрее

В следующие несколько абзацев хочу поделиться не так давно случившимся у меня опытом проведения ретроспективы по методу шести шляп. Метод шести шляп (англ. Six Thinking Hats) — метод организации мышления, помогает взглянуть на проблему с разных сторон, а также одна из разновидностей мозгового штурма при работе в команде.

Интересно будет тем, кто ищет новые способы проведения ретроспектив, кто интересуется командной работой, подходами к принятию решений и генерации идей.

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

Привет, Хабр! Сегодня мы расскажем о том, как разные команды в JetBrains “готовят” Agile и работают с Agile досками.

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

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