English Version

Приритезация бэклога для практиков: три важных аспекта

Автор: Александр Якима

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

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

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

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

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

Массу полезных аспектов приоритезации вы сможете разобрать в рамках практических упражнений на нашем открытом воркшопе по приоритезации, который пройдет 22 декабря в Киеве.

Открытый Воркшоп: Приоритезация Бэклога

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

Этот воркшоп будет полезен Менеджерам Продукта, Бизнес-Аналитикам, Проектным Менеджерам и Лидерам Команд, а также всем, кому интересно ознакомиться с подходами определения важности бизнес-задач в контексте разработки продукта.

Дата и время: 22 декабря, 2011, 18:00. Продолжительность: 2 часа.

Место проведения: Учебный Центр компании "Люксофт" по г. Киев, ул. Радищева 10/14, корпус Б, офисный центр "Ирва".

Воркшоп проведут Александр Якима и Филипп Дзюба.

Ивент бесплатный, но необходима регистрация.

РЕГИСТРАЦИЯ ЗАКРЫТА!

Бизнес-Аналитик в Agile

Автор: Александр Якима.

Какова роль бизнес-аналитика в Agile? Вот наш центральный вопрос, на который мы постараемся ответить без излишнего сравнительного драматизма с другими методологиями. Просто и по сути.

Среди всех аспектов, наиболее существенны следующие:

- Бизнес-аналитик в Agile – это центральная роль в области, которая в Agile является достоянием всех участников процесса, в частности, команды и заказчика. Речь идет об управлении требованиями. Вся команда участвует в PBR (Product Backlog Refinement), в планировании итерации, в различного рода воркшопах. Также и заказчик соприкасается с командой в разрезе требований часто на том же PBR, планировании, демо. Таким образом, Agile бизнес-аналитик всегда заинтересован, чтобы команда и заказчик максимально понимали и применяли методы эффективной работы с требованиями, в то время как он, скорее, оркестрирует и корректирует процесс.

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

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

а)Четкая дисциплина коротких итераций – чтобы быстро и часто верифицировать и валидироать требования. Agile бизнес-аналитик больше всего верит только одному источнику истины: рабочему ПО. Вместо длительных рассуждений и предположений – прототип , вместо формального анализа рисков – функциональный спайк – вот эффективный подход Agile БА.

б) Групповая работа (см., например: Define-Build-Test ) над пользовательскими историями (или как бы не назывались «кванты» требований, которыми команда превращает идею в рабочую функциональность) – чтобы с одной стороны всегда было несколько пар глаз в одном и том же контексте, а с другой – меньше работы в прогрессе , которая приводит только к тому, что требования имплементируются неполно и некачественно.

в) Agile-практики, поддерживающие качество и скорость реализации требований: автоматизация приемочного тестирования, системный рефакторинг, непрерывная интеграция, коллективное владение кодом, инкрементальная архитектура и т.д. …

- БА Очень хорошо и четко понимает принципы Lean и неотъемлемую сложность ПО. Как эти две вещи связаны? Очень просто. Agile бизнес-аналитик не руководствуется наивным оптимизмом по поводу того, что систему можно точно заспецифицировать на целый релиз или даже больше и потом успешно реализовать, как это было задумано. Тут здорово помогает подход «точно вовремя» (Just-in-time или JIT) из Lean, который исходит из «контейнеров» (например, пользовательских историй, ММФ – минимальных маркетируемых фич и т. д.) в качестве единиц требований, которые наполняются по ходу выяснения новых обстоятельств и информации в принципе недоступной на этапе начального специфицирования и планирования разработки. Метод проработки «точно вовремя», вместе с четкой приоритезацией требований, составляют мощные средства для успешной работы с требованиями. Удивительно, но именно этот подход спасает даже в случае, когда заказчик принципиально настроен на fixed scope.

Итоги: Роль бизнес-аналитика в Agile обретает еще большую важность, так как теперь это уже не роль «сама в себе», а активное связующее звено между бизнесом и инжинирингом. Роль бизнес-аналитика, как лидера и фасилитатора, помогает заказчику и команде выработать наиболее подходящие в каждом отдельном контексте методы работы с требованиями. Agile бизнес-аналитик видит гораздо глубже и помогает команде внедрить и поддерживать гибкие инженерные практики, поддерживающие качественную и своевременную имплементацию/валидацию требований. Наконец, принципы Lean и правильное понимание неотъемлемой сложности ПО помогает выбрать оптимальный курс развития релиза продукта.


