User Stories Applied : Собираем Истории..

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

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

При таком способе выявления требований, мы сталкиваемся с рядом проблем:

• мы закидываем сеть сегодня, а требование может появиться завтра.

• мы прекрасно осведомлены тем, что мы не сможем выловить абсолютно все требования

• необходимо знать, где ловить

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

• Интервьюирование

• Анкетирование

• Наблюдение

• Семинары по написанию требований

Интервьюирование .

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

Открытость вопроса заключается в том, что вопрос не направляет мысль человека, а инициирует мыслительный процесс. Остается только собирать мысли человека.

Контекстная независимость – это отсутствие ответа в постановке вопроса. Пример:

• Контекстно-зависимы вопрос: Должна ли система делать автосохранение каждые 15 минут?

• Контекстно-независимы вопрос: Какого поведения ожидает пользователь от системы в случае экстренного завершения приложения?

Анкетирование

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

Практично в случае определения характеристик новой функциональности, заложенной в истории.

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

Наблюдение

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

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

Семинары по написанию историй

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

На сегодняшней встрече, посвященной этой главе, было предложена вариация практик анкетирования , наблюдения и семинара. Член команды, выполняющий роль аналитика, готовит анкету по новой функциональности, которая будет заложена в продукт, рассылает все заинтересованным лицам. После получения обратной связи устраивается семинар для мозгового штурма по поводу истории(ий). Обратная связь используется в качестве оценки построения анкеты. Таким образом, на каждой итерации построения анкеты, мастерство этого построения увеличивается. Можно завести check-list с критериями построение анкеты.

Послушать оригинал подкаста можно по адресу http://study-group.rpod.ru/139752.html.

Все подкасты по User Stories Applied можно найти на AgileGuru.Ru -> User Stories

На этом думаю все.

Всегда с Вами,

Михаил Шогин

User Stories Applied : Начало.

