Where to start. . . .

Where to start. . . .: "

So much is going on that what's been keeping me from posting for over two months has pretty much been a lack of focus on where to even start and what to share that is of value. So, first of all, I must beg your indulgence in what might not be the most advice-filled or productive posting from a reader's perspective. I'm hoping, at least, from my end that it will be somewhat cathartic in helping jar loose something useful for all of us. I'll start with a list of what I've been up to, professionally, since my last post. Maybe that will bring up some salient threads:

• Working on CMMI v1.3 -- specifically coming up with language that will make it through the review board to help provide some Agile perspectives.
• Working on an article for CrossTalk on CMMI and Agile 'needing' each other.
• Preparing presentations and tutorials for: Scrum Gathering, CEE-SECR, Agile Development Practices, and SEPG-NA-2010, and SEPG-Europe-2010.
• Working for the SEI on, and delivering several pilots of, Introduction to CMMI for Services class.
• Becoming a People-CMM SCAMPI Lead Appraiser.
• Learning about the Resiliency Management Model.
• Program committee work for SEPG-NA-2010.
• Working on strategic issues with SEI for the Partner Advisory Board.
• Early planning for an AgileCMMI conference (probably 2 days in DC in Winter 2010).
• Incorporating more Kanban and lean (process excellence) into our efforts.
• Gathering data and case work for at least two books-in-work (one on Agile, another on process excellence).
  
• Of course, there's client work and,
  
• Contrary to what the above list may imply, I'm actually working on transforming the messaging of Entinex to be less SEI-centric and more aligned with what we actually do.

Perhaps it's that last bullet that bears some discussion.

Despite knowing that we specialize in lean and agile methods in all our work, recently, someone asked whether we only use SEI tools and techniques. Obviously, it seemed an odd question since SEI doesn't provide any tools or techniques with "agile" pasted on them. But it got me to thinking, "yeah, really, what are we truly up to?" And I concluded this:

Aligning effort with the need to satisfy expectations.

You can expand on that in a number of ways. Chiefly, whose need? The business' needs. Whose expectations? Customers' expectations. Merely satisfy? Of course, not. To exceed and delight.

We bring to bear whatever tools and techniques will help make this happen.

In all cases, we're deeply in pursuit of process excellence and what we've learned is that it's irrelevant to lead with anything from either the SEI or the Agile community. What's relevant is results. Powerful ones.

In truth, I've known this all along, but our messaging was anything but this.

Conversations with David Anderson, Jim Benson, Alistair Cockburn, Jesse Fewell, Alan Shalloway, Ahmed Sidky and many others in the agile world, plus my experience working with SEI, SEI Partners, and clients over the last several months have really surfaced some critical distinctions for me about managing effort, developing products, delivering services, and growing organizational competencies.

Many organizations want to implement agile or CMMI or whatever but they're failing to account for two critical pieces:

1. Understanding their own business, their own competencies, the details of their efforts be they services, development, management, (etc.), their own value stream, and everything it takes to get things done and get paid. And,
2. Making a business case for change whatsoever. Without the first piece, this piece is worthless, so it's logical that organizations fail to make a business case for changing things if/when they don't understand enough about their business.

I find myself more and more having to walk clients and students through both 1 and 2 before we can move on to making meaningful improvements. Neither 1 nor 2 begin or end with Agile or SEI-stuffs. Sometimes we can leverage Agile or SEI-things to help motivate organizations to address 1 and 2, but it's seldom a strong prod. It's become very much like another in a string of tests-of-commitment for clients and prospective clients. We'll lead them to water and it becomes very evident through not just whether they drink, but how they get the water to their mouths as a determinant in our ability to help them become a success story.


This is where to start, and if organizations are already here, fabulous. If not, their work is waiting.

"

RichFaces 3.3.2.CR1 Released

Nueva versión de RichFaces, el CR de la 3.3.2, muchos "bugs fixed" interesante.

