Agile Modelling is dead ?
Theme
1. Хватай и Беги -- когда планирование сводится к минимуму,
архитектурных решений не принимается, и для каждой истории
разрабатывается свой более-менее независимый инструментарий.
2. Посмотри вокруг -- когда часть порграммы изменяется вместе с
тасками, т.е. дублирование минимально, но возникают структуры которые
используются в нескольких местах.
Вопросы для практикующих:
1. К какому варианту вы ближе
2. Преимущества и недостатки каждой крайности
3. Следствия первого подхода для крупных проектов (работа для 5 чел
более одного месяца) ?
Alexey Krivitsky
не совсем ясна ассоциация планирования и моделирования.
-------
никто не отменял хороших архитекторов даже в agile проектах.
а важность хорошего кода - тем более.
agile методологии - не о гибкости к написанию кода (срезание углов),
а в гибкости к подходе с заказчиком - гибкости к планированию и требованиям.
поэтому я и ищу другой перевод слова agile (см другой топик),
так как слово" гибкий" может быть истрактовано некорректно,
и тогда любой проект, который НЕ заботится о дизайне и качестве кода,
будет гордо называться agile ....
эта группа и бы создана для того, чтоб развеять подобное суждение.
спасибо, что поднял этот ВАЖНЕЙШИЙ вопрос.
ArtyRak
Есть методы управления проектами, а есть методы проектирования. И хоть
корень один - "проект", работы и знания нужны разные.
Вообще, русский перевод в этой области сильно хромает, и создает кучу
непонятностей у людей, изучающих проектирование (Design) и
планирование (Planning). И когда речь заходит о моделировании, даже
самые опытные менеджеры порой ошибаются в конкретном применении этого
понятия в документах.
Попробую внести ясность (которую определил для самого себя).
Создаем мы ПРОДУКТ. Его же и дизайним (мне так проще называть
проектирование, помогает ;) ), разрабатываем, тестируем, поставляем,
внедряем и эксплуатируем. Это результат работ.
Есть модели, описывающие Дизайн (в СССР применяли слово проект)
продукта: модель данных, модель процессов, модель потоков данных и
т.п. Есть модель GUI - Прототип.
Планируем мы ПРОЕКТ. Им же и управляем, его оцениваем, начинаем,
заканчиваем, откладываем и отменяем. Это процесс выполнения работ.
Есть модели, описывающие Проект. График работ (Модель Гантта). Модель
процесса разработки (MSF, RUP - разные Планы на их основе). Модель
взаимодействия с заказчиком (шаблоны документов, уставы и т.п.).
Отдельно выделены ТРЕБОВАНИЯ. Это и часть продукта, и часть проекта
одновременно. Это не только исходная информация, но и руководство к
действию и уже готовые принятые решения в проетировании.
Модель Прецедентов (Use Case). Модель Деятельности (Activity). Бизнес
модели (AS IS/TO BE). Даже текстовое описание требований (User Stories
в Agile) уже содержит элементы дизайна. А методы WBS и Functional
Points превращают требования в планы.
Как видим, моделирование присутсвует везде. Поэтому лично я
предпочитаю вообще не использовать это слово, заменяя его на три
конкретный понятия: Дизайн, Планы, Требования. Оперирую во всех
документах и обсуждениях именно ими. Даже слова Продукт и Проект редко
использую в ходе проекта. Вместо них Версия, Билд, Поставка и
[Название проекта], [План такой-то], [Фаза такая-то]. Эта конкретика
снимает непонимание, хотя и требует определенного начального обучения
участников проекта. MSF в этом плане очень практичен :) Самое удобное
- это документ "Структура проекта", который содержит отправные точки
для дизайна, планов и требований, а также адаптирует базовый процесс
разработки под частный случай.
Я думаю, Алексей с легкостью подставит аналоги из Scrum в мое
описание :)
On 22 фев, 12:16, "Alexey Krivitsky" <alexeykrivit...@gmail.com>
wrote:
ArtyRak
1. В VS 2005 (и ранее) MS организовывает исходный код в проекты
(project). И даже с добавлением Решений (solution) они эту практику не
изменили. Хотя по сути это Приложения (application), о чем и говорит
диалог выбора их типа при создании. Конечно, не все варианты создают
исполняемый код. Есть и скрипты и т.п. Но лично мне намного проще
называть приложениями и модулями (module).
2. В VSS MS вообще все папки называет проектами (project), что совсем
глупо звучит, если это отражать в документации. Появляются проекты
"...bin/release" к примеру. Ну это ж полная глупость :) Я зову их
папками (folder), ну и соответственно говорю "путь" для обозначения
вложенности.
3. В MS Project, кто бы подумал!, вообще все файлы называются
проектами. Да и сам продукт назван проектом компании Microsoft. Вот уж
где бывает путаница в английских описаниях. Ну здесь у меня довольно
просто. Планы (без дат) я в MS Project не строю. Хватает MS Excel и
просто текста. Соответственно строю только календарные графики
(schedule). Так эти файлы и называю. Ну и сам продукт зову в русских
обсуждениях "Проджект", а в английских MS Project. Аналогично с MS
Project Server и MS Project Central.
4. Проектирование, как я уже говорил, называю Дизайн. Пусть калька,
зато без путаницы.
5. Во всех сторонних продуктах, где используется понятие проект
(project), которое описывает набор чего-либо с описанием (например,
проекты в Nero), я использую сочетание "файл проекта" или что-то такое
же специфическое. Еще один пример - "проект закона" - тоже
нераздельное словосочетание, хотя часто использую законопроект.
Вообще по теме наименований и определений у меня уже выработался
рефлекс. Если слышу/читаю неточное применение термина. сразу исправляю
и объясняю в чем неточность. Пусть это отнимает некоторое время, зато
потом исключает кучу ненужных усилий.
Theme
> будет гордо называться agile ....
Насколько я понял, есть
architecture -- стандартная архитектура, как в строительстве
agile architecture -- или самая простая, появляющаяся за счет
коллективного владения кодом и планирования итерации (в основном, я не
говорю про проекты где есть непишущие архитекторы ;) ), применяющаяся
в agile процессах разработки
chaos -- когда время на внутреннюю организацию продукта не
выделяется, кривая стоимости изменений уходит резко вверх (но не
сразу).
здесть архитектура == дизайн IMHO
erka
>коллективного владения кодом и планирования итерации (в основном, я не
>говорю про проекты где есть непишущие архитекторы ;) ), применяющаяся
>в agile процессах разработки
agile architecture -- или самая простая, ... или? (второй вариант это
chaos?)
ArtyRak
Например - .NET Framework или MS SQL Server.
Архитектура - это конкретика. Ее выбирают, и изредка разрабатывают (не
из воздуха же .NET нарисовался ;) ).
Описывает же будущее (?прошлое? ;) ) решение - Дизайн.
Если говорить об Agile, честно, не понимаю при чем здесь
архитектура :) Это подход к организации процесса разработки ПО. Он к
дизайну и архитектуре имеет такое же отношение, как Гражданский Кодекс
к интеръеру супермаркета Фуршет.
Alexey Krivitsky
обычно такая, которая позволяет решить ближайшие наиважнейшие цели,
что является плюсом с одной стороны, так как многие проекты страдают
от overengineering-а - наборе внутренних фич, которые невостребованны
и есть вероятность, что таками и останутся. лишний код - усложняет
процесс разработки,
замедляя разработку, что противоречит agile (закладка 1).
с другой стороны, цели проекта меняются, таким образом и архитектура
должна быть адаптирована под новые требования... тут-то и начинается
самое сложное имхо. что делать? рефакторить. жестко и смело. иначе -
прямой путь к хаосу.
в итоге все сведется в такому коду, который поддерживать будет на
столько тяжело, что говорить о быстром реализации требований будет
невозможно (закладка 2)
а если невозможно быстро реализивать важные требования и получить
экономический эффект - это не agile.
т.е. обе ситуации (см. закладки выше) являются нежелательными, и
только хорошая команда находит правильный путь, лавируя между заумным
кодом и нацеленным на решение реальных задач.
ArtyRak
Вначале прототипируем архитектуру под возможные цели (а они у нас есть
в списке US, пусть и не на этот скрум).
Потом на каждый скрум добавляем "выделенный" кусок архитектуры, без
которого мы не сможем обойтись сейчас и в следующем скруме.
Конечно же, "на будущее" прорабатываем архитектуру поверхностно,
какждый раз "вычищая" невостребованный функционал.
В таком случае мы не наталкиваемся на необходимость рефакторинга, а
регулярно его выполняем.
Просто мне как-то совсем не верится, что Скрум-проект может стартовать
без понимания общей картины (дизайна) хотя бы одним разработчиком в
команде.
Ведь браться за подобное - это слепо верить в удачу :) А раз есть
концептуальный дизайн, значит есть и преположения по общей архитектуре
решения.
Хотя, скорее всего, в подобных Agile-проектах всеже разрабатываются
"типовые" решения, основанные на уже знакомом инструментарии и готовом
фреймворке. А это сужает круг архитектурных просчетов до тех, которые
можно отыскать в форумах по выбранным инструментам/фреймворку.
On 22 фев, 23:27, "Alexey Krivitsky" <alexeykrivit...@gmail.com>
wrote:
Tim Yevgrashyn
http://www-128.ibm.com/developerworks/rational/library/feb05/krebs/
У меня давно в голове бродила мысль, что SCRUM не исключает RUP, вроде
как они не противоречат. Собственно ребята взялись это доказать в
статье, как я понял.
Все получается логично:
* RUP - это engineering процессы, про управление там сказано очень
мало. А то, что сказано не противоречит SCRUM.
* SCRUM - это management framework, про технические аспекты он ничего
не говорит.
> > кодом и нацеленным на решение реальных задач.- Hide quoted text -
>
> - Show quoted text -
Theme
связаны, эту тему можно долго обсуждать
получается у меня вот какая картина:
1. Если нет планирования и архитектуры -- то разработкой это назвать
можно только с натяжкой (agile или нет. неважно)
2. Эта архитектура минимальна, но всё-таки она есть, благо ссылок гугл
на тему agile modeling даёт много.
3. Архитектура требует времени. Так что её создание надо как-то
учитывать.
Если я пришел к неправильным выводам, поправьте пожалуйста.
Заранее спасибо
>Если говорить об Agile, честно, не понимаю при чем здесь
>архитектура :) Это подход к организации процесса разработки ПО. Он к
>дизайну и архитектуре имеет такое же отношение, как Гражданский Кодекс
>к интеръеру супермаркета Фуршет.
Мне кажется что организация пчелиного улья и соты -- аналогия немного
лучше :)
erka
виденье реализации проекта. Итерация закончилась, появились новые
требования, появилось новое виденье - архитектура динамически меняться
с каждой итерацией. Процесс рефакторинга будет происходить на каждом
этапе. Если будет хорошо поставлено колективное владение кода - то
архитектура будет наиболее соответствовать текущим требования проекта
(тоесть если можно обойтись простым модулем вместо создания веб
сервисов - то будет создан модуль и никто даже не будет думать о
SOAP). В аджаил архитектура выплывает из колективной разработки, а не
из решиний архитектора, что это нам обьязательно пригодиться через 10
итераций.
Alexey Krivitsky
но добавлю, что проектные роли там не менее могут присутствовать,
и таким образом в команде может присутствовать архитектор, дизайнер,
тестировщик, техписатель.
если продукт должен быть в писан в семейство продуктов, к примеру,
к проекту может быть прикреплен архитектор семейства продуктов, опыт которого
несомненно поможет создать продукт, вписываемый в семейство.
когда мы говорим об архитектуры, которая разрабатывается в agile проетке,
мы акцентируем внимание скорее эволюционировании архитектуры, в
соотвествии с требованиями текущей итерации.
таким образом, если соответсвие архитектуры каким-то внутренним
стандартам - это требование, то тогда в первые итерации должны быть
спланированы истории, разработка которых позволит команде выработать
необходимые элементы архитектуры.
On 2/24/07, erka <erka....@gmail.com> wrote:
> Суть не в архитектуре. Есть начальные требование, есть начальное
> виденье реализации проекта. Итерация закончилась, появились новые
> требования, появилось новое виденье - архитектура динамически меняться
> с каждой итерацией. Процесс рефакторинга будет происходить на каждом
> этапе. Если будет хорошо поставлено колективное владение кода - то
> архитектура будет наиболее соответствовать текущим требования проекта
> (тоесть если можно обойтись простым модулем вместо создания веб
> сервисов - то будет создан модуль и никто даже не будет думать о
> SOAP). В аджаил архитектура выплывает из колективной разработки, а не
> из решиний архитектора, что это нам обьязательно пригодиться через 10
> итераций.
>