Всем привет! Продолжаю тему постов про подход к сбору требований под названием Spec By Example. Я уже делал вебинар про общие ценности данного подхода (о нем чуть ниже), а сегодня хочу показать как оно на работает на примере достаточно простого, на первый взляд требования. Самого требование звучит очень просто:

В системе должно отображаться уровень заполненности склада за счет отображения количества товаров каждого типа. При отгрузке/приеме товаров значение должно обновляться.

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

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

Итак, вы хотите стать DevOps? Хорошо, но прежде чем начать, давайте взглянем на некоторые вещи, которые вы не должны делать.

В старые добрые времена, мы просто называли их «плохие идеи», но появилась дипломатия и политкорректность, ушел «мозговой штурм» и появился «idea shower», а вместе с ним и слово «анти-паттерны».

Если «паттерн» это правильный путь, то по своей сути «анти-паттерн» является неправильным — и поэтому, чтобы не дать вам пойти неверным путем, мы составили этот список (с небольшой помощью DevOps сообщества).

«Покой — это ложь. Есть только страсть.
Через страсть я познаю силу.
Через силу я познаю могущество.
Через могущество я познаю победу.
Через победу мои оковы рвутся.
И Великая Сила освободит меня.»
— Кодекс ситов

Я хочу поговорить о темной стороне кода и о том, к чему это приводит. Что я понимаю под темной стороной кода? С моей точки зрения — это такой код, который был написан программистами, которые поддались желанию написать кое-как, исходя из своих собственных целей, а не целей продукта. Они оставили покой (размеренное написание кода согласно практикам) в угоду страсти (код ради кода). А если есть темная сторона, то есть и ее представители — Темные властелины, Дарты. Вот о них мы сегодня и поговорим.

(Продолжение перевода, первая часть здесь)

8. Как Infosec и QA интегрируются в поток работ DevOps?

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

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

От переводчика

В 2009 года за рубежом возникло движение, которое назвало себя DevOps. На первый взгляд это разработчики с навыками сисадминов и сисадмины с навыками разработчиков. Но на самом деле это отнюдь не так. Данное подход имеет четкие цели, философию, инструменты и методы, которые только некоторые русскоязычные компании начинают использовать. Мне кажется, что данный подход у нас незаслуженно игнорируется и мне хотелось бы рассказать об 11 вещах, которые нужно знать о DevOps, в частности:

• что такое DevOps
• каковы его ценности
• как он внедряется
• кому он приносит пользу

Надеюсь, этот текст вам понравится.

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

• А почему ты перестал быть программистом?
• Как ты можешь учить, если сам не кодишь?
• Неиграющий тренер?
• ваш вопрос

Что самое главное — вопросы такого типа нельзя считать на 100% троллингом, все они обоснованы. Чтобы как-то ответить на эти вопросы и было решено стартовать этот проект. Проект частично будет обучающим (будет рассмотрены техники XP и гибкого тестирования), частично развлекательный, частично направленный на развитие сообщества и так далее. Больше подробностей под катом.

От переводчика. Вопрос о том, нужно ли давать премии, бонусы и прочие плюшки достаточно остро стоит во многих организациях. Я бы хотел представить 6 советов по данной теме от Юргена Аппело, автора книги Management 3.0. Юрген занимает 6 место в рейтинге самых влиятельных людей в Agile (гибкая разработка), а его блог признан третьим по популярности блогом в Agile мире. Подход Юргена очень занимателен и, что самое главное, рационален. «Ваша карьера — это ваша обязанность. Ваш работодатель — не ваша мама,» — говорит Юрген.

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

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

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

Додзё — это место, где мы дисциплинируем и совершенствуем себя, чтобы стать лучше.

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

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

Я столкнулся с командами в нашей организации, которые пытаются внедрить Test Driven Development (TDD).Иногда одному или двум разработчикам удается применить его без посторонней помощи, но у большинства этого не выходит. Чтобы лучше понять проблему я провел опрос среди членов команды и обнаружили, что даже после обучения еще многое предстоит сделать. Эта стратегия была разработана, чтобы помочь любому внедрить TDD в организации, хотя некоторые из идей применимы лишь для средних и крупных компаний.

