• [I-15530] По итогам спринта закрыто 5 историй с плановыми оценками в 9 чел-ч
• [I-15543] Странное поведение трудоемкости при выполнении задач...

• [I-15431] Некорректное отображение столбца в отчете о тестировании по версиям
• [I-15434] Если в качестве методологии проекта задан Канбан, невозможно списать время на задачу. Кнопка "Сохранить"...
• [I-15437] В отчете по затраченному времени дублируется списанное время
• [I-15447] Не удается повторно запланировать пожелание с задачами

• Scrum (Jeff Sutherland and Ken Schwaber – also Mike Beedle)
• DSDM (DSDM Consortium represented by Arie van Bennekum)
• ASD (Jim Highsmith)
• XP (Kent Beck, Ward Cunningham and Ron Jeffries – Martin Fowler)

Ниже приводятся основные вехи в становлении Agile-движения, с упоминанием всех основных его участников.

1992 – Crystal Methods

Семейство методологий Crystal послужила отправной точкой в развитии методологий разработки программного обеспечения, что в итоге привело к тому, что мы сейчас называем Agile-движением. Честь создания Crystal принадлежит Алистеру Коберну (Alistair Cockburn). Методология была названа Crystal в 1997 году. Методология может быть применима к командам, состоящим из 6 - 8 участников, расположенных в одном месте, работающих над созданием программных систем, не являющихся критичными для жизни пользователей. Вы можете обнаружить зачатки Agile-манифеста в методологии Crystal, поскольку она фокусируется на: Частой поставки работающего кода конечным пользователям. Разумных улучшениях. Всепроникающей коммуникации (osmotic communication) между членами команды, расположенными в одном месте. Под всепроникающей коммуникацией подразумевается непосредственная передача информации, в том числе путем подслушивания или наблюдения за вещами, происходящими вокруг. Вы можете познакомиться с публикацией Notes on the writing of the agile manifesto. В настоящее время он является консультирующим партнером в основанной им компании "Humans and Technology".

1993 – Refactoring

Термин "Рефакторинг" (Refactoring) впервые ввел Bill Opdyke в статье под названием "Creating Abstract Superclasses by Refactoring". Вот как рефакторинг описывается в Википедии: процесс изменения внутренней структуры программы, не затрагивающий её внешнего поведения и имеющий целью облегчить понимание её работы. В настоящее время он занимает позицию Arcitecture Lead в компании JPMorgan Chase.

1994 – Dynamic Systems Development Method

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

Arie van Bennekum является одним из автором Agile-манифеста и принимал активное участие в работе консорциума DSDM начиная с 1997 года. DSDM фокусируется на восьми основных принципах: Фокус на потребностях бизнеса Поставлять во время Взаимодействовать Никогда не снижать качество Создавать постепенно с самых основ Разрабатывать итерационно Непрерывно и ясно общаться Демонстрировать управляемость И вновь вы можете видеть основы Agile-манифеста.

1995 – Scrum and Pair Development

SCRUM был разработан совместно Джефом Сазерлендом (Jeff Sutherland) и Кеном Швабером (Ken Schwaber), которые представили доклад на конференции OOPSLA ’95 в Остине штат Техас. Джеф Сазерленд занимает пост CEO в компании Scrum, Inc. Кен Швабер является основателем Scrum.org. Mike Beedle был одним из первых евангелистов Scrum и внедрил эту методологию во много организаций, начиная с середины 90-х. Как вы знаете, Scrum является фактически стандартом де-факто для гибкой разработки. В настоящее время он основатель и CEO в компании Enterpise Scrum.

Парное программирование как концепция была описана одновременно и независимо несколькими авторами. Jim Coplien опубликовал статью “A Development Process Generative Pattern Language”, в которой содержится описание паттерна “Разработка в парах”. В настоящее время он обучает применению практик Lean и Agile в разработке программного обеспечения в Дании.

Larry Constantine писал о “Dynamic Duos” в своей книге “Constantine on Peopleware”, опубликованной в том же году. Данная концепция стала составной частью методологии Extreme Programming. Независимо от того, что было выполнено несколько исследований, демонстрирующих эффективность программирования в парах, данная концепция не нашла реального отражения в Agile-манифесте.

