Жизнь меняется, а интернет пространство становится все более социализированным. Люди начинают больше получать информации из социальных ресурсов чем из классических источников наподобие RSS. Поэтому, для удобства наших пользователей, мы создали аккаунт в Twitter. Сделите за новостями, анонсами тренингов, интересными фактами и статьями с помощью своих любимых устройств! Можете даже «чирикнуть» что-нибудь о нас!
Эта статья посвящена очень опасному и распространенному в наше время недугу под названием Scrum-оголизм. Распространение этого недуга непосредственно связано с одной из наиболее известных и практикуемых Agile методологий – Scrum. Давайте сначала разберемся кто же такой Scrum-оголик. Вот некоторые характерные черты:
В чем же проблема данной болезни? Scrum-оголики забывают о том, что на самом деле Agile – это набор ценностей и принципов, которые были сформулированы и поддерживаются большим количеством людей из мира IT. И не более чем. На базе этих принципов и практик сформировалась философия разработки, под которую попадает целый ряд методологий: Scrum, XP, Kanban, FDD, Crystal и многие другие. В самой методологии Scrum нет ничего плохого. Просто подойдет она далеко не каждому проекту. Вообще у каждого проекта собственный уникальный контекст, который состоит из специфики разрабатываемого продукта, отношения заказчика к бизнесу, команды разработчиков, стиля управления компании и многих других факторов. Конечно, многие проекты попадают под определенные шаблоны, характерные для множества проектов. Но применять методологию без анализа контекста применения просто недопустимо. Scrum отлично подходит как базис, с которого можно начать построение процесса для конкретного проекта, адаптируя и модернизируя его по мере развития. При распространении же Scrum-оголиком методология преподносится как серебряная пуля, которая спасет в любой ситуации. Неокрепшие умы и отчаявшиеся люди воспринимают Scrum именно так и часто тоже заболевают. Хуже всего то, что при этом начинают подвергаться сомнениям и ломаться устоявшиеся процессы вне зависимости от меры их успешности. То, что стоилось годами, приносится в жертву Scrum. Напоследок оно гневно называется Waterfall-ом. Все это очень напоминает религию. А, как мы знаем из истории, подобные действия со стороны религиозных организаций всегда причиняли только вред.
Как же распознать Scrum-оголика в себе и окружающих? Это очень просто! Scrum-оголики в большинстве своем придерживаются некоторых поведенческих шаблонов, которые легко узнать:
Как же бороться с Scrum-оголиками и причем здесь «сухари»? Лучший принцип – это пропускание информации через призму практики и контекста конкретного проекта. В данном аспекте мне нравится восточная философия «Shu-Ha-Ri» (она же «сухари») в применении к разработке.
На уровне «Shu» вы пытаетесь понять базовые принципы, основы и практики, на которых построена методология. Вы ничего не меняете и следуете всем практикам, пытаясь отточить свое понимание и технику исполнения. Через некоторое время (у каждого оно разное) вы готовы к переходу на следующий уровень. К этому времени вы уже имеете немало правильных вопросов к методологии и целесообразности применения тех или иных практик (правильного применения вы добились на предыдущем уровне).
На уровне «Ha» вы начинаете задавать эти вопросы, обычно начинающиеся со слов «почему …» и «зачем …». Это помогает вам адаптировать методологию под свои нужды, выбросив из нее все ненужное и усовершенствовав полезное. На данном уровне вы находитесь в поиске новых подходов, решений и приемов. Вы экспериментируете с другими методологиями и выбираете то, что подходит именно вам.
Наконец, на уровне «Ri» вы уже не следуете правилам. У вас появляется твердое ощущение, что есть правильно, а что нет. Вы не ограничены рамками одной методологии, вы строите методологию сами, исходя из своего опыта, знаний и понимания контекста. Scrum-оголики обычно находятся на уровне «Shu» и не готовы идти дальше. Эти люди еще не готовы выйти за рамки правил, им проще попросту действовать по инструкциям. Они не воспринимают советы от людей с других уровней, эти советы слишком абстрактны и неконкретны для них.
Так вот, если вы встретите Scrum-оголика, постарайтесь повлиять на него. Накормите его «сухарями» (расскажите о философии «Shu-Ha-Ri» и его место в ней) и ни в коем случае не поддавайтесь его влиянию. Если вам нравятся те идеи, которые несет в себе Scrum, то пробуйте применять его, но не становитесь Scrum-оголиком. Кушайте «сухари» и будьте бдительны!
11 сентября Харьков собрал всех представителей IT индустрии на очень интересное событие – конференцию IT-Jam. Конференция отличилась очень большим наплывом участников и насыщенной программой. В этом году еще 5 компаний поддержали начинание компании Ciklum и помогли с организацией, в том числе и компания Zoral Labs. Многие участники приехали из других городов Украины: Киева, Днепропетровска, Львова, Одессы. Организаторы выбрали неожиданный формат для конференции. На протяжении четырех часов параллельно действовало 5 сцен: основной зал для ключевых докладов и 4 тематические сцены для мини-докладов и открытых дискуссий. Продолжительность докладов была ограничена получасом, поэтому участники имели возможность прослушать более 25 докладов из различных сфер разработки программного обеспечения.
Мне довелось выступить на сцене, отведенной докладам на тему баз данных и менеджмента, с докладом «‘Code Review’ practice application for the product quality improving». Неожиданно для меня, нашлось очень много желающих послушать мой доклад и сцена наполнилась до отказа. Времени было достаточно мало, а вопросов очень много. Пришлось отвечать на них в перерыве и после него, что лишило меня возможности посетить доклад Дмитрия Ефименко «Ongoing project requirements are changed pretty often and even favorite Agile cannot help? Receipts out of trenches». Дима очень опытный руководитель и мне кажется, что его опыт был бы интересен многим.
До своего выступления я успел посетить два доклада. Первым был «QA Driven Process, or Everyone Get What They Want». Я всегда являлся сторонником подходов, в которых QA выделяется ключевая роль соединительного звена между другими участниками процесса разработки. Ребята организовали подобный процесс, избавившись от многих проблем. Второй доклад был посвящен «Database versioning: how to avoid chaos». К сожалению, я не услышал ничего нового на этом докладе. Представленный материал был больше направлен на рекламу конкретных инструментов, продаваемых компанией докладчика. Тонкости и приемы работы над версионностью базы данных были попросту пропущены. Очень жаль, потому что тема действительно очень интересная.
После основной части конференции состоялся розыгрыш призов от спонсоров и партнеров, а также праздничный концерт. Мне очень понравилась идея собрать таланты среди участников и подготовить концерт своими силами. Было свежо и интересно. Ниже представлен небольшой фотоотчет:
Надеюсь IT-Jam 2011 будет еще интереснее и насыщеннее!
Терминология занимает важное место в любой методологии или процессе разработки, потому что она позволяет участникам лучше понимать друг друга и оперировать едиными понятиями и терминами. Неточная терминология приводит к недопониманиям и разногласиям. Я бы хотел обсудить два термина, которые всегда вызывали у меня странное ощущение неприятия: нефункциональные требования и приемочный критерий.
Начнем с нефункциональных требований. Во-первых сразу хотелось бы отметить, что сами по себе они очень важны. Но из-за специфического названия многие склонны о них забывать. Часто заказчики даже не понимают о чем идет речь: «Нефункциональные требования? Нам в первую очередь нужен качественно сделанный функционал!». Мне гораздо больше нравится понятие «качество сервиса» (quality of service). Ведь качество всегда является важным фактором и его нельзя игнорировать. В это понятие входит доступность, надежность, производительность, расширяемость, устойчивость и так далее. При такой формулировке нефункциональные требования превращаются в качественные показатели системы. Если задать вопрос заказчику об его ожиданиях от качества разрабатываемого продукта, то он с радостью поделится с вами, так как вопрос будет ему понятен и важность его будет действительно высока.
Второй термин, который хотелось бы обсудить – это приемочный критерий. На первый взгляд с ним все нормально. Заказчик или «владелец продукта» (Product Owner) формулирует приемочные критерии для каждой новой функциональности системы, после чего они используются для написания приемочных тестов, модульных тестов, интеграционных тестов, а также приема готового функционала. Но что если заказчик не готов придумывать и выставлять приемочные критерии? Что если фаза приема нового функционала вообще отсутствует на проекте? В этом случае теряется смысл слова «приемочный» и многие попросту начинают игнорировать приемочные критерии, тем самым лишая команду разработки важного артефакта. Мне больше по душе термины «критерий готовности» (Definition of Done) или «критерий завершенности» (completion criteria). Цель этих терминов очень похожа – указать, что необходимо сделать чтобы функциональность считалась готовой или завершенной. Добавлять критерий готовности может кто угодно: разработчик, лидер команды, менеджер проекта, тестировщик. Физически данные критерии добавляются в описание задачи в системе управления задачами или на доску задач. Для этого может быть использовано описание задачи или отдельная секция под названием «как продемонстрировать» (how to demo). Например, для регистрации пользователя в приложении могут быть использованы следующие критерии готовности:
Критерий готовности позволяет ничего не упустить в процессе разработки функциональности и является источником для тестов. В случае использование формального приема функциональности заказчиком эти же критерии могут быть успешно использованы.
Используйте такую терминологию, которая будет понятна всем в вашей команде и за ее пределами!
Очень часто мы говорим о качестве кода, о необходимости писать код правильно, использовать инженерные практики и шаблоны проектирования (design patterns) . Но как качество кода отражается на бизнесе? Какими последствиями чреват низкокачественный код? Давайте разберем эти вопросы на примере одного проекта.
На начальной стадии проекта необходимо осуществить планирование релизов (как минимум одного). Это требуется для того, чтобы планировать развитие бизнеса, принимать решения по различным финансовым вопросам и по многим другим причинам. В идеальном случае, при Agile планировании опытной командой, берется в расчет продуктивность команды и оценки сложности необходимой функциональности.
И вот начинается разработка. Чем больше кода разрабатывается, тем сложнее он становится для понимания и использования. Код плохого качества усугубляет ситуацию наличием множества дубликатов, мелкими ошибками, различиями в дизайне и стиле, огромными кусками неструктурированного кода, невнятными названиями методов и переменных, глубиной вложенности логики и так далее. Вдобавок не всегда присутствуют модульные тесты и код незадокументирован. Таким образом добавлять новый код в систему или изменять старый код становится все сложнее и сложнее. А это не может не отразиться на продуктивности работы членов команды. Естественно продуктивность падает.
Почему же команда не уделяет внимания проблемам с кодом? Все дело в том, что у команды не хватает на это времени (часто также не хватает опыта и знаний) – ведь нужно разрабатывать новую функциональность. Накопление проблем в коде называется техническим долгом (technical dept). Чем больше долг, тем тяжелее жить с ним. Если же продуктивность команды падает в результате возросшего технического долга, то команда начинает не успевать завершить новый функционал и начинает торопиться еще больше. Образовывается замкнутый цикл. Чем больше команда торопится, тем меньше времени уделяется качеству кода. Чем меньше времени уделяется качеству кода, тем больше технический долг. А чем больше технический долг, тем меньше продуктивность и тем меньше успевает команда выполнить в срок. И, как следствие, начинает еще больше торопиться.
Через определенное время сторона бизнеса начинает понимать, что команда не успевает все выполнить в запланированный срок. Если используется Agile подход, то это станет видно гораздо раньше, чем при применении классических подходов. И тут необходимо что-то предпринять. Очень часто принимается решение расширить команду разработки (конечно, если хватает бюджета). Чем больше становится разработчиков, работающих над тем же кодом по тем же принципам, тем хуже его качество. Кое-как система доживает до успешного релиза и ее начинают использовать.
Разработка продолжается и появляется необходимость поддерживать систему. Пользователи находят множество проблем, требующих мелких доработок и исправлений. Изменения в коде даются очень тяжело. Продуктивность падает еще больше. И тут кому-то в голову приходит гениальная мысль – пришло время переписать ядро системы заново, переделать архитектуру, сделать новый дизайн и решить раз и навсегда все проблемы. Остановить работу над новой функциональностью нельзя, потому что это грозит бизнесу крахом. Поэтому выделяется небольшая команда для реализации идеи новой архитектуры. Обычно такая команда состоит из опытных разработчиков.
Начинается трудоемкая работа по дизайну, анализу проблем текущей системы и разработке новой архитектуры. После чего происходит миграция функциональности. Но основная команда разработки тоже не стоит на месте, а продолжает разрабатывать код для старой системы. Его становится все больше, а значит, разбираться в нем становится все труднее. Это начинает замедлять команду разработки новой архитектуры, так как весь свежий функционал необходимо перенести. Процесс превращается в бесконечную гонку. Ситуация усугубляется тем, что часто причиной проблем считается не качество кода, а лишь архитектурные и проектировочные решения. Благодаря этому новый код получается того же уровня качества и вскоре начинает страдать от тех же проблем, что и его предшественник.
В итоге новая система поставляется, но с урезанной функциональностью или же гораздо позже запланированного срока. При этом качество кода в ней опять оставляет желать лучшего и все проблемы, описанные ранее, появляются вновь. За время разработки сменились многие члены команды, и кому-то снова приходит идея переписать все заново (мы все считаем, что можем сделать лучше других). Процесс продолжается до тех пор, пока не закончится бюджет или же не лопнет терпение у стороны бизнеса.
Вот к таким последствиям может привести плохое качество кода. Для того, чтобы этого избежать, необходимо предпринимать ряд упреждающих мер:
Следите за своим кодом и вы сможете избежать многих проблем!
Регистрация на конференцию Agileee 2010 в самом разгаре. Также продолжается регистрация на мастер-классы от известных тренеров. При регистрации и оплате до 15-го сентября действуют скидки на мастер-класс «Agile Design: Beyond the basics» с J.B. Rainsberger (стоимость участия ниже на 10% – $495, с 15 сентября – $550). Скидка на групповую регистрацию одной команды – 15% (* скидки не суммируются). Информация о других мастер-классах:
В августе команда Agileee участвовала в конференции Agile 2010 (Орландо, США) – самом грандиозном Agile-событии мира: 1500 участников, более 100 докладчиков, 16 параллельных потоков! Благодаря «людям в шляпах» конференция Agile Eastern Europe стала еще известнее в западном Agile-сообществе, и мы ждем новых гостей. Наблюдения и мысли по этому поводу вы можете найти в группе Linkedin и на Developers. Также доступны видеоролики с ключевыми спикерами Agileee:
XP Injection тоже не останется в стороне. Наши тренеры подготовили доклад на тему «How to be proud when you are done», который уже добавлен в программу конференции. В этом докладе будет рассказываться о понятии критерия завершенности (Definition of Done), его полезности, часто встречающихся проблемах и советах по его внедрению. Также в докладе будет приведено несколько примеров различных критериев завершенности для различных команд и проектов, будет обсуждаться их важность при работе с заказчиком и распределенной командой. Приходите, будет очень интересно!
Начало осени будет очень насыщенным событиями в мире Agile и IT в целом: конференции Agileee в Киеве и IT-Jam в Харькове, тренинги от тренеров с мировыми именами, конференция Agile Days в Санкт-Петербурге. Мы тоже решили не оставаться в стороне и, помимо выступлений на конференциях, организуем несколько тренингов.
12 сентября в Харькове пройдет тренинг “Планирование и оценивание в Agile проекте”. На тренинге будут рассматриваться вопросы сбора и управления требованиями в Agile проекте, планирования на различных уровнях, различные подходы и приемы оценки. Участники смогут на практике опробовать многие техники и убедиться в их эффективности. Тренинг будет полезен разработчикам, тестировщикам и менеджерам проектов. Регистрация на тренинг уже открыта и продлится до 7 сентября. Торопитесь, количество мест ограничено!
25 сентября в Киеве пройдет тренинг «QA в Agile», на котором тестировщики смогут лучше понять свою роль и подходы к работе, которые используются в Agile методологиях. Также им будет предложены несколько рабочих QA процессов в командах, работающих по Scrum. Много интересных презентаций, различные полезные практики и игровые симуляции делают этот тренинг очень познавательным и полезным. Регистрация на тренинг уже открыта и продлится до 20 сентября. Торопитесь, количество мест ограничено!
2 октября в Киеве пройдет тренинг «Continuous Integration на практике». Этот тренинг будет интересен не только разработчикам, но и менеджерам проектов, лидерам команд и руководителям. Благодаря обширной практической части участники смогут не только ознакомиться с основными принципами и подходами в представленной теме, но и получить достаточно практического опыта для внедрения предложенных практик и инструментов в своей компании. Данный тренинг ориентирован не только на Agile проекты, обсуждаемые практики помогут любому проекту вне зависимости от методологии разработки, языка программирования и применяемых инструментов. Будут рассмотрены наиболее современные инструменты для Continuous Integration (TeamCity, Hudson, Bamboo и другие), а также тенденции в развитии такого рода инструментов и сравнительный анализ рынка. Каждый сможет выбрать себе наиболее подходящий инструмент и быстро внедрить его в своем проекте. Регистрация на тренинг уже открыта и продлится до 27 сентября. Торопитесь, количество мест ограничено!
Стоимость участия в каждом тренинге 800 гривен (в оплату тренинга входит обед и кофе-паузы). При регистрации сразу нескольких участников (не менее 3) скидка 10%. Ждем вас на наших тренингах!
Мы используем файлы cookies для различных целей, включая аналитику и персонализированный маркетинг. Продолжая пользоваться сайтом, вы соглашаетесь на использование файлов cookies. Подробно ознакомиться с правилами работы с файлами cookies можно здесь
