It's Roy, but that's OK. I don't mind being mistaken for Ron  Not sure what his take might be though.
 
OK, your reply highlights a problem that I have seen for many years when teaching database development, and in database textbooks. That is, what to call what. I take an ER Modelling approach to developing databases (within a User Story Driven Approach). I call the ER Model the Conceptual Model. The ER Model can be, and in my view should be, defined without database considerations in mind, at all. But, nonetheless, there is a usual assumption that an major outcome of this activity will ultimately be a database. So the Conceptual Model (ie: ER Model) can be transformed into the Logical Data Model, where the data is defined. Entities have attributes which transform into datafields, usually, and are given physical definition ... datatype, length etc. You then can add table processing required datafields as well. Then, the logical model is transformed into the Physical Model. This is where the specific DBMS will need to be understood. Table and index clustering, table types, accessing paths etc. need to be defined. This is a DBA function, to define the physical database to be as efficient as possible, whilst maintaining the integrity of the logical data design. I would suggest that a DBA would be 'on loan' to a development team, to many develoment teams, and not part of a specific team. Similarly to a network administrator, or a security administrator, this is more in the realm of looking after things after the development is complete. I think that tuning the database is something that must happen depending on observed performance. We can make some assumptions up front about network or database traffic, but in any case, tuning the database is not a one time activity ... it is a continuing function for the lifetime of the system, using daily statistics.
 
