В теме 13 ответов, и 11 участников, последнее обновление сделано пользователем 
Виктор Глейм 9 г, 9 мес. назад.
-
Сообщения
-
Вот всё же меня очень интересует опыт людей, реально работавших по Аджайлу (и по Скраму в частности), и то, как именно строилась документация на проекте, в каком виде она присутствовала, как создавалась, как поддерживалась и т.д.
Поделитесь опытом, м? А то только и слышишь в инете споры и обсуждения об отсутствии документации в аджайле..К сожалению не имею большого опыта участия в проектах, разрабатываемых по Agile, но все же вставлю свои пять копеек по поводу "отсутствия" документации на таковых. Документация на Agile проектах ведется, только в минимальных объемах и фиксируется только самая важная, если не критическая для проекта информация. Обязательным условием документации на Agile проектах является наличие читателей, или гарантия того, что документация будет полезна для участников проекта. Под участниками, разумеется, надо понимать всех заинтересованных лиц, а не только разработчиков.К своим словам хочу добавить цитату одного опытного дядьки по имени Andy Hunt:
One of the tenets of agile software development is to avoid needless documentation. That is, if documentation doesn’t provide value, don’t do it: writing documentation for documentation’s sake is a waste of time.That’s because it is common to waste a lot of time preparing low-level, detailed design documents that become obsolete almost immediately. Worse, these sorts of documents generally have no audience—they aren’t serving any useful purpose, other than fulfilling a checkbox to prove that the team “produced documentation.” Because it’s such a wasteful practice, agile teams take a hard look at any documentation they are required to produce to ensure that there’s a genuine need for it. Many people interpret this as “agile developers don’t do documentation,” which is wrong. Agile developers do create documentation, but they use a pragmatic filter to make sure the investment in creating any documentation is really worth the effort. It has to have value.
Сорри за много-букав
На нашем проекте сейчас некое подобие SCRUM (пишу "подобие", потому что из-за специфики проекта от многого пришлось отказаться, например, от того, чтобы каждый самостоятельно общался с product owner-ом (из-за наличия языкового барьера), также есть разделение на роли: есть аналитик, есть QA, есть девелоперы; также фактически отсутствует свободный выбор задач, что обусловлено тем, что к SCRUM мы подошли внезапно, каждый уже со своей задачей, и передать ее кому-то другому было проблематично). С документацией дела обстоят так: на каждую фичу создается небольшая спека (если нет сложной логики вычислений, по размеру такие спеки получаются 15-20 страниц). Есть документ New Functionality Checklist, о котором я писала вот здесь: viewtopic.php?f=8&t=83, он помогает не забывать, какие места новый функционал может затронуть.
Мне повезло, в моей команде есть несколько человек, которые сами неплохо справляются с аналитическими задачами. То есть не всегда на вход им нужно давать детальные требования: можно показать на простом случае, что от них требуется, а со сложными случаями они разбираются сами (при минимальном участии аналитика). И разбираются весьма успешно.
В условиях SCRUM нет времени писать подробные спецификации, поэтому мне кажется ключ к успеху здесь в представлении о реальных возможностях каждого члена команды. Для кого-то есть смысл потратить несколько часов и описать фичу максимально подробно. С кем-то стоит только подтолкнуть — и он сам нагуглит все что нужно. У кого-то лучше лишний раз спросить, все ли понятно, нет ли проблем, если надо — сесть рядом и вместе разбираться.
Что мне не понравилось: к началу нового спринта ситуация такая: все начинают в один день, в том числе и аналитик. Но в том и дело: пока аналитик не подготовит хотя бы высокоуровневое описание того, что нужно сделать, никто не может начать. Вот и выходит, что за 1-2 дня аналитик должен выкатить требований на 2 недели вперед.Личным опытом поделиться не могу: работала только на проекте с некоторым подобием скрам.
На соседних проектах в течении нескольких лет работают по agile методологии.
1. Каждую фичу описывают в виде user story.
2. User story пишут BA.
3. Затем из user stories собирают спринт.
4. Для управления юзер стори используют Mingle.
Т.е. Документация есть, но только для определённого спринта.
Если новый человек приходит на многолетний проект, то для него нет дока описывающего систему вцелом.1. Каждую фичу описывают в виде user story.
А когда это происходит по отношению к спринту: до него или непосредственно во время?
На текущем проекте используется тоже нечто похожее на Scrum (вначале было совсем не похоже, но сейчас приблизились достаточно). Причиной этому вижу высокую степень доверия заказчика. Позиция такова: "Я говорю вам, какая фича мне нужна, а тонкости реализации вы берете на себя. В конце я скажу, нравится мне это или нет".
Итак:
1. Вначале разбили фазу на мелкие Work Packages (название наше), которые были приблизительно одинаковы по часам, объединены тематически, и состояли из более-менее мелких фич.
2. Расставили приоритеты для каждого Package и выбрали первый в списке приоритетов для разработки;
3. Описали первый (т.е. развернули каждую фичу) подробно (но описание не фиксировали, в процессе разработки к нему возвращались и подправляли актуальными сведениями);
4. Собрали фидбек, завалидировали описание, расставили приоритеты для каждой фичи и в путь
5. Как только имлементация фич из данного WP выходит за рамки оценки WP, следующие фичи из него уже переносятся в out-of-scope данного WP;
6. Параллельно описали еще 2 WP;
7. Завели документ с обзором будущих WP/фич для следующих фаз с менее подробным описанием.Ммм.. На мой взгляд, Scrum — не панацея для проектов, где заказчик абстрагируется от деталей реализации фичи. Хотя может и не так выразился. Скорее, другие подходы к организации процесса разработки сработают не хуже, если есть только вышеупомянутое требование. Суть скрама все же немного в другом.. имхо
Интересны следующие моменты:Описали первый (т.е. развернули каждую фичу) подробно (но описание не фиксировали, в процессе разработки к нему возвращались и подправляли актуальными сведениями)
Если не секрет, какую документацию вы для этого использовали и какова степень детальности описания фич?
Да, ты прав тут в отношении Scrum, я не ставила своей целью причесать проект под какую-то методику (на мой взгляд, учитывая все аспекты, тут подойдет больше DSDM, и то не в чистом виде).
По поводу документации и методики мы не используем стандартный шаблон SRS, наоборот выработали собственную структуру документа (по запросу заказчика), где я описываю Use cases, данные (поля/валидация etc) и прикладываю к этому mockups и flowcharts/diagrams, где необходимо. Для сбора комментариев и подтверждения описания мы используем MS Office Live Space, куда есть доступ представителям бизнеса.Вот всё же меня очень интересует опыт людей, реально работавших по Аджайлу (и по Скраму в частности)..
По Аджайлу (имею ввиду Скраму) работать не приходилось. Однако пришлось ставить процесс работы с требованиями после чистого XP.
В свое время уделила достаточно внимания Agile-методологии. Хотелось бы поделится выдержкой из своей статьи, затрагивающей документирование в Agile (хотя, возможно, не совсем уместно).
"Документация в Agile
…одним из отличительных признаков Agile считается легковесность и прозрачность…
…agile-разработкой считается та, которая не перегружена излишней документацией, излишними артефактами и ролями.
… минимум документации – НЕ РАВНО ноль документации.
… в Agile кроме всего прочего обязательным критерием является прозрачность
«…Прозрачность и осознанность – одни из чуть ли не главных особенностей agile-подходов в разработке программного обеспечения…», — А. Кривицкий, лидер укр. agile-сообщества.
…известно, что хорошее документирование – один из инструментов обеспечения прозрачности, т.е. в Agile документация – не в нагрузку, а в помощь.
… документация действительно станет «в помощь», только при условии высокого качества таковой. В Agile качество документации становится одним из решающих факторов успеха.
… все апологеты постоянно напоминают, что в agile нельзя жертвовать качеством. В agile всё должно быть качественным (в том числе – и документация).
«9. Continuous attention to technical excellence
and good design enhances agility», (agile manifesto).Теперь видно, что в Agile документации не просто минимум, в Agile-e она еще и обязательно качественная. Следовательно, если в Agile документации мало, то это не значит, что над ней нужно мало (т.е. недостаточно) трудиться. Наоборот, в Agile над документацией нужно особо тщательно трудиться– а это часто занимает время.
На нечитаемую документацию в Agile просто не остаётся времени."Попробую реанимировать тему
много воды утекло, IIBA выпустил Agile extension к BABOK, каждый популярный аналитический ресурс отметился статьями о роли аналитика в скраме и т.п. — литературы о юзер сториз и вообще статей предостаточно, так что интересует именно практика.
Может кто-то поделиться практическим опытом работы аналитика в скраме ?гм, хорошая очепятка — и scam, и scum имеют довольно негативное значение.Уже нет негативной ассоциации, но интерес к вопросу остался)Тема может уже не ой какая актуальная, но позволю себе вставить своих пару копеек.Jira & Confluence — это то, что необходимо БА в эджайле (будь-то скрам, канбан или еще что…)
Jira:
1) User Stories — из которых формируются эстимейты, собираются спринты, а также которые являются родителями для подзадач (например серверной разработки). Стори пишуться в таком ключе, чтобы любому члену комманды было понятно о чем речь, начальное и конечное действие, а также в конце формируются Acceptance Criteria, по которым БА принимает задачи и закрывает спринт.
2) Tasks — задачи, которые по каким-либо причинам были упущенны, обнаружились в процессе разработки и т.д..
3) Bugs — тут все понятно, в спринт или мимо него летят баги, которые заводит как БА (Acceptance Testing по User Stories) так и КУА (все остальное). Баги заводяться по принципу тикетов определенным девелоперам с описанием Step to reproduce, Actual Result and Expected Result. Прикрепляеться скрин или лог и на этом баг улетает девелоперу.
Confluence
1) Документы описывающие архитектуру приложения
2) Документы с нефункциональными требованиями
3) Документы с вводной информацией от заказчиков, митинг ноуты
4) Элементы UI (прототипы, лого, наброски…)
5) QA — результаты различных видов тестирования (Smoke, Load, Network etc.)
и т.д. и т.п.
Таким образом, вся документация оформляется, храниться и передаеться через даные инструменты, что я считаю очень удобным и оправдывающим себя на практике.
Недавно интересовался схожим вопросом в группе аналитиков на FB.
Вы должны авторизироваться для ответа в этой теме.