1997 – Feature Driven Development

Методология Feature Driven Development (FDD) изначально была разработана Jeff De Luca. Основные практики, описанные в FDD, следующие: Моделирование объектной модели домена. Разработка на основе фич. Индивидуальное владение кодом. Команды, организованные по фичам. Инспекции. Управление конфигурацией. Регулярные сборки продукта. Видимость прогресса и результатов. Интересно то, что практика индивидуального владения кодом вступает в противоречие с концепцией коллективного владения кодом, что сегодня является ключевой практикой. В настоящее время он возглавляет консалтинговую компанию Nebulon.

Процесс разработки ПО по методологии FDD был представлен миру посредством публикации книги "Java Modeling in Color with UML: Enterprise Components and Process", где Джеф выступил в соавторстве с Питером Кодом (Peter Coad). Питер основал компанию TogetherSoft, которую затем продал компании Borland. Jon Kern, один из авторов Agile-манифеста, работал совместно с Джефом и Питером и помогал формировать концепцию FDD. Вот его заметки “Agile Manifesto Notes – Feb 2001, Snowbird, Utah“.

1999 – Adaptive Software Development

Jim Highsmith сформулировал концепцию Adaptive System Development и опубликовал книгу с таким же названием. Идея выросла из его работы на методологиями быстрого создания приложений (RAD). Он предложил три фазы жизненного цикла: Speculation Collaboration Learning Также он написал историю того, как был сформулирован Agile-манифест. Сейчас он работает старшим консультантом в компании ThoughtWorks.

The Pragmatic Programmer

Andrew Hunt опубликовал свою книгу "The Pragmatic Programmer: From Journeyman to Master". В книге описаны характерные черты прагматичного программиста, который является: Early adopter (человек, начинающий приобретать новый товар или использовать новую технологию вскоре после появления товара/технологии, т. е. на ранних этапах жизненного цикла товара/технологии) Любознательный и пытливый. Критически мыслит. Реалист. Эрудирован и не обязательно специализируется в чем-то конкретном. Соавтором этой же книги выступил Dave Thomas. Если вы пройдетесь по детальному списку рекомендаций как стать прагматичным разработчиком, то обязательно найдете влияние на Agile-манифест. Вот и его история о том, что произошло в феврале 2001 года: Some Agile History

Extreme Programming, User Stories, Release Planning and Continuous Integration

Во время работы в Chrysler Кент Бек (Kent Beck) разработал концепцию экстремального программирования (Extreme Programming). Он опубликовал этот метод в 1999 в книге - Extreme Programming Explained. Частью Extreme Programming является концепция историй пользователя (User Stories) и планирования релиза (Release Planning). Данная методология описывает лучшие практики в сфере планирования, управления, проектирования, кодирования и тестирования. Ward Cunningham и Ron Jeffries также привнесли свои идеи, так что все трое считаются основателями метода XP.

Некоторые думают, что Мартин Фаулер (Martin Fowler) ввел термин "непрерывная интеграция" (Continuous Integration), однако на самом деле термин CI также был введен Кентом Беком. Вот его воспоминания на тему создания Agile-манифеста: “Writing The Agile Manifesto“. Он называет себя автором и спикером и работает в ThoughtWorks.

2000 – События ведущие к манифесту

Bob Martin проявил инициативу и взялся за организацию, ставшей исторической, встречи, прошедшей в феврале 2001 года на горнолыжном курорте. Он является владельцем Uncle Bob Consulting.

2002 – Новые идеи в Agile

Test Driven Development

Благодарность за TDD идет к Кенту Беку. Концепция разработки через тестирование изначально появилась в XP, в виде подхода "сначала тест". Чуть позже эта техника была описана более подробно Кентом в его книге: Test Driven Development: By Example.

Planning Poker

Концепция игры в планирование (Planning Poker) была сформулирована James Grenning. Вот исходная статья. Он является основателем компании Renaissance Software Consulting.

2003 – Lean Software Development

