نمذجه الاجایل هي طريقه ونمذجه نظم البرمجيات على أساس أفضل الممارسات. وهو عبارة عن مجموعة من القيم والمبادئ التي يمكن تطبيقها على مشروع تطوير البرمجيات (اجايل). هذه المنهجية أكثر مرونة من طرق النمذجة التقليدية ، مما يجعلها ملائمة بشكل أفضل في بيئة سريعة التغير.[1] جزء من تطویر برمجیات الاجایل مجموعه الادوات
Agile modeling is a supplement to other agile development methodologies such as Scrum, extreme programming (XP), and Rational Unified Process (RUP). It is explicitly included as part of the disciplined agile delivery (DAD) framework. As per 2011 stats, agile modeling accounted for 1% of all agile software development.[2]
Core practices
There are several core practices:
التوثيق
- الوثيقة بشكل مستمر. يتم التوثيق طوال دورة الحياة ، بالتوازي مع إنشاء بقية الحل.
- وثيقة في وقت متأخر. يتم التوثيق في أقرب وقت ممكن ، وتجنب الأفكار المضاربة التي من المرجح أن تتغير لصالح معلومات مستقرة.
- المواصفات القابلة للتنفيذ. يتم تحديد المتطلبات في شكل "اختبارات العملاء" القابلة للتنفيذ ، بدلاً من الوثائق "الثابتة" غير القابلة للتنفيذ.
- معلومات أحادية المصدر. يتم تخزين المعلومات (النماذج والوثائق والبرامج) في مكان واحد ومكان واحد فقط ، وذلك لمنع الأسئلة حول ما هي المعلومات / الإصدار "الصحيح".
Modeling
- Active stakeholder participation. Stakeholders of the solution/software being modelled should be actively involved with doing so. This is an extension of the on-site customer practice from Extreme Programming.
- Architecture envisioning. The team performs light-weight, high-level modeling that is JBGE at the beginning of a software project so as to explore the architecture strategy that the team believes will work.
- Inclusive tools. Prefer modelling tools, such as whiteboards and paper, that are easy to work with (they're inclusive).
- Iteration modeling. When a requirement/work item has not been sufficiently explored in detail via look-ahead modeling they team may choose to do that exploration during their iteration/sprint planning session. The need to do this is generally seen as a symptom that the team is not doing sufficient look-ahead modeling.
- Just barely good enough (JBGE). All artifact, including models and documents, should be just sufficient for the task at hand. JBGE is contextual in nature, in the case of the model it is determined by a combination of the complexity of whatever the model describes and the skills of the audience for that model.
- Look-ahead modeling. An agile team will look down their backlog one or more iterations/sprints ahead to ensure that a requirement/work item is ready to be worked on. Also called "backlog grooming" or "backlog refinement" in Scrum.
- Model storming. A short, often impromptu, agile modeling session. Model storming sessions are held to explore the details of a requirement or aspect of your design.
- Multiple models. Agile modelers should know how to create a range of model types (such as user stories, story maps, data models, Unified Modeling Language (UML) diagrams, and more) so as to apply the best model for the situation at hand.
- Prioritized requirements. Requirements should be worked on in priority order.
- Requirements envisioning. The team performs light-weight, high-level modeling that is JBGE at the beginning of a software project to explore the stakeholder requirements.
History
The development of agile modeling was led by Scott Ambler starting in the autumn of 2000. It initially was called extreme modeling (XM) but at the suggestion of Robert Cecil Martin was renamed to AM in the spring of 2001. The book Agile Modeling [3] was published in 2002 by John Wiley Press. He also has a promotional web site.[4]
Limitations
There is significant dependence on personal communication and customer collaboration. Agile modeling disciplines can be difficult to apply [citation needed]:
- On large teams (say 30 or more) without adequate tooling support
- Where team members are unable to share and collaborate on models (which would make agile software development in general difficult)
- When modeling skills are weak or lacking.