вторник, 24 декабря 2013 г.

Agile results - результаты за 2013 год


Уже пару лет используют технику Agile results.
Из тех логов что удалось найди. Выполнено

  1. 37 целей на месяц
  2. 161 целей на неделю
  3. 424 целей на день

Из крупных/важных/интересных целей на 2013 год запомнилось:

  • Подал налоговую декларацию на 2010-2011 чтобы получить налоговый вычет (без специальной цели год не мог это сделать) 
  • Запустил первый тренинг
  • Внедрил Impact Mapping (теперь в любом процессе системного мышления его выстраиваю) 
  • Перешел на CEO распорядок дня (я так называю ложиться спать в 23 часа и просыпаться в 6 утра)
  • Начал бегать по городу по утрам
  • Внедрил Power engagement для повышения продуктивности через управление энергией
  • Заработал первые деньги как Agile Coach
  • Научился кататься на роликах (лет 5 собирался духом)
  • Съездил в Америку
  • Съездил в Париж
  • Запланировал отдых на НГ
Но теперь это кажется таким простым. И 10 целей на январь-февраль будут сложнее. 

воскресенье, 22 декабря 2013 г.

Лучшие книги 2013 года (из прочитанных)

У меня была цель - прочесть 50 книг за год.
Я прочитал только 36. Но даже эти 36 сильно изменили мое мышление. Как обычно жаль что я не прочел эти книги раньше.
Я думал что практика легко заменяет теорию - я сильно ошибался. 

Если интересно какие книги я бы рекомендовал, то они далее. Без приоритетов.
Ссылки на Amazon есть на самом Shelfari. У меня можно взять PDF версии.


Делать продукты через оказывание положительного влияния на наш Мир

Как проводить изменения в своей жизни и жизни окружающих

Управление не временем, а энергией для более продуктивной жизни

Lean Startup мышление в разработке продуктов

Практическая инструкция по запуску продуктов/стартапов 

Дополнение к системному мышлению о том как измерять неизмеряемое

Теперь любой бизнес/продукт рассматриваю с точки алого и голубого океанов


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

Уровни лидерства. Раскрыла глаза о том, что Эксперт это самый первый уровень. Самый простой.

Пусть будет ровно 10 книг. 

суббота, 21 декабря 2013 г.

#Focus Продукт

Добрый день.

Есть большое количество To-Do приложений в сети и для смартфонов. Они позволяют записывать идеи, задачи, мысли, и делают это хорошо и просто. КупиБатон, Any.do, OmniFocus и тп.

Каждый из нас хочет развиваться. Хочет ставить для себя новые цели и достигать их. Идеальнее всего это делать на бумаге, но в наше время это становится не удобно. И мы пытаемся используется те же самые To-Do приложения, но к сожалению просто напоминать нам о наших задачах не достаточно.

Здесь необходима помочь в ФОКУСИРОВНИИ на наших целях.
Для этого я предлагаю продукт #Focus.



Что он будет предлагать:

  • Помощь в постановке целей. Мы должны фокусировать не только на деньгах, работе и карьере. Здесь можно узнать больше - ссылка#1, ссылка#2.
  • Удобная реализация Agile Results техники для достижения целей - 3 цели на месяц, 3 цели на неделю, 3 цели на день. Больше не нужно будет использовать для этого Evernote или RTM. Здесь можно узнать больше - cсылка#1, ссылка#2, ссылка#3.
  • Визуализация прогресса и мотивация на достижение целей. Это очень важно так как все мы чаще всего бросаем то, к чему стремились. Здесь можно узнать больше - ссылка#1, ссылка#2.
  • Помощь в рефлексии для того чтобы найти Ваш путь к целям. То, что будет работать для вас. Здесь можно узнать больше - ссылка#1, ссылка#2.
Если вы хотите достигать Ваших целей, здесь можно подписаться чтобы быть в курсе. 
Участвовать


понедельник, 9 декабря 2013 г.

Полный Power Engagment

Дорисовал mindmap по Power Engagement.
Большая картинка - здесь

Меньше всего мощности у меня в эмоциональной энергии.
А у вас?

среда, 27 ноября 2013 г.

За что отвечает Scrum команда?

Была Ретроспектива на спринт 1.0.6.
Говорили про "Прозрачность".

Проблема - Команда определяет Scope Спринта. Далее пишет фичи как может и на Демо мы все узнаем что успели. Burndwon chart показывает что дела плохи. Но команда ему не верит так как несколько задач в прогрессе, и после их закрытия все будет хорошо. Обычно куча задач закрывается за день-два до Демо. Или не закрываются. 

1) Более мелкие Stories не хотим - утраивают
2) WIP уже ограничивали - устраивает
3) Не суть

При закрытии задачи я генерирую различные замечания/улучшения которые становятся видны лишь после реализации. Команда уверена что это увеличивает Scope фич и роняет спринт. 

На Демо решили улучшить Burndown chart чтобы он работал у нас. Все согласились. Думаю и правда будет лучше - проверим.

Под конец заговорили о том почему chart не работает сейчас и вскрыли расхождение в мнениях. Пусть будут варианты А и Б.

Вариант А.


Команда на планировании сама оценивает все задачи и определяет Scope на Спринт. Если все пойдет хорошо, то именно этот объем будет выполнен через 2 недели. Команда коммитится (ну, предсказывает) что сделает все что в их силах чтобы так случилось.



Далее во время Спринта что-то случается. При возникновении проблем команда вообще и каждый разработчик принимают различные решения. Наша стратегия направлена на распространении информации чтобы каждый принимал решения чуть лучше чем раньше. При принятии решений возникает треугольник, но он не много отличается от того что есть у менеджеров. Я выделил 3 критерия - Время, Scope и качество кода.

1) Сейчас команда решает проблемы через критерий "Время" - мы обеспечивает нужное качество кода и тот Scope что хочет РО за счет времени. В результате коммитмент на Scope Спринта редко когда сбывается.
2) Балансировать за счет качества кода мы не готовы - это дорого.
3) В результате я предлагаю команде балансировать за счет Scope. 

У команды есть возможность отклонять тем замечания/улучшения что я генерирую (кроме того что в АС явно указаны). Команда отвечает за Scope Спринта - она решает что успеет сделать и что нет.

Более точный Burndwon chart должен позволить принимать решения "Успеваем/Как сильно не успеваем" не экспертно, а более формально. 


Вариант В.


Все так НО. Команда отвечает только за качество кода и продукта. Обрезать Scope во время Спринта должен РО. То есть он или не делает замечаний/улучшений или пусть не рассчитывает на успех Спринта.

Далее моя риторика.


Почему Я должен принимать решения по Scope каждой задачи? Кто принимает решения - тот и несет ответственность.
1) Команда закомитилась на некоторый Scope - я отвечаю чтобы команда его реализовала. Не хочу.
2) Этих решений слишком много - они мелкие. Не хочу.

Самое простое, наверное - это спросить у РО что ему важнее. Красиво или функционально.
Я говорю что функционально. Первый релиз, снижаем риски, нужен MMF на балансировку консолидированной модели и сценарный анализ.

А вы что думаете?

Создание презентаций для тренингов

Смена подхода по созданию слайдов для презентаций за последние 2 недели. Последние презентации доступны здесь - Slideshare.net

Как результат - уверенно "черчу" на графическом планшете. 

понедельник, 25 ноября 2013 г.

А вы проводите ретроспективы для своей жизни?

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

В Scrum есть отличная практика делать ретроспективу в конце каждого спринта. Я делаю ретроспективу в конце каждой недели в пятницу утром пока голова соображает.

Это выглядит как запись в дневнике в формате

  1. Мои победы/успехи за неделю
  2. Мои неудачи
  3. Что изменить

Анализирую относительно того, что случилось за неделю (это обычно про победы) и того, как достигнуты недельные цели (это обычно неудачи).

Главное признать что

  1. что проблемы есть (здесь важна техника ставить корректные цели)
  2. что результаты не достаточны
  3. что это твоя вина

Из моих побед следует решение что я должен продолжать делать. Из неудач следует что нужно изменить или начать делать. Здесь нужно потратить минут 5-10 на анализ (см. всадник, слон + окружение) и сразу принять решения/действия на следующую неделю.

