Dev[elopment of] Art[ifacts]

У нас в каждом митинг руме висит табличка: «Is this meeting AAA? Attendees, Agenda, Action». Как и концепции S.M.A.R.T., этот девиз позволяет «сохранять фокусировку». Методология Agile органично стала частью моей проф. деятельности. Почему?

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

В соответствии с концепций постоянного улучшения процессов, я старался сформулировать для себя нечто аналогичное, но с уклоном и специализацией в сторону разработки программного обеспечения. И если обратиться к первоисточникам то это проекция некоторого симбиоза RUP + Agile на процесс разработки.

Is your project FISABCT?


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

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

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

Features(s)

Первый этап. В течении этого этапа Вы определяете, что то, во что выльется разработка будет полезным и принесёт прибыль. Для большинства разработчиков этот этап либо скрыт, либо неявно выражается в виде SRS или иных формах. Но для тех кто хоть раз разрабатывал собственный продукт, это очень важный этап. Тут нужно «чувствовать» main-stream прикладного домена и определять USP вашего продукта\системы.
  • Делать ли стандартную регистрацию или оставить только OpenID?
  • Undo/Redo операции должны быть обязательно реализованы для WYSIWYG системы!
  • ...

Idea

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

Scope

Этап разумного расширения задач. Здесь, Вы можете включать родственные задачи, предугадать будущие задачи. Девиз этого этапа — решить задачу в максимально общем виде.

Architecture

Цель данного этапа — сформировать «Общую Картину». По его завершению, должно быть определено максимальное количество сущностей и взаимодействий как внутри системы так и на её границах.

orthogonal Basis

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

Code

Этап непосредственного написания кода. Используя тот или иной язык\среду, Вы создаёте программный код, который в прямом или преобразованом виде будет представлять продукт. Сюда также входя скрипты развёртывания и сопровождающее ПО.

Test(s)

Тестирование разработчиком во время написания кода, юнит-тестирование, функциональное, интеграционное, нагрузочное тестирования. Типы и объём тестов определяются сложностью системы и требованиями к ней.

Комбинаторный взрыв

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

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

Каждый из переходов важен и требует внимания от разработчиков, но некоторые из них имею большее влияние на увеличение сроков и стабильность создаваемой системы. Вот некоторые из них:
  • I -> S На этом этапе мы не только препарируем требования и преобразовываем их в технические, но и расширяем список задач, предугадывая будущие запросы и оптимизируя выполнение родственных задач
  • A -> B Все предыдущие этапы, влючая А, производят сбор информации, расширяют границы системы и увеличивают её сложность. Построение базиса призвано уменьшить эту сложность
  • B <- C Переход, который констатирует факт того, что разработанная ранее архитектура и базис, больше не могут удовлетворять все запросы по реализации

Роли и Артефакты

Для предложенного базиса можно выделить пять ролей: Product Owner (PO)/Application Engineer (AE), Architect, Developer, Configuration Manager (CM), Test Engineer (TE). Конечно в некоторых случаях, несколько или даже все роли могут совмещаться одним разработчиком.

Минимальный набор актефактов по проекту может выглядеть следующим образом:

  • PO, AE : Описание системы сточки зрения пользователя, например в форме SRS
  • Architect : Описание архитектуры информационной системы, например с использованием UML
  • Developer : Исходные коды, комментарии
  • CM : скрипты автоматизации и развёртывания
  • TE : отчёты об ошибках и выполненных тестах

Что же позволяет получить данный подход?

  • Выразить систему в определённом базисе
  • Разграничить зоны ответственности и утвердить список необходимых артефактов для каждого этапа
  • Выработать набор реакций на изменения в каждой конкретной части системы. Отчёт от ошибке C <- T, отличается от «Epic Fail» B <- C

Підписуйтеся на Telegram-канал редакції DOU, щоб не пропустити найважливіші статті.

👍НравитсяПонравилось0
В избранноеВ избранном0
Подписаться на автора
LinkedIn



Підписуйтесь: Soundcloud | Google Podcast | YouTube


20 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

В украинских реалиях это происходит так :

imageshack.us/...35/diagramr.png

Такая схема нормальная — всё-таки WIn-Win.

