Про методологии Agile мы узнали достаточно недавно – около полугода назад, и нашли очень много общего с тем бизнес-процессом, который сформировался у нас по факту. Изучение Agile дало нам прежде всего осознание того, что мы далеко не уникальны в отношении итерационной разработки, а также помогло сформулировать большое количество принципов, которые никак не могли вырваться наружу в какие-то документы. В своей статье я бы хотел рассказать с абсолютно практической точки зрения как теория превращается в практику – как принципы Agile ложаться на реальную жизнь.
Принцип №1. Итерационная разработка
Все законы – имитация реальности. (c)
Метазакон Лилли.
Начать описание практической стороны этого принципа я бы хотел с очень интересного выступления Стива Джобса перед выпускниками Стэнфорда:
Я бросил Reed College после первых 6 месяцев обучения, но оставался там в качестве “гостя” ещё около 18 месяцев, пока наконец не ушёл. Почему же я бросил учёбу?
Всё началось ещё до моего рождения. Моя биологическая мать была молодой, незамужней аспиранткой и решила отдать меня на усыновление. Она настаивала на том, чтобы меня усыновили люди с высшем образованием, поэтому мне было суждено быть усыновлённым юристом и его женой. Правда, за минуту до того, как я вылез на свет, они решили, что хотят девочку. Поэтому им позвонили ночью и спросили: “Неожиданно родился мальчик. Вы хотите его?”. Они сказали: “Конечно”. Потом моя биологическая мать узнала, что моя приёмная мать ‐ не выпускница колледжа, а мой отец никогда не был выпускником школы. Она отказалась подписать бумаги об усыновлении. И только несколько месяцев спустя всё же уступила, когда мои родители пообещали ей, что я обязательно пойду в колледж.
И 17 лет спустя я пошёл. Но я наивно выбрал колледж, который был почти таким же дорогим, как и Стэнфорд, и все накопления моих родителей были потрачены на подготовку к нему. Через шесть месяцев, я не видел смысла моего обучения. Я не знал, что я хочу делать в своей жизни, и не понимал, как колледж поможет мне это осознать. И вот, я просто тратил деньги родителей, которые они копили всю жизнь. Поэтому я решил бросить колледж и поверить, что всё будет хорошо. Я был поначалу напуган, но, оглядываясь сейчас назад, понимаю, что это было моим лучшим решением за всю жизнь. В ту минуту, когда я бросил колледж, я мог перестать говорить о том, что требуемые уроки мне не интересны и посещать те, которые казались интересными.
Не всё было так романтично. У меня не было комнаты в общаге, поэтому я спал на полу в комнатах друзей, я сдавал бутылки Колы по 5 центов, чтобы купить еду и ходил за 7 миль через весь город каждый воскресный вечер, чтобы раз в неделю нормально поесть в храме кришнаитов. Мне он нравился. И много из того, с чем я сталкивался, следуя своему любопытству и интуиции, оказалось позже бесценным.
Вот вам пример:
Reed College всегда предлагал лучшие уроки по каллиграфии. По всему кампусу каждый постер, каждая метка были написаны каллиграфическим почерком от руки. Так как я отчислился и не брал обычных уроков, я записался на уроки по каллиграфии. Я узнал о serif и sans serif, о разных отступах между комбинациями букв, о том, что делает прекрасную типографику прекрасной. Она была красивой, историчной, мастерски утонченной до такой степени, что наука этого не смогла бы понять.
Ничто из этого не казалось полезным для моей жизни. Но десять лет спустя, когда мы разрабатывали первый Макинтош, всё это пригодилось. И Мак стал первым компьютером с красивой типографикой. Если бы я не записался на тот курс в колледже, у Мака никогда бы не было несколько гарнитур и пропорциональных шрифтов. Ну а так как Windows просто сдули это с Мака, скорее всего, у персональных компьютеров вообще бы их не было. Если бы я не отчислился, я бы никогда не записался на тот курс каллиграфии и у компьютеров не было бы такой изумительной типографики, как сейчас.
Конечно, нельзя было соединить все точки воедино тогда, когда я был в колледже. Но через десять лет всё стало очень, очень ясно.
Ещё раз: вы не можете соединить точки, смотря вперёд; вы можете соединить их только оглядываясь в прошлое. Поэтому вам придётся довериться тем точкам, которые вы как-нибудь свяжете в будущем. Вам придётся на что-то положиться: на свой характер, судьбу, жизнь, карму ‐ что угодно. Такой подход никогда не подводил меня и он изменил мою жизнь.
(полная версия выступления тут: Интервью Стива Джобса)
Стив очень глубоко раскыл суть того, что в реальном бизнесе, а не в строительстве “потемкинских деревень” невозможно представить все с самого начала. Первично желание – потом появляется вера и путь открывается только по мере движения по нему. Я видел много различных success stories о бизнесе, читал различные интервью Forbes, читал статьи о успехе различных компаний и я абсолютно убежден, что нету никакой логики и четкости в создании успешной бизнес идеи. Все это происходит насколько спонтанно и неосознанно, что врядли тут можно создать какую-то четкую логическую модель. Поэтому начало понимания этого принципа я бы начал с принятия положения о том – что успешная бизнес идея всегда хаотична.
Почему я говорю только о успешной бизнес идее, если как правило, на практике существует некто – Заказчик, успех которого редко волнует исполнителя – компанию разрабатывающую ПО. Мое мнение, что исполнитель просто обязан ставить во главу угла успех заказчика, ведь никакая другая идея не создает из заказчика настоящий актив. Сливаясь с заказчиком, разрабатывая софт который действительно успешен в плане бизнеса, понимая его – вы привязываете заказчика к себе настолько прочно, что можете без лишних проблем повышать свою норму прибыли, например, повышением цен, если это экономически обоснованно. Наша практика показывает, что заказчик без особых проблем пойдет на такой шаг, так как редко успешные люди хотят ломать процесс, который успешно работает. В данном случае – устоявшийся процесс разработки ПО. В общем, я считаю, что win-win solutions, когда выигрывает и исполнитель и заказчик давно показали свое превосходство над идеями вроде win-lose. Понимая цели заказчика, идеи заказчика, вы становитесь с ним одним целым – и вас уже объединяет не только проект или контракт – а нечто большее – то, что называется успех, и эта связь и есть актив – который дает стабильные дивиденды в виде прибыли с конкретного заказчика, а также положительный PR, который является основным в создании прибавочной стоимости на рынке аутсорсинга.
Согласитесь, что если вы поможете своему заказчику разработать Google2, то не будет никакой проблемы согласовать новую цену оказываемых услуг, а новость о том, что вы действительно это сделали будет хорошим информационным поводом, который привлечет множество других клиентов.
Итак, на практике никогда нет четкой цели к чему бы заказчик хотел прийти, нет четкого понимания. Как правило, редко появляются абсолютно новые бизнес-идеи. Как правило, заказчики берут существующую идею и направляют ее на какую-то особенную целевую аудиторию – например careerbuilder для китайцев – или берут существующую идею и направляют ее на новую платформу – Google SpreadSheets или Writely (Word в онлайне). Причем большинство клонов, как правило, имеют огромное количество различных фич, которые совсем необязательно реализовывать прямо сейчас. Возможны варианты – заказчик делает сразу огромное ТЗ и ищет финансирование – по факту тратит лишние деньги на кучу фич, которые, как показывает практика, совсем не нужны. В процессе Agile все по-другому. Agile можно представлять заказчику как PR фишку – мы не такие как все – мы лучше – мы приведем вас к успеху и сэкономим ваши деньги – нам не все ровно что будет с вашим проектом. Поэтому, как правило, при должном понимании работа по проекту начинается совершенно по-другому – не так, как это принято по waterfall модели. Берется цель заказчика – цель должны быть всегда конкретна, достижима и иметь реальный срок. К примеру: “сделать систему бух учета (копию 1с) с 100ым веб интерфейсом и стартануть продажи к 1ому января 2008”. Компания разработчик договаривается с заказчиком о продаже ему какого-то количества программистов на запланированный срок – к примеру если мы начинаем работать 1ого мая 2007ого – то это на 7 месяцев. В данном проекте можно использовать от 2ух до 10ти человек. Соответственно от этого будет зависеть количество фишек которые будут реализованы.
Принцип номер 2. Выполнение действительно важных вещей. Backlog.
Чем сложнее и грандиознее план, тем больше шансов, что он провалится (c)
Производная от закона Мерфи, предложенная Наггом
Возникает вопрос. Как заказчик может подписать бюджет не имея точного набора функционала, который он получит. Тут приходит на помощь большое количество коммуникации между заказчиком и исполнителем, в результате которого начальная высокоуровневая бизнес идея начинает обрастать конкретными детальными идеями. И тут важен PR вашей компании, как компании, которая таким образом привела кого-то к успеху. В любом случае на каждой итерации заказчик будет иметь четкое представление о том, что уже сделано и может действительно потрогать какой-то функционал и будет иметь представление о том, что будет сделано. Тем самым вы идете вместе – рука об руку – в процессе создания работающего бизнеса.
Все начинается с backlog – минимального функционала, который необходим для реализации проекта. К примеру, если это портал – то сразу надо запустить CMS-ку, определиться с готовым решением для организации почтового сервиса, сделать блок новостей. В конце каждой итерации – к каждой встрече с заказчиком должно быть реально работающее решение. Потому что то, что можно пощупать – координально меняет качество общения, общение переходит в исключительно созидательный процесс – и именно этот процесс и ведет к успеху.
При удаленной коммуникации отлично работает телефон – очень важно, чтобы все разработчики знали язык заказчика. Еще лучше конечно видео-конференции – чем ближе контакт – тем больше проявляются положительные принципы Agile.
Например сейчас, я пишу эту статью сидя буквально у подножья Эльбруса и это не мешает мне участвовать в ежедневных митингах (ровно 15 минут) и чувствовать что происходит за тысячи километров от меня. И периодическое погружение в проект, при постоянно отвлеченном внимании дает множество различных идей и нестандартных решений.
На практике также хочу сказать, что много раз видел огромное количество фич, которые были придуманы и ввиду ограниченного количества ресурсов и их неважности всегда сдигались в реализации – а по итогу и просто были удалены из плана, в случае с ватерфольной разработкой – все эти фичи были бы реализованы и неизбежно привели бы к потере денежных средств.
Принцип номер 3. Stand-up или Scrum Meeting
Эффективность совещания обратно пропорциональна
числу участников и затраченному времени. (c)
Закон Уолда и Кана
Как мы это делаем на практике. Совещания планируются абсолютно в разное время и никто не знает когда они будут. Как правило, я их планирую ровно за 15 минут до очень важной встречи, на которую нельзя опоздать. Это придает небольшой “экстрим” в проведение совещания. Как правило, это происходит спонтанно и участники совещания узнают об этом максимум за час до совещания. Митинг начинается со слов – у меня ровно 15 минут – давайте стремительно – Саша что у тебя?…. Как правило четко обсуждается что сделано и что будет сделано – какие есть проблемы и какие видятся им решения. В атмосфере небольшого экстрима человеческий мозг работает в тысячу раз эффективнее – в этом и суть этих митингов – точнее суть их стремительности.
До этой статьи как раз читал книгу Норбекова – о способе избавиться от очков – очень интересный был приведен пример: если вы попытаетесь вспомнить хотябы кого-нибудь кто ехал с вами в автобусе – то врядли у вас это получится. Но если вашу голову зажмет в двери автобуса и вы будете бежать рядом – то вы запомоните буквально каждого кто был там. Это о мобилизации ресурсов организма во время стресса. В каждом из нас где-то внутри есть гений и проще всего его увидеть в экстримальной ситуации, так почему не научиться создавать экстремальные ситуации самому?
Подводя итог – самое важное на таком совещании это атмосфера – атмосфера четкости и стремительности. Ведь успех всегда требует креатива и нестандартных решений – а значит максимальной мобилизации
Принцип номер 4. Самоорганизующаяся комманда и самоорганизующийся процесс.
Если вы хотите, чтобы команда выиграла прыжки в высоту,
найдите одного человека, который может прыгнуть на семь футов,
а не семь человек, прыгающих на один фут. (с)
Закон новшества.
Это на самом деле самый важный и самый сложный из всех этих принципов. Фактически – сама цель – Agile. Мне очень сложно написать здесь что-то в стиле “как к этому прийти” – могу лишь сказать что получилось по факту. Команда – которая очень сильно взаимодействует друг с другом – постоянно читает различные новые технологии и веяния – не боится их внедрять на практике и предлагать свои идеи. В общем, есть общая идея – постоянное развитие – которая пронизывает нашу работу во всем. Я бы сказал, что идея – самое важное для начала строительства такой комманды – и, наверное, это первое что необходимо определить руководителю. Далее идея обрастает определенными правилами или принципами – где-то это называется корпоративной культурой – у нас это просто есть в сознании каждого. Например, мы создаем софт для веба – используем мобильные технологии – в компании все используют только ноутбуки, в офисе у нас не стоит ни одного сервера – все в интернете.
Хочу сказать что в нашей компании детальное документирование каждого процесса привело только к снижении нормы прибыли и лишению креатива. Документы важны – но на практике это просто протоколы совещаний – очень короткие – которые высылает специально назначенный на эту роль сотрудник по факту совещания.
Для организации управления проектами мы используем Basecamphq – www.basecamphq.com. Из огромного числа пересмотренных нами систем эта система просто идеально подходит для нашего процесса. Она web-based – а значит к ней можно получить доступ откуда угодно. Она AJAX и web 2.0 – а значит броузер имеет удобство оффлайн приложения. Она очень ограничена в различных фишках – там есть только то, что действительно нужно – никаких диаграмм Ганта и network chart-ов. Просто проекты – цели – группы задач – задачи – ответственные за задачи и цели, а также простенькая система для ведения timelog-ов. Удобна как для реализации своих проектов так и для взаимодействия с заказчиком. Кстати в комманде http://www.37signals.com/ – которая создала этот замечательный продукт, которым пользуются миллион пользователей! Это одна из самых моих самых любимых компаний. Потрясающий пример эффективности ведения бизнеса.
Для управления почтой мы используем корпоративный Gmail – http://www.google.com/a/. Очень удобно – организует почту в конференции, один из самых лучших спам фильтров на сегодняшний день, web-based чат, действительно удобный web 2.0 интерфейс, очень легок в администрировании, не требует расходов на содержание админа, как в случае с MS Exchange и т д.
Вобщем если говорить о инфраструктуре – то я бы сказал что Corporate Gmail + Basecamphq – Agile совместимы.
В заключение хочу сказать, что Agile это не просто очередное модное слово – это естественный процесс разработки ПО. Я думаю, что многие, кто потратил хоть какое-то время на изучение Agile почувствовали что-то общее с тем что на сегодняшний день работает в реально существующих компаниях. В связи с этим хочу призвать вас к развитию этой темы в рунете – напишите agilerussia.ru о вашем практическом опыте Agile – давайте вместе развивать идею самоорганизующегося процесса.