В обычном контексте я бы не смог принимать такие изменения - они достаточно "дорогие" и "не приятные". Вести дневник, бегать по утрам? Ха. Но когда ты видишь какую проблему это может решить и у тебя есть остается мотивация на достижение цели - это работает горадно лучше.

Половина изменений по результатам ретроспективы оказываются мусором - не работают для меня, не толкают к цели. Но value от остальных 50% достаточно для прогресса.

Итак, что дает личная ретроспектива:

  1. Рефлексия на стеройдах. Не случайная, постоянная, плановая.
  2. Анализ текущих проблем, которые самые Важные сейчас, так как не дают достигать самых Важных для вас целей.
  3. Ведет к изменениям, которые проще внедрить с использованием "остывающей", но еще "живой" мотивации.
  4. Возможность найти простое решение, и не использовать Heroic mode. Когда вы решаете что нельзя быть тряпкой и тратите на цель больше усилий чем могли бы.

пятница, 22 ноября 2013 г.

Планирование и визуализация

Размышлял над проблемой достижения целей.
Есть 10 целей на ноябрь-декабрь.
Стратегия №1:
  • Нужно каждый день делать небольшой шаг к каждой цели и в результате ты придешь к ней. Например, Бизнес-Молодость или подобное на Smartprogress.ru 
В результате по истечению времени ты оказываешься в какой-то точке на ПУТИ достижения цели, не достигнув ее. Это походит - как мы спринты исполняем. Мы просто делаем что успеем, и в конце спринта смотрим что получилось. "Burndown chart" у нас не работает.

Стратегия №2
  • Запланируй как будешь достигать цель и только после этого начни что-то делать.
Это лучше, но планирование 1-2 часа в самом начале для цели на 2 месяца недостаточно. Все слишком сильно меняется.

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

Так же решил перенять burndown chart из Scrum и визуализировать проблему. В результате есть такое.


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

понедельник, 18 ноября 2013 г.

Книги "Leadership Agility: Five Levels of Mastery for Anticipating and Initiating Change" и "Visualize This: The FlowingData Guide to Design, Visualization, and Statistics"


Первая книга - Leadership Agility: Five Levels of Mastery for Anticipating and Initiating Change. Крутая вещь, мне очень понравилось. Она специфична, слишком теоритична, и потому скучна. Но по смыслу очень крута. О том что главное для развития - это рефлексия. И смысл в постепенном развитии системного мышления (как я это называю, в книге не так) до высокого уровня. 
Я даже решил сделать mindmap, выделить цели и пути достижения след уровня лидерства, и внести это в 10 целей до НГ. 
Не важно чего я смогу достичь, главное что после этого я буду знать чуть больше.    

Я ее советовал ранее - я ошибся. Ничего полезного. Пролистал за несколько часов, зато до конца. Там нет теории, там практика для статистиков как программировать в программе R, и потом обрабатывать картинки в Adobe Illustration.
Не открывайте ее.

вторник, 12 ноября 2013 г.

Внедряем Power Engagement

Одна из 10 моих новых целей на ноябрь-декабрь - это более полное внедрение принципов Power Engagement (как я называю). То о чем рассказывают в книге "The Power of Full Engagement: Managing Energy, Not Time, Is the Key to High Performance and Personal Renewal".


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

Цель - не сильно SMART, но я решил по ходу дела метрики выработать и пытаться их достичь.
Vision - это больше счастья в настоящем и больше здоровье в будущем. Думаю любые вложения здесь вполне оправданы.

В процессе исполнения с понял что зря не сделал mindmap на книгу, когда читал, потому приходятся пролистывать ее снова с начала, и фиксировать.
В сети есть чужие mindmap, но они не кажутся мне полезными.

В общем, вот. Предлагаю посмотреть на mindmap первой 1/3 книги, по которому я планирую внедрять изменения в жизнь.   



четверг, 24 октября 2013 г.

Теория ограничений или как измерить качество?

Я не люблю Теорию ограничений - скука смертная. Если бы не художественное изложение ряда книг - ничего бы не осилил. У меня все еще теплится надежда попробовать эти диаграммы для решения проблем, но пока не могу найти случая и команды для этого. Наверное нужны желающие чтобы можно было это делать совместно - просто впихивать это своим сотрудникам можно их сразу отпугнуть от ТОС и они даже не захотят потом читать про него.

Из ВСЕХ этих книг про ТОС я взял лишь небольшую часть небольшой идеи и пытаюсь применить это в своей работе.




Опишу то малое что я взял и хочу использовать.
В производстве есть 3 показателя, которыми можно описать нашу деятельность

  • Выпуск - то что мы выпускаем и продаем, то есть наш доход от продажи продукции
  • Операционные расходы - наши затраты на осуществление деятельности, которые нельзя вернуть
  • Инвестиции - наши инвестиции в производство, которые мы можем в будущем обналичить и вернуть

В результате все НАША деятельность направлена на достижение простой Цели

  • Увеличивать выпуск
  • Уменьшать операционные расходы и инвестиции

Теперь что это относится к ИТ.

  • Выпуск - это тот продукт что мы разрабатываем. Чтобы его померить не хочется оперировать деньгами, сделаем упрощение и будем измерять его в кол-ве фич, которые мы выпускаем, или Velocity (да, это неправильно. Я знаю. Это упрощение). То есть мы выпускаем фичи - нам за них ПЛАТЯТ. При этом мне сразу хочется здесь выделить из всего Выпуска его часть и назвать его Value. Это те фичи, которые реально нужны заказчика. То есть платит он нам за все фичи, но его реально нужны лишь ЧАСТЬ из них
  • Трудозатраты - все трудозатраты, которые списываются на проект. В часах. Легко переводится в деньги.
  • Инвестиции - тут сложнее. Нет у меня станков или роботов, которые потом можно будет продать. Можно попробовать переделать это в знания, которые в дальнейшем помогают нам выпускать лучше, и тогда стратегия меняется на их увеличение. НО лучше упростить - инвестиций нет.

То есть вся моя деятельность как менеджера направлена на увеличение выпуска и уменьшение трудозатрат. Это было интуитивно понятно и до ТОС.

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

Ко мне приходят аналитики Маша и Катя и говорят что они сильно постарались и перевели процесс поставки требований в Use Cases на User Stories. И теперь этот процесс занимает в 2 раза меньше времени. Я узнаю увеличилась ли скорость разработки, то есть Выпуск. Он не увеличился (предположим).  Я увольняю Машу. Так как Выпуск не увеличился, то для Общей Цели это ничего не дает. Зато теперь я могу снизить трудозатраты. После этого никто никаких "инноваций" мне не предлагает.

Конечно же я считаю что практика User Story полезна. Она должна заставить команду меньше общаться через документы и больше общаться в живую. В результате процесс передачи знаний должен улучшится, снизится время на переработку фич в результате непонимания, и должен увеличится Выпуск.
А снижение трудозатрат аналитиков мы используем чтобы перенести часть работ со Спринта на предспринтовую деятельность. Например, более детальную проработку UI прототипов, что так же должно увеличить Выпуск. Используйте User Stories.

Потому можно утверждать что любая практика, которую вы решите внедрить, должна увеличивать Выпуск. То есть TDD, BDD, CI, Code Review и тп должны "драйвить” разработку вперед. Если новая практики оптимизирует только какую-то ЧАСТЬ процессов и не увеличивает Выпуск, то это Wastes. Можно выкидывать.

Давай поставим новую Jira. Выпуск увеличится? Waste.
Давай перейдем на Jenkins. Waste.
Давай будем описывать в Confluence How-To, которые нам возможно потом помогут. Waste.

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

Как измерить Качество?


Мы пишем unit-тесты - мы увеличели Качество. Хм, а как проверить?
Фактически Качество так же заложено в вашем Выпуске и Трудозатратах.

Вы используете CI чтобы быстро находить баги и исправлять их. В результате баг исправляется за 2 минуты сейчас, а не за N часов или M дней завтра с использованием поддержки 1, 2 и 3 уровней. Это не стопает разработку, значит “драйвит” Выпуск.