Now, I will admit that all of my experience has been with business systems, where data stored relationally is entirely adequate. Exactly how things might change given different (sometimes radically different) DBMS's and different storage paradigms, I really don't know. But I would still hold to the view that the data must be defined conceptually (that is, understanding the business information architecture), logically (understanding the design of the data architecture itself) and physically, on the disk, according to best usage of the specific DBMS. (Maybe 'cloud computing' brings with it significant changes to how we do all this, especially the last part, but again, I don't know at this stage).
 
However, having said all that, which seems to me to be better discussed in a database forum, I fall back to the discussion about an agile approach to this, and I will steadfatly hold to my view that the database can, and should, be developed incrementally, evolving, and that this does not create specific and dangerous problems for future ' refactoring'.

Regards,
Roy Morien
To: scrumdevelopment <at> yahoogroups.com
From: stephan.huez <at> gmail.com

Date: Wed, 31 Mar 2010 18:06:42 +0200

Subject: Re: [scrumdevelopment] iterative development with system design

 

Hi Ron

Actually, I think that we concur on the first part. The conceptual or logical or whatever we name it view on the database can be seen early. Nevertheless, when we speak relationally, it points me to the database and tables and foreign keys, whereas in higher levels of the application, I only speak in objects and relationships. I take it that when you said " You can design and implement the database relationally, without heed to the underlying physical structres.", you referred to what I call the logical model whereas database tables and their relationships are the physical model.

You said that tuning the database is a DB function and not a developer function. Could you elaborate on the way you see DBA interacting with the team? I usually prefer that DBA be part of the team and be considered as developers as any other team member.

Actually, my most recent experience is based on working mission critical systems whose focus was as much, not to say more, on the non-functional requirements than on the functionality. This might seem weird to many but this happens. To get to that, you need to prove that you system is responsive, stable and reliable well before rolling it out into production. In such cases, the tuning happens prior to the roll out because the more you add to the system, the more you must make sure that performance remains steady. This is, I think, why we have diverging opinions on when the tuning begins.

Cheers,

Stephan

On 31 March 2010 17:03, Roy Morien <roymorien <at> hotmail.com> wrote:

 

Perhaps I have spent too long designing relational databases, and applying normalisation principles. Mind you, I apply the normalisation principles way back at the ER Modelling stage, in what I see as a modular, loosly coupled, highly cohesive design.
 
In my view, we can readily see what is often refered to as the External View of the database, or the Conceptual View, dependng on your book. You can design and implement the database relationally, without heed to the underlying physical structres. That is the level of refactoring that is most likely, I think. As is stated in this posting " the actual database refactoring takes place when the database is tuned to help meet performance requirements". This is a DBA function, not a developer function, and should continue well into the implementation lifetime of the databasem which is why I don't particularly agree with the statement that "One single story will never get it right.". Such refactoring mostly occurs long after all User Stories have been attended to. How much any developer can foresee this situation  is a matter of fact, and I think the fact is, the developer can't, and really shouldn't spend much time being concerned about it. Performance tuning must necessarilly be based on performance history, which has not yet occured at the development stage.

 
Regards,
Roy Morien

 
To: scrumdevelopment <at> yahoogroups.com
From: stephan.huez <at> gmail.com

Date: Wed, 31 Mar 2010 16:35:28 +0200

Subject: Re: [scrumdevelopment] iterative development with system design

 

In my experience, it is always better to keep the database design to what is actually used and not what is likely to be used. Personally, I don't like wasting time creating, and maintaining something that is not used.

I also find that it is much better to make the upper levels work fine and provide customers with the right functionality prior to starting digging into the database. If the database is properly abstracted, it is easy to work as if it weren't there. It also works the other way round. Nevertheless, I find it much easier to refactor the code than the database. Once you get into the database, you also need to start with heavier integration tests, which take longer to run and take usually more energy to maintain. Technologies that generate the database can come in handy in this situation. This lets you time to reflect on the actual database structure to put underneath.

On the other hand, I would say that the actual database refactoring takes place when the database is tuned to help meet performance requirements.You can only properly design your database based on the way it will be used. One single story will never get it right. This happens when we eventually know how the database will be used in terms of load patterns, distribution and so forth. The database might in the end look much different from the domain objects that the application deals with. If the performance requirements were critical aspects, as I have already encountered, it is important to work out how to get the system fast early, including the database.When we get to this stage, we are supported by the test suite that was built. We know that we are safe to refactor the database without braking everything.

Applying good design principles help prevent the application from falling apart when a domain object changes for instance.This nevertheless happens way too often IMHO. Evolutionary design of the database is not, IMHO, the easiest to be successul with.

Cheers,

Stephan

On 31 March 2010 16:02, Roy Morien <roymorien <at> hotmail.com> wrote:

 

I agree entirely ... a basic tenet of good project management is to ensure the feasibility of the product, and that must include approaching the riskiest parts, or most complex parts,  of the system first. If they cannot be done, then there is little point in spending time on the easy bits.
 
But that has little to do with the matter of whether or not you plan ahead, and try to second guess what might lie ahead to avoid refactoring etc.
 
The question that I alway ask about database designs, usually done in a BDUF manner, is why (as an example) it is necessary to know about 'TEACHERS' when we are analysing 'STUDENTS'. To me, developing the database is a bit like 'How do you eat an elephant?' ... a little at a time. If you apply those basic tenets that Ron mentioned earlier about programming (high cohesion, low coupling, modularity) to the database then you can evolve the database without much refactoring, if any. To me, adding a new table to the database is not refactoring. Even adding new columns to a database table isn't really refactoring, in my book.
 
The fundamental problem being addressed is where new requirements demand a destructive redevelopment of previously completed work. How often does this happen if good design principles are followed?
 
This seems like a folk memory of olden days, of werewolves and ghoulies that aounded in an earlieer time, in the form of having to restructure an IMS schema, for example. Of having to rewrite the processing code to an X-Y addressed terminal, for another example. But times have changed!

 
Regards,
Roy Morien
 
To: scrumdevelopment <at> yahoogroups.com

From: stephan.huez <at> gmail.com
Date: Wed, 31 Mar 2010 11:56:11 +0200

Subject: Re: [scrumdevelopment] iterative development with system design

 

Hi all,

Personally, and maybe it's due to my RUP experience and architect's background, I tend to follow the RUP principle of identifying architecturally significant use cases, which
will be stories in this case.

I think it's worth identifying what stories bear the greatest technical risks and uncertainties and ask the PO whether the team can plan them in early iterations. The
architectural value must of course be balanced with the business value. If a story were technically risky with a limited business value, it could wait for sure.

Working this way allows for sort of securing, most probably only temporarily, architectural choices but for stories that bring value to the customer. You don't design and
architect the solution for future stories but for those that you implement right away only. This also means that from one sprint to the next, there will nevertheless be
refactoring because we don't do any big design upfront but instead implement the solution that serves the stories planned in the sprint.

Cheers,

Stephan

On Wednesday 31 Mar 2010 06:30:16 Roy Morien wrote:
> Has this question arisen becaue you have a real situation that you need to
> overcome (in which case could you give me / us a concrete example), or are
> you asking 'just in case' you face the situation in the future?
>
>
>
> I often think situations like this are more apparent than real, and are
> usually brought about because of poor design and programming practices,
> rather than being a problem in its own right.
>
>
>
> For (a simple) example, if I write a function that reads the clock and
> checks to find if a file exists, then I may very well run into a
> refactoring requirement if someone in the future just wants to call a
> function to read the clock. But this is, of course, bad programming
> practice, which has caused the need for refactoring
>
>
>
> If I design a database tale, that is subsequently found to need more
> datafields, then I guess I am going to need to 'refactor' my database ...
> is this poor analysis practice wherein I should have found ALL of the
> datafields at the start? No, it is simply evolution of undersanding about
> the requirements. Is it a huge problem? No, refactoring databases is
> almost a trivial activity these days, but does have an impact on
> processing code.
>
>
>
> SO in one situation we have poor code, demanding refactoring, and on the
> other situation we have an evolution of understanding, which is a good
> thing.
>
>
>
> If I must refactor my database because of efficiency concerns, because the
> db traffic grew well beyond expectations, then maybe some better forward
> thinking was in order ... but we are all wise in hindsight. This again
> doesn't really seem to be an example of your apparent concern.
>
>
>
> Let us know more.
>
>
>
> Regards,
>
> Roy Morien
>
>
>
> To: scrumdevelopment <at> yahoogroups.com
> From: adam.sroka <at> gmail.com
> Date: Tue, 30 Mar 2010 21:18:39 -0700
> Subject: Re: [scrumdevelopment] iterative development with system design
>
> On Tue, Mar 30, 2010 at 9:05 PM, zp.dai <tyitsf <at> hotmail.com> wrote:
> > Hi guys,
> >
> > When the team is working on stories for the current sprint, how can they
> > do a good design which can also covers stories in future well? In other
> > word, how do you suggest to minimize refactoring existing code?
>
> Keep the design simple, in large part by refactoring proactively.
> Also, have frequent discussions about the general approach and how to
> improve it - include everyone.
>
> > In our team, we will write dev approach for the all defined user stories,
> > no matter they will be done in this sprint or next. But I'm not sure
> > this is the best practice, as this seems not so iteratively somehow.
>
> I would suggest having discussions opportunistically - as close as
> possible to the time when you actually do it. Writing it down is much
> less important than talking about it. Designing it too soon is almost
> certainly wasteful, because things will change. Designing it too late
> will lead to more refactoring/re-designing, as you implied. Designing
> it just in time (As you are about to implement it) works very well.
>
>
>
>
> __________________________________________________________
> Get personal with Windows. Download a free gift for your PC.
> http://experience.windows.com

Meet local singles online. Browse profiles for FREE!

Meet local singles online. Browse profiles for FREE!

Download a free gift for your PC. Get personal with Windows.

__._,_.___

To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.com

Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe

__,_._,___

 

I started working as an SM recently in a team that has tried to adopt Scrum for some time now with more than questionable results. They have mostly reverted back to the old ways of working and the situation seems quite difficult.

What are some of the suggested ways to make the team feel less hostile towards Scrum? How would you reintroduce Scrum to a team in a situation where mostly everyone thinks Scrum is useless? I'd like to hear similar stories and possibly even some suggestions.

I thought I would start first with the team's biggest pain points and reasons why they think agile and Scrum are not that useful. Then I should be able to pinpoint the root causes. Does this make sense at all?

 

The Scrum Alliance announced last year that Scrum creator Ken Schwaber resigned as President and Chair of the Board of Directors. This might be however not the end of the turmoil in the Agile world. Ken Schwaber was replaced October 5 by Mike Cohn, but there are now rumors that he might leave the Scrum Alliance to join the Waterfall Alliance. And this is not the only surprise that might happen soon: other unverified sources mentions that the Waterfall Alliance is also currently negotiating with Jeff Sutherland and Tom Gilb to join its board.

Read the full story here: http://www.devagile.com/modules/news/article.php?storyid=601

__._,_.___

To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.com

Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe

__,_._,___