RichFaces 3.3.2.CR1 Released:

This is a candidate release for for the 3.3.X branch and is primarily a bug fix and stabilization release. Please take a look at 3.3.2.CR1 and let us know what you think, or if you find any issues!

For all the details of what is fixed take a look at the 3.3.2.CR1 jira page or the release notes.
We will be aiming for a 3.3.2.GA release at the end of September or early October.

Decoupling Between Functional Units (Components) Is A Must If:

Interesante artículo acerca del desacople de unidades funcionales, problema recurrente cuando desplegamos aplicaciones de negocio distribuidas basadas en componentes, que a su vez comparten datos, y hasta un front-end.


Decoupling Between Functional Units (Components) Is A Must If:: "

1. The functional units are already independent or loosely coupled in the target domain (from the conceptual perspective).
2. The functional requirements allow asynchronous communication between the components. Even better: they are already modeled as asynchronous processes.
3. The service component, which offers the services, is likely to change, what would break the "client" component.
4. The service component is not technology or even vendor agnostic. Direct communication with such service component would "pollute" all clients. Encapsulation is a must in this case.
5. Both components have different release cycles. Service component is likely to change, but the client component cannot be re-installed or rolled-out.
6. Both components are going to be developed by different teams, or even some parts outsourced to other companies.
7. An average RFE will cause only local changes in a single component and the decoupling / indirection will help you to isolate those changes.
8. There are already different algorithms available for a given functionality or use case (see e.g. the Strategy Pattern).
9. You are building an API or platform, which is going to be used by other applications.
10. Obvious: the UI should be always decoupled from the business logic realization. Multiple UIs (e.g. JSF, RIA, IPhone) are very likely - also in enterprise environment.

Decoupling or modularization do cause additional coding / conceptual / auditing (e.g. metrics) effort. The reason / intention for decoupling or modularization has to be clearly documented, otherwise the resulting code can be hard to understand and, in long term, to maintain.

[Data Transfer Objects are often introduced to increase decoupling, see page 153 in "Real World Java EE Patterns - Rethinking Best Practices" and Premature Encapsulation Is the Root of All Evil, Page 253]

"

Los problemas de XML en el manejo de grandes cantidades de datos.

Sigamos recomendando artículos de otros blogs hasta que tengamos tiempo de sentarnos a depurar alguno de los tantos borradores que tenemos incompletos.

Los problemas de XML en el manejo de grandes cantidades de datos.: "

No es el uso, es el abuso, que puede transformarse en delirio.

Mi opinión sobre el uso (resumen de los links anteriores) está muy bien condensada en uno de los puntos del artículo: XML es perfecto para para crear documentos estructurados que puedan ser manipulados “como cajas negras” por aplicaciones o, más apropiado todavía, interpretados fácilmente por seres humanos. Por ejemplo:

…pero si tenemos que compartir una gran cantidad de datos entre aplicaciones con una estructura preestablecida… ¿Para qué especificarla junto a los datos mismos si está, justamente, preestablecida?

Tal el caso que se ilustra en how xml threatens big data, un artículo reciente de Dataspora Blog (en inglés) donde el autor comenta brevemente su fracasado intento (enderezado a tiempo) de usar XML como formato para compartir grandes cantidades (ahí el problema) de datos entre aplicaciones.

En resumen, tres razones para el fracaso:

1. XML aumenta la burocracia: creación, parseo, tipado, conversión…

2. El tamaño importa. XML encaja bien para documentos (cantidades de información manejable por seres humanos), pero no para datos (cantidades de información manejable por aplicaciones).

3. La complejidad tiene su costo. XML es mucho más complejo que otros formatos (CSV, JSON).

… y una propuesta de tres reglas para “Rebeldes del XML”:

1. ¡Basta de inventar nuevos formatos XML!

2. Obedece la regla de los 50 minutos: no debería llevar más de 50 minutos aprender el formato.