Или качество это увеличение соотношения Value / Выпуск, то есть больше поставки того что бизнесу надо, а не то что написано в ТЗ. НО вам еще нужно постараться превратить это деньги. Если вы не можете превратить это в деньги, то такое качество Вам не нужно. Именно так и происходит в заказной разработке. Платят за фичи в ТЗ, а не за то что процент ПОЛЕЗНЫХ для бизнеса фич будет выше.

вторник, 22 октября 2013 г.

Книга "Switch: How to Change Things When Change Is Hard"


Книга о том как внедрять изменения в жизни. В свой жизни, в команде, в компании, в обществе. Такое обобщение всех практик и методов в одну стройную модель. 
Это сама модель в кратком виде. 
  • Направляйте всадника. Всадник абсолютно логичен, быстро меняет направление. И для него нужно знать направление, знать путь (шаги до цели) и успешные примеры.
  • Мотивируйте слона. Слон действует исходя из привычек и ощущений. Его сложно свернуть с пути. Потому нужно искать нужные ощущения для внедрения изменений. Разбивать весь путь на мелкие шаги и двигаться постепенно, праздную маленькие победы. Изменять мышление людей, чтобы они идентифицировали себя с теми кто уже изменился.
  • Очищайте путь. То есть изменяйте окружение чтобы поддержать изменение. Вырабатывайте правильные привычки. Управляйте поведением окружающий (толпы).
И в книге очень много примеров изменений из разных сфер жизни. Есть даже про изменение механизмов госзакупок в USA. Мужик много смог изменить без ресурсов и власти.

Эту модель можно использовать везде. Причем она хорошо описывает что есть много разных причин для fails во внедрении изменений.

Я хочу похудеть но этого не происходит. Я понимаю что у меня нет достаточной мотивации для этого. Вес 92, рост 192. Идеально совпадает с формулой. И вроде бы всадник хочет, но слон не имеет ощущений, достаточных для перем.
У кого-то огромная мотивация похудеть, но он не знает Как.
Кто-то знает Как, но окружение и привычки не позволяют. 

Same с желанием бросить курить.

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

Ссылка на mindmap

Как обычно - у меня можно попросить электронную версию.




понедельник, 21 октября 2013 г.

Состав задач спринта

Закрывали релиз.
Было большое желание сделать все задачи по функционалу данного релиза перед тем как закрыть его. В результате мы набирали кучу всяких beefups из разных фич. Хотели - еще чуть-чуть и все. Так мы закрывали релиз 3 спринта. Набирали много несвязных задач - цель спринта было не определить.
Главное - было ощущение что нет никакого движения "вперед".

В результате решили следующее:

  1. Чиним все основные баги (бесплатно, оценка 0)
  2. Более половины спринта берем основной функционал, который сильно двигает продукт вперед. Это составляет цель спринта.
  3. Набираем мелкие фичи (при необходимости)
  4. Из всего множества beefups набираем только самые важные сверху.
В результате туча улучшений, которые есть всегда, не мусорит спринт и позволяет делать большие шаги за каждый спринт.

воскресенье, 6 октября 2013 г.

Lean №12 - Заряжать команду

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

1. Сотрудники говорят менеджерам как нужно работать, а не наоборот. 


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

2. Мотивация.


У команды должен быть не просто список задач в виде беклога, например. Нужна цель чтобы заряжать их. Как этого можно достичь:

  • Начните со понятной и озвученной цели
  • Убедитесь что цель достижима
  • Дайте команде доступ до Пользователя
  • Позвольте команде самой коммититься
  • Удаляйте помехи и скептиков

3. Лидерство


Тут понятно. Все время ищи проблемы у себя и анализируй их.
Не могу делегировать процесс бизнес-анализа так как решаю сам их проблемы.
Нет давления по тестированию - нет крутого тестирования.
Проблемы архитектуры не становятся проблемой команды - потому нет желания делать KISS решения.

4. Экспертиза


С трудом вижу возможности для распространения различной экспертизы в рамках Компании. Это настолько не свойственно для крупных компаний. И все то обучение что выстроено - оно кажется таким малополезным. 
  • Как делать презентации? 
  • Изучаем SQL. 
  • Делегирование. 
Это все здорово, но это не экспертиза. Это какие-то навыки. Потому меня полезным кажется только платные обучение в ScrumTrek. Хотя мы сами можем выстроить все эти тренинги внутри и иметь их бесплатными.
  • У нас отсутствует процесс тестирования в проектах. Его заменяет процесс создания бессмысленных скриптов на Selenium. 
  • Процесс аналитики выстраивается только в рамках старой Waterfall парадигмы. 
  • Разработка? Нет смены культуры с создания value для бизнеса вместо технических задач.
Думаю эта настоящая экспертиза. Это хотелось бы развивать. Но желание в Компании отсутствует. 

вторник, 20 августа 2013 г.

Мои 7 Insights по эффективности


За последние полгода сильно изменилась жизнь в части моей собственной эффективности. А именно

  1. Я очень доволен своим развитием. Есть ощущение прогресса, которого раньше не было.
  2. Я доволен своей эффективностью.  
  3. Я не ночую на работе. Я не перегружен, и потому могу принимать решения более правильно. Я вижу лес за деревьями. 
  4. Теперь хочу еще больший прогресс.
Соответственно мои инсайты по увеличению эффективности (по приоритету):

1. Цели

По текущей модели я ставлю 10 целей на 3 месяца, и делаю все чтобы их достичь. Раньше были 3 цели на год - это слишком долго и скромно. За год цели успевают устареть + нужно хотеть большего, 3 - это слишком мало.

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

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

2. Agile results

Тут может быть любая GTD система которую вы выдержали более 3х месяцев, и сформировали привычку. Я использую Agile Results. Почему? Потому что Agile. Мне в ней нравится что 
  1. Она простая
  2. Она сфокусирована на цели, а не на time management
  3. Там есть ретроспектива каждую неделю, когда я и правда нахожу что было плохо за неделю и строю предположения как это можно изменить. 
Нельзя делать одно и тоже каждую неделю и ожидать что когда-то будет лучше. Я каждую неделю тестирую 2-4 новые идеи. Из них 20% приносят пользу и изменяют систему эффективности. И это сильно.

За тот год что я применяю Agile Results, я ее модифицировал под себя и четко понимаю почему то, что было раньше не работало, и почему я сейчас делаю именно так.    

3. Рано вставать

Я всю жизнь был совой, и был твердо уверен что это лучший вариант. Какой смысл рано вставать, если ночью ты можешь сделать кучу всего независимо от событий за день. Ночь свободна, и ночью можно отлично поработать. Для меня это было важным условием работы - уметь возможность работать до 3-х ночи и прийти на работу к 11 часам.

Но по статистике успешные люди рано встают + они успевают сделать кучу всего до приезда на работу. И это правда офигенно. 

Я ложусь спать в 23 часов и встаю в 6 часов (раньше не могу - нужно будет ложиться в 22 часа, а это тяжело). Делаю физическую нагрузку или бегаю. Потом еду на работу и в 8 бываю в офисе. Голова свободна от разных мыслей, и с 8 до 10 часов я имею 2 креативных часа. За это время я успеваю сделать пару фокус задач из 3-х задач на день. Успеваю сделать задачи на levelup в области, которая мне интересна. К 10 часам когда в офис начинают приходить коллеги, у меня возникает ощущение что я уже сделал все, что планировал на день. И остались лишь рутинные задачи и встречи по работе.

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

4. Восстановление энергии

Есть такая книжка "The Power of Full Engagement: Managing Energy, Not Time, Is the Key to High Performance and Personal Renewal". По названию походит на очередную псевдо-теорию про мотивацию. Но на самом деле очень чудная книжка с понятным подходом о том почему энергия важнее чем время ("вечером есть время сделать что-то важное и полезное, но сил что-либо делать нет"). И про простые способы постоянного восстановления энергии. 

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

Я работаю в среднем с 8 до 19 часов. Полчаса на обед. Не курю, чай не пью, в настольный футбол не играю. В результате раньше часам к 15 был как овощь, часто болела голова. Делать перерывы на полчаса, отдыхать, пить чай - не помогало. Я сделал список из 5 занятий, которые меняют мою активность и помогают восстановить умственную энергию. Например, общаться с коллегами чтобы узнать/решить их проблемы, визуализировать проблему на доске чтобы найти решение, визуализировать на графическом планшете знания для предстоящих встреч. Ага, видимо мозг здесь не включается.

