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

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

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

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

TL;DR Agile супер, работайте по Agile, делайте зарядку, будьте счастливы.

Если я вас заинтересовал, добро пожаловать под кат. Начнем. Поехали. Ай-да!

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

Решение самых важных вопросов

Здесь надо отметить, что первым делом, перед тем как приступить к внедрению самой эффективной Agile-практики, я решил, что для этого необходимо внятное и понятное название своей должности, которое сразу внушит всем, насколько эффективна будет работа. Методом solo-brainstorming’а (о нем я расскажу в следующих публикациях, если эта наберет 100 лайков) я пришел к следующим вариантам:

• Sprint Planning Integrator
• Royal Leader of Best Practices
• Chief Agile Komissar
• CEO of Agile Integration
• Head of Development Optimization Stories

Здесь надо обязательно сказать, что это очень важный вопрос, поэтому я решил начать с testing’а и researching’а того, как наши команды относятся к данным предлагаемым выше вариантам. К слову, эта история показалась им очень интересной, они крайне положительно восприняли мои идеи нововведений и даже после обеда повысили свою эффективность на 0,3%, что по моим сугубо субъективным наблюдениям — крайне положительный показатель.

Поэтому первым делом я решил собрать meeting с целью обсуждения вышеподнятых вопросов. После восьми часов обсуждения мнения распределились так:



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

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

Полученный и опробованный алгоритм мы также применили на выбор названия новой Agile-практики и назвали ее Royal Agile.

Новая практика или как сделать аджайл аджайлистее

Итак, пришло время рассказать вам где раки зимуют в чем заключается новая практика.

• Трехдневный спринт
  
  Первый день — Планирование
  Второй день — Разработка
  Третий день — Спринт ревью
• Максимальная активность на митингах. Молчать нельзя.
• Не писать код. Используются только Google и hotkeys: ctrl-c ctrl-v

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

Теперь остановимся подробнее на каждом пункте по отдельности.

1. Во время планирования Royal Leader of Best Practices должен объявить чтение ценностей компании и бизнес-миссии. В дальнейшем документ зачитывается по одной строчке по очереди, чтобы все могли внести свой вклад в произнесение ценностей компании.
2. На основе общественных исследований составляется портрет кастомера. Ему выбирают имя и историю. Затем коллективно рисуют портрет, распечатывают и вешают на рабочем месте каждого сотрудника. Это помогает сотрудникам лучше понимать боль кастомера и его нужды.
3. Подбираются референсы для фичи. Каждый сотрудник должен предложить два референса.
4. Еще раз проговаривается, для чего мы делаем данную фичу. (На каждый пункт должно отводиться не менее двух часов, иначе эффективность данных пунктов будет ниже требуемой).
5. В результате исследований мы установили, что тратить время на написание нового кода больше не имеет смысла. Все уже написано и надо лишь использовать готовое. Поэтому разработчикам запрещается писать новый код. Можно только компоновать готовые решения. Это позволяет сохранять дух стартапа, когда сделанное на коленке быстро и с энтузиазмом из готовых решений выстреливает в ногу у кастомеров.
6. На спринт ревью каждый рассказывает, что он сделал и какую пользу его фича принесет кастомеру. Затем вновь зачитываются ценности компании и объявляется переход к новому спринту.

Здесь стоит обратить внимание, что рабочая неделя должна состоять из двух спринтов. Поэтому Royal agile работает в условиях восьмидневной недели, что еще раз доказывает ее инновационность и опережение времени.

Как мы столкнулись с проблемами и решили их

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



Тем не менее, стоит заметить, что некоторые мелкие недостатки могут возникнуть в ходе тройного внедрения. Одним из таких недостатков стали разработчики.

Они показывали себя крайне неэффективно на собраниях. Молчали, дремали, задавали мало вопросов. Для сравнения мы попробовали нанять для разработки не-разработчиков, и они справились с собраниями гораздо эффективнее.

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

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

Выводы:

1. Выбору и обсуждению названий можно уделять не больше восьми часов.
2. Трехдневные спринты наиболее эффективны пока не введены двухдневные
3. Писать код не нужно если можно копировать
4. Разработчики крайне неэффективны на собраниях, поэтому зря просиживают деньги. Лучше их уволить

На этом первая часть моего рассказа закончена. Если хотите еще, я обязательно напишу еще. У меня в разработке темы, как я уже говорил, solo-brainstorming, а также я занимаюсь концепцией новой практики infinite sprint, настолько эффективного и завлекающего в продуктивную деятельность, что оторваться от спринта невозможно.