The Pomodoro Technique

I have come across a very interesting but simple answer to time management. It is called the Pomodoro Technique, after those nifty little kitchen timers shaped like tomatoes (Pomodoro is Italian for tomato).

http://www.pomodorotechnique.com/

Why mention it here? Because we spend our careers making people's work using our systems more effective and efficient (at least we hope we do). What some of us do not do is make our own anything like as efficient as we do with the BPM systems we write. It's "the cobblers children never have shoes" syndrome, I guess.

I happen to be the worst (or perhaps that's best) procrastinator in the world. I have so many tasks that my 'to-do' list is a legend in its own right. I actually think items on it breed. I wrote the book on procrastination. Well, I nearly did, but I put it off, of course.....

So how does this technique work? The idea, as I said, is a simple one. Break time into fixed chunks time. 25 minutes of work, and 5 minutes of 'down-time' to have a break. This does not have to be 25 minutes, but they have found it is best.

You work on a task until the 'Pomodoro' is ended (the timer rings). When it rings, you stop, even if there is only a few minutes of the task left. If you complete a task before the end of the Pomodoro, review it, improve on it etc until the end of the Pomodoro.

Do not let internal or external distractions stop the task. Internal ones, jot down, external ones explain and jot down, perhaps with a deadline if not today. You may add a Pomodoro just do deal with these queued up mini-tasks, too.

That is only a very simplistic overview, and you can get a lot more from the web site. There is also quite a bit you can do to develop the technique, especially regarding estimating time and recording and planning, that I will let you find out for yourself if it interests you.

I shall be working on a Metastorm BPM Pomodoro process shortly. It was actually my first 'parked' task I jotted down when working on my first Pomodoro!

Moving from Metastorm BPM Version 7 to Version 9 - Naming Conventions

http://www.processmapping.com.au/MBPMv7Tov9/NamingConventions%282%29.html

Metastorm BPM version 9 has significant new restrictions on naming of elements. This is based on the architecture employed, since the many elements will become properties or functions of the same C# class. There are basic limitations to all names, as well, that are linked to C# syntax.

On top of this, there is the new ability to provide ‘captions’ to many components and elements. These are often also changeable to support different languages supported by the user’s browser. Some we find are never used in the system at all, however.

There has also been a significant change in the way variables are referenced. Metastorm BPM is now strongly types, and the addition of Intellisense to all editing scenarios gives us the freedom to dispense with the awkward prefixes that abound in examples from earlier versions. We will certainly be very glad to see the back of these, although we are sure they will persist regardless in some quarters.

Because of these changes, we have developed a new set of naming conventions for Metastorm BPM. These conventions are designed to minimise the potential conflicts, and give us much greater ability to distinguish between items when no other indication is available (as it now is with variables).

These conventions are neither exhaustive or fixed in stone, they are merely what we have come across that needs a convention, or indeed, that needs one being dropped!

 

We no longer need to prefix our variables with the type. This was been very often misused due to ignorance in any case, and the field type is often used instead of the data type (eg %drpText1 and %rgpText2 and %txtText3 when all three are text variables).

Take the above example. We have three variables, each with a different type.

When we reference them in the Formula editor with the ‘%’ symbol, we have no way to tell what the variable type is. This can cause problems with erroneous conversions and the similar mistakes.

Now we move in to the (relatively) type-safe world of Metastorm BPM version 9.

When we try to assign values using the Formula Builder, we get a clear indication of the variable type.

When we select a value from any Business Object, we again have a clear indication of the variable type.

Even when we use Intellisense to find and select the variable, either in the Formula Builder or the C# editor, we get a clear indication of the variable type. We can lay the variable prefix to rest at last.

 

The naming of Processes has been the bane of many a Metastorm BPM developer. Firstly, once it is set, it is set for good. This is one reason we work very hard to get it right first time. Unfortunately the business owners rarely understand the significance of getting it wrong. They then ask, months later, “can we change the title of this process” (most often not in those words). Groans ensue. Well, it’s all over. All of it! We can name the process anything the users want, even with symbols in it! This is because we now have ‘Captions’ for our Processes. The upshot is that we can have what we have been requesting for a long time, namely a table name that is different from the Process Name. The facility has always been there, but never activated in the Designer. Look in the eMap table and you can see the eTableName field. This can be anything you like (we’ve hacked and it works).

What we now do is treat the Process name itself as a table name. Typically we group all tables for a particular system by prefixing the table with the initials of the system. When you have many systems on the same database, which we will always have, it makes it a great deal easier to see and select related tables. In Metastorm BPM version 9 we have decided to do exactly the same with our Process names.

This has the added advantage that the Process Data Business Objects are much easier to identify in what inevitably becomes a rather large list.

 

Solution Tables

When we define Solution Tables we employ the same naming conventions as we use in the Process Tables.

We do not, however, use the name eFolderId in Solution Tables that relate to Process tables using the Folder ID. If you do this, you end up with an extremely confusing schema that anyone who did not design the system cannot determine from the names alone. We use a convention of Id for these fields, so that it is clearly not a Process Table, and the related table is clearly identifiable. Given the same table prefix, this is rarely difficult to work out at a glance.

 

Roles

Roles are another area where naming is important to allow identification. All roles that relate to a specific Process are prefixed with the initials of the Process. This can be seen on the list above. In general these are dynamic Roles, although that is not always the case. If possible, Roles relating to the Process itself may be prefixed with the system prefix. If the Role may be used outside the system, which is common, we dispense with this convention, however. We arrange the roles in the following order: Default Metastorm Roles Process Specific Roles Other Roles We also add both a Caption and a Description, although generally both are set the same. This is because the Caption is seemingly never written to the database, although the Description is. We happen to think this is the wrong way around. Both can have different translations, but these are seemingly never written to the database.

As you can see, we show this description in our standard ‘Assign Users to Project Roles’ form that we can use in any Project.

We find this a great deal easier than the default approach that ignores both the Caption and Description. It also does not let you filter by Project, so making even a basic system a nightmare to administrate.

We find that generally the roles will then be easier to pick from the Toolbox. The few at the bottom are from Libraries, although not prefixed as such.

 

Forms

Now that forms are no longer associated with any particular Process, it is more important to find a naming convention that allows you to identify where they are used. We prefix the name with the initials of the Process they are associated with. Forms that are not associated with any specific Process have no prefix.

The exception is Forms in Libraries where we may prefix them with a numbering system. This is purely because there is no longer any way to set the order of Forms in Libraries, the are in alphabetical order by default. When we tend to add a large number of forms in one particular order, it saves a lot of time to ensure that the order is alphabetical.

 

Business Objects

Business Objects probably pose the most challenges when it comes to identification. As we have outlined elsewhere, there are a significant number of different usages for Business Objects. Each usage is potentially entirely different, and requires both different conditions and methods to employ the resulting Business Object. The different usages of Business Objects we have identified are: Editable table Single editable record Single read-only record List of records Filtered list of records Although some may appear to be very similar, they still need to be created differently and used differently. It is also possible for some types to be used as others, but there still remains these five unique possible different usages. Accordingly, we have created a prefix for each of these types. We list them here with a description of each: Usage PrefixConditionsCommentsEditable tableTablSingle Entire Table Primary Key Not read-only Can be used as a listSingle editable recordEditSingle Entire Table Primary Key Not read-only Unique Filter Can be used as a Single read-only recordSingle read-only recordDataUnique Filter Read-only List of recordsListGeneral or no Filter Read-only Will not change Filtered list of recordsFiltGeneral Filter Read-only Expected to change Can be used as a List

 

Admin Groups & Forms

There is little need to prefix Admin Form groups with anything. Nothing that the system creates will be relevant. Admin Form groups no longer even create a custom variable table.

If desired they can be prefixed with the system initials.

There also seems to be no real need to have any naming convention for Admin Forms.

In general, if naming conflicts occur a change of name is required. The Caption can remain as desired, of course.

 

Stages and Actions

There is a significant new restriction in the naming of Actions. No two Actions in the same Process can be the same. The restriction used to only apply to Actions from the same Stage.

However, the Caption can be anything you like, so this is not really a restriction that bothers us. In fact, you can now have three actions with exactly the same ‘name’ (Caption in reality) from the same Stage!

It is very important to make sure the name of Stages and Actions is edited, however. Most Process designers will happily edit the caption in place and ignore the actual name. This is not a good idea at all. As we have noted on our Forums, it can even lead to serious problems at a later date if they are renamed. If you leave the defaults, you will end up with Stage1/2/3 and UserAction1/2/3 in the eEvent table. No auditor would find that acceptable. You can link to the Caption in the eStage / eAction tables (and we do), but it is easier in the long term to avoid the necessity. Generally we try to keep the real name close to the Caption. To do this we enter the name without spaces or symbols, and then edit this in the Caption property to make it more friendly.

We do the same with Stages

 

Visual Script Activities

We deliberately do not change the naming of any Visual Script activity. We also leave the Container name as is, unless it causes a naming conflict (as described on our Forum). What we try to achieve is to ‘tell the story’ of what the code is doing. This is roughly equivalent to comments in code, althou vastly easier to read, typically. You can see fairly clearly in the above example what is occurring in the Visual Script, we feel.

If we have additional comments to make that do not fit on the Caption of the Activity, we add this to the description. This is not seen until you hover the mouse over the Activity, so is less likely to be seen. It is a very useful place to add notes that may be pertinent to developers maintaining the system, for example, but that do not add to the overall documentation. Oddly enough, this tooltip actually stays up until you move the mouse, unlike others that disappear after about five seconds. That means you can actually read this one!

 

Flags

Generally we name flags prefixed with the Project name. This allows us to more clearly identify their origin when examining the database or audit records, as well as during fault diagnosis.

 

Projects & Solutions

We do not have any naming conventions for Projects. They do not need a prefix, and as long as they are suitably descriptive, that is acceptable.

As Projects do not have any kind of ‘Caption’ that may be used for presentation, it is actually very important that the names of Projects are not garbled. It will not make the system more readable or understandable, and it can cause confusion.

Solutions can be named anything you like as long as it does not violate Windows file naming conventions, as far as we are aware. The Solution name is also not important like the Procedure name used to be in Version 7 and earlier. It is merely a container for the Project and Library files.

 

 

Metastorm BPM 9 Collaborative Training Course

Collaborative Training is the only way forward with Metastorm BPM 9, we think. 

See the details at:
http://metastorm.processmapping.com.au/post?id=4581397


Ours is a unique approach, we feel. The solution is built up in a series of stages by three collaborative parties - Analyst, Developer and Administrator. Each does separate work that is used by the others.

The more we look at the problems that are being faced by developers, and the problems that we know will be faced by developers in the future, the more we see how vital this complete separation of analyst and developer roles in Metatsorm BPM 9 will be. If we do not force the separation, we run the very real risk of putting the analyst in the ridiculous position of being forced to resolve C# issues, learn C#, or have nothing more to do with Metastorm BPM.

I think that would be costly for all Metastorm's existing customers in very many ways. Given the need for an almost complete rewrite of existing processes, to be documented in our Migrating to Metastorm BPM version 9 series, this poses some serious issues for the future of current Metastorm BPM systems.

It is clear to us that this either has not been foreseen by Metastorm, or they have chosen to ignore it. Either way could be ruinous for them in terms of the existing customer base.

Migration to Metastorm BPM 9 - 1 The Benefits of Metastorm BPM version 9

http://www.processmapping.com.au/MigrationToMBPMv9/TheBenefitsofMetastormBPMversion9.html

Firstly, let us look at what we stand to gain over version 7.

Processes Processes are the heart of the whole product. Are we going to get a great deal more in terms of functionality with these? We think there is little benefit in regards to process design per se, as it happens. Formatting is much nicer, however.
Swimlanes For those that like them, there are now Swimlanes. They are there for those that don’t like them too, of course, but they can be very easily ignored. As can be easily seen, they do add quite a bit to the attractiveness of the Process map. This is more pronounced when colours are employed. I am not certain I shall often use them myself, as it can make the process design awkward. Many analysts will love the idea, especially as a lot of specifications use the concept. Managers may well like the idea from a documentation perspective. The addition of meaningful icons, as we have here, makes them even more useful.
Process styles We now have the ability to set some options regarding the style of the Process map. Most important is probably the addition of ‘shapes’ for the Stages. These are potentially attractive if you wish to keep to a particular notation. You have the ability to change these from the default, but not to set the default shape for a Stage type. This could require a lot of maintenance if the defaults (as shown) do not conform to your needs. We find the addition of the Visual Script ‘arrows’ makes the diagram a bit ‘busy’, although they are extremely useful to portray the existence of scripts (solid arrows), and offer an easy way to edit them. Another potential useful option is the different line styles. You now have the option to use the standard ‘bendy’ lines, hard or rounded ‘square’ lines, or straight lines. Care does need to be taken to use each style effectively, but you can set the default and change each line individually to deal with any difficult positioning.
True parallel processing As we have demonstrated, it is now possible to have truly parallel processes. This was not really possible before, and any attempt would involve a significant amount of awkward and difficult to maintain code. http://www.processmapping.com.au/MBPMv9HnT/2010/01/index.html You can even now do this with no code or SQL at all, viewing and updating data from different processes, due to the new way forms and data have been dissociated from the process. This can result in far more elegant and easy to maintain systems, although care does need to be taken.
Formatting As well as the formatting options for fields, these are available in full for Process Maps as well. This can make laying maps out quite a bit easier.
Zooming Process Maps can now be zoomed in and out. This can make navigation of larger maps a great deal easier.

Forms
Field formatting As shown above for Process maps, we have full layout facilities for form fields. The size Equally option is especially welcome, and for me, the icons showing how centering works is great (I was always getting it the wrong way around). The Increase and Decrease spacing are welcome additions too. What is even neater, is the ‘snap to other fields’ feature. This is much better than a ‘snap to grid’ feature, we feel. The ability to resize multiple fields at once with the mouse is a great addition. It makes reorganising forms much less fiddly!
Drag & drop variables This is my favourite new feature: Drag fields from a Business Object to create fields for that variable. The only problem is you cannot get dropdown or listbox fields this way, but that is minor. And you get the option to create a grid if you drag multiple fields! The easiest and quickest way to create grids possible, I think.
Local Variables We’ve been after ‘temporary variables’ for a long time now. At last we have them in all forms. We also have them for form segments, so we can create really useful and functional reusable components to drag and drop onto a form. Obviously, once you delve into C# code you have the option to create as many local variables as you wish as well.
Field grouping There is a new ‘Tab Order’ feature that Metastorm are touting as fairly nifty. It is possibly clearer to use that the old way, although adding new fields can involve a lot of clicking about, which is a pain. What is neater, and I’m not sure Metastorm are really aware of it since it is not documented at all, is the ability to Group fields. This also gets set in the tab order, very usefully. There are some issues with display of grouped fields in the Designer, however.
Templates & defaults One of the most time-consuming tasks that are non-productive in Metastorm BPM is setting up forms to look the way you wish. It is possible to have a standard form and keep importing it, but in version 9 there are much easier ways. The approach is two-fold. Firstly you can set the colour of all new forms. We are not sure why you cannot set the font as well, as it would seem fairly simple. Better is the ability to save any form, admin form or form segment as a template. You can (and we do) even add segments to the template. Selecting the template you wish creates a copy of that form. There are so many uses for this, we will not attempt to exhaust them here, but will discuss in a forthcoming Metastorm BPM Hints & Tips episode. http://www.processmapping.com.au/MBPMv9HnT/

Code
Native C# code For the code monkeys among us, there is native C# code. All Metastorm code is now generated C# code, or Metastorm functions called from this code. You can also create as much of your own C# code as you wish, and import any DLL files you may wish to use, of course. You have a full C# editor here And many useful editing tools, including the all-important Script Validation.
Intellisense You also have Intellisense, as you would expect. What may not be expected, however, is the same facility in all areas where you can edit Metastorm code. In the Expression Builder you can use Intellisense at any time by pressing Ctrl-Space. Or it is automatically invoked at appropriate points. It is even available in the properties box fields where appropriate, making editing very swift indeed.
Easier code reuse One of the hindrances to code reuse has been the awkward scripting calls that are required in version 7 and before. This is now a thing of the past. all C# scripts can be promoted to the Expression Builder and Visual Scripts Toolbox. You can even add descriptive names for functions and parameters, as well as helpful hints for the Expression Builder. And in the Visual Script Toolbox Visual Scripts can also be promoted to the Visual Scripts Toolbox. And then used in any Visual Script.
Visual scripting Visual Scripts are a very nice way to write Metastorm code. Effectively they generate C# code by building the statements from Drag and Drop components. Here you can see the available components. And these are a set of components built into a script. You can see that certain components allow the nesting of others. You can even collapse containers of other activities to keep clutter to a minimum. And you can zoom in and out just like the Process Maps. When descriptive comments are added to the activities, the code is very nicely documented.
Conditionals & Looping As shown above, we now have looping within Metastorm code. This used to have to be handled by writing a script, or by means of conditional loopback actions. Looping if a basic do while loop. For each allows you to perform activities on a property of any Business Object. Although a list is accepted, it does not work with lists as far as we can tell, however. Conditional execution is an If – else if ... else format. Any Activity or container of Activities may be disabled by un- checking the ‘enabled’ checkbox. This is a neat way to disable code during development.

Data
Easier sharing of data In version 7 and earlier, you had to create the required SQL for every database call and grid. Now we have Business Objects that can be set up and shared among many components. This is a simple table BO which may be used for lists and read- only grids, or in an editable grid or recordset. You can also create a BO that uses any query you like, even employing views and stored procedures. These are always read- only. These Business Objects can be created and maintained in a library for use in any other Solution. This is a major potential time saver when tables are added or modified.
Data sources can be shared In version 7, if you wanted to access another database, you had to reference it each time it was used. In version 9 we now have Connectors. These may be created in a library and shared with other Solutions. This can make it a great easier to maintain separate connections for different environments. You could have a different set of connectors in different versions of a Library for Development, UAT and Production environments, for example. Ensuring the correct version is published to each database and retrieved on deployment would ensure the correct databases are used for that environment.

New Features
Multi-language support Metastorm are aiming at the larger corporate market. Many large corporations, even if only based in the US, will benefit from the new multi-language features. Forms can now be edited in as many languages as you like. The functionality remains the same, as well as the data, but the captions labels form names, and even field position, may be customised for each language. All of the process names, stages and Action names are likewise editable. These names are visible in different languages in the client, even for the same Folders.
Reports & graphs Most Metastorm BPM systems will have some kind of reporting needs. Now you can add your own reports into Metastorm BPM directly. Since these reports may well use the same Business Objects that you employ in your processes, much of the development work can potentially be reused.
Collaboration Metastorm BPM development has up until now mostly been a solo exercise. There are ways to share development responsibilities, but they are limited and awkward. Now the various components of a Metastorm BPM solution are in separate files. These can be easily shared using a source control system such as Visual Source Safe. Files that are not ‘checked out’ for editing are available and included in the Project, but not editable. This is also plainly demonstrated by the shading of the properties and toolbox.