Это помогает гораздо лучше чем просто отдохнуть и перекусить. И это согласуется с теорией.    

5. Книги 

Есть огромное количество супер полезных, общепризнанных книг в оригинале на Amazon. Они дают бесконечно количество знаний, которые делают тебя лучше.  

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


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

6. MacBook

Не знаю как это работает, но MacBook физически приятнее открывать чтобы поработать. Какой-то позитив от работы увеличивает внутреннюю мотивацию и делает тебя эффективней. Или это так мобильность в работе с ним делает тебя лучше. Не знаю. 

Но этот ноут что-то изменил по сравнению в тем, что было раньше. Мистика. Не реклама.

7. Любовь 

Yep.


Еще есть vision, который описывает в одном предложении, "Зачем?" я что либо делаю и "Почему?" Это интересно иметь чтобы периодически сверятся с ним в тяжелых жизненных решения.

среда, 14 августа 2013 г.

Инкрементальность и прозрачность


Мы не успели. Мы хотели реализовать фичу с межведом и не успели.

Какие есть факты?

  1. Команда А потратила в совокупности примерно 2 месяца на фичу межведомственного взаимодействия.
  2. После этого была полная уверенность что все хорошо. Мы видели запросы - они создавали ощущение что все OK 
  3. Комнада Б получила неделю чтобы показать свою часть и общее демо по задаче при сильно уменьшенном scope.
  4. В результате продемонстрировать фичу в полном объеме не смогли.
  5. Не смогли показать - значит все потраченное время это waste.
Знакомо?

Сейчас когда все видят fail, лучше всего пытаться что-то изменить. Мы все делали как раньше - это привело к fail, наверное есть что можно поменять.

Я вижу 2 проблемы.

Инкрементальность 


"Scrum employs an iterative, incremental approach to optimize predictability and control risk." Из Scrum Guide.
Как было в нашем случае. 
Мы разбили фичу на отдельные US, которые можно было делать параллельно. Потратили неделю. За день до демонстрации стали соединять куски в общую фичу. Вылезли проблемы. В результате ошиблись в сроках где-то на день, и как результат - фичу не показали. Это не единичный случай - большинство fail спринта имеют эту проблему в основе.
Как можно было сделать в рамках инкрементального подхода. 
Сделать маленькую сквозную задачу чтобы получить результат в самом минимальном объеме:
  1. На форме ввода данных запроса есть только кнопка отправить запрос.
  2. На клиентской части показываем лишь номер запроса и кнопка "Ответить".
Получить работающий прототип. На основе него принять следующие решения что и куда инкрементально развивать.
В рамках этого подхода через 2 дня была бы работающая фича в MVP виде. Риски по интеграции были бы удалены. Можно было бы параллельно развивать любые части, и в любой день иметь работающую фичу и тем функционалом, который был бы возможен с учетом сроков. Не нужно было бы сидеть по ночам.
Если бы это было бы не специальное демо, а просто обычный спринт - мы так же увидели бы фичу в конце спринта возможно с неполным АС. Но фича бы была. По ней можно было бы узнать больше и принимать следующие решения. Это крайне важно.

Какие варианты решения я вижу? 

Shift

Нужен shift мышления самих разработчиков. Его сейчас нет ни в одной из команд. Более того сейчас у разработчиков позиция что это нельзя делать, так как в инкрементальном подходе стоимость фичи выходит дороже. Нет - это не так. Это такое же заблуждение как с парной разработкой. "2 разработчика отдельно сделают всегда больше чем в паре." 
Эта смена мышления решит все проблемы с инкрементом продукта, но это сложно. Каждому в голову не залезешь.

Backlog 

Сверхспособный РО умеет так бить User Stories заранее что вынуждает команды из-за WIP ограничения поставлять продукт в рамках спринта инкрементально. Но фактически это означает что РО будет думать не над тем как быстрее и эффективнее сделать продукт. Его мысли направлены на то, чтобы вместо Scrum Master сформировать такие ограничения чтобы команда самоорганизовалась в сторону инкремента продукта. Это возможно, но это печально. 

Scrum Master 

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

Прозрачность 


Второй факт что усугубляет проблему - это отсутствие прозрачности. Мы используем следующие утверждения:
  1. Команда самоорганизована и отвечает только за финальный результат спринта. За промежуточные результаты в спринте никто не отвечает. То есть команде можно сказать что "у вас есть проблемы" только в самом конце спринта уже на демо. Когда все что могло случится - уже случилось и изменить ничего нельзя.
  2. Burn-down chart ни о чем не говорит. Это мое любимое! Не важно что прошло пол-спринта и мы не съели ни одного point! Это не твои проблемы, Чувак! Ты нам мешаешь. Еще полчаса и мы сразу закроем 2 задачи на 5 и на 8, и все сразу станет OK.
В результате burn-down chart не используется, перетаскивание задач по статусам используется только чтобы видеть статус конкретной истории. То есть НЕТ НИКОГО прозрачного механизма, который бы мог показать как идет дела в любой момент времени. 
А его нет потому что он и не нужен. Подход прост - мы как Команда делаем что можем и в конце просто смотрим успели мы закрыть спринт или нет.
И все управления процессом поставки продукта у нас сводится к тому чтобы прийти за пару дней до демо и сказать - Чувак, нижних 3-х задач не будет, не жди. Давай выкинем их из спринта.

Chart - это один из механизмов перехода с Push управления на Pull на управление через  сигналы и прозрачности. РО должен не присутствовать на daily, и просто проходя мимо доски глядя на chart понять если ли риски на fail спринта и какие. Смысл chart-а в том что он убирает все эти эмоции и ощущения членов команд (Да, эта фича уже готова. Там пара тестов написать, залить в develop и перенесем в "Done"), и показывать просто цифры. Chart показывает факт - остальное ему не важно. В этом и смысл.

Для РО гораздо лучшей стратегией будет сократить scope ряда историй чтобы успеть сделать все запланированые фичи, чем выкинуть нижние фичи. Но он должен своевременно это увидеть. 

Что делать?

Я изменю процесс определения scope истории на более формальный и более определенный. Должно быть лучше видно как можно вырезать scope в случае проблем. Но это не решение.

Что делать командам А и Б?
Проведите ретроспективы и найдите решения по инкременту и прозрачности, которые будут работать у вас.

среда, 7 августа 2013 г.

Lean №11 - Поставляйте как можно быстрее

Зачем поставлять быстро?

  1. Это нравится Заказчику. Чем быстрее покажешь, тем ему приятнее, тем быстрее он сможет использовать продукт.
  2. Это снижает риски. Вы можете много закодировать, но пока это не в проде, вы не снимите все риски.
  3. Это позволяет принимать решения как можно позже. Вместо того чтобы месяц думать над сложным решением, лучше показать через неделю и снизить уровень неопределенности, чтобы иметь возможность принять более правильное решение.