На правах рекламы: Тренинги для компаний.

"Непотопляемый" приемочный тест

Автор: Александр Якима

На прошлом воркшопе, посвященном Разработке Через Приемочные Тесты (ATDD) (/2011/11/workshop-atdd-with-junit.html) прозвучал вопрос о том, как быть с приемочным тестом, идея которого пришла уже после написания самой функциональности и, более того, мы практически уверены, что тест успешно выполнится. Суть вопроса в том, нужен ли вообще такой тест, который, кстати, даже не удастся "завалить"?

Вот некоторые аспекты такой ситуации, которые важно учитывать:
  • Да, тест который мы так и не видим не выполняющимся, опасен, так как в нем самом может быть ошибка. Однако, как всегда в таких случаях, ошибка просто имеет свою вероятность, и более того, есть шансы, что в будущем она выявится. То есть, мы точно ничего не теряем.
  • Во-вторых, тест вполне вероятно будет все же корректным и через некоторое время при изменении покрываемой им функциональности может отловить свежепоявившуюся проблему в коде. Ценность очевидна.
  • И, наконец, тест часто можно целенаправлено завалить, даже если кажется, что это уже невозможно. Смотрим, какие еще два-три полезных теста мы могли бы реализовать, чтобы более точно описать поведение этой функциональности. Запускаем и сваливаем их. Начинаем работать над реализацией под эти тесты. Есть неплохие шансы, что запуская тесты в процессе такой работы мы завалим наш основной тест и цель будет достигнута.

Не будем также забывать, что речь идет о приемочных тестах, которые обычно определяются командой совместно с заказчиком (в идеальном случае), или хотя бы командой, но не индивидуально отдельно взятым разработчиком. А это значит, что перед имплементацией у нас уже быдет целый набор "примеров" поведения системы, которые мы и реализуем в качестве тестов вначале, а потом добавим реализацию. Таким образом мы сможем увидеть все тесты незапускающимися в какой-то момент времени.

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

Недельная подборка

автор: Александр Якима.

Короткое резюме статей, обнаруженных (не то же, что "опубликованных") за неделю:

  • Статья Элистера Коуберна о "Last Responsible Moment" - концептуальном подходе в принятии решений (хоть на софтверном проекте, хоть в личной жизни). Статья скорее критична по отношению к методу и аргументы Элистера весьма интересны. Есть и немного философии и, с другой стороны, примеры.
  • Статья Мартина Фаулера о "Полиглотстве в программировании доступа к данным", то есть о применении различных технологий для одной задачи. Интересные мысли... Однако, статья немного техническая.
  • Джоанна Ротманн в своей статье: "Оценка неизвестного: дата или бюджет" прелгагает ряд интересных советов. К примеру, интересная идея (хотя и не всегда реализуемая в реальных обстоятельствах): "подождите с оценкой до тех пор, пока не поймете, как работает команда"...
  • Кент Бек приводит несколько советов по "удаленной парной работе". Насчет джаббера можно и поспорить, а вот Saros (тул для синхронизации проектов, о котором там идет речь) хотелось бы попробовать. А... и неплохой пример парной работы за роялем... однако, не представляю, как это можно было бы делать удаленно :).
  • И, наконец, хорошая статья о тестировании... для всех. Так и называется: "Тестирование - задача для всей команды". Link



Приятного чтения!

Открытый воркшоп: разработка через приемочные тесты с помощью JUnit

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


Воркшоп проведут:

Александр Якима (www.enter-agile.com) - независимый консультант по гибким методам разработки, работающий с компаниями в США и Индии по широкому кругу вопросов от масштабирования Agile-методов до внедрения гибких инженерных практик, и…

Роман Киндрук (Luxoft) – ведущий разработчик, за 10 лет опыта разработки участвовавший в сложных проектах на широком ряде технологических платформ и бизнес-областей. В своем опыте Роман широко использовал различные гибкие практики разработки ПО.

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

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

Дата и время: 1 декабря, 2011, 18:00.
Продолжительность: 2 часа.