Один из основных вопросов, которые задают себе участники почти всех тренингов — «Что мне с этим делать дальше?» Безусловно, на этих тренингах рассматривается много полезной информации, участники практикуют новые навыки, но все же реальные проекты сильно отличаются от тех, которые рассматриваются на обучении. Мы бы хотели изменить такую ситуацию и представляем вам анонс двух принципиально новых тренингов:

• Использование практик XP для спасения проектов от 2 лет и более
• Тестирование взрослых проектов: от стабильной боли к стабильному качеству с помощью XP практик

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

20 сентября состоится очередная встреча AgileRussia. Она пройдет в экспериментальном формате Jam Session и нашим гостем в этот раз будет Дэвид Хассман (консультант по организации процессов и продуктовому менеджменту, DevJam). Знание английского языка — понадобится.

Что это такое?

Что такое Jam Session? Как говорит сам Дэвид, это Бойцовский Клуб мира разработки ПО. Первое правило Клуба — никому не говорить о… ну, вы знаете. В общем, каждый новый участник должен поделиться с другими своим мнением или опытом. При этом желательно, чтобы участник не был экспертом. Ну, и самое главное — общение на заданную тему с другими участниками.

Обычно нам достаточно сложно определиться с темой для следующей встречи. Мы набираем список, голосуем, но некоторые темы постоянно оказываются вне нашего внимания. Формат Jam Session позволит обсудить пять-шесть тем в рамках одной встречи. И мы ждем их от вас! Все что нужно — это подготовить мини-доклад на 15-20 минут о том, чем бы вы хотели поделиться с другими или что бы хотели обсудить. Присылайте мини-презентации на почту.

Осталось 9 дней до старта конференции Agiledays Санкт-Петербург. Что нас ждет:

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

Итак, окончательный формат:

• Один поток Keynote-спикеров. В основном на английском языке.
• Второй поток — доклады на русском языке.
• Третий поток — полуторачасовые мастер-классы

Адрес и место проведения: Отель Азимут, Санкт-Петербург

Подробнее о докладах...

#1 Being agile at Microsoft patterns & practices. Григорий Мельник, Microsoft
Очень интересный доклад от нашего бывшего соотечественника, ныне проживающего в США и работающего в компании Microsoft. Григорий расскажет историю о том, как в Майкрософт столкнулись с практиками Agile в то время, когда когда их еще называли Легковесными (light-weight), во времена до создания Agile Manifesto. Григорий поделится своими мыслями о том, как Agile-подходы влияют на людей, поставку софта, а так же об экономической целесообразности внедрения Agile. Этот доклад является ключевым и откроет сцену «Keynote спикеров».

Разговоров про Agile так же много, как и книг, но вопрос, как сделать разработку гибкой и эффективной в конкретной компании, порождает кучу дискуссий. Как показывает практика и предыдущие посты на Хабре об Agiledays и встречах сообщества Agilerussia, интерес к данной теме не угасает. Именно поэтому мы продолжаем делать конференции, связанные c вопросами организации процессов разработки.

Можно поздравить жителей северной столицы — Agiledays добрался и до их города.

Я думаю, рекламировать Agiledays не имеет смысла. Скажу только, что это уже третий раз за последний год, когда мы собираемся вместе (Москва, Екатеринбург), чтобы обсудить современные подходы управления разработкой ПО.

Когда?

Произойдет это все в одной из петербургских гостиниц 17 сентября.
Будет несколько потоков: один или два основных потока с докладами и параллельные сессии мастер-классов и  open space’ы.

Поводов собраться у нас более чем достаточно

К нам на конференцию приезжают:

Как так получилось?

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

Где и как все будет происходить?

