Еще: О вреде Agile Опыт работы программистом в Германии
Еще: О вреде Agile Опыт работы программистом в Германии
...Читать далее
Опыт работы в компаниях, занимающихся разработкой программно-аппаратных систем (для себя, по заказу, программные продукты) за последние 20 лет (порядка 7 крупных компаний включая зарубежные) показал слабое использование средств проектирования систем, средств основанных на UML, в частности. В большинстве случаев применение средств проектирования сводится к «рисованию» иллюстраций бизнес-процессов, требований, архитектур систем для «вклеивания» в документы (в том числе презентации). Это неплохо, но очень мало по сравнению с эффектом от систематического подхода к проектированию. Основные аспекты систематического подхода к проектированию программно-аппаратных систем: • Хранение моделей систем, включая элементы/объекты проектирования в едином репозитории (для UML наиболее распространен Sparx Enterprise Architect);
• Многопользовательская работа с репозиторием всех типов участников проектирования:
o Бизнес аналитики;
o Системные аналитики;
o Архитекторы (программные и аппаратные);
o Проектировщики программных модулей и пользовательских интерфейсов;
o Проектировщики тестов.
• Управление версиями моделей и объектов проектирования;
• Взаимосвязь (трассируемость) объектов проектирования, создаваемых разными участниками и разными типами участников процесса проектирования, например:
o Связи между объектами моделей бизнес-процессов и объектами системного анализа (требования к разрабатываемым программно-аппаратным системам);
o Связи между объектами системного анализа и объектами архитектуры (программной и аппаратной);
o Связи между архитектурой м модульным дизайном систем, объектами моделей пользовательского интерфейса;
o Связи между системными требованиями и тестовыми сценариями.
• Автоматизированная генерация документации по проектированию с возможностью настройки и многократного использования шаблонов документов и возможностью выбора набора моделей и объектов для отражения в документе.
Малое внимание к проектированию программно-аппаратных систем вообще связано с широко распространенным убеждением что проектирование – излишество. Все могут сделать программисты и другие разработчики, непосредственно связанные с системами (код программ, аппаратура), при интенсивном взаимодействии с заказчиками или так называемыми «продукт овнерами». Это часто поддерживается (на философском уровне) Agile методологиями. Следование таким убеждениям по опыту работы в большинстве компаний приводит к печальным последствиям:
• Сроки разработки и внедрения систем не сокращаются, а возрастают;
• Существенно повышается вероятность провала проектов;
• Экономии на ресурсах (участниках разработки) нет;
• Качество разработки и внедрения систем существенно снижается;
• Стоимость поддержки и развития систем существенно возрастает.
Как следствие - существенная неудовлетворенность со стороны Заказчиков.
Влияние проектирования систем на эффективность и качество разработки, внедрения и сопровождение систем характеризуется следующими аспектами:
1. Проектирование систем является объективно неизбежной частью общего процесса разработки и внедрения систем, даже если в разработке участвует один человек, например, программист (в таких случаях разработчик выполняет все роли по проектированию системы, возможно неформально, «мысленно»).
2. Разработка систем (программирование, сборка аппаратно-программных комплексов) выполняется существенно быстрее, дешевле и качественнее при достаточном уровне предварительного проектирования (бизнес-процессы, требования, архитектура и дизайн).
3. Проектирование систем быстрее и дешевле разработки (программирование, сборка и настройка аппаратно-программных комплексов).
4. Качество проектирования не может быть «абсолютным» (требования, архитектура, дизайн). Требуется периодический выпуск версий системы для получения обратной связи от Заказчика. Лирическое отступление:
a. Многие приверженцы Agile подходов считают, что идея итеративности выпусков системы– заслуга методологии Agile против всего старого под названием «водопад» («условно» основатель данного подхода - доктор Уинстон У. Ройс «Managing the development of large software systems» 1970г).
b. На самом деле никакого «водопада» никогда не было. Уже У. Ройс в своих работах настаивал на итеративном подходе, все последующие методологии, все современные классические (не Agile) методологии – итеративные.
5. Необходим продуманный и обоснованный оптимум между противоречивыми тезисами 2,3 с одной стороны и 4 с другой стороны (все классические методологии разработки и внедрения систем предполагают такой оптимум).
6. Разделение труда между дисциплинами по разработке систем (виды проектирования, виды разработки и внедрения систем) приводит к существенному росту эффективности. Это связано с тем, что каждая дисциплина требует высокого профессионализма (накоплен большой объем знаний и большой опыт). В конце концов высокая эффективность разделения труда доказана еще Адамом Смитом (эксперименты с «булавками»).
7. Повторное использование объектов проектирования участниками разработки существенно повышает эффективность проектирования. Основные аспекты повторного использования объектов проектирования:
a. Повторное использование объектов проектирования специалистами одного направления (например, системные аналитики) в рамках разработки одной системы. Примеры: использование объектов типа «сущность» и ER моделей, общих требований верхнего уровня, нефункциональных требований;
b. Повторное использование объектов проектирования специалистами одного направления в рамках разработки разных систем. В системном анализе это использование аналогичных сущностей в ER моделях, аналогичных функциональных и нефункциональных требований, в архитектуре – повторное использование модулей, компонент, архитектурных фреймворков, и.т.д.
c. Проверка соответствия между объектами проектирования разных направлений (трассируемость). Примеры: проверка соответствия/покрытия системными требованиями описаний бизнес-процессов, проверка соответствия/покрытия архитектурными решениями (модули, компоненты, …) системных требований. Проверка трассируемости снижает риск не учета всех требований и задач разработки, а также выявляет избыточность в решениях по разработке.
8. Автоматическая генерация документации для по системам для широкого круга пользователей:
a. Описание бизнес-процессов – для Заказчиков и бизнес руководства разработчика;
b. Документы Технического Задания и Технического проекта – для Заказчиков, руководства от разработчика, всех видов разработчиков;
c. Документация для сотрудников по внедрению, поддержки и эксплуатации;
d. Документация для сопровождения;
e. Документация для разработчиков, участвующих в развитии системы;
f. Документация для «быстрого вхождения» в разработку, внедрение и развитие системы новых участников.
Вывод: потенциал систематического проектирования программно-аппаратных систем с точки зрения повышения эффективности, качества, снижения рисков – очень большой.
Конечно, есть трудности с внедрением такого подхода:
1. Мало специалистов с хорошим знанием систематических нотаций (например, UML, BPMN, IDEF, ..);
2. Мало специалистов с хорошим знанием технических средств проектирования, поддерживающих систематических подход к проектированию;
3. Необходима существенная поддержка руководства и энтузиазм участников процесса разработки, внедрения и сопровождения систем. Это, наверное самое главное!!!
Опыт работы в компаниях, занимающихся разработкой программно-аппаратных систем (для себя, по заказу, программные продукты) за последние 20 лет (порядка 7 крупных компаний включая зарубежные) показал слабое использование средств проектирования систем, средств основанных на UML, в частности. В большинстве случаев применение средств проектирования сводится к «рисованию» иллюстраций бизнес-процессов, требований, архитектур систем для «вклеивания» в документы (в том числе презентации). Это неплохо, но очень мало по сравнению с эффектом от систематического подхода к проектированию. Основные аспекты систематического подхода к проектированию программно-аппаратных систем: • Хранение моделей систем, включая элементы/объекты проектирования в едином репозитории (для UML наиболее распространен Sparx Enterprise Architect);
• Многопользовательская работа с репозиторием всех типов участников проектирования:
o Бизнес аналитики;
o Системные аналитики;
o Архитекторы (программные и аппаратные);
o Проектировщики программных модулей и пользовательских интерфейсов;
o Проектировщики тестов.
• Управление версиями моделей и объектов проектирования;
• Взаимосвязь (трассируемость) объектов проектирования, создаваемых разными участниками и разными типами участников процесса проектирования, например:
o Связи между объектами моделей бизнес-процессов и объектами системного анализа (требования к разрабатываемым программно-аппаратным системам);
o Связи между объектами системного анализа и объектами архитектуры (программной и аппаратной);
o Связи между архитектурой м модульным дизайном систем, объектами моделей пользовательского интерфейса;
o Связи между системными требованиями и тестовыми сценариями.
• Автоматизированная генерация документации по проектированию с возможностью настройки и многократного использования шаблонов документов и возможностью выбора набора моделей и объектов для отражения в документе.
Малое внимание к проектированию программно-аппаратных систем вообще связано с широко распространенным убеждением что проектирование – излишество. Все могут сделать программисты и другие разработчики, непосредственно связанные с системами (код программ, аппаратура), при интенсивном взаимодействии с заказчиками или так называемыми «продукт овнерами». Это часто поддерживается (на философском уровне) Agile методологиями. Следование таким убеждениям по опыту работы в большинстве компаний приводит к печальным последствиям:
• Сроки разработки и внедрения систем не сокращаются, а возрастают;
• Существенно повышается вероятность провала проектов;
• Экономии на ресурсах (участниках разработки) нет;
• Качество разработки и внедрения систем существенно снижается;
• Стоимость поддержки и развития систем существенно возрастает.
Как следствие - существенная неудовлетворенность со стороны Заказчиков.
Влияние проектирования систем на эффективность и качество разработки, внедрения и сопровождение систем характеризуется следующими аспектами:
1. Проектирование систем является объективно неизбежной частью общего процесса разработки и внедрения систем, даже если в разработке участвует один человек, например, программист (в таких случаях разработчик выполняет все роли по проектированию системы, возможно неформально, «мысленно»).
2. Разработка систем (программирование, сборка аппаратно-программных комплексов) выполняется существенно быстрее, дешевле и качественнее при достаточном уровне предварительного проектирования (бизнес-процессы, требования, архитектура и дизайн).
3. Проектирование систем быстрее и дешевле разработки (программирование, сборка и настройка аппаратно-программных комплексов).
4. Качество проектирования не может быть «абсолютным» (требования, архитектура, дизайн). Требуется периодический выпуск версий системы для получения обратной связи от Заказчика. Лирическое отступление:
a. Многие приверженцы Agile подходов считают, что идея итеративности выпусков системы– заслуга методологии Agile против всего старого под названием «водопад» («условно» основатель данного подхода - доктор Уинстон У. Ройс «Managing the development of large software systems» 1970г).
b. На самом деле никакого «водопада» никогда не было. Уже У. Ройс в своих работах настаивал на итеративном подходе, все последующие методологии, все современные классические (не Agile) методологии – итеративные.
5. Необходим продуманный и обоснованный оптимум между противоречивыми тезисами 2,3 с одной стороны и 4 с другой стороны (все классические методологии разработки и внедрения систем предполагают такой оптимум).
6. Разделение труда между дисциплинами по разработке систем (виды проектирования, виды разработки и внедрения систем) приводит к существенному росту эффективности. Это связано с тем, что каждая дисциплина требует высокого профессионализма (накоплен большой объем знаний и большой опыт). В конце концов высокая эффективность разделения труда доказана еще Адамом Смитом (эксперименты с «булавками»).
7. Повторное использование объектов проектирования участниками разработки существенно повышает эффективность проектирования. Основные аспекты повторного использования объектов проектирования:
a. Повторное использование объектов проектирования специалистами одного направления (например, системные аналитики) в рамках разработки одной системы. Примеры: использование объектов типа «сущность» и ER моделей, общих требований верхнего уровня, нефункциональных требований;
b. Повторное использование объектов проектирования специалистами одного направления в рамках разработки разных систем. В системном анализе это использование аналогичных сущностей в ER моделях, аналогичных функциональных и нефункциональных требований, в архитектуре – повторное использование модулей, компонент, архитектурных фреймворков, и.т.д.
c. Проверка соответствия между объектами проектирования разных направлений (трассируемость). Примеры: проверка соответствия/покрытия системными требованиями описаний бизнес-процессов, проверка соответствия/покрытия архитектурными решениями (модули, компоненты, …) системных требований. Проверка трассируемости снижает риск не учета всех требований и задач разработки, а также выявляет избыточность в решениях по разработке.
8. Автоматическая генерация документации для по системам для широкого круга пользователей:
a. Описание бизнес-процессов – для Заказчиков и бизнес руководства разработчика;
b. Документы Технического Задания и Технического проекта – для Заказчиков, руководства от разработчика, всех видов разработчиков;
c. Документация для сотрудников по внедрению, поддержки и эксплуатации;
d. Документация для сопровождения;
e. Документация для разработчиков, участвующих в развитии системы;
f. Документация для «быстрого вхождения» в разработку, внедрение и развитие системы новых участников.
Вывод: потенциал систематического проектирования программно-аппаратных систем с точки зрения повышения эффективности, качества, снижения рисков – очень большой.
Конечно, есть трудности с внедрением такого подхода:
1. Мало специалистов с хорошим знанием систематических нотаций (например, UML, BPMN, IDEF, ..);
2. Мало специалистов с хорошим знанием технических средств проектирования, поддерживающих систематических подход к проектированию;
3. Необходима существенная поддержка руководства и энтузиазм участников процесса разработки, внедрения и сопровождения систем. Это, наверное самое главное!!!
