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
Все про українське ІТ в телеграмі — підписуйтеся на канал DOU
20 коментарів
Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.