English Version

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

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

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

  • Статья Элистера Коуберна о "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. Вот это и есть полноценная роль и должность, требующая гораздо большего, чем формальной фасилитации базовых ритуалов, требующая и таланта и тонкого чувства того, как работать с командой, какова ее способность к изменениям, как внедрять новое и закреплять достигнутые командой результаты. Это действительно сложная и важная роль. Такого скрам-мастера нельзя так просто заменить на существенный период времени.
Newer Posts Older Posts Home
Powered by Blogger