Привет. Решили, в рамках Agile Study Group (http://study-group.net/) освоить книгу Майка Кона - User Stories Applied: For Agile Software Development.

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

Может возникнуть резонный вопрос: Для чего нужны эти Ваши User Stories?

Первое с чего начинается проект – это сбор требований к конечному продукту. Этот процесс подразумевает под собой взаимодействие всех членов команды. Основная проблема, с которой сталкивается команда в процессе сбора требований - это проблема коммуникаций. Проблемы возникают в том случае, когда происходит дисбаланс «лагерей»: бизнес «лагеря» и технического «лагеря». В такой ситуации преобладание одной из сил над другой отражается на проекте. Преобладание технической составляющей приводит к преобладанию технической составляющей в бизнес области, как пример, бизнес задачи описываются на техническом жаргоне.

Что такое user story - это просто история, продукт методологии. Путь создания этого продукта, причем правильный путь, как раз и позволяет соблюсти баланс сил и повысить качество коммуникации.

Каждая User Story содержит в себе небольшую часть функциональности системы и включает в себя три аспекта:

• написание истории
• обсуждение истории и указании напоминаний
• тестирование истории.

Пример User Story может быть такой:

Пользователь может отправить тестовую смс-рассылку.

Просто, не правда ли? Возникают резонные вопросы:

• А где же детали?
• Должен ли пользователь быть зарегистрирован и авторизован?
• Как выглядит тестовая рассылка?

Ответы на большинство этих вопросов, как ни странно, так же являются User Stories. Что же получается, мы разбиваем все наши большие истории на маленькие. Согласитесь, маленькую задачу проще и быстрее реализовать и получить feedback, нежели большую. Правда нет необходимости разбивать большие истории на маленькие до бесконечности, всему есть придел.

После принятия истории, мы можем указать какие либо напоминания, которые критичны для этой истории, и перейти к следующей. Главный конек этого процесса, заключается в том, что мы вернемся к деталям user story, тогда когда настанет час ее реализации. Получается простая, гибкая и удобная схема: бизнес выбирает историю на итерацию, разработчик берет историю и идет к заказчику, обсуждаются детали истории, с учетом измененных требований.

Если мы вспомним аспекты присущие user story, то вспомним третий пункт – тестирование. Помимо напоминаний, каждая карточка истории содержит приемочный тест для этой истории. Как правило тест записывается на оборотной стороне карточки. Тест помогает разработчику не уйти от основной линии функциональности и остановится в нужный момент – тест зеленый.

В начале статьи было отмечено, что у нас есть два «лагеря» - бизнес и it. Оба лагеря участвуют в сборе требований – мозговом шторме, но писать истории – это ответственность заказчиков. Все дело в том, если доверить написание истории it отделу, то мы получим историю, описанную техническим жаргоном. Такую историю будет тяжело понимать людям не связанным с технической областью.

После того как истории написаны, можно перейти к планированию релизов. К этому моменту, технический отдел выставил каждой истории стоимость(velocity). Бизнес отдел выставляет истории приоритеты (запрещается ставить приоритет без стоимости истории ) и принимает решение о том, какая история попадет в текущую итерацию. В зависимости от выбора историй, технический отдел может менять стоимость ( такая ситуация может возникнуть, когда стоимость истории была оценена с учетом истории, которая еще не выполнена).

Закончим наше начало на приемочном тестировании.

Приемочное тестирование это процесс проверки того, что user story реализована так, как задумывалась. Приемочное тестирование должен делать заказчик истории: только он обладает полной информацией об истории. Рекомендуется писать приемочный тест до окончания итерации. Раннее написание теста позволяет сократить доработки истории в будущем.

Подводя итоги, скажем о некоторых плюсах использования user stories:

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

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

Ссылка на подкасты

User Stories Applied - 1. Введение

Балдеющие от адреналина и зомбированные шаблонами. Паттерн 2

 

Всем привет. Продолжаю рассматривать книгу балдеющие от адреналина. И сегодня рассмотрим второй паттерн. Называется он «На старт». В лучших традициях по названию не возможно понять смысл паттерна. В паттерне рассматриваются проектные или командные собрания.  Как у Вас проходят собрания? Все ли Вам нравится? Принимаются ли решения? Принимаются ли конкретные шаги для решения вопроса?

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

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

Оперативные команды обладают характерными чертами:

 - в таких командах не принято переносить задачи. В отсрочках эти команды видят реальную угрозу проекту.  Они стремятся выводить продукт настолько быстро, насколько это возможно, при сохранении должного качества. Сразу же появляются аналогии с GTD техниками. Если кто не знает, может послушать курс подкастов. В GTD есть техника разбора всей приходящей информации. Мы начинаем разбирать приходящие, не зависимо от приоритетов. Т.е. если мы взяли какую-то информацию, то не имеем права ее отложить и должны принять по этой информации конкретное решение. Что мы имеем на практике? А ничего, если нет состоявшейся команды, то один человек может внести сомнения по поводу рассматриваемой задачи и этим самым повлиять на перенос или отсрочку.

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

Поговорив о плюсах, было не честно не сообщить об антипаттернах.

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

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

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

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

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

Резюмируя, хочется сказать, что  команда должна жаждать сделать дело и приступать к реализации  сразу же после принятия решения.

 

 

 

Балдеющие от адреналина и зомбированные шаблонами. Начало

Давно меня не было в эфире. Все как-то в работе да в работе. Но тут случилось беспрецедентное событие. Я нашел отличную книгу. Не со своей помощью, конечно, с помощью одного agile-guru. Книга называется Балдеющие от адреналина и зомбированные шаблонами. Автор книги Том Демарко , Тимости Листер и другие соавторы. Книга включает в себя 86 паттернов командного поведения. В русском переводе издана в издательстве Символ.

Том Демарко и Тимоти Листер известны как авторы книги Человеческий фактор. Книга была издана еще в далеком 87 году, но как ни странно до сих пор имеет место быть . Мой хороший знакомый менеджер IT проектов, недавно начал ее читать и был просто поражен содержанием. А когда я сказал что книга 87 года изадния…. Ну вы понимаете что было дальше .

Вернемся к балдеющим от адреналина. Авторы книги говорят что у ней собран опыт 150 лет командных разработок. Отличные отзывы дали такие монстры IT мира как Алистер Коберн, Эд Йордон и многие другие.

Во введение авторы рассуждают о том что нас с вами делает людьми и отличает от всего остального. Я конечно не философ, всех рассуждений не знаю, но думаю что это мне подойдет для дальнейшей жизни. Так что же это? Оказывается все очень просто. Сугубо человеческое свойство – это абстрактное мышление. Что же такое абстракция и почему она сугубо человеческая? На эти вопросы лучше ответят философы, если конечно хватит сил выслушать все, что они скажут. Однако краткую притчу я все же процитирую: «Когда-то давным-давно, в доисторические времена, далекий предок человека уставился на что-то смутно знакомое – и вдруг его озарило: «Эге!.. Да это же опять тот-самый-какбишь-его!». Вот и все! Вот и появился человек!

А животные не могут это сделать. Хотя можно сказать: «Как же так, собака отлично распознает момент когда Вы пойдете с ней гулять». А например моя кошка отлично знает момент когда можно попросить пить (у нее форма морды приплюснутая, она не может пить из блюдца, потому пьет из крана, а кран надо открыть) . Однако, даже при такой способности распознавать ни моя кошка, ни Ваша собака не могу обобщить: «Эге!.. Да это же опять тот-самый-какбишь-его!». Для этого требуется абстрактное мышление.

А теперь собственно первый паттерн. Кстати интересное замечание прочитал о слове паттерн.

С английского паттерн переводится как шаблон. Понятие Шаблон устоялось в литературе, посвященной шаблонам проектирования в программировании. Означает буквальное воспроизведение тех или иных практик. В тоже время слово паттерн, находится в компетенции психологов, и означает узнаваемые в общих чертах совокупности признаков. Хотя последнее время, когда мы говорим о шаблонах проектирования, мы чаще используем слово паттерн. Если посмотреть на способы реализации шаблонов GoF, то можно увидеть, множество различных вариантов, зависящих как от технологии, так и от человека. И в конечном итоге мы получаем узнаваемые в общих чертах совокупности признаков.

Итак. Первый паттерн.

Звучит он просто «Балдеющие от адреналина!»

Буквально это означает – «Перманентный факап!» Определяется тем, что абсолютно все зачади в проекте мега-срочные. Не срочных проблем просто нет. Если появляется проблема, то она имеет два пути:

1 – перводится в статус «Мега срочная» и остается жить

2 – ставится статус «не срочная» и умирает до следующего случайного обнаружения

В таком проекте, отсутствует стратегическое мышление, и как правило даже минимальный среднесрочный план. Приоритеты постоянно меняются, задачи идут постоянным потоком, сроки выполнения задач – «все нужно вчера».

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

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

Лирическое отступление. Я когда прочитал этот отрывок, я был просто в шоке, я увидел себя в нем. Еще каких то 8-9 месяцев назад, я вел себя именно так. Потом, по счастливому случаю, я нашел http://study-group.net, познакомился с умными, профессиональными людьми. Узнал что такое Agile, начал читать книги, занимался одно время с ребятами. И стал понимать, что мое поведение – как то не очень накладывается на то что называется «лидер», «команда», «профессионал». Стал читать еще больше. Сейчас я могу смело сказать что в профессиональном плане я сильно изменился, и уже стараюсь избавится от вредных профессиональных привычек. Но дается это тяжело. Кстати, подкасты это один из самых действенных способов поменять свое мышление. Почему? Потому что записывая подкаст, ты тщательно прорабатываешь материал, осознаешь его еще больше и он откладывается у тебя в подсознании. Получается само-программирование. Да и к тому же, твои коллеги всегда могут тебя отправить слушать твой же подкаст, если ты ведешь себя не так как говоришь.

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

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

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

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

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

Оригинал подкаста можно послушать здесь http://personal-agile.rpod.ru/134648.html

Надо бросать курить

Если я брошу курить сегодня,
то за	45	лет
сэкономлю
492750 руб.
Сколько можно заработать, отказавшись от курения

Календарик одним sql запросом

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

Через некоторое время пришлось столкнуться с календариком - и как то я его нарисовал ;). Сегодня полез в пакет и наткнулся на то, что у меня тогда получилось ))

