Software Creation Mystery - http://softwarecreation.org

Archive for the ‘Agile’ Category

Know What Software Features to Build Next: User Stories, Business Canvas and Market

“Devoted to Facebook IPO”

Is there any development process that can really increase chances of the software system market success in this uncertain world?

Traditionally Project Managers make decisions for the horde of software developers what features should be attacked in the long release. Yes, this approach frees busy developers brains from the mind boggling task of thinking about the business. But developers no longer get business context – why features should be done and what is important for the business. In addition, long releases detach developers from the product market results and inhibit learning and adaptation to the customer needs.

Agile Development

Agile fixes these problems with three important practices – The Whole Team, Small Releases and User Stories. Customers and developers are one team that frequently discuss features face-to-face and create User Stories together. Important User Stories become part of the new release, others go to Backlog. The team releases features frequently and learn from customer feedback and implementation.

User Story captures the ‘who’, ‘what’ and ‘why’ of a requirement in a short simple way from the customer perspective. A user story is a unit of requirement, estimation and planning. It should be testable and fit into a single iteration. Often a user story is broken into programming tasks which describe specific implementation steps.

User Story is done when it is:

  • Code Complete and Working
  • Tested
  • Accepted by customer

Agile is wonderful process! Developers work closely with business providing speed, accurate interpretation of requirements and intellectual contribution (surprise!) in translating business vision and needs into the concrete software system.

The Customer accepts the User Stories at the end of frequent iterations, provides feedback and change future User Stories based on experience with this real working system. In short, the customer steers the direction of the project instead of being a hostage of the unruly slow development machine.

However, one big problem remains – everything depends on the customer’s ability to get brilliant ideas, correctly read the market and envision what set of features will succeed. Unfortunately, it is almost impossible to get right. Business geniuses (except Steve Jobs), smart analysts or even consumers themselves cannot reliably predict how people would react, what they really need and will like next. And developers can contribute more to the market discovery and quality of business decisions.

Read full post >>

Raising Software Architecture. 9 Troubles and 3 Answers

The main architecture goal is to strengthen and align system ideas, muscles and structures in areas most impacted by stress, changes and expansion.

In short, architecture covers every important aspect of the software system.

A good thoughtful software developer is torn apart by conflicting approaches for architecting complex software system:

  1. Heavy upfront system design leads to rigid, costly and over-engineered solutions
  2. Ignored business and technical perspectives cause business irrelevance or failure
  3. Poor reliability, performance or flaws could kill promising beautiful software system

What is the best approach to build a sound and successful system?

Problems

Let’s consider several architecture challenges that a software team faces during system development.

  1. Idealism (assumed known knowns) – mostly theoretical views, lack of practical experience, illusions. We often exaggerate our intellectual abilities to find right solution theoretically.
  2. Open problems (known unknowns) – problems or needs without foreseeable solution. These evil inconvenient unknowns could seriously impact the course of the project
  3. Uncertainty (unknown unknowns) – low predictability of the future in technology, business and Universe. Many good decisions could turn to be wrong after some time.
  4. Over-complicationover-engineering for domain problems because of over-thinking, misunderstanding, lack of information or technical enthusiasm. Over-complication steals development time and increase cost and complexity.
  5. Fragility – poor system quality (performance, reliability, uptime, security, etc.). Neglecting quality could cost reputation and harm system success.
  6. Complexity – complex structures, unpredictable behavior and states that turn a system into the Ball of Mud.
  7. Inconsistency – dissonance of the system approaches and parts; fragmented and incomplete knowledge in heads. Development teams produce incoherent system without coordination of ideas and implementation.
  8. Inertia– difficulties to introduce disruptive changes (for business, users, operations). People and established processes resist changes and have inertia that is difficult to overcome.
  9. Misalignment – with business goals, existing systems, infrastructure. Building a software system without considering business vision, existing IT landscape is the path to disaster.

Three Architecture Answers

There are 3 useful approaches to Software Architecture that address these challenges:

  1. Strategic
  2. Technical
  3. Evolutionary

Read full post >>

Software Creation Mystery - http://softwarecreation.org
This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 License .