Происходить это будет в Екатеринбурге 4 июня 2010 года
в отеле Novotel. Екатеринбург очень красивый город — один из крупнейших и старейших городов Урала.

Мы таки решились на новую встречу сообщества AgileRussia.
Думаю Agile-практики хорошо отдохнут и будут готовы снова обсуждать современные подходы к разработке ПО.

Когда?

Итак, 12 мая 2010 года состоится очередная встреча AgileRussia на тему «Agile-инструменты»

О чем будем разговаривать?

Многие из нас читали книги про Agile. Их много, все они разные, но их объединяет один очень важный момент: они рассказывают нам, что нужно делать. Но крайне редко в них можно найти совет, с помощью каких инструментов.

Зачем мы это сделали?

Многим известно, что практики Agile/Scrum просты на бумаге. Каждый, кто читал про Agile, может расказать все принципы и практики всего за каких-то полторы минуты (а то и меньше). Однако, не смотря на простые правила организации Agile-процесса, нередко допускают большое количество ошибок. Это приводит к тому, что у вас получается ScrumButt.

Поэтому мы решили написать чеклист по Agile-процессу, основанный на нашем опыте. Он поможет разобраться с базовыми вещами и не наступить на типичные «Грабли» совершаемые большинством команд.

24 марта 2010 года состоится очередная встреча AgileRussia на тему «Архитектура в Agile»

Встреча будет состоять из трех частей:

• Роль «Архитектор», её особенности в Agile, взаимодействие с командой и PO;
• различные подходы к проектированию (эволюционный дизайн, сверху-вниз, снизу-вверх), их влияние на Agile-процесс, ограничения применимости;
• беглый обзор наиболее популярных технических практик: Test-Driven Development, Behavior-Driven Development, Domain-Driven Design.

Архитекторы, ведущие разработчики, тим-лиды, PM — приходите, обменяемся мыслями, соображениями и опытом.

Место и время проведения: 24 марта, 19:00, центр Москвы, офис компании Заказные ИнформСистемы

Условия участия: Бесплатно. Регистрация обязательная. Просто заполните регистрационную форму.

P.S. — Большое спасибо коллегам из CustIS за предоставленное помещение.

Немного об Agile и офисе

Недавно прошел тренинг Agile Development with Scrum и 2-х дневный workshop (тренингом не совсем это назовешь — 50% времени этого тренинга работа с живими документами и генерацией артефактов для получения информации о проекте) по сбору требований в Agile — REQ-Agile Requirements Analysis.

Было достаточно интересно. Первый тренинг проходил почти в виде круглого стола. В течении 4 часов мы обсуждали Agile — что это такое, почему подход рекомендует те или иные практики. Пришли к тому, что магии особой в этом нет и это здравый смысл в организации работы проектов.

Один из участников приятно отозвался об этом тренинге

Москва – управление требованиями и Scrum

10 февраля в Москве будет однодневный тренинг по Scrum. Сразу за ним 11–12 февраля двухдневный тренинг по требованиям в Agile (Agile Requirements). Вести тренинги будет Никита Филиппов.

Что будет интересного?

• Управление продуктом
• Жизненный цикл требований от концепции до (пере-)планирования релизов.
• Разберемся с User Story и еще одним инновационным методом – Story Mapping.
• Изучим контракты с фиксированной ценой и T&M
• Затронем вопрос «полезных» метрик.
• Ну и куча всего другого полезного
  

Стоимость тренинга — 3000 рублей за AD-Agile Development with Scrum и 16000 рублей за REQ-Agile Requirements Analysis.

Екатеринбург – Scrum и Test Driven Development

Еще на февраль планируется набег на Екатеринбург при поддержки компании Microsoft и «СКБ Контур». 11 февраля будет однодневный тренинг по Scrum. Его будет читать Асхат Уразбаев. А сразу за ним – однодневный тренинг по Test Driven Developement от Дмитрия Лобасева.

Тренинг по Scrum стоит 2000 рублей, по TDD — 6000 рублей