Сказ про успех или Как мы уволили всех разработчиков или Король прогибания
Доброго времени обращения земли вокруг оси суток, уважаемые хабрапацаны и хабранессы дамы и господа.
Недавно мне все надоело, задолбало захотелось сменить стезю профессиональной деятельности и занять новую для себя ипостать, чтобы в дальнейшем развиваться. Поэтому я подумал и решил стать бэтменом 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.
Новая практика или как сделать аджайл аджайлистее
Итак, пришло время рассказать вам где раки зимуют в чем заключается новая практика.
Здесь стоит пояснить, что изначально обсуждалась идея двухдневного спринта. Но после долгих обсуждений я не нашел способа ужать его в данное количество дней. Предполагалось, что разработка начнется в первый день сразу после планирования, а законится на второй день перед Sprint review. Но в данном случае нам пришлось бы сокращать время митингов, что не представляется возможным на данный момент. Возможно в будущем нам все же удастся сократить второй этап и оптимизировать спринт.
Теперь остановимся подробнее на каждом пункте по отдельности.
- Во время планирования Royal Leader of Best Practices должен объявить чтение ценностей компании и бизнес-миссии. В дальнейшем документ зачитывается по одной строчке по очереди, чтобы все могли внести свой вклад в произнесение ценностей компании.
- На основе общественных исследований составляется портрет кастомера. Ему выбирают имя и историю. Затем коллективно рисуют портрет, распечатывают и вешают на рабочем месте каждого сотрудника. Это помогает сотрудникам лучше понимать боль кастомера и его нужды.
- Подбираются референсы для фичи. Каждый сотрудник должен предложить два референса.
- Еще раз проговаривается, для чего мы делаем данную фичу. (На каждый пункт должно отводиться не менее двух часов, иначе эффективность данных пунктов будет ниже требуемой).
- В результате исследований мы установили, что тратить время на написание нового кода больше не имеет смысла. Все уже написано и надо лишь использовать готовое. Поэтому разработчикам запрещается писать новый код. Можно только компоновать готовые решения. Это позволяет сохранять дух стартапа, когда сделанное на коленке быстро и с энтузиазмом из готовых решений выстреливает в ногу у кастомеров.
- На спринт ревью каждый рассказывает, что он сделал и какую пользу его фича принесет кастомеру. Затем вновь зачитываются ценности компании и объявляется переход к новому спринту.
Здесь стоит обратить внимание, что рабочая неделя должна состоять из двух спринтов. Поэтому Royal agile работает в условиях восьмидневной недели, что еще раз доказывает ее инновационность и опережение времени.
Как мы столкнулись с проблемами и решили их
Надо отметить, что Royal agile решает все проблемы, и недостатков у методологии почти не было выявлено. Вот так согласно нашим измерениям выглядит график эффективности Royal Agile по-сравнению с другими методологиями.
Тем не менее, стоит заметить, что некоторые мелкие недостатки могут возникнуть в ходе тройного внедрения. Одним из таких недостатков стали разработчики.
Они показывали себя крайне неэффективно на собраниях. Молчали, дремали, задавали мало вопросов. Для сравнения мы попробовали нанять для разработки не-разработчиков, и они справились с собраниями гораздо эффективнее.
Не-разработчики были крайне активны, комментировали идеи, на 27% выразительнее читали ценности и предлагали пути дальнейших решений. Тогда мы приняли очень болезненное, но необходимое решение. Поскольку разработчики не были достаточно эффективны на собраниях и не дотягивали до наших показателей активности — мы их уволили.
Тем самым нам удалось сэкономить приемлемое количество денег на развитие наших продуктов и дальнейшего продвижения на customer territories. Кстати, надо сказать, что это же решение позволит нам оптимизировать спринты до их идеального двухдневного состояния.
Выводы:
- Выбору и обсуждению названий можно уделять не больше восьми часов.
- Трехдневные спринты наиболее эффективны пока не введены двухдневные
- Писать код не нужно если можно копировать
- Разработчики крайне неэффективны на собраниях, поэтому зря просиживают деньги. Лучше их уволить
На этом первая часть моего рассказа закончена. Если хотите еще, я обязательно напишу еще. У меня в разработке темы, как я уже говорил, solo-brainstorming, а также я занимаюсь концепцией новой практики infinite sprint, настолько эффективного и завлекающего в продуктивную деятельность, что оторваться от спринта невозможно.