Что предлагается для этого:
  1. Переход с Push системы на Pull. Всегда кажется что чтобы команда работала наиболее эффективно, необходимо микроменеджмент чтобы каждому говорить что ему нужно делать в каждый момент времени. Проблема в том что ИТ системы довольно сложны и комплексны, и четкий план мало вероятен. Лучше работает Pull система, основанная на сигналах и договоренностях. Для этого можно использовать:
    1. Короткие итерации.
    2. Визуальный контроль. Так как работа само-управляема, необходима визуализация того что происходит для всех. Burn-down chart, список проблем, список возможных рефакторингов, список идей для улучшений, статус сборок, статус тестов. Это все улучшает процесс само-организации. Нужно подумать как это можно улучшить сейчас.
  2. Теория очередей. 
    1. Необходимо постоянно оценивать время цикла и работать над тем чтобы его снизить. Время от начала грумминга истории до ее закрытия. Время от начала разработки истории с спринте, до ее установки на UAT стенд. 
    2. Постоянная скорость прибытия работ. Скидки в ресторанах в дневное рабочее время, дешевый трафик по ночам. Все стараются избежать пиковых нагрузок и распределить их более равномерно. Не нужно выгружать все истории на тестирование в конце спринта - нужно стараться распределить поставку более равномерно. Не важно что вы много кодируете, если не успеваете это тестировать. Не важно много тестировать, если вы не успеваете выгружать это в прод.
    3. Малые объемы работ. Чем меньше объем задачи, тем быстрее она пройдет весь процесс, тем меньше для нее будет время цикла. Тем быстрее ее можно будет протестировать и закрыть. Это позволяет распределить процесс тестирования по спринту более равномерно, и не сваливать его в самый конец.
    4. Оценивайте объем работы, который ждет чтобы его выполнили. Он будет соотносится с временем цикла. Нужно посмотреть на все наши процессы более обще, со стороны.  
    5. Чем больше вариативность времени прибытия работ или времени исполнения работ, тем выше будет время цикла и время ожидания работ. 
    6. Чем больше объем работ, тем больше вариативность времени прибытия и исполнения (при чем не линейно). Из этого следует что более эффективно уметь разбивать User story для спринта на примерно одинаковый объем (оценку в points) чтобы сделать процесс более предсказуемым. Тогда время цикла будет меньше, ожиданий будет меньше, визуализация на Burn-down chart лучше.
    7. Уменьшение вариативность в начале процесса оказывает больше влияния чем уменьшение вариативности в конце процесса.
Надо измерять и много думать. Можно использовать как одну из тем на ретроспективе.

Как быстро оценить стоимость проекта

Читаю How to Measure Anything - очень круто и жутко полезно.



Приходит на оценку проект с большой степенью неопределенности. Даже не проект - Концепция проекта. Идея, из которой я даже vision не могу сформировать. Есть Идея на создание федеральной системы - "Самой Главной".  Но для vision в самом начале нужны пользователи и их проблемы. Их нет в концепции, есть лишь ощущение что Система будет Самой Главной и потому жутко полезной.

Нет vision - нет целей. Нет целей - нет объема предположений, которые нужно провалидровать для их достижения.

Оцени!

Книжка крута мыслью что "оценка - это снижение неопределенности под нужным углом зрения". То есть главное здесь определить нужный вам угол зрения, и неопределенность после оценки должна снизиться.

Метод 1 - MS Project.

Лет 5 назад процесс предварительной оценки у меня сводился к следующему. Берешь MS Project, вписываешь в него работы, назначаешь людей на работы, задаешь рейт и MS Project сам считает себестоимость. При чем в начале сумма выходила не очень большой. Тогда ты расписываешь все работы в глубину, и общая сумма начинает увеличиваться. Расписываешь до тех пор пока сумма не увеличится до нужного тебе числа. Как только общая сумма стала солидной, ты останавливаешься и говоришь что дальше расписывать смысла нет - это уже частности.

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

Метод 2 - Простой.

Оценивая Концепцию по своему опыту определяешь за какой время возможна ее реализация силами твоей команды. N месяцев * стоимость Команды = Себестоимость. Далее Маржа, НДС и тп = Сумма проекта.

Метод 3 - Экспертный, 90%.

Смотришь на Концепцию и оценки стоимости в голове не возникает. Можно оценить диапазон, в которую стоимость входит с вероятностью 90% (что довольно хорошо для данной оценки)
Спрашиваешь себя с вероятностью 90% какая минимальная стоимость проекта? 150 руб. То есть меньше чем за 150 руб ты бы точно не взялся за проект.
Какая максимальная стоимость проекта? 600 руб. То есть при сумме больше 600 руб ты уверен что проект не будет интересен Заказчику, или ты точно проиграешь в конкурсе на него.
То есть ты оцениваешь что с вероятностью 90% сумма проекта должна быть между 150 и 600 руб.
Нужно одно число? 600 + 150 / 2 = 375 руб

Метод 4 - Метод Монте Карло.

Формируешь крупно блочно состав работ по проекту. Для каждой работы оцениваешь диапазон сроков куда эта работа попадает с вероятностью 90%. Оцениваешь какое количество людей понадобится на данную работу - можно так же с диапазоном. Далее простая формула для общей суммы и метод Монте-Карло.

У меня результаты Методы 3 и 4 сошлись с расхождением меньше 5%.

воскресенье, 4 августа 2013 г.

Lean №10 - Простые правила

Решения принимаются на любом уровне. Не возможно предугадать все ситуации или все контролировать. Не возможно сформировать инструкции для всего. Потому предлагаются простые правила для принятия решений:
  1. Удаляйте потери. Тратье время только на то^ что приносит Заказчику ценность (value).
  2. Развивающее обучение. Если есть проблемы, увеличивайте feedback.
  3. Принимайте решения как можно позже. Оставляйте варианты решений как можно дольше. 
  4. Доставляйте как можно раньше. Доставляйте value Заказчику как можно раньше.
  5. Заряжайте свою команду. Позвольте сотрудникам раскрыть весь свой потенциал.
  6. Встраивайте целостность системы. Не пытайте достраивать целостность системы после, выстраивайте ее сразу.
  7. Смотрите в целом. Не стоит оптимизировать части системы, только всю систему.
Это основные принципы Lean.

четверг, 1 августа 2013 г.

Lean №9 - Принятие решение в самый последний момент

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

Что предлагается для того чтобы это было возможно:
  1. Не делайте дизайн системы в самом начале. Дизайн системы должен развиваться по мере того как мы больше узнаем про систему и требования к ней. 
  2. Оптимизируйте процесс взаимодействия между теми что знает бизнес и тем кто знает код чтобы упростить внесение изменений в дизайн системы.
  3. Любители пытаются сделать все правильно с первого раза. Эксперты выявляют ошибки до того как они приведут к проблемам.
  4. Используйте объект-ориентированный дизайн и компонентную разработку. Например:
    1. Используйте модули. Прячьте поведение внутри модуля, откладывайте дизайн модуля как можно дольше.
    2. Используйте интерфейсы. Отделите интерфейсы от реализации.
    3. Используйте параметры.
    4. Используйте абстракции.    
    5. Декларативное программирование, а не процедурное. Алгоритмы не должны зависеть от окружения.
    6. Избегайте повторений кода - DRY. 
    7. Модуль имеет одну, простую функцию. Поэтому метод по валидации объекта не должен менять содержимое этого объекта (чтобы оптимизировать лишний SQL запрос), Марат.
    8. Инкапсуляция. Изменения не должны приводить к каскадными изменениям в других модулях.
  5. Реализуйте максимально простое решение сейчас вместо того чтобы делать решение которое будет удовлетворять "будущим" потребностям. Завтра вы будете знать больше, потому завтра вы сделаете более крутое решение.
  6. Избегайте лишних фич, добавляйте их лишь just-in-case. Любая фича - это потери на понимание, реализацию, тестирование, подддержку. НЕ бывает бесплатных фич.
  7. Исследуйте то что критически важно бизнесу. Малое время формирования ответа. Когда тратить на него силы? В самом начале и потом поддерживать его до конца проекта, или оставить на завершение работ и сэкономить время? Это не ваше решение - это приоритет бизнеса. Если ему это критически важно - сделайте в самом начале, чтобы снизить риски изменения архитектуры в конце работ.
  8. Чем медленнее ваша реакция на изменения, тем раньше вам нужно принимать решения. Чем быстрее вы можете менять код системы, тем больше вы сможете отложить решение.
 

понедельник, 29 июля 2013 г.

Как писать пользовательские истории (User Stories)

Вы "вляпались" в Scrum и начали описывать требования к продукту в виде User Stories. Есть Шаблон - он понятен, но жутко не удобен. Но это же Scrum - просто делай, и будет магия.



Но проблема в том, что без понимания эта магия не работает. В результате вы "тяните эту баржу" что есть сил. Но никакой полезности от историй вы не получаете.

Приходите на планирование. РО читает название истории. Все делают удивленные лица. РО рассказывает, что нужно сделать в рамках этой историй. Все кивают. Оценивают. И далее нужно лишь запомнить, что под этим большим, непонятным названием истории с оценкой "5" скрывается задача на добавление нового поля на форму и в БД.