Хуже когда $->ИБД (Иммитация Бурной Деятельность)->Завал проекта->Попробуйте найдите нас в Украине

Извиняюсь, что отвечаю здесь, а не в каждой ветке.

Хочу уточнить одну деталь, чтобы не было подмены понятий

И если обратиться к первоисточникам то это проекция некоторого симбиоза RUP + Agile на процесс разработки.

Тоесть описанная механика, не есть нечно, что может стать на уровне с RUP + Agile

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

— можно ли привести пример процесса (или исправления сбоя) где в описываемом FISABCT одни действия, а в каноническом XP или SPRINT — другие ?

Соответственно, если выражаться в терминах плюсов FISABCT — частичная специализация.
Один из параметров — это я, так как описываю и обобщаю свой опыт.

Второй параметр — проекты, в которых я участвовал.

Еще интересны границы применимости. То есть какой типичный масштаб проекта ?

Если Вы используете RUP или Agile для своего проекта, то можете использовать некоторые идеи, описанные выше.

1. чем базис отличается от архитектуры? я не понимаю, как «минимально возможный набор сущьностей» (который базис) может покрыть «максимальное количество сущностей» (который архитектура). вот тут пример бы очень помог.

Набор функций работы с файлами ( fopen, ...) - базис, позволяет реализовать все манипуляции с файлами, встречающиеся в Вашей Архитектуре (проект), базирующейся на списке задач (Scope), построенного на описании необходимого поведения (Feature(s)). И Вы можете выбрать другой базис WinAPI (CreateFile, ..., не важно что fopen базирется на CreateFile), и попытаться выразить Архитектуру через него.

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

Ace3DEngine — ключевая характеристика — проблемы с определение Features(s), проект из разряда: сделайте мне хорошо и красиво. Данный проект показал важность и проблемы переходов F->S, F<-S.

АН-148 авиа-симулятор (графическая и её сетевая подсистемы). Общая архитектуры была недоступна для модификации с нашей стороны, она полностью контролировалась специалистами из АНТК, F + S были очень хорошо определены, основные задачи были как в базисе всей системы выразить нашу. Ключевые переходы, A->B, B<-A, а также входящие внешнние требования для A.

Legacy code refactoring (текущий проект) — почти намертво захардкоженные S, A, B. Тоесть необходимо проталкивать новые F через все этапы, сохраняя работоспособность кода и привнося новые свойства (мультиплатворменность, соответсвие ISO C++, покрытие юнит-тестами, CI и пр. )

Уже упоминал об этом проекте, Paintball.Editor, в его контексте я выступал во всех 5-ти ролях и верифицировал все переходы и артефакты.

пока вывод такой, что базис — это ограничения на фреймворк\апи.

или надо объяснять дальше.

Не совсем ограничания. Базис это один из равновозможных способов реализации архитектуры. Очень часто выражается в выборе АПИ, так как B, расположен между A и С и призван уточнить и упростить реализацию в коде. Тут конечно вопрос, где границы термина АПИ.

Одним из критериев разбиения на такие этапы FISABCT, была возможность максимально ослабить зависимость между частями.

Простой пример. Архитектура : клиент-сервер, базис : сервисы, демоны, «голые сокеты», boost::asio и пр.
Тоесть, если у меня приходи запрос\баг в Базис это одна реакция и одни затраты, но если в процессе реализации выясняется, что нужно было закладывать peer2peer — это уже другая история и с другими последствиями.

ну собственно очень похоже на фиксацию инструментов.

насчёт изменения базиса — как борешься со страхом изменения? ну можно в базис засыпать всё очень низкоуровневое, что 100% даст возможность реализовать что-угодно, а можно положить что-то высокоуровневое, что даст выйгрыш в скорости разработки, но даст риск того, что его надо будет менять.

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

ну можно в базис засыпать всё очень низкоуровневое, что 100% даст возможность реализовать что-угодно, а можно положить что-то высокоуровневое, что даст выйгрыш в скорости разработки, но даст риск того, что его надо будет менять

Смотрим на уровень команды: сильные спецы — можно и низкоуровневое закладывать. «Legacy» vs «from Scratch» — для первого вариантат с базисом врядли можно будет играться. Размер и «шаблонность» проекта и т.д и т.п.

