5 советов для команд инженеров в стартапах

Перевод статьи Алекса Исколда “5 Tips for Startup Engineering Teams”.

Спринт это хорошая организация рабочего процесса разработки ПО

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

Создание программного обеспечения это искусство, ремесло, процесс.

Построение и поставка ПО это марафон, который длится весь жизненный цикл компании.

Чтобы эффективно поставлять ПО, вам нужно установить ритм и процедуру. В этом посте мы обсудим легковесный фреймворк и советы, которым могут следовать стартапы, чтобы поставлять программное обеспечение регулярно и эффективно.

1. Внедрение спринтов

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

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

Спринт начинается с планирования того, что нужно построить. Функционал организовывается в два списка: все функции, которые вы хотите реализовать, и те, которые вы хотите реализовать в ходе данного спринта.

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

Как только функции выбраны, они ЗАКРЕПЛЯЮТСЯ за этим спринтом. Вы не можете добавлять новые по ходу спринта.

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

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

Вот примерные установки для вашего спринта:

  • Планирование: за 3 дня до старта.
  • Исправление багов: день 1: среда.
  • Исправление багов: день 2: четверг.
  • Программирование: день 3-7: пятница – четверг, за исключением выходных.
  • Тестирование: день 8: пятница.
  • Тестирование: день 9: понедельник.
  • Поставка: день 10: вторник.

Есть несколько тонкостей при планировании спринта.

Никогда не делайте релиз в продакшн в пятницу или вечером.

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

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

Если у вас двухнедельный спринт, то на написание кода у вас есть 5 дней. Это большое количество времени, если вы разобьете свой функционал на маленькие кусочки. Фактически, данная система склоняет вас к этому. Так вы всегда будете достигать прогресса, улучшать продукт и двигаться вперед.

Последняя часть спринта это тестирование и проверка того, что вы выпускаете качественное ПО.

Последние несколько дней каждого спринта должны напоминать спираль.

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

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

2. Расстановка приоритетов и работа с непредвиденными ситуациями

В дополнение ко внедрению спринтов ваша команда всегда должна расставлять приоритеты фичам и багам.

Когда все важно – ничего не делается.

Создайте простой и понятный язык, который все будут применять, говоря о приоритетах. Например:

  • Р1 – самый высокий приоритет, критическая важность для бизнеса
  • Р2 – средний, должно быть сделано, но не критично
  • Р3 – не важно, просто неплохо бы иметь

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

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

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

3. Парное программирование и тестирование

Разработка Agile имеет набор инструментов и методов, помогающих создавать высококачественное программное обеспечение. Парное программирование и тестирование – мои фавориты.

Парное программирование следует понимать буквально: это когда два программиста работают вместе. Один вводит код, а второй наблюдает.

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

Парное программирование повышает качество кода и способствует установлению прекрасных товарищеских отношений между членами команды. На выходе вы получаете чистый код без багов.

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

Есть два вида очень полезных тестов. Первый набор тестов предназначен для критически важных частей вашего ПО – вещей, которые просто не могут ломаться. Второй набор – для выявления найденных вами багов. Когда вы находите баг, сначала напишите тест, который его будет показывать, а затем исправляйте код. Таким образом вы будете уверены, что если баг повторится, то ваши тесты его выловят.

4. Рефакторинг кода

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

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

Поощряйте инженеров удалять ненужный код и постоянно совершенствуйте ПО, улучшая его.

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

5. Создание счастливой и продуктивной команды инженеров

Отшлифовать вашу команду инженеров довольно просто, большинство стартапов быстро справляются с этим.

Стартапы процветают в хаосе, но хаотичный подход к созданию ПО просто не работает. Это как пытаться бежать спринт в ходе марафона – просто невозможно.

Написание программ это очень творческая и напряженная интеллектуальная деятельность, которой нужно заниматься на свежую голову; она требует ясности и специфического ритма.

Разработка ПО может быть очень благодарным делом или невероятно стрессовым.

Спринты и понятные приоритеты это первый шаг к созданию счастливой и продуктивной инженерной команды.

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


[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]

Оставьте комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Прокрутить вверх