Зачем нужны User Stories?
Про это написано куча статей. Не верите в User story - не используйте.

Мои правила на написание User Story


  1. Есть один actor 
  2. Есть одно действие
  3. Есть одна ценность / value / impact. Я выделяю ее ЗАГЛАВНЫМИ БУКВАМИ при написании User story.  

Actor 

C актером все более-менее просто. Вы выделили персоны, или у вас есть роли, и вы легко их вписываете в  начало истории. Есть одна проблема. Убери часть истории про актера. Если история ничего при этом не потеряла - значит эта часть бесполезна.
Вы определили роли в Системе и поняли что их не очень много - Пользователь, Оператор и Админ. И креативите по 100 историй, которые начинаются как "Как Пользователь Я ...". У вас закрываются  несколько спринтов, истории которых начинаются одинаково. Зачем вам это нужно?  Да, это бесполезно.
Джеф Паттон предлагает следующее:

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

Действие


Наверное здесь сложно ошибиться - это суть истории, "что нужно сделать". Что можно улучшить. Действие должно быть одно - основное. Нет смысла описывать "авторизуется и выполняется поиск" или "указывает параметры поиска и выполняет поиск". Укажите то действие, что вам действительно нужно.
Важно описывать историю на уровне "ЧТО?" делает, а не "КАК?" Это главное в истории. Опишите проблему, а не ее решение. Лучше вы потом с командой это обсудите и найдете более оптимальное "КАК"-решение.

Ценность

Главная проблема с User Story. Вы всегда знаете первую часть истории, но всегда сложно указать для чего это делается. Но это Scrum, все должно быть указано как User story согласно шаблону, и потому вы пишите "чтобы ..." и какую-то чушь, в которую сами не верите.
Уберите эту часть из истории. Если ничего не потеряли - значит формализация ценности в истории была бесполезна. Что же можно сделать?

Отказаться от формулировки "чтобы". Это корень зла. ДА, для каких-то историй можно указать ценность истории в таком формате, но не для большинства.

Перейти с понятия ценности (value) на влияние (impact). Ваша история не обязательна должна иметь ценность, но обязательно должна оказывать влияние на кого актера, что указан в истории. А уже это влияние ведет в конечном итоге к цели, которая имеет для вас ценность.

Представим что вы создали историю - "Как инвестиционный аналитик я получаю отчет №17 об инвестициях чтобы БЫСТРЕЕ принять решение".
У меня Аcceptance Сriteria - это метрика на value в US. Как померить такой value? Как понять что аналитик принял решение быстрее? Как вы поймете в конце что история выполнена?
Переделаем историю на влияние - "Как инвестиционный аналитик я получаю отчет №17 об инвестициях БЫСТРЕЕ". То есть сейчас этот отчет формируется за 60 сек. Вы указываете в АС что отчет должен формироваться за 15 сек. В конце понятно выполнено ли АС, понятно какие влияние вы оказали на работу аналитика.

Но в чем ценность того, что аналитик стал получать отчет быстрее?
Здесь можно перейти к общей постановке Цели для продукта. Чтобы прийти к такой истории вы:

  1. Вы построили Impact mapping
  2. Вы определили Цель и метрику на нее. Например, "ускорение сроков согласования инвестиционных бюджетов". 
  3. Вы определили что "инвестиционный аналитик" может вам помочь в достижении этой цели.
  4. Вы сделали предположение что если аналитик будет получить отчет №17 быстрее, то это приведет вам к вашей цели.  
  5. Потому данная история - это проверка данного предположения достижения цели.  
То есть смысл Impact map - это трассировка от User story к общей Цели продукта. Если такой связи нет и вы не можете ее найти - значит вы делаете что-то бесполезное.

То же самое можно сделать в любой момент времени на любом этапе создания продукта. Вы знаете что нужно сделать и это будет полезно, но вот ценность определить однозначно не можете. Вы видите десятки вариантов то, что нужно написать в "чтобы ...". Постройте путь до цели в Impact map. Найти то влияние что вы должны оказать на актера в результате. Не пишите всякую чушь, в которую сами не верите.    

Удачи! 

четверг, 25 июля 2013 г.

Как определить Цель продукта

Долго время я делал ИТ проекты/продукты, и все это время мне не было никакого дела до Цели (с большой буквы). Ну как не было - цель всегда была. Она указывается в пункте 2.4 в каждом ТЗ и ЧТЗ, и мы всегда свободно вписывали туда все что считали нужным. Часто путали что такое "цель" и что такое "назначение" - не знаю смогу ли я сейчас это правильно определить.

Далее был Agile и Scrum. Члены настоящей Agile-команды должны понимать куда идет продукт/видеть цель. И это не проблема. Часто рассказываешь Что и Зачем - они вроде кивают, понимают.

Потом пришел Гойко Аджич (опять он) и сломал мне все мироощущение со своим Impact mapping.

Оказалось что все это время в проектах не было Цели - вернее Цель была ложной. И по моей текущей модели это корень зла всех проблем:
  1. Большинство Fail-ов в разработке software 
  2. Бесполезные ИТ-системы, которые никто не использует (особенно государственные системы)
  3. Бесконечные списки замечаний от Заказчика, когда ты приходишь к нему в конце проекта с восклицанием "Подписывай акты, Чувак! Все круто получилось!" 

IMHO, это все следствие того, что Цель проекта не была согласована между Заказчиком и Исполнителем, причем обеим сторонам она казалась такой очевидной.

Мы - Исполнитель, и наша цель - это разработки системы.
Они - Заказчик, и их цель - решение проблемы.
И здесь видно что эти цели слабо пересекаются. Вернее, если нам повезет и наше предположение о том, что система решит проблемы Заказчика, сработает, то мы в шоколаде. Но везет редко и немногим. Обычно процесс закрытия проекта уходит в "допинывание" продукта по огромному списку замечаний Заказчика, после чего уже не хочется этот продукт трогать, ибо "пахнет".

"Нет метрики - нет цели" (с) Т.Д.

И правда - без метрики на цель самой цели быть не может. Какая же метрика?
Наша метрика на цель - пройти испытаний и передать Систему в промышленную эксплуатацию, подписать акты.
Их метрика на цель - Мы не знаем??? Просто решите нашу проблему, вы же профессионалы.
И тоже как то не сходится.

Но вернемся к Impact mapping.
Представим что есть Заказчик, у него есть проблема. Мы собрались вместе подумать что и как мы будем делать. И первый вопрос - "Какая наша цель, и какая метрика на ее достижения?"
Варианты:

Вариант А. 
Исполнитель подсказывает самый популярный и естественный вариант. "Цель проекте - это создание системы А. Метрика цели - система работает." Далее, если желание создавать Impact map не пропало, то рисуется какая-то хрень, состав которой следует из ТЗ. Разбежались. 2-10 месяцев и имеем результат, который описан в самом начале.

Вариант В.
Так как Impact map рисует Исполнитель, то через пару минут появляется такая мысль. Цель - заработать денег. Метрика - 15 млн. руб. Здесь всегда интересно следующее. Цель должна быть прозрачна, то есть с ней должен согласится Заказчик. Как происходит тот диалог, на котором Исполнитель сообщает Заказчику, что конечная цель всего мероприятия в том, что Исполнителю нужно заработать 15 млн. И как на это должен согласится Заказчик. С такой целью весь Impact mapping хочется закопать поглубже и забыть.

Любой продукт имеет своей целью каким-то образом изменить наш мир. Продукт, после которого Исполнитель становится на 15 млн. богаче, возможен в нашем мире. На госзакупках таких продуктах много. Но о них мы не будем.

Итак, после долгих измышлений мы взяли проблему Заказчика и решили трансформировать ее в Цель.
Для примера представим, что есть процесс управления инвестиционными проектами. Нас пригласили его автоматизировать.

Вариант С.
Спасибо, Виктор. Цель - создание системы по автоматизации процесса управления инвестиционными проектами. Метрика - процесс управления стал быстрее. Беда в том, что метрика и цель совсем никак не связаны, вернее притянуты за уши. Мы боимся признать, что процесс создания системы это никак не цель, это лишь одно (но видимо ГЛАВНОЕ) наше предположение для достижения цели. Мы боимся так как процесс достижения цели не полностью зависит от нас, и значит любые проблемы по достижению это цели - будут нашими проблемами. Проще не брать эти проблемы на себя - проще просто сделать систему по "нашему" же ТЗ, которое бедный Заказчик имел неосторожность подписать.