Место проведения: Учебный Центр компании "Люксофт" по г. Киев, ул. Радищева 10/14, корпус Б, офисный центр "Ирва".

Ивент бесплатный, но необходима регистрация. Количество мест ограничено.


До встречи!

Воркшоп по специфицированию примером состоялся

автор: Александр Якима.

Наш воркшоп по Специфицированию Примером (Specification by Example), который я проводил с Филиппом Дзюбой, успешно состоялся в прошедший четверг. Спасибо всем за хорошую работу. Команды действительно потрудились очень серьезно.

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

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

Молодцы! Это видно...







Преодоление Барьеров Понимания: Специфицирование Примером и Гибкое Приемочное Тестирование

Мы предлагаем вам перевод отдельных отрывков книги Гойко Аджича (Gojko Adzic) "Преодоление барьеров понимания: специфицирование примером и гибкое приемочное тестирование" ("Bridging The Communication Gap: Specification by Example and Agile Acceptance Testing") с разрешения, любезно предоставленого автором.

Автор перевода: Александр Якима

Глава 1.2. Императивные требования очень легко неправильно понять.

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

История с серией экспериментов, которые проводил Лоуренс Шэтток (Lawrence G. Shattuck) с четырьмя регулярными батальонами Армии Соединенных Штатов (ссылка: http://www.au.af.mil/au/awc/awcgate/milreview/shattuck.pdf – прим. переводчика), приведенных также в книге Гари Клейна «Источники силы» (Gary Klein, “Sources of Power”), иллюстрирует эту проблему как нельзя лучше. Исследователи в рамках эксперимента присутствовали на военных учениях и просто слушали, в то время как командиры отдавали приказы своим солдатам. В продолжение учений они записывали все, что делали подразделения. Потом они обсудили фактические действия подразделений с их командирами. В результате эксперимента выяснилось, что действия солдат на полигоне полностью соответствовали тому, что подразумевалось их командирами, всего в 34% случаев. Читая об этом, я удивлялся, насколько эта история похожа на мой ранний опыт в разработке программного обеспечения. Командиры – это заказчики или бизнес-аналитики, приказы – это требования или спецификации, а солдаты – это разработчики и тестировщики. Мы все садимся в одной комнате, внимательно слушаем заказчика, договариваемся об определенном наборе требований и спецификаций, а потом удаляемся и разрабатываем что-то, что совсем не соответствует тому, чего хотел заказчик. Мне не известно о каких-либо подобных экспериментах, которые бы проводились с командами разработчиков, однако я не сильно удивлюсь, если результат окажется таким же. В некотором смысле вся эта история о том, что подобное происходит в Армии США, обнадеживает, так как из этого вытекает, что мы не единственные, кому досаждает неправильное понимание требований и некорректные предположения. К сожалению, это чувство быстро проходит, если на секунду задуматься о том, что у этих ребят самые большие пушки в мире, и при этом они неправильно понимают приказы в двух случаях из трех.


Глава 3.4. Определение важных примеров.

В Agile-разработке возможности системы инкрементально наращиваются посредством добавления функциональности от итерации к итерации. Майк Скотт (Mike Scott, из частной переписки автора) рекомендует концентрироваться вначале на «главной истории», содержащей основную суть отдельной возможности системы (иными словами – «фичи» - прим. переводчика), а потом добавлять дополнительные детали и исключения в последующих итерациях. Планирование проектов и разбиение отдельно взятой возможности системы на части, реализуемые в рамках нескольких итераций, выходит за рамки нашего текущего обсуждения, но я все же слегка коснусь этих вопросов в главе 9. Сейчас же хочу просто отметить, что мы сфокусируемся на работе с примерами, важными для отдельно взятого промежутка разработки, как бы он ни был запланирован. Нам следует, безусловно, учитывать будущее развитие функциональности, чтобы не зайти в тупик с разработкой, но при этом важно не переусердствовать, излишне усложнив процесс или увязнув в чрезмерном анализе всех возможных вариантов.

Итак, нам хотелось бы собрать достаточно много репрезентативных примеров, чтобы пройтись по всем вариантам и важным случаям для отдельно взятой возможности системы в рамках текущей итерации. Можем начать с того, что возьмем описание некоторой будущей функциональности системы, например, use-case сценарий, пользовательскую историю или любую другую «единицу» разработки, которую используем для планирования, и зададим заказчику вопрос: «как нам удостовериться, что эта функциональность реализована полностью и корректно?». Иной вопрос, который я часто применяю, звучит так: «представьте, что эта будущая функциональность чудесным образом уже реализована; тогда как именно вы бы ее тестировали?». Вот эти примеры нам и нужно будет записать и детально обсудить.

Затем нам следует определить «крайние случаи», негативные сценарии, а также сценарии, в которых не все идет согласно плану, и включить их в обсуждение. Слишком уж часто я встречал представителей бизнеса, обеспокоенных только сценариями, в которых все идет правильно, в то время как негативные варианты приходится разбирать уже самим разработчикам. Опять-таки, вы же не хотите, чтобы разработчики принимали решение о вашей бизнес-модели. Дональд Гоз (Donald Gause) и Джеральд Винберг (Gerald Weinberg) в книге «Exploring Requirements: Quality Before Design», ст. 251-252, выделяют следующие три категории, которые должны учитываться при создании тестов для отдельного требования (в гибком приемочном тестировании они соответствуют примерам):

1. нормальное использование функциональности

2. непредусмотренное, но разумное использование

3. непредусмотренное и нерациональное использование

Здесь под «нерациональным» использованием понимаем что-то, что пользователь в здравом уме никогда бы не сделал, но это все же может в действительности произойти. Эти случаи, скорее всего, смогли бы «нащупать» тестировщики, поскольку они мыслят «деструктивно» по отношению к системе. Гоз и Винберг говорят об этом так: «Никакая другая проблема в работе с требованиями не приводит к большему количеству судебных исков, чем смелое предположение, что ‘никто в здравом уме этого бы не сделал’».

Члены команды часто знакомы с крайними случаями и потенциальными проблемами и знают даже, как их можно бы решить, но им еще как-то необходимо их правильно донести. Если бы команда в свое время сообщила о своих проблемах и опасениях, то самолет, о котором пойдет речь в главе «Разрушение Духа Канзаса» на странице 21, мог бы все еще летать. Чтобы в нашем программном обеспечении избежать дорогостоящих дефектов подобного рода, нам всем следует сконцентрироваться на рассмотрении как можно большего числа именно таких «нерациональных» случаев. В обязанности тестировщиков как раз входит находить примеры, которые рано выявляли бы проблемные ситуации, являющиеся обычно предметом проверки на более поздней стадии. В следующей главе я ознакомлю читателей с концепцией воркшопа по специфицированию, способствующего такого рода обсуждениям.

Если в отдельно взятом примере фигурируют числовые данные, то я часто добавляю крайние значения, чтобы как-то «встряхнуть» систему требований, и посмотреть, что интересного из этого получится. Можно немного уменьшить значения чисел в примере, или же рассмотреть очень малые, а также весьма большие значения. Это не обязательно приведет к иному сценарию обработки данных, но вполне может подвести вас к видению того, что было с самого начала упущено. Примерами вышесказанного могли бы послужить транзакция размером в 0.01 при обмене валюты, 999 кликов в баннерной системе или приобретение видео-файла за $9.50. При обсуждении же крайне малых или больших значений, стоит спросить себя, насколько они вообще реалистичны. Следует иметь в виду, что существует разница между нерациональными и нереальными значениями. Очевидно, что нет особого смысла тратить время на рассмотрение мнимых данных, не представляющих для системы особой важности.


Различия в похожих примерах


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

Обратите внимание на следующие примеры для интернет-магазина цветов, предлагающего многоразовые ваучеры на бесплатную доставку для VIP-клиентов, если те делают разовую покупку на сумму более чем $50:

• Марк является VIP-клиентом. Он формирует заказ в корзине на $50 и переходит к оплате. На этапе оплаты ему предлагается бесплатная доставка, поскольку он проживает в США.
• У Марка осталось неиспользованное предложение на бесплатную доставку. Он формирует свой заказ на $30 и переходит к оплате. На этапе оплаты ему предлагается бесплатная доставка.
• У Марка нет предыдущих неиспользованных предложений по бесплатной доставке. Он формирует заказ на $30 и переходит к оплате. На этапе оплаты ему предлагается только доставка на общих условиях.
• Люси – VIP-клиент из Великобритании. Она формирует заказ на $50 и переходит к оплате, но получает только доставку на общих условиях, поскольку проживает в Великобритании. Мы не предлагаем бесплатной доставки за пределами США. Вместо этого мы даем ей бесплатный подарочный ваучер.
• Том не является VIP-клиентом. Он формирует заказ на $50 и переходит к оплате. На этапе оплаты ему предлагается только доставка на общих условиях.

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



Если выписать все подобным образом, то сразу становится проще заметить другие случаи, интересные для обсуждения. Очевидно, мы могли бы записать пример для VIP-клиента из Великобритании, сформировавшего заказ на $30. Но здесь присутствуют и такие пробелы в спецификации, которые заметить будет посложнее; но наша таблица помогает выявить также и их. К примеру, что мы делаем, если у кого-то есть неиспользованный ваучер на бесплатную доставку, но он также является VIP-клиентом и делает заказ на более чем $50? Переносим ли мы ваучер по доставке на следующий раз? А что если клиент в этот раз решит не пользоваться бесплатной доставкой – позволим ли мы ему перенести на будущее целых два ваучера или только один? Что будет, если вдруг каким-то образом окажется, что клиент из Великобритании обладает таким ваучером? Как такое вообще может произойти (возможно, система позволяет пользователю изменить адрес, но при этом оставить за собой ваучер), и стоит ли нам блокировать такую возможность? В идеальном случае нам хотелось бы успеть пробежаться по этим важным примерам, имея в распоряжении время экспертов в бизнес-области.


Таблицы упрощают обнаружение различий

Те, кто уже имел дело с системой FIT, уже наверняка успели заметить непосредственное соответствие между вышеупомянутыми таблицами и приемочными тестами в FIT (мы обсуждаем FIT детально в главе 10). Пока же, давайте просто пренебрежем тем, что мы знаем о FIT или любой другой подобной системе, включая и то, что нам нравится, и то, что нет. Если даже средство тестирования, которое вы используете, не поддерживает работу с таблицами, не стоит из-за этого отказываться от ценного метода. Смотрите на таблицы, как на отличный механизм, способствующий эффективному обсуждению требований. Рик Магридж (Rick Mugridge) и Ворд Каннингем (Ward Cunningham) отмечают, что таблицы предоставляют как раз такую необходимую структуру, чтобы эффективно организовать информацию, и при этом не усложнить ситуацию излишней формализацией данных (Fit for Developing Software: Framework for Integrated Tests, ст. 28). Таблицы уже активно использовались для эффективных обсуждений и качественного определения требований задолго до появления приемочного Agile-тестирования или изобретения метода разработки через тесты. Дэвид Парнас (David Parnas) применял их на проекте под названием A-7 для Военно-морской исследовательской лаборатории армии США еще в 1977 году. Он написал о своей работе в 1996 (Реляционные методы в компьютерных науках: табличное представление в реляционных документах, ст. 184-196):

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

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

* * *

Обсудить книгу можно в LinkedIn-группе

"Контроль сцепления" в разработке ПО

автор: Александр Якима

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

Это просто замечательная метафора для разработки ПО, гораздо очевиднее, чем, например, работа в прогрессе (WIP).

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

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

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

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

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

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

Открытый воркшоп "Specification by Example" От Agile Requirements and Quality (RU)

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

Дата и время: 17 ноября, 2011, 18:00.
Продолжительность:
2 часа.

Место проведения:
Учебный Центр компании "Люксофт" по ул. Радищева 10/14, корпус Б, офисный центр "Ирва" (как они нас только терпят...).


Воркшоп я буду проводить совместно с Филиппом Дзюбой.

Процедура регистрации обычная - просьба прислать мне на alex[at]yakyma.com письмо с темой: "SBE Workshop" с вашим именем, фамилией, названием компании и моб телефоном.

До встречи на воркшопе!
-Александр Якима

Наша пользовательская группа в LinkedIn

Мы в LinkedIn!

Теперь можно в удобной форме задавать вопросы, читать и писать умные мысли. Все сие ради качественной инкрементальной доставки софта :)

