alm Questions

How do I address story writing and slicing challenges?
By Krishnan K - September 29, 20203 Answers

I would like to get some expert opinion on the following product environment in terms of story writing and story slicing. Suppose if we have an enterprise product and many clients would be onboarding to the product in different timelines of deadlines with customized extra features than the basic product. As many clients are getting onboarded with more unique customized features and the overlap is in place, the Product owners are getting challenges in writing the story which enriches the base product that fits our system and slicing the stories into smaller units that fit into the 2-week sprint for the clients. What would be your suggestion or approaches on these sort of situations to address the story writing and slicing challenges?

Can somebody point me to resources on the internet that deals with best practices for managing IT product releases?
By RamaRaghavendran - March 2, 20122 Answers

We are a small IT company developing a variety of IT products. I want to incorporate best practices into our product lifecycle management (PLM) process

Thanks,
Rama

What are best practices in release management in an agile environment?
By ne02886 - March 23, 20113 Answers

Can anyone shed some light on best practices of when / where/ how to establish the scope of the Release in the Agile Development Lifecycle model?

Our problem seems to be that we can never get to the point when we can nail down what the scope of the release is. When we do, it seems to be last minute and I am sure that this is not the best method for testing.

Meaning of life—a.k.a. The value of Application Lifecycle Management systems
By Marc Girod - February 19, 20117 Answers

I recently assisted a presentation of Rational Team Concert, and I am shocked.

It could have been, I am sure, some other product. I don't intend to bash RTC.

Only, here is a large vendor which spends large amounts of money (I assume) to produce something I believe and I hope can only be a terrible flop. Nobody will buy that, will they?
Only, they won't buy it for the wrong reason: because it costs money, and the market of ...CM/SCM/ALM/whatever has now gone such a way that nobody will anymore pay anything for that. Everybody knows that whatever allegedly useful there might be in that domain has to be free (like beer, not like speech).

No, my problem is elsewhere: this big company must have targeted a potential customer base, and beyond that, well, somewhere *users*. But who would *use* that?

It is the answer to that question which is frightening.

Pseudo-management. People who would be completely helpless faced to software development, yet in a situation of having some hope to survive this obvious fact in the context of some organization.

The kind of tools I am talking about is meant to hide incompetence, by creating a virtual reality from quantifying the activity of others (developers?) without needing to understand anything of what it consists in.

There are several problems bound to this.

This is not only useless, but lethal. It creates a reality made of amounts of resources, of milestones, of names, of tokens of various kinds, of percentages (passed tests ratios, coverage, numbers of lines of code changed, etc.), which takes precedence over the primary reality made of semantics and of symptoms. It eventually makes it impossible to analyze issues, to fix code, to discuss the compatibility of options and the propagation of changes.

The ultimate problem lies in the paradox that organizations which could put such a dangerous amount of power into the hands of structurally irresponsible people do not seem to fear facing quick bankruptcy. Quite on the contrary.

Stalin has come back?

Marc

Which is best path—fully integrated ALM or custom best of breed?
By tekkie - December 2, 20107 Answers

Below are some observations I've made and I'd like to solicit the communities feedback on the conclusion I've drawn from it.

When looking at industrializing software development by creating a fully integrated and automated pipeline through which changes flow from check-in, through integration, build, testing, packaging and deployment; there are 2 paths one can follow:

1) Buy and implement a single vendor solution that covers the whole pipeline from check-in to deployment, the main drawback with this option being that most of the tools that make up the pipeline will do an OK job, not great, not the best in the industry but they will get the job done. Secondly there is the tie-in to a single vendor which is often perceived as a thorny issue because of the usual what-ifs and the constraints on customization of processes, tools etc.

2) Buy individual 'best of breed' tools to cover each of the stages in the pipeline and integrate these tools with your own resources. Creating this integrate pipeline with your own resources will take time, most likely a couple of man years to get a fully automated pipeline in place and then there is the support. Second because of the less than 'uber' tight integration the value of all the tools together is less than the sum of their individual value.

The above observations bring me to the conclusion that there isn't that much to be gained from buying the best of breed tools for the individual areas, sure you will have the most powerful tool for this and the other, but in the bigger picture that value won't be that noticeable. Just like a single vendor solution won't give you the best pipeline just because it's fully integrated as each of the stage which will be performed OK.

At the end of the day the value you will gain from both paths will be more or less equal, some areas will be better in one others will be better in the other.

What do you say? Did I miss something obvious?

- Antoni

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.