select 
    mon, tue, wed, thu, fri, sat, sun 
from (
    select
          lv4group,
          max(mon) mon,
          max(tue) tue,
          max(wed) wed,
          max(thu) thu,
          max(fri) fri,
          max(sat) sat,
          max(sun) sun
    from (
          with tr as (
                 select add_months(sysdate, 0) base from dual
         )
         , month_days as (
                 select
                      mod(lv,7) lv4weekday,
                      case 
                          when mod(lv, 7) = 0 
                          then lv/7 -1 
                          else floor(lv/7) 
                      end lv4group,
                      case
                         when 
                              curd between trunc(base, 'mm') 
                                      and last_day(base)
                         then curd
                         else null
                      end mthd
                  from (
                       select
                            level lv,
                            base,
                            mind + level - 1 curd
                       from (
                            select
                                  base,
                                  trunc(trunc(base, 'mm'), 'd') mind,
                                  trunc(last_day(base), 'd') maxd
                            from tr
                       ) t
                       connect by mind + level <= maxd + 7
                  ) t
          )
          select
               lv4group,
               decode(lv4weekday, 1, mthd) mon,              
               decode(lv4weekday, 2, mthd) tue,
               decode(lv4weekday, 3, mthd) wed,             
               decode(lv4weekday, 4, mthd) thu,
               decode(lv4weekday, 5, mthd) fri,
               decode(lv4weekday, 6, mthd) sat,
               decode(lv4weekday, 0, mthd) sun
         from  month_days
    )
    group by lv4group
    order by lv4group
);