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

Lean №5 - Value Stream Mapping


Не получается провалидировать в боевом режиме - наши текущие процессы не имеют больших потерь по времени ожидания. Но идея понятна.
  1. Берем процесс (или нужную часть процесса)
  2. Бьем на активности, по исполнению которых есть результат
  3. Считаем время исполнения активности (над чертой) и время ожидания (под чертой)
  4. Используем 2 идеи
    1. Канбан - общее время процесса должно быть минимально, потому думаем как сжать  весь процесс по ширине и минимизировать время ожидания (и внтуренние циклы - если они есть)
    2. Принятие решений как можно позже. То есть процесс принятия решения должен быть как можно правее.
  5. На картинке жизнь User story от инициации (разбивание Epic на мелкие User stories) до реализации.
  6. Здесь в итоге решили
    1. что не тратим время на User stories до grooming, на котором принимаем решение что US войдет в следующий спринт
    2. не хватает время между Grooming и Workshop чтобы подготовить US
    3. время между Workshop когда обсуждаем US и Planning когда берем их в работу должно быть минимально чтобы уменьшить вероятность изменения scope Spring Backlog
    4. Потому сдвинули workshop на пятницу за 2 дня до демо/ретро/планирование

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

Идея №38. Бизнес

Новая идея для валидации. Попал на сайт - http://game.molodost.bz/ и http://molodost.bz/entry/
Сделал те же самые выводы что и неделей ранее

  1. Нужно ставить больше целей - здесь это 10 одновременных целей за 3 месяца
  2. Цели должны быть более амбициозные, сложные, valuable
Так же решил двигаться в сторону бизнеса, продаж. Я плохой продавец, но нужно что-то менять.

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

Lean №3 - Итерации

Итеративный подход является следствием Feedback практики. Чем меньше итерация, тем более быстрый feedback мы можем получить. Тем меньше потерь, быстрее сходятся точки зрения, мы более гибкие к изменениям.

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

Как следствие идеи на проверку
  1. Просить feedback не только после ретроспективы но и после каждого events - планирование, grooming, workshop, daily, какие-то специфические встречи. Это позволит менять формат events в лучшую сторону - мы уже год мало что меняем в них. 
  2. Помимо полугодовых аттестации в Компании проводить feedback встречи с сотрудниками (кто захочет) каждый месяц, например. Это было бы полезно. Но обычно никто не хочет развиваться. 

Идеи по Lean
  1. 3 принципа итераций 
    1. Исполнение работы маленькими порциями. Чем меньше порция результатов тем быстрее они проходят полный рабочий цикл. Если мы пытаемся тестировать все задачи спринта в конце спринта - это fail. Если дизайнер нарисовал прототипы сразу всех страниц и отгрузил их то любое замечание отправит большую часть его работы с корзину. Тоже самое с форматом требований, спеками, тестами и тп. 
    2. Вариативный подход. Всегда реагируем на факты, а не полагаемся на наши планы. Нужно уметь подстаиваться, быть готовым к изменениями. 
    3. Итерация - это точки синхронизации людей, команд и тп. Покажи продукт пользователю и синхронизируй vision. Покажи реализацию команде ASAP и у нее будет больше шансов тебя поправить. Провалидируй предположения с Impact mapping карты и меньше будет глобальных изменений 
  2. "У Заказчика постоянно меняют требования - значит он не знает что он хочет - значит он идиот". Наоборот, это vision, понимание, точки зрения на продукт сходятся. И чем меньше итерация тем это дешевле стоит для команды. 
  3. Изменяемый Scope работ - это хорошо. Это позволяет быстрее добится схождения точек зрения на продукт между Заказчиком и Исполнителем. Это позволяет реализовать только то что реально нужно, и то что не нужно будет удалено. 
  4. "Но Scope не должен менятся во время спринта" - это уже задача PO и PO support team. Нужен root-cause анализ почему scope истории изменился во время спринта? Чаще всего это следствие плохой аналитики по истории, или не согласованности точек зрения на эту историю с Заказчиком или пользователем. 

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

Lean №2 - Feedback

Обратная связь - на мой взгляд, главная практика в Lean и Agile, внедрение которой дает burst-эффект. И этому мне нужно еще учится и учится.