И последний вариант.
Например, Цель - сделать процесс согласования инвестиционных проектов быстрее.
Метрика
1) Название - время согласования инвестиционных проектов
2) Способ - Время от инициации проекта до получения статуса "Согласовано"
3) Текущие значение - 60 дней
4) Минимально допустимое - 20 дней
5) Целевое - 5 дней

И уже после этого мы начинаем создавать Impact map, придумывать предположения и договариваться с Заказчиком что и зачем мы будем делать.

А вы понимаете Цель своего текущего проекта?

воскресенье, 21 июля 2013 г.

BDD, Spec By Example или Как писать спецификации

Часто валидирую, переделываю, упрощаю спецификации, потому хочу описать HOW-TO как писать спецификации правильно на основе своего текущего понимания.

Зачем нужны спецификации?

Советую прочитать "Specification by Example How successful teams deliver the right software" от Гойко Аджича. Для нас это:
  • АС тесты 
  • способ передачи бизнес информации в разработку
  • живая документация и способ фиксирования знаний
Как АС тесты и способ донести информацию до разработчика - это оказалось очень мощной техникой. Если вы не пишите спеки и у вас проблемы с качеством, то советую попробовать. 

Спецификации мы пишем на  Cucumber, потому рассматриваю только Gherkin формат. 

Какие есть требования к спецификациям? Мое основное требование к спецификациям - это их эффективность.

И обычно проблема со стоимостью спеки. Стоимость - это трудозатраты на создание спеки, ее реализацию и поддержку в течение жизни продукта. Чем меньше придется переделывать спеку со временем, тем она дешевле.

Я переделываю чужие спеки не потому, что они не правильные - если разработчик может реализовать данную спеку, то она верна и имеет value. Я переделываю их, чтобы сделать более дешевыми и потому более эффективными.

Спека
"Пользователь авторизуется, заполняет форму, нажимает "Сохранить" и данные формы сохраняются"
возможна и полезна для продукта, но слишком дорога в поддержке. Потому не эффективна. Сейчас мы не пишем спецификации на GUI совсем. Это слишком дорого для нас. Вместо этого мы пишем
  • Спеки на логику
  • Unit тесты на View и Save 
  • Smoke GUI тесты  

Требования к спецификации

Мое главная требование к спеке:
  1. она должна покрывать одно небольшое атомарное действие (action). 
  2. Это то знание, что вы хотите зафиксировать для себя, для Заказчика, для продукта. Нет знания - нет спеки.
Основное правило для Gherkin формата. Мы описываем, что система находится в состоянии А, выполняется action, система переходит в состояние В.

Описывается это в Gherkin формате как 
  • GIVEN - Состояние А
  • WHEN - action 
  • THEN - Состояние В
Состояние А - это набор исходных параметров, которые влияют на action.

Состояние В - это описание результата в виде других параметров.

Action обычно не имеет параметров, это явное описание действия. Такое как - валидация, сохранение, сложение, проверка и тп. Но в ряде случаев для улучшения понимания возможно перенести часть параметров состояния А в WHEN и указать как параметры действия - action(param). Но лучше не надо!

Важно, что action должен быть как можно более атомарным, маленьким по времени. Представим такую спеку:
  • GIVEN пришел запрос на поиск данных
  • AND    система выполнила поиск и сформировала результат
  • WHEN система выполняет валидацию результата поиска 
  • THEN  результат содержит только идентификатор записи
Мы правильно выделили в WHEN, что нас интересует только процесс валидации результата поиска. Но информация о том, что пришел запрос и был выполнен поиск была лишней. Получается, что спека описывает промежуток времени от момента прихода запроса до момента когда мы валидируем результат поиска. Это может быть очень большой промежуток времени. В результате по данной спеке разработчик реализует именно то что описано:
  1. создаст запрос
  2. выполнит поиск
  3. получит результат
  4. выполнит валидацию результата 
  5. сравнит результат с ожиданием в THEN
При этом пункты 1 и 2 лишние для данной спеки. Эти делают ее дорогой в исполнении и поддержке. Нам это не нужно. Состояние А здесь - это момент когда мы уже всё нашли, у нас уже есть результат. Остальное к спеке не относится. Потому
  • GIVEN система сформировала результат поиска на запрос
  • WHEN система выполняет валидацию результата поиска 
  • THEN  результат содержит только идентификатор записи

Мета-шаблон спецификации 

При разработке спецификация мы со временем вырабатываем шаблоны, практики для сходных случаев. Они нужны аналитикам из PO support team на уровне Shu. К сожалению это не позволяет корректно действовать в новых, нетипичных ситуация. Потому хочется описать шаблон спецификаций для мета уровне, который можно использовать в большинстве количестве случаев.

Мы хотим описать некоторую логику "Аction", которую можно представить как черный ящик. Для этого логики есть входные параметры "А" и "В", которые влияют на нее. И один выход "result" как результат выполнения логики.

Что важно:
  1. Результат всегда один, хотя в результате можно быть набор параметров.
  2. Результат детерминирован. То есть на основе одних и тех же параметров, результат должен быть одинаков. Из-за большого количества примеров эта ошибка это может быть незаметна.  
  3. Удалить всё что не влияет на логику и результат напрямую
То есть неважно что именно вы описываете. Представьте черный ящик, данные, которые поступают в него, и результат, который из него выходит. И вся сложность именно в том чтобы из всего многообразия бизнес случаев спецификаций найти этот "черный ящик".

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

Ниже ряд ошибок, которые встречаются при написании спецификаций:


Логика использование спецификаций как тесты и валидация результата

Спека на сложение 
  • GIVEN есть числа <a> и <b> 
  • WHEN сложение чисел
  • THEN результат <c> - <d> 
  • Examples 
  • | a | b | c | d             |
  • | 2 | 3 | 5 | верен      |
  • | 2 | 3 | 6 | не верен |
  • | 2 | 3 | 4 | не верен |
Спецификация - это не тест, это описание поведения системы. Потому более эффективной будет спека.   
  • GIVEN есть числа "2" и "3" 
  • WHEN сложение чисел
  • THEN результат "5" 
Нет смысла валидировать поведение системы - система детерминирована, любой другой результат кроме описанного невозможен.

Много лишней, ненужной информации

  • GIVEN Пользователль авторизовался как "user" 
  • AND     открыл форму и заполнил значения "2" и "3"
  • WHEN пользователь выполнит отправку форму 
  • THEN  видит результат "5"
Информация про логин и открытие формы никак не влияет на логику - их нужно удалить чтобы упростить спеку и сделать ее более понятно.

Логика поиска 

Часто нужно описать логику поиска значений. Для этого используется следующий шаблон:

  • GIVEN Есть список значений 
  •   | key | value |
  •   | 101 | москва |
  •   | 203 | самара |
  •   | 307 | тула |
  • WHEN выполняется поиск
  • THEN результатов поиска являются значения с идентификаторами "101, 203"
Важно 
  1. Следует перечислить все "edge cases" значения и те атрибуты, которые влияют на логику поиска
  2. Следует явно указать какие значения должны быть найдены 

Результатом логики является список значений

Есть 2 варианта (когда вам не достаточно просто указать идентификаторы значений как в примере выше).
Вариант А.

  • THEN в списке результатов присутствуют <key> и <value>
  • Example:
  • | key | value |
  • | 101 | москва |
  • | 203 | самара |
То есть вы указываете, что вам важно чтобы в списке результатов были следующие значения. Проблема может быть в том, что в списке результатов так же могут быть значения, которые вы не ожидаете там увидеть. И вы об этом не узнаете - спека будет зеленой. Тогда
Вариант В.
  • THEN список результатов равен
  • | key | value |
  • | 101 | москва |
  • | 203 | самара |
То есть вы явно указываете полный список результатов и любое лишнее значение в нем будет FAIL.

Предположения 

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

Использование частицы "Не"

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