Фотоотчет по Инновационным Играм

Вчера мы замечательно (по отзывам участников) провели воркшоп по Инновационным Играм. Было действительно весело и "команды" поработали наславу. Ниже предоставляем несколько фотографий с "места происшествия". Вскоре будут анонсы следующих событий.







Скрам-мастер. Тип II.

автор: Александр Якима

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

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

Совсем другая ситуация - это скрам-мастер, который кроме фасилитации ритуалов процесса делает еще и следующее:
- Фасилитация взаимодействий на уровне отдельного эпизода из жизни команды (здесь следует вспомнить, что фасилитация - это способствование взаимодействиям в любых их проявлениях, не только стандартных митингов. Другие примеры: Воркшоп по специфицированию, "случайное" взаимойдействие нескольких сотрудников, например при обсуждении изменений в архитектуре из-за новой фичи и т.д.)
- Взращивание команды. Одно дело, фасилитировать ретроспективу, совсем другое - иметь дорожную карту или бэклог, если хотите, для совершенствования команды. Общее видение того, куда направить развитие. Такой "бэклог" стоит отдельного поста, но здесь вкратце перечислим, что туда может входить
а)новые практики, которые полезно внедрить
б)развитие софт-скиллов
в)работа над конкретной производственной целью (повышение качества доставляемого продукта/сервиса, сокращение цикла доставки, повышение гибкости и скорости реакции на изменение требований и т. д.)
г)развитие командных взаимодействий
д)и т. д. ...
- Лидерство примером. Не нужно делать именно то, что делают сотрудники в команде, у скрам-мастера роль другая. Однако, как и каждый в команде, скрам-мастер взаимодействует с людьми, у него тоже есть свои задачи, он тоже сталкивается с проблемами и т. д. Разница, быть может, в том, что на скрам-мастера обращено больше взоров, его поведение в центре внимания. Этим нужно уметь (в хорошем смысле) воспользоваться и демонстрировать команде, как вы беспощадно расправляетесь со своими задачами, как общаетесь с людьми, как ведете себя в случае серьезных проблем...
- Создание открытой и продуктивной атмосферы в команде, где лидерство - не прерогатива избранных, а нормальное (возможно, ситуативное, спонтанное) явление, где каждый может проявить свои сильные стороны и принести пользу, а также помочь это сделать другим. Атмосфера, в которой доверие лежит во главе угла, нет боязни конфликтов, посклоьку конфликт никогда не деструктивен, не выходит на личностный уровень, а только является цивилизованным средством уравновешивания точек зрения, чтобы достичь консенсуса и двигаться на всех парах вперед как команда - вот настоящая цель. Командное эго растет, личное эго уходит на задний план, цели команды превалируют...

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

