JIRA issue tracker -> Автоматическая рассылка e-mail
2009-07-24 10:47 FruIT
Добрый день. Недавно создал новый workflow для проекта. Появилась потребность рассылки e-mail, для тех, кто подписаны к данному заданию :) 1. Выставляем задание, проходит 2 дня, а человек, которого мы подписали под это задание не отвечает, и ничего с этим не делает, так вот, после 2х дней без перехода на след. статус этого человека надо уведомить, чтобы он что-то предпринял. 2. Похожая ситуация, можно сказать идентичная - только проходит 7й дней без перехода на след. статус и тоже надо всем об этом рассказать.
Тестирование защищенности во многом напоминает деятельность хакеров (кракеров), овеянную легендами и окруженную таинственностью. Этот вид тестирования, в отличие от всех остальных, позволяет наиболее полно раскрыться деструктивным наклонностям, которые многие считают одной из отличительных черт характера тестировщика. Здесь это стремление сломать действительно уместно и даже в какой-то мере необходимо. На этом семинаре мы рассмотрим три наиболее распространённые разновидности уязвимостей веб-приложений -- кросс-сайтовое выполнение скриптов (cross-site scription, XSS), внедрение несанкционированных SQL_запросов (SQL injection) и внедрение вредоносных файлов (File injection). Для каждого вида уязвимостей будут продемонстрированы способы их обнаружения и описаны способы защиты.
Стоимость участия в семинаре для физических лиц менее 700 рублей.
Тестировщикам (и не только им, конечно) иногда приходится работать в сильно зарегулированной среде -- крупные компании, государственные или военные заказы, требования SOX или CobiT. В такой ситуации естественно существует масса инструкций, регламентов, требований по соблюдению стандартов. А нужны ли стандарты всем остальным, над кем не нависает дамоклов меч аудита? Можно ли извлечь из них какую-нибудь практическую пользу? Да, можно. Изучение стандартов ничуть не хуже изучения любых других источников -- книг или статей в журналах. Просто они написаны специфическим языком, и это затрудняет их чтение. Но вообще-то авторы стремились описать в них полезные и хорошие практики, почему бы не использовать их, отделив от шелухи и мусора слов. Мы рассмотрим наиболее близкие к деятельности тестировщиков стандарты: ГОСТ Р ИСО 9126-93 "Оценка программной продукции характеристики качества и руководства по их применению" и его прототип ISO 9126 "Software engineering -- Product quality", ГОСТ 28195 "Оценка качества программных средств", IEEE 829-1998 "Standard for Software Test Documentation", ISO/DIS 31000 "Risk management -- Principles and guidelines on implementation". Кроме того, будет уделено внимание широко распространённым моделям разработки программного обеспечения Rational Unified Process (RUP) и Capability Maturity Model (CMM/CMMI) применительно к тестированию.
Стоимость участия в семинаре для физических лиц менее 700 рублей.
Управление проектами -> Kanban vs. Scrum
2009-07-24 16:03 belonesox
7 июля в прошло очередное собрание сообщества AgileRussia, посвященного занимательнейшей теме – сравнению методологий разработки Scrum и Kanban. И если Scrum уже начал терять ореол свежести и модности, уже накопились претензии не от тех, кто «Пастернака не читал, но осуждает», а от реально практикующих Scrum в течение пары лет, то Kanban – штука в софтверной индустрии новая, и при этом не выдуманная заумь от софтверных методологов (или даже целых Институтов Программирования), а реальная практика, пришедшая из японского автомобилестроения – индустрии, уважаемой большинством программистов, даже не ездящих на «японках».
Кстати, обычно практики приходящие в софтверный инжиниринг из реальной инженерии (строительство, машиностроение, …), отличаются тяжеловесностью, обилием сложных правил и ограничений, содержат строгую специализацию по ролям – ведь в реальном мире все это действительно оправдано, и отклонение от СНИПов и прочих строительных ГОСТов, нарушение последовательности строительных операций, и т.п. – почти гарантированно приводят к проблемам, а зачастую и к катастрофам с человеческими жертвами. В софтверной же индустрии, используемый при построении информационных систем и других сложных программ «материал» – операционные системы, библиотеки, фреймворки – не менее сложен, чем сталь или бетон, но при этом более гибок, – например, для информационной системы можно (хотя и сложно), без последствий для пользователя, полностью или частично заменить фундамент – сменить используемые библиотеки или даже архитектуру. Поэтому «классическое управление проектами», с диаграммами Ганта и безликими человеческими ресурсами плохо работает в разработке ПО, где для эффективной работы в первую очередь надо сосредоточиться на удобстве командной работы, учитывая психологию разработчика (по отдельности и в группе), минимизируя ручные операции, исключая ненужную работу, т.е. всеми возможными способами повышая мотивацию участников и исключая «узкие места» процесса. Собственно успех Agile-практик показывает, что мораль Крыловской басни «...а вы друзья, как ни садитесь...» к софверной разработке не очень применима, а вот применим скорее сюжет фантастического рассказа «Побег» (из сборника «Лавка сновидений» Ильи Варшавского), где удалось радикально поднять производительность уборки хлопка у заключенных, просто убедив их, что они свободны, и собирают «белые цветы радости».
Этим и объясняется успех Scrum-а для измученных нарзаном RUP-ом или MS Project-ом. Но с другой стороны, у многих, особенно у пришедших к Scrum-у от «методологии Бей и беги Code-and-Fix», возникает много претензий к Scrum-практикам – можно ли еще упростить? Можно ли выкинуть еще один (детский? туземный?) ритуал? …
Так вот, пришедший из автомобилестроения Kanban несет в себе дух Lean-практик, избавляющихся от любых ненужных ритуалов, и содержит в себе всего 3 правила! Сравните с 9 правилами Scrum или более, чем 120 правилами RUP. Неудивительно, что зал нашей компании был полон ПиЭмами, интересующимися – решит ли Kanban их проблемы со Scrum? Можно отказаться от итераций, планирования и жесткого time-boxing-а, не потеряв при этом управляемость и прозрачность процесса?! А, может, как часто бывает, «истина где-то посередине» – и оптимальным будет именно сочетание Scrum и Kanban?
Далее мы представляем видеозапись обсуждения в четырех частях (где-то по часу каждая). Да, обсуждение было настолько захватывающем, что народ не расходился практически до закрытия метро.
Правда мы должны предупредить читателя, что перед тем как смотреть видео, лучше выполнить домашнее задание и прочитать-пролистать вводные материалы по Kanban (собственно это заранее и проделали все собравшиеся):
Ну, а если лень, то тогда наверное лучше начать со второй части видео, где все-таки рассказывается об основных принципах и происхождении Kanban и проводится соотнесение его практик с Scrum.
В целом, содержание видео следующее. Первая часть – вербализация проблем Scrum, которых собравшиеся надеялись решить через Kanban. Была исписана целая [s] стена плача[/s] маркерная доска, где были и здравые надежды и претензии типа «...доктор, я смогу после операции играть на скрипке?...», а советы по лечению, под стать вопросам, отсылали даже, скажем, к сексуальным играм для взрослых.
Кратко ключевые слова из этих проблем, ставшие «меню» этой встречи:
«Проектная аритмия» (сбивается ритм демо, планирований, ретроспектив) — разный ритм участников разработки (включая заказчика).
«Проблема счастливой семейной жизни» — waste времени на ретроспективы.
«Дефицит Product Ownerов» — они могут стать критическим ресурсом.
«Расслабляющая команда», «Деградация через самоорганизованное командой уменьшение Scope».
«Трудно форсировать Аврал».
Далее была лекционная часть-ликбез, про историю, происхождение и основные принципы Kanban. Если вы осилили предложенные ранее ссылки – вполне можно пропустить без особого ущерба.
Ну и далее два часа горячего обсуждения, когда проверяли, сможет ли Kanban вылечить диагнозы, записанные Доктором Agile на доске при, так сказать, коллективном дифференциальном диагнозе. Тоже местами было более чем живо, где например услышишь о уставе боя танковых колонн.
Возник вопрос такого плана. Для заказчика требуется предоставить sla-документацию по тому, что может аутсорсинговая компания по обслуживанию компьютерных сетей. Вопрос, где найти пример такой документации? Есть общие требования, а примеров не нашел.
Тестирование ПО -> Scrum, Kanban и т.д. для отдела тестирования
2009-07-26 21:55 novak
В свете поднятой темы про Scrum и Kanban возник следующий вопрос: не сталкивался ли кто-нибудь с подобной организацией работы не маленькой команды разработки всё-в-себе, а именно команды тестирования? Возможно, есть какие-то особенности, противопоказания или же наоборот, бенефиты от применения таких гибких подходов для более специализированной деятельности, нежели разработка в целом.