Сказ про успех или Как мы уволили всех разработчиков или Король прогибания

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

Недавно мне все надоело, задолбало захотелось сменить стезю профессиональной деятельности и занять новую для себя ипостать, чтобы в дальнейшем развиваться. Поэтому я подумал и решил стать бэтменом 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. Но в данном случае нам пришлось бы сокращать время митингов, что не представляется возможным на данный момент. Возможно в будущем нам все же удастся сократить второй этап и оптимизировать спринт.

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

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

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

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

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

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

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

    Выводы:

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

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