3. Adoptar modelado de datos tardío (Lazy Data Modeling), un concepto comparable a la “evaluación tardía”: grabar los datos como son y dejar su interpretación (tipado) para el momento en el que se los requiera, implementando esa interpretación de acuerdo a las necesidades del caso. Es un un punto que tal vez merece más reflexión y que da para mayor discusión.

Ése es el resumen, mucho más detalle por aquí, en el artículo original.

"

Bestselling Project Management Books

Bestselling Project Management Books: "

Today I would like to highlight some of the best selling books on project management at the moment. I’m using Amazon.com as my reference for ranking and descriptions.

Project Management: A Systems Approach to Planning, Scheduling, and Controlling

Harold Kerzner, Ph.D.

Now in a Tenth Edition, this industry-leading project management “bible” aligns its streamlined approach to the latest release of the Project Management Institute’s Project Management Body of Knowledge (PMI’s PMBOK® Guide), the new mandatory source of training for the Project Management Professional (PMP®) Certificat-ion Exam. This outstanding edition gives students and professionals a profound understanding of project management with insights from one of the best-known and respected authorities on the subject.

From the intricate framework of organizational behavior and structure that can determine project success to the planning, scheduling, and controlling processes vital to effective project management, the new edition thoroughly covers every key component of the subject. This Tenth Edition features:

• New sections on scope changes, exiting a project, collective belief, and managing virtual teams


• More than twenty-five case studies, including a new case on the Iridium Project covering all aspects of project management


• 400 discussion questions


• More than 125 multiple-choice questions

Project Management: A Systems Approach to Planning, Scheduling, and Controlling

The Fast Forward MBA in Project Management (Portable Mba Series)

Eric Verzuh

This is one of the bestselling books ever published on the topic of project management. Now in a revised new third edition, it presents you with a wealth of proven techniques for managing projects?from establishing project objectives to building schedules to projecting costs. It includes all the basics on defining, planning, and tracking a project, as well as building stronger project teams. This new edition includes new chapters on Agile Project Management, PMI exam prep, and more.

The Fast Forward MBA in Project Management (Portable Mba Series)

Microsoft Project 2007: The Missing Manual

Bonnie Biafore

Schedules, budgets, communications, resources. Projects big and small include them all, and Microsoft Project 2007 can help you control these variables — not be controlled by them. But Project is complex software, and learning it is, well, a project in itself. Get up to speed fast with Microsoft Project 2007: The Missing Manual. Written by project management expert Bonnie Biafore, this book teaches you how to do everything from setting budgets and tracking schedules to testing scenarios and recognizing trouble spots before your project breaks down.

Find out what’s new in Project 2007 from previous versions, and get help choosing the right edition, whether it’s Project Standard, Project Professional, or Enterprise Project Management Solution. With Microsoft Project 2007: The Missing Manual, you get more than a simple software how-to. You also get a rundown on project management basics and plenty of solid advice on how to use Project to:

• Define your project and plan your approach


• Estimate your project, set up a budget, define tasks, and break the work into manageable chunks


• Create a schedule, define the sequence of work, and learn the right way to use date constraints and deadlines


• Build a project team and assign resources to tasks: “who does what”


• Refine the project to satisfy objectives by building reality into the schedule, and learn to keep project costs under control


• Track progress and communicate with team members via reports, information sharing, and meetings that work


• Close out your project and take away valuable lessons for the future

Microsoft Project 2007 is the flagship of all project management programs, and this Missing Manual is the book that should have been in the box. No project manager should be without it.

Microsoft Project 2007: The Missing Manual

Would you like to review these books or another book you have read? If so, contact me about publishing your review on pmStudent.com

---

Copyright © 2008
This feed is for personal, non-commercial use only.
The use of this feed on other websites breaches copyright. If this content is not in your news reader, it makes the page you are viewing an infringement of the copyright. (Digital Fingerprint:
)

Related posts:

1. Are You Missing This Critical Piece Of Your Project?

"