Posts Tagged ‘pragmatic’

h1

The UML’s Double-Edged Sword

July 9, 2010

The sword is one of the most ubiquitous crafted weapons across civilizations worldwide. They come in many different shapes, sizes, and materials. An attribute that they all have in common is a sharp edge. Some multiply their offensive capability by being sharpened on both edges, i.e., the double-edged sword. These are more deadly because they can “cut both ways”. Who would have expected that the innocent use case would introduce a double-edged sword into the UML? Read more at DevX.com…

h1

Come One, Come All!

June 1, 2010

If you’d like to enjoy some fun in the sun AND learn about pragmatic modeling techniques (those two things always go together, right?), then you are in luck. For the 11th year in a row, I have the privilege to be speaking at the IBM Rational Innovate 2010 conference (previously know as the Rational Software Development Conference and the Rational Users Conference).
On Wed. June 9th, 2010 I’ll be presenting “Practical Visual Modeling – Lessons From the Trenches”. Beginning and experienced modelers often wonder why modeling isn’t working well for them. This is because there are many snares and traps to fall into. This presentation, based on lessons learned from real-world projects, approaches visual modeling pragmatically. Visual modeling essentials are discussed augmented with practical, experiential advice, best practices, and heuristics for modelers. Common project failure points, SOA, agility, how to avoid typical modeling pitfalls, and simple risk-based planning techniques are just some of the topics covered.
We will discuss:
• Where the most costly and common project mistakes are made
• What parts of the UML to use and which to ignore
• Business modeling and system modeling via use cases and how to use them
• Avoiding common modeling pitfalls during analysis and design
• Project planning, prioritization, and risk
• Career shortening red flags that indicate when you should get out of Dodge.
• Numerous practical modeling techniques and practices.
So if you are going to be in the Orlando area for the conference, please drop into my session, say hello, sit back, and have some fun!

h1

Fun With Frames and the User Experience Model

April 12, 2010

Development teams don’t necessarily receive “requirements” from their stakeholders as use cases, textual requirements, user stories, or even “drive-by requirements” (where the stakeholder throws a yellow sticky note – that contains their latest requirement – over your cubicle wall as they walk down the hallway). And sometimes the end users (an important stakeholder) are so focused around the user interface of the system, that suggesting changes to their user interface is the only way they know how to express their needs.

The advice you commonly hear regarding using the UML© for user interface modeling ranges from “don’t do it” to (at best) “create a User Experience (UX) model”. The UX model as traditionally described is good for simple situations, but with the advent of more modern, complex UI presentation options, the traditional UX model’s utility begins to reach its limit quickly.

I was pleased to find an elegant answer available in a little used area of the UML© that does not get delved into deeply very often…Read more

h1

A Fool With a Tool…

February 25, 2010

So often, the development teams I coach on modeling ask “What free UML tools are out there?” As you probably know, there are quite a few now. But the problem with asking that question is these teams often have already purchased a modeling tool! Why don’t they ask earlier?

Many times the people who will be the end users of the tools are not (or just marginally) involved in tool selection. Some process or tool group is often commissioned to survey available tools, assess their applicability, and recommend what should be purchased. The tools are purchased, deployed, and then the end users find out that the tools don’t quite fit the manner in which the team actually works. This is a classic problem with a “tools first” approach to process improvement. Tools must support the way you work, not force you to work their way.

I was a member of such a tool committee at a company that was consensus driven in the extreme. We were directed to gather every possible stakeholders’ ideas on what criteria should be used to evaluate the tools. We ended up with a matrix of 123 different criteria. Did the people who would actually use the tools regularly use 123 different tool capabilities? Of course not. When the actual decision was made, after struggling through weeks of gathering, clarification and prioritization of all these decision criteria, the final decision came down to only 3 core criteria. It would have been a more pragmatic activity and much time would have been saved if we had known those 3 key criteria at the start.

But if modeling is new to your environment how would you know what you need? You may not have yet established how you are going to work with modeling. How about trying your new modeling practice with some of the open source (often free) tools? In this way you can easily and inexpensively discover what you really need in a tool for the level of modeling you intend to do. Not everyone does full Model-Driven Development. You may need only some simple diagramming capability. Maybe you won’t need that expensive gold-plated modeling tool. Every development team / organization is different. You may discover that a more modest tool may be sufficient to support your way of working.

If you want to read a nice survey of open source modeling tools read more at http://bit.ly/ll4UY.

h1

Backlog vs. Fatlog

February 2, 2010

I recently spoke with a CIO whose teams were trying to become more agile, but were having significant problems with the basic question of when they were “done”. There are many reasons that this deceptively simple question still eludes people. John Sonmez recently wrote about one reason – the Fatlog.

Do you use a bulldozer to build your sprint backlog – just scooping up everything in sight and building large piles of work items? Does your sprint have an objective or is it just a heap of stuff? How about doing just a little bit of analysis to make your sprint content cohesive? Or as John suggests, just simply divide up your Fatlog into smaller pieces.

So often the most challenging problems can be resolved with very basic, pragmatic techniques. What do you do to organize your sprint backlogs? Enjoy John’s article.

h1

Rarely Mentioned Architect Skills – Do You Have Them?

January 12, 2010

The development community spends so much time debating ceaseless questions such as “What is architecture?” and “What is the difference between this and that type of architect?” We should look behind the labels.  Looking at the type of skills an architect has or needs may give real insight as to what type of architect he/she is. 

Take a look at Peter Cripps’ blog on the Attributes of an IT Architect.  Peter lists a number of non-technical skills that are rarely ever mentioned as skills an architect needs.  My particular favorite is #5 Apply Processes Pragmatically

Aside from Peter’s list and the long list of hard technical skills that could be mentioned, what other skills have you found are critical in the role of an Architect? 

–Bob Maksimchuk (www.ProjectPragmatics.com )

h1

SOA by the Numbers

January 4, 2010

SOA has not ended hunger or achieved world peace (some of the early marketing came close to promising everything) but it has achieved major inroads in software / systems development.  However, its level of “success” still appears to be a bit muddled. 

Loraine Lawson recently posted a pragmatic look (at ITBusinessEdge.com 29 Dec 2009) at statistics gathered in a Forrester report regarding companies’ satisfaction level with their SOA initiatives.

One of the most interesting statistics is that only 24% of the companies surveyed have (or are working on) an enterprise-level SOA strategy.  Hopefully, this is not indicative of the lingering mindset that SOA = web services.  SOA is really a strategic architectural approach to aligning business and IT (and seeing that the report reflects this is quite satisfying).  To achieve that in its fullest requires quite an investment in not only technology (e.g. an altered development process, modeling, choreography, architecture, reuse, business activity monitoring, business process management, re-skilling and so forth) but may also require organizational change – always a difficult adjustment.  This level of commitment is difficult for all but the largest organizations and even then it is a true challenge.

So follow the above link and enjoy Ms. Lawson’s article and the report.

–Bob Maksimchuk (www.ProjectPragmatics.com )