Является ли практика бережливой разработки ПО расширением Agile-методологии? Должны ли мы рассматривать эту практику как нечто отличное от Agile? Нужно ли здесь упоминать об этой практике? Я включил эту практику по той причине, что многие последователи Agile считают ее будущим развитием Agile-движения. В любом случае, термин был введен Мэри и Томом Поппендик в 2003 году. Это адаптация бережливых принципов производства к разработке программного обеспечения. Рассматриваются 7 принципов: Устранять расходы Усиливать обучение Принимать решение как можно позже Поставлять как можно раньше Оказывать поддержку команде Встраивать целостность Видеть картину в целом

--

Оригинал статьи на английском языке вы можете найти на сайте автора: http://agilescout.com/history-of-agile-t[...]ncers-and-drivers-of-the-agile-movement/

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

1. Работа нескольких команд в одном релизе или итерации

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

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

2. Настройка внешнего вида и поведения

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

При создании пользовательских атрибутов можно указать признак уникальности, таким образом, при сохранении объекта система будет проверять, что значение в этом поле должно быть уникальным среди всех объектов того же типа. Теперь отдельно для каждого типа требования можно задавать свои индивидуальные пользовательские атрибуты.

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

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

3. Работа с требованиями и тестовой документацией

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

 Текст, текст, текст
 Страница не найдена: R-123
 Текст, текст, текст

где R-123 является идентификатором страницы.

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

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

4. Burndown и новые отчеты

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

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

В системе появилось несколько новых отчетов:

• Отчет с результатами тестирования с детализацией по сценариям. Для отображения отчета необходимо открыть ссылку "Результаты" на закладке "Тестирование" и в фильтре выбрать представление "Детальный".
• Отчеты по продолжительности этапов обработки различных артефактов проекта: историй, задач, требований, тестовой и пользовательской документации и т.п.
• Распределение количества коммитов по разработчикам.
• Частота коммитов в разрезе разработчиков.

Полный список выполненных доработок и исправленных ошибок