Воркшоп: Инновационные игры в управлении требованиями

Вскоре мы проводим интереснейший воркшоп: "Инновационные игры в управлении требованиями".

Дата и время: 3 ноября, 2011, 18:00.
Продолжительность: 2 часа.
Место проведения: нас приютит Учебный Центр компании "Люксофт" по ул. Радищева 10/14.

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

Проводить воркшоп будут Александр Якима и Филипп Дзюба.

Воркшоп является открытым, однако мест есть только 20, поэтому просьба ко всем желающим принять участие - написать на alex[at]yakyma.com, указав свое имя, роль, компанию, моб. телефон.

До встречи!

Юнит-тесты: до или после кода

Когда писать юнит-тесты: до или после того, как написан код?

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

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

Действительно, (проблема 1) если тесты пишутся через достаточно длительный промежуток времени после того, как написан код - значит в код (даже если он свой) прийдется снова "въезжать". Тогда нормальное покрытие займет очень много времени или, как это случается чаще - быстренько покроется только малая часть кода.

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

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

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

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

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

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

Анонс: Ката по Фасилитации

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

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

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

В качестве аудитории приглашаются все, кому интересен этот топик и кто готов интенсивно потрудиться на протяжении всего воркшопа. Кол-во: до 20 человек.

Дата и время: Пятница, 2 сентября 2011. 18:00 - 19:30.

Место проведения: Тренинг-центр компании Luxoft, Киев, ул. Радищева 10/14, корпус "Б".

Важно: если вы решили участвовать, пожалуйста, обязательно отошлите письмо мне на alex [at] yakyma.com, указав свое имя, должность и подтверждение участия. Это важно, поскольку кол-во участников ограничено.

Ката проводятся бесплатно для участников.

До встречи в пятницу,
-Александр Якима.
Newer Posts Older Posts Home
Powered by Blogger