Удачи!

четверг, 18 июля 2013 г.

Lean №8 - Вариантное принятие решений

Options Thinking.

Идеи:

  1. Необходимо вариативное принятие решений. Формы заявлений были важным решением для Ruby системы. Мы выбрали спорное, не классическое решение без рассмотрения вариантов. Это стоит 1-2х недель переделки всех созданных форм. Текущие формы лучше, но может быть более лучше решение так как другие варианты мы не валидировали.
  2. Откладывание необратимых решений как можно дальше дает большой экономический эффект
    1. Лучше сами решения
    2. Ниже риски
    3. Снижение сложности системы
    4. Снижение потерь
    5. Более счастливые пользователи.
  3. Старая парадигма - это предсказывающие процессы (ЧТЗ, ТехПроект). 
  4. Новая парадигма - это адаптивные процессы. Мы даем пользователю возможность выбрать как можно позже. Но это не знает что в Agile и Lean мы ничего не планируем. Мы планируем, но в плане не специфицируются детально активности которые зависят от ситуации. Потому это Road Map, Story map и Product Backlog, а не диаграмма Ганта и ЧТЗ.

Lean №7 - Одновременная разработка

Смена мышления на парадигму по одновременной разработки

Идеи:

  1. Одновременная разработка - это означает разработка "вширь" вместо парадигмы последовательной разработки "вглубь". Мы не пытаемся принять все технические решения по продукту сразу, максимально быстро. Мы итеративно поставляем продукт, стараясь открывать горизонт наших знаний максимально широко, чтобы принимать решение just-in-time обладая максимальным техническими знаниями. Мы ничего не знаем про offline-режим, и потому не закладываемся на него. Все что нам нужно - это аггресивный рефакторинг.
  2. Но при этом в самом начале мы делаем самые главные пользовательские активности, основные User stories, валидируем критические архитектурные решения. Это нужно чтобы сформировать концептуальный дизайн продукта. Нужно показывать беклог команде и включать в него технические задачи на создание концептуального дизайна продукта.
  3. Лучше закодировать фичу чтобы проверить, показать ее, чем вкладываться в проработку требований по фиче. Плохо, что нет мгновенного feedback для валидации любых фич.
  4. Для Software свойственны потери связанные с внесением изменений. Изменения по некоторым типам ошибок после вывода на прод "стоят" в 1000 раз дороже чем тоже изменений на уровне концептуального дизайна. Архитектурные изменения могут стоить 100:1. Баги - 3:1 или 2:1. 
  5. Последовательная разработка принимает решения как можно раньше, потому стоимость изменений высокая.
  6. Одновременная разработка предлагает принимать решения как можно позже, что позволяет:
    1. Уменьшить количество высоко уровневых ограничений. Эх, BPEL и редактирование регламентов услуг. Эх, Oracle DB.
    2. Расширение горизонта знаний вширь позволяет принимать высоко уровненые решения более правильно.
    3. Отодвигание принятия решений как можно позже уменьшает количество изменений. Эх, огромные сущности в протоколах и в БД. Полный waste.
    4. Снизить стоимость изменений.
  7. Lean мышление позволяет создавать дизайн систем, доступный для изменений. Это особенно необходимо для некоторых областей применений, где изменения могут проходить даже после успешного запуска продукта, и необходимо чтобы дизайн допускал внесение изменений и снижал их стоимость. 

среда, 17 июля 2013 г.

Lean №6 - Разработка на ограничениях

Сложная тема про мышление через ограничения.

Идеи:
  1. Сложно выполнить синхронизацию если все ее участники являются мастер-источниками данных. Когда есть Java-система которая накладывает условия по протоколам взаимодействия, а остальные их должны соблюдать, и нужно лишь убедиться что нет логических противоречий, то есть ошибок на бизнес-уровне - это одно. Но что если все участники могут накладывать условия. Нужно назначить встречу для 5х. Выбираешь время - кто-то не может. Выбираешь другое время - другой не может. В результате проходит много итераций. В этот момент люди интуитивно переходят на мышление через ограничения. Нужно собрать со всех их ограничения по времени (когда они могут), принять решение на основе этих ограничений и просто уведомить всех о выбранном времени. Количество итераций минимально.
  2. В разработке я использую это следующим образом. 
    1. Собираем все известные бизнес-требования, все value-feature которые есть/знаем в PBL
    2. Вырабатывает технические решение 
    3. Проверяем что оно удовлетворяет всех требованиям
    4. Итеративно упрощаем его, проверяя что требования все еще проверяются
    5. Результат - есть KISS решение. 
    6. Например, версионность оЗАГС в Java проекте, иерархия организаций и ролевая модель в Ruby проекте
  3. При принятии дорогих, критических решений - сформируйте несколько вариантов, сделайте их все, провалидируйте и примите решение. Ошибиться в конце и все переделать будет дороже.
  4. Итерация - это одно из следствий такого подхода. Да, делаем только один, самый лучший по нашему мнению вариант, но чем быстрее покажем пользователю, тем быстрее провалидируем вариант, и сможем его изменить.
  5. Критично. Дизайн системы должен быть доступен для внесения изменений.
  6. Агрессивный рефакторинг - один из подходов внесения изменений, так изменений становятся дешевле. Если в Java проекте это уже 7-ая версия архитектуры - нужно жестко удалять все старые, ненужный куски кода. Они тянут вниз, тормозят разработку.
  7. Код никогда не должен фризится.
    

Lean №5 - Синхронизация

Синхронизация важна для подхода когда нет четкого разделения зоны ответственности членов команды на отдельные области. То есть когда команда совместно делает какую-либо feature. Можно называть это Feature Driven Development, но по сути это общая практика для всего Agile мышления.

Идеи:

  1. Для эффективной синхронной работы становится важным общее владение кодом. Потому мы используем git с дешевыми коммитами и merge. Потому мне так нравится GitHub и я готов его оплачивать. За месяц работы в GitHub код систем неожиданно стал публичным - его смотрят, его ревьюят, за него становится стыдно при fails. Хотя раньше был GitLab но в нем это было не интересно. Нужно продолжать вкладываться в коллективное владение кодом - это и качество продукта, и эффективность/скорость разработки.
  2. Работа с git сейчас не достаточна эффективна. Возможно стоит найти публичные проекты на GitHub и посмотреть политику коммитов там для примера. Мы наверное сейчас на уровне SHU и нужно не строить свои регламенты, а начать с копирования хороших продуктов. 
  3. Один из дешевых способов синхронизации команды - это CI. Красный билд - отличный показатель ошибки синхронизации усилий в части кода. 
  4. Получается чем меньше коммит, тем меньше размер chunk, тем чаще синхронизация, тем меньше потерь на решение проблем синхронизации.
  5. Чем чаще идет синхронизация веток в git, тем так же меньше потерь на решение проблем. Какой у нас регламент поднятия изменений из develop в feature-ветки? Почему Андрей фиксит тесты в develop, у Славы эти же тесты падают в своей ветки, он так же сам их фиксит, а потом нужно решать конфликты здесь? Почему feature-ветки такие огромные и включают в себя любые изменения которые разработчик решил сделать за время работы над feature, что в результате ни о какой синхронизации не может идти речи? И остается лишь один вариант - впихнуть потом это все в develop, полдня поднимать красные тесты и выдохнуть.   
  6. Для синхронизации с внешними системами нужна тестовая система, которая эмулирует работу внешней и позволяет протестироваться интеграцию. Да, SoapUI решает можно проблем, но для эмуляции работы ведомства по межведу нужно было написать простую Web-форму чтобы визуализировать процесс. Это позволило бы протестировать не только протоколы и интеграцию, но и удобство работы с нашей системой по этим протоколам. ЭТО ВАЖНО! Почему мы сами не увидели проблему в межведе с тем что тип ответа должен быть известен заранее чтобы можно было сформировать ответ, подписать его человеком, и хранить для отправки по запросу. А вопрос удобства - это то самое Agile тестирование и Agile-тестировщик.
  7. Вопрос интеграции и взаимодействия должен решаться первым чтобы как можно раньше выявить проблемы и риски, синхронизироваться и выполнять внутреннюю разработку компонент или систем независимо.