• [I-14579] Можно ли в пользовательских атрибутах кроме обязательности поля добавить еще признак уникальности?
• [I-13399] Доработки по burndown и метрикам
• [I-13863] Есть ли возможность настроить напоминание о...
• [I-13877] Доработки по управлению вехами (milestones)
• [I-13951] С т.з. администрирования было бы очень удобно, когда в резервных копиях еще бы отображалось поле...
• [I-14286] Вы не планируете сделать возможность редактирования комментариев?
• [I-14516] Как настроить, чтобы пожелание автоматически не переводилось в «Выполнено», если все задачи по нему были...
• [I-14709] Пользовательские атрибуты должны настраиваться на вид требования
• [I-14969] Возникла потребность использовать создавать комплексные требования и глоссарий.
• [I-14996] Так же при настройке адреса техподдержки для пункта "Способ подключения" выпадают на выбор странные...
• [I-15049] Отображение артефактов, подготовленных в спринте
• [I-15050] Разделение между проектами задач, итераций и релизов
• [I-15051] Убрать ICQ, Skype и другие контактные атрибуты из базы данных, значения перенести в кастомные атрибуты...
• [I-15052] В режиме просмотра истории изменений Wiki добавить возможность выбора представления (с учетом форматирования или без...
• [I-15053] Позволять отключать секции справа через настройки фильтра
• [I-15058] Настраивать перечень столбцов, отображаемых на доске пожеланий или задач
• [I-15081] Добавить множественные операции на файлы
• [I-15086] Excel: импорт/экспорт требований, тестовой документации и пользовательской документации
• [I-15093] Отображение Release Burndown (Product Burndown) при использовании задач
• [I-15100] Удобно, если бы строка таблицы...
• [I-15131] Анализ целостности таблиц и автоматическое восстановление
• [I-15138] Доработка инсталлятора
• [I-15158] Задача - увидеть срез состояния выполнения всех тесткейсов на текущий момент.
• [I-12396] Поиск по словосочетанию дает очень много лишних результатов, из-за чего невозможно найти то что...

Stay tuned!

http://facebook.com/devprom

• [I-15110] Создание сборки в явном виде.
• [I-15091] Глюк при замене картинок в редакторе elRTE (возможно и в CKEditor тоже).
• [I-15115] Коды сообщений Devprom

• [I-15073] Визуализация страницы раздела (требования/док-ции/..),... 1я часть
• [I-15074] Нужна возможность указать только логин участника проекта для подключения к SVN
• [I-15075] Правильный выбор дефолтной итерации
• [I-15054] При одновременном использовании нескольких подключений к SCM в списке ревизий некорректно отображается выпадающий список подключений

• [I-15002] Небольшой глюк. Открываем вкладку Задачи. В Фильтрах "Итерация:все". Списка задач нет.

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

WYSIWYG редактор в описании пожелания

В "легких" методологиях, где не обязательна глубокая проработка требований или создание подробных спецификаций (BRUF, Big Requirements Up Front), процесс управления требованиями превращается в создание/уточнение историй пользователей и процесс управления баклогом продукта.

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

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

Несколько репозиториев в одном проекте

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

Теперь можно указать индивидуальные параметры подключения к репозиторию для каждого участника проекта, что с одной стороны позволяет разграничить доступ к различным каталогам в репозитории, а с другой - связать выполненные изменения с конкретным участником проекта. Например, это может пригодиться при списании времени на истории пользователей в комментарии к комиту, например, I-123 #resolve #time 3h

Множественный выбор значений в фильтрах

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

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

Дополнительные настройки Workflow

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

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

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

Самодиагностика приложения

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

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

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

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

Полный список выполненных доработок и исправленных ошибок

• [I-12843] Добавить больше диагностики о потенциальных проблемах
• [I-13002] Доработки по интеграции с системами контроля версий
• [I-13204] WYSIWYG редактор в описании пожелания
• [I-13314] Зависимости между задачами и пожеланиями не ограничивают действия
• [I-13407] Будет крайне полезна возможность переноса (копирования) требований в другой проект (а еще...
• [I-13462] Встроить возможность множественного выбора в настройках фильтра
• [I-13497] Необходимо в настройках переходов задавать перечень сбрасываемых полей
• [I-13537] Для пользовательских полей добавить тип...
• [I-13542] Описать в документации варианты подготовки состава релиза
• [I-13598] Описание в документации начальный импорт историй из Excel
• [I-13743] Смягчение ограничения Kanban доски
• [I-13758] Можно ли добавить возможность упорядочивания релизов в обратном порядке? Т.к. чаще приходится поднимать что-то...
• [I-13944] Невозможно установить при занятых IIS портах
• [I-13952] Отображать подсказку с расширенным описанием задачи на доске задач по аналогии с доской пожеланий.
• [I-14116] Есть пожелание такое - когда редактируем документ...
• [I-14147] Хочется при просмотре или редактировании...
• [I-14258] Подскажите, можно ли сделать так, чтобы в отчете "Затраченное время", когда формируем по задачам,...
• [I-14339] Сделать зеленую линию Burndown более чувствительной к переоценке пожеланий в процессе работы над ними
• [I-14740] Как можно перетащить все незаконченные задачи из одного спринта в другой одним махом?
• [I-14384] Формат отображения даты брать с сервера, а не чтобы зависел от языка интерфейса
• [I-14512] Ложное предупреждение блокировки задачи. После...
• [I-14783] Редактирую страницу в базе знаний (на...
• [I-14848] В истории изменений требования не...
• [I-14855] Раньше совершенно точно можно было оценивать истории в бэклоге прямо в бэклоге.
• [I-4384] Обработка почтовых ящиков по IMAP
• [I-12739] Очень сильно не хватает возможности дать осмысленное название зафиксированному набору пожеланий.
• [I-13787] Управление порядком выполнения задач не видно в настройках методологии
• [I-14497] При переносе задачи часть которой уже выполнена из одной итерации в другую

Stay tuned!

http://facebook.com/devprom

• [I-14799] Групповые операции с задачами. Операция "изменение версии". Не формируется выпадающий список версий.
• [I-14842] Попытка изменить в отчете номер спринта на 1.10 ни к чему не приводит.