Идеи

  1. Пишите тесты как можно раньше. Быстрее команда разработки получит feedback по своим же изменениям в коде, и будет снижать технический долг
  2. Вместо долгого планирования и разработки требований для разработчиков - просто напишите код и проверьте идею. Поэтому нет смысла делать ТЗ, ПМИ и ФТ для Ставрополя - пусть используют систему и говорят что еще им не хватает.
  3. Вместо долгого сбора требований - покажите им примерный экран и получите по нему feedback. Делаем много дешевых mock-ups для сбора feedback на этапе сбора требований.
  4. Вместо долгого изучения продуктов - выберите 3 лучших и протестируйте.
  5. Всегда нужен НАСТОЯЩИЙ, МГНОВЕННЫЙ пользователь. Ростелеком и Минкомсвязь - это не пользователи, это заказчики. Наша главная беда всегда для всех проектов Электронного Правительства. Нужно биться в кровь за возможность общаться с Пользователем.
  6. Чем меньше Feedback loop - тем лучше. Всегда. В любых случаях. Можешь показать реализацию story команде и РО - покажи. Можешь показать версию продукта Заказчику или пользователю - показывай. Можешь согласовать сложную спеку без полной реализации - согласовывай. Потому мы хотим показывать версию продуктов по завершению каждого спринта.
Feedback - самый простой и дешевый способ избежать потерь и повысить эффективность. А в условиях Startup (startup - это любой проект с высоким уровнем неопределенности. Потому почти любая разработка продукта - это startup) - это почти единственный способ успеха.

Хочешь стать лучше как разработчик, аналитик, тестировщик, менеджер - прости feedback у коллег.

Книга - Экстремальный тайм-менеджмент / Николай Мрочковский

Прочел книгу "Экстремальный тайм-менеджмент" - было интересно.
Для тех кто не увлекается GTD, но хочет улучшить свою эффективность в жизни - самое то. Вместо инструкций кто делать и зачем - рассказ о том как меняется жизни героя книги от "зомби" до супер-успешного человека за неделю. 
Там немного глав и немного советов. С частью из них я не согласен. Но пару идей оттуда взял.
В Agile Result идет фокус на 3 цели в году, 3 цели за месяц и тп. Это реально работает и цель на год про Agile-мышление исполняется очень уверенно. Но все остальные сферы жизни (Hot spots согласно Agile results) остаются без внимания. 

После прочтения я (хочу адаптировать это к Agile Results) решил:
  1. вкладываться в развитие равномерно сразу по всем сферам жизни и брать сразу много целей в работу на месяц (но они будут не Focus цели)
  2. вкладываться в Творчество и Яркость жизни (или Fun у меня). Стыдно что я все еще не умею кататься на роликах, на серфе, так и не пробовал рисовать на планшете. Куча всего чем хотелось бы занятся.
  3. ставить более амбициозные цели. 
Сейчас читаю "The Power of Full Engagement. Managing Energy, Not Time, is the Key to High Performance and Personal Renewal"
Новая теория что управлять нужно не временем, а энергией, так как время для развития ты выделяешь, но сил на это уже не остается, потому Fail.
Это TRUE - буду изучать и валидировать идеи.

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

Lean №1 - Удалить потери

Изучаю, внедряю, валидирую идеи Lean.