Для меня вообще Agile загадка. Можно подумать, что все сидели программировали по жестким процедурам, при этом проваливая проект за проектом, пока какой-то гуру не сказал «ОК, а давайте будем гибкими!» — и у всех сразу озарение «вау, действительно, давайте!».
По-моему, по схожим принципам проекты жили лет за тридцать до того, как появилась «методология Agile». Просто называлось это по-другому.

А мода — ну это прикольно, да.

Своё мнение я уже выразил здесь

Да, и вот в этим я уже абсолютно согласен.
А насчёт Agile — тут просто недоумение, когда все вокруг начинают с этим носиться, семинары, конференции. Просто потому что модно. И никто не анализирует, что надо для данного конкретного проекта, для данных целей и для данной команды. А ведь Agile очень требовательный к способностям членов команды, и если ключевой член команды окажется некомпетентным (в реалиях украинского рынка IT- обычная ситуация) — то потом концы с концами уже не свести.
И самое страшное, что эта мода распространяется и на заказчиков — «о, давайте использовать Agile, документации не надо, мы вам требования по скайпу надиктуем, а вы потом что-нибудь сделаете и мы как-нибудь заплатим».

нормальная продажа волшебных примусов и вечных бритв :)

Можно подумать, что все сидели программировали по жестким процедурам, при этом проваливая проект за проектом,

Ну вообщем нечто похожее часто и было...

По-моему, по схожим принципам проекты жили лет за тридцать до того, как появилась «методология Agile». Просто называлось это по-другому.

Ну насчет 30 не застал, но были теже рекоммендации РУПа, в которых четко отводились фазы под исследования, под спецификацию со всякими майлстоунами типа «Спецификация закончена» и т.д.

я беседовал с чуваком, который писал софт для космоса в 70-80-е давно. так вот, по итогу дискуссии — много там было гибкости в процессах без потери жесткости критериев приемки :)

систему ценностей, которую благополучно перенял agile придумали в 19-м веке :)

Еще интересны границы применимости. То есть какой типичный масштаб проекта ?

на первый взгляд — клёво! :)

на второй — реальный бенефит только в формальном «выразить систему в определённом базисе», остальное и так присутствует в... да в чём угодно.

или я что-то не понял или в чём цимес-то?

на второй — реальный бенефит только в формальном «выразить систему в определённом базисе»

Две аналогии:

1. Вы ставите себе цель (простите, не удержался) «Стать сеньёром в 23 года и рубить 3к!». Если проверифицировать эту цель через SMART, то это не более чем какатекст.

2. Вы продали 50 жопомест (ёмкий термин, респект изобретателю) в Канаду. Получаете свои законные 5к и 5% с прибыли. Но со временем что-то начинает идти не так. И что бы найти в чём же проблема, Вам нужно препарировать систему, разложить на части — выразить в некотором базисе.

Тоесть выбор базиса ключевая и нетривиальная задача (некоторые задачи эффективнее решаются в декартовых, а некоторые в сферичесих координатах)

остальное и так присутствует в... да в чём угодно

Если это попытка потроллить, от просто отсылаю сюда

Если есть конкретика, то буду рад обсудить.

Вобще-то конкретный смысл вопросы СОТОНы придать можно, переформулировал его следующим образом:
— можно ли привести пример процесса (или исправления сбоя) где в описываемом FISABCT одни действия, а в каноническом XP или SPRINT — другие ?

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

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

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

так вот конкретный вопрос:
1. чем базис отличается от архитектуры? я не понимаю, как «минимально возможный набор сущьностей» (который базис) может покрыть «максимальное количество сущностей» (который архитектура). вот тут пример бы очень помог.
2. отличная формулировка от Руслана — можно ли привести пример процесса (или исправления сбоя) где в описываемом FISABCT одни действия, а в каноническом XP или SPRINT — другие ?

P.S.: и это не тролинг :) мне очень импонируют всякие систематизации и прочее. опять же было бы интересно услышать историю создания (обычно в терминах «применяли X, воткнулись в проблему Y, подумали, подкорректировали X до FISABCT»)

Подписаться на комментарии