[FLOW3-general] [TYPO3-mvc] [RFC] Keeping FLOW3 Compatibility

Daniel Felix d.felix at codeworkz.net
Mon Feb 13 07:25:16 CET 2012


Hello,

I'm not part of any TYPO3 project at all, but I've got a suggestion how we solve such problems. 

We have some UI Developer and a Database Backend-Team. At some Points this Teams overlap which could get to confusions. To clear such problems as double development, misleading development or crashes we make some other kind of Meetings. 
Our UI - Team consists out of 45 People, the DB-Team out of 70 People. 
The UI Team always tends to make SCRUM Meetings, which are not useful for our DB - Team. The DB - Team makes just quick Kickoffs of a new Project starts and make weekly meetings. 
To stop miss development we merge our meeting. We send one or two of the DB Team to the Meetings of the UI-Team, because often some little changes from the UI Team weren't fully protocoled because they are just small and no important for the UI, but distort the DB, which no one knows from the UI Team. To prevent this, those people who go to the scrum-Meetings from the DB team invoke if something will distort the DB or deliver alternatives. On the other side, the UI team comes to the DB meetings. This way we have some kind of ambassadors which care about the processes which affect the other side and we have a better communication. 

We improved our In-house development this way and my project management gets just easier! We nearly have no distortion in our development. 

We first tried the same way with protocols but, as already said, some little changes weren't protocoled and everything went wrong. 

Well, this is just a hint from the outside, but maybe it's helpful for you too. 

Best regards,
Daniel

P.s: sorry for some bad sentences, I'm writing from my iPhone just on the fly...

Am 13.02.2012 um 06:41 schrieb Sebastian Kurfürst <sebastian at typo3.org>:

> Hey Felix,
> 
> thanks again for voicing your concerns here!
> 
> While I like very much that we are doing an open discussion now, I have
> the feeling that you are quite frustrated about the whole collaboration,
> criticizing the way it works currently (where you certainly raised some
> valid points!). However, I'd even more like to see more constructive
> ideas on how we can *improve* collaboration in the future.
> 
> IMHO it does not help if we criticize things and do not provide
> alternative solutions.
> 
> The point I'm trying to raise is also not about you personally, but I've
> seen it quite often in the TYPO3 Community so far: People often
> criticize, but rarely offer some alternatives for the future after their
> critique. I've also done that some times in the past, but I'm trying to
> change that ;)
> 
> So, I'd like to propose one rule for productive mailing-list discussions:
> 
>    *If you criticize some thing, try to propose an alternative solution
> for the future*.
> 
> This way, discussions should have the general tone "how can we improve
> in the future" instead of "what all went wrong in the past".
> 
>> Even on the Code-Sprint Berlin 2011 (meant to be "Transition Days 2")
>> nothing even remotely happend in this direction. The v5 team was busy
>> working on the T3CON website all by theirself.
> It's a matter of time. The FLOW3 / Phoenix team in itself has very many
> deadlines and ambitious goals and we are only very few active people.
> It's certainly not bad-will.
> 
>> One hand washes the other. We have a lot of work to do ourselves, so I
>> don't think it's asked too much, to split work on the hole "in
>> sync"-thing more equally.
> I  fully agree. See my other email on some ideas how we might be able to
> solve it :)
> 
> Greets,
> Sebastian
> 
> _______________________________________________
> FLOW3-general mailing list
> FLOW3-general at lists.typo3.org
> http://lists.typo3.org/cgi-bin/mailman/listinfo/flow3-general


More information about the FLOW3-general mailing list