...

Getting Real

Getting Real (GR) — это методология, разработанная специально для стартапов и начинающих команд. GR предполагает максимальное использование особенностей небольших проектов и компаний — мобильности, гибкости, стремления к поиску новых решений и оптимизации, отсутствия бюрократии и жесткой запутанной иерархии.

Эту методологию использовали основатели компании 37signals (теперь — Basecamp, компания-разработчик ПО и создатель одноименного инструмента управления проектами) Джейсон Фрид и Давид Ханссон. В их интерпретации Getting Real — это максимально простая, понятная и функциональная система для решения реальных задач.

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

Вот некоторые принципы работы по GR:

1. Делайте меньше, чем конкуренты.

Если у вашего продукта-конкурента есть 1000 функций, сделайте 50, но ими решите главные проблемы пользователей. Это позволить сэкономить в ресурсах и привлечь клиентов простотой. Остальной функционал можно сделать позже.

2. Финансируйте свой проект сами.

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

3. Придерживайтесь ограничений, работая в условиях FFF: fix time, fix budget, flex scope.

Зафиксируйте два из параметров, а третий сделайте гибким — так, в 37signals сделали открытым скоуп, зафиксировав время и бюджет. Если с каким-то объемом работ вы не справляетесь, подумайте, настолько ли важна для продукта задуманная функция и если да, то как можно оптимизировать ее разработку.

4. Придумайте/найдите себе врага.

Когда 37signals работали над Basecamp, в качестве “врага” был выбран MS Project. Команда проекта постаралась сделать меньше функций, оставив лишь самые необходимые — но воплотила их таким образом, что продукт стал более удобным для пользователей, чем MS Project.

5. Оставайтесь маленькими.

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

...

Методологии Crystal

Crystal — малоизвестное в нашем регионе семейство гибких методологий. Автор методологий Crystal — Алистер Кокберн, один из авторов “Манифеста гибкой разработки ПО”. В рамках подхода Crystal акцент делается на результат, а не на сам процесс. Главное — достижение требуемых характеристик, а не следование процедурам. Приоритеты в Crystal — безопасность и эффективность разработки.

Выбор конкретной методологии Crystal определяется количеством человек в команде и описывается названием цветов. Если в команде от 2 до 8 человек, то вам подойдет методология Crystal Clear, если от 10 до 20 человек — Yellow, если в команде от 20 до 50 человек — Orange, если на проекте до 100 человек — Crystal Red. Под более масштабные проекты идут методологии Crystal Maroon, Crystal Blue, Crystal Violet.

Что общего во всех методологиях Crystal? Все проекты, которые разрабатываются с учетом этого подхода соответствуют трем показателям:

1) Быстрая доставка рабочего кода, что достигается через короткие итерации;

2) Совершенство через рефлексию — новая версия ПО улучшается на основе данных о предыдущей;

3) Хорошая коммуникация в рамках команды.

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

У Crystal есть свои стратегии. Вот некоторые из них:

Исследование на 360°. В начале работы над идеей команда рассматривает проект в следующих направлениях: бизнес-ценность, требования, требуемые технологии, план проекта, состав команды, выбранные методологии. Это помогает понять, насколько полезен продукт, насколько продумана его идея и можно ли его создавать с имеющимися ресурсами и технологиями.

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

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

...

Feature-driven development

Feature-driven development (FDD) — это разработка, управляемая функциональностью. Суть ее в том, что работа над проектом делится на короткие итерации, по итогам каждой к продукту добавляется новая “фича” — полезная возможность, функция.

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

Сама модель сформировалась в 1997. Ее предложил Джефф де Лука, когда искал оптимальную методологию для разработки ПО для банка в Сингапуре. Тогда он и разработал прообраз FDD, состоящий из пяти процессов:

1. Разработка общей модели — команда предлагает несколько моделей решения задачи, а затем выбирает самую оптимальную оптимальную;

2. Создание списка полезных функций;

3. Планирование и анализ рисков;

4. Дизайн и разработка;

5. Реализация.

Методология FDD идеальна для долгосрочных проектов.

...

Test-driven development

Test driven development (TDD), или разработка через тестирование, основывается на повторении коротких циклов разработки. Сначала пишется тест и только затем — код, после идет рефакторинг с постоянной проверкой прохождения всех тестов.

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

Цикл разработки по TDD:

1. Создать тест для новой, еще не реализованной функциональности

2. Запустить все тесты и убедиться, что новый тест не проходит

3. Написать код, который обеспечит прохождение теста

4. Запустить тесты

5. Провести рефакторинг

Плюсы методологии:

• Хорошая архитектура разрабатываемых приложений

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

• Разработчики не боятся вносить изменения в код, т.к. в случае ошибки об этом сообщат результаты тестирования

...

Behavior-driven development, дословно «разработка через поведение»

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

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

...

LeSS

Large-Scale Scrum (LeSS, или “Крупномасштабный Скрам”) — это набор принципов и правил, выведенный из методологии Scrum, для повышения гибкости организации через упрощение ее оргструктуры. Простыми словами, это когда по скраму работают не только разработчики, но и вся компания.

Принципы методологии:

Scaled Scrum is Scrum: скрам на уровне организации — это все тот же скрам, а не надстройка над скрамом, по которому работает одна из команд.

Whole Product Focus — фокус на всем продукте, не на его частях. Вся организация работает над одним продуктом, таким образом, все сотрудники координируются и кооперируются.

Lean Thinking — в LeSS очень много от бережливого производства (Lean в Toyota). Это значит, что вы работаете по принципу постоянного улучшения. Внедрение новой функции не заканчивается, когда функция разработана и включена в проект. С каждой итерацией она будет дорабатываться и совершенствоваться. В LeSS изменения — это постоянное явление, норма, по которой работает организация. Процессы улучшения, экспериментов и обучения идут постоянно.

Методология родилась в 2005 году, когда Крэг Ларман и Бэс Вод (Bas Vodde), разработчики Agile-манифеста и авторы скрама, начали экспериментировать с гибкими практиками в отношении больших продуктов.

LeSS помогает избежать лишних ролей в команде. Часто возникает соблазн создать более специализированные роли (например, архитектор, релиз-инженер, множество вариантов менеджеров среднего звена). Назначение четких ответственностей этим ролям отдаляет людей от команды. LeSS уменьшает количество ролей. Меньшее деление приводит к большему самостоятельному управлению внутри команды и, в конечном счете, к большей гибкости организации.

...

Резюме

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

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

Методология Crystal Clear из семейства методологий Crystal также подойдет для стартапа. Здесь акцент — на достижении конкретных целей. Разработка идет короткими итерациями, а в команде должна быть налажена хорошая коммуникация.

Feature-driven development — довольно известная методология, предполагающая ведение разработки от “фичи” к “фиче”: каждая новая итерация прибавляет новую функцию — “фичу” — вашему продукту.

Test-driven development — это разработка через тестирование, когда сначала создается тест, а только затем — код. Вариация TDD — Behavior-driven development — предполагает предварительное описание будущей функциональности обычным пользовательским языком, затем — написание теста и только потом — кода.

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