Смотрим на потери в продуктах.

  1. Части продукта, которые не приносят Заказчику Value. 
    1. Webadmin - нужен только нам для визуализации данных в Системе. Но потребляет усилия и время Ruby team. При переходе WebAdmin -> TechPortal value для Заказчика должен появится. Потому оставляем. Было бы полезно передать support на Java team и поставить кому из команды задачу на levelup по Ruby. 
    2. Сложная структура БД, которая "стоит" нам больше чем нужно. Было бы полезно ее упроситить
    3. Валидация документов-оснований. Фича, которую нужно было придумать на 3 года позже. Иначе тратим на это кучу времени
    4. Протоколы. В рамках итеративного подхода протоколы были бы в 2 раза проще и доступнее. 
    5. Выделение интеграционной части Service в отдельный компонент
  2. Процессы, которые не являются прямой аналитикой и разработкой.
    1. Разработка ДОКУМЕНТАЦИИ! 
    2. Разработка подробного описания задач в Jira, которое никто не читает
    3. Фиксирование знаний в Confluence, которые никто не читает
    4. Работа с требованиями
    5. Долгосрочное планирование
    6. Работа с рисками в классическом плане (никогда ничем не помогала)  
    7. Тесты, которые полезность которые ниже их стоимости.
    8. Бесполезный Code Review 
    9. Дорогой Code Checkstyle
    10. То есть для всех Agile support практик необходимо понимать стоимость и оценивать их полезность, так как иначе возможно пустое следование канонам
  3. Частично сделанная задача тормозит движение вперед.
    1. Story, которую не смогли закрыть в этом спринте, и потому приходится закрывать в следующем не дает сильных потерь. Это прото плохо с точки зрения velocity, поставки продукта и как следствие fast feedback
    2. Проблема с задачами, которые были частично сделаны и отложены на месяц и более. Фактически огромные затраты на решение задачи по merge всех типов объектов делают огромные же затраты на save всех типов объектов в прошлом году БОЛЬШИМИ ПОТЕРЯМИ. То что в том году задача не была сделана в нужном объеме делает ее бесполезной, так как сейчас почти вся логика была переписана.
    3. При этом отложение решения проблем с merge и реализация merge всех типов до конца может привести к тому же глобальному рефакторингу позже.     
  4. Extra фичи, которые Заказчику не нужны, но которые мы считаем ВАЖНЫМИ так как нам виднее. Для этого необходима валидация связи от feature к цели продукта с помощью Impact mapping. Если мы не можем построить эту связь - значит это waste. Хотя если нужно мы построим - видимо нужна валидация этой связи с помощью Заказчика.
  5. Переключение между задачами. Возможно ли было делать задачи между 2-мя Ruby проектами полностью раздельно? В разных спринтах. Подумать в следующий раз.
  6. Любые ожидания.
    1. Ожидание процесса сборки - мерить и оптимизировать периодически
    2. Ожидания тестов - выделять самые долгие тесты и оптимизировать по 2 теста за спринта, добавить в Craftsmanship как Silver метрику 
    3. Ожидание mock-up интерфейсов - делать их на спринт вперед, делегировать процесс с команды разработки на PO support team 
    4. Согласование АС тестов - сейчас гораздно быстрее когда все спеки уже написаны и согласованы. 
  7. Долгие activity-процессы
    1. Сколько времени уходит на получение ответа у аналитика? Сейчас вроде бы не долго
    2. Сколько действий нужно совершить чтобы увидеть какие тесты упали?
    3. Сколько действий нужно сделать чтобы найти причину красного теста? Судя по fixing time долго
    4. Ненужная авторизация. Сделать auth-links так же для Webadmin 
    5. Сколько времени "стоит" git за одну задачу? Нужен ли gitflow? Для меня GitHub for Mac приложение делает работу с git дешевым.
  8. Bugs, которые тормозят разработку. Много в Ruby. Нужен root-cause анализ чтобы стопать весь конвеер и решать причину багов. 
  9. Лишний, дорогой менеджмент. Не вижу потерь - текущие процессы мало формализованы и дешевы по времени.   
Интересная риторика:
  1. Если документы никто не ждет (команда разработки), значит они бесполезны
  2. Если вы не можете поддерживать базу знаний в актуальном состоянии, значит ее никто не использует. 

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

Craftsmanship / Мастерство

Чтобы помочь коллегам в своей Компании развиваться, на текущий проверяю идею, которую называл Craftsmanship

Я взял 3 практики: 

  1. Software Craftsmanship (http://en.wikipedia.org/wiki/Software_craftsmanship) как общую идею, слоган
  2. http://en.wikipedia.org/wiki/Gamification. В геймификацию проектов я не верю, но для развития навыков - хочу проверить 
  3. Ожидания от своих сотрудников на следующую аттестацию, как советует HR департамент Компании чтобы сделать процесс оценки и повышения ЗП более предсказуемым. (Ранее фиксировать произвольные ожидания у меня не получилось - они устаревают, плохо формализуются и неоднозначно оцениваются.)  
В рамках этой идеи я взял набор областей, в каждой области набор практик и для каждой практики 3 уровня мастерства с набором метрик. 

Здесь текущее описание практик (нужно перейти по табам) 

Здесь область по разработке 

В результате ожидания на следующую аттестацию трансформируются в набор ожидаемых уровней мастерства по интересуемым практикам.

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

пятница, 5 июля 2013 г.

Идея №37 - Hot spots

Прочел в книге "Экстремальный тайм-менеджмент" by Николай Мрочковский идею про колесо жизни. Что есть 8 сфер жизни, которые являются секторами колеса и вместо должны образовывать единое колесо. У каждой сферы указывается оценка того на сколько эта сфера развита у человека. 
Если какие то сферы не развиты, то колесо жизни получается ущербным и потому "не поедет".
Все что бы далее в книге я выкинул, но это идею с визуализацией применил к Hot spots из Agile Results.
В результате 
  1. Переделал Hot spots на эти 8 сфер (оставил формат в виде MindMap) 
  2. Указал оценку на каждую сферу - как сильно эта сфера развита в моей жизни.
  3. Проанализировал самые слабые сферы и запланировал по ним цели, которые я хочу достичь чтобы выровнять колесо
  4. Эти цели постепенно разберу на цели месяца или цели недели
Хуже всегда сейчас у меня - это "творчество" (духовность опускаю) и "друзья и окружение"