Technical Dept Meeting

Today we had a meeting to identify and prioritize issues that keeps us from working at optimal efficiency.
We came up with the following:

Scrum process related issues:

1. We need well defined user stories and scenarios for a couple of reasons:
   1. To speed up the poker planning phase we have on the start of each sprint
   2. For communication to users, stakeholder and the developers
   3. To get more insight on the related tasks
2. We need well defined tasks for the developers in JIRA. These tasks should have good descriptions, screen mock-ups when available and when it involves error issues then we also need the steps to reproduce the error.

Actions:

The scrum master and the product owner should be responsible to define the user stories. Optionally they should be reviewed by a domain expert (or functional tester) or an important stakeholder. The user stories should be prepared before the sprint starts!

The scrum master should be responsible to define the tasks and their user story relations in JIRA. It's his task to prepare them at least at the start of the sprint.

Requirements:

• User stories should be available on wiki under sprint page
• Tasks must be defined in JIRA
• Tasks need a reference to the wiki user story
• User stories should have references to the JIRA issues
• User stories and tasks should have good descriptions and preferably examples and applications
• Optionally user stories should have use case scenario's ie. Steps to take to reach your goal

General development issues:

1. We need a well defined "definition of done" document which every developer must use as a check list to improve code quality.

The "definition of done"- document should contain rules like:

1. Every interface we define must be properly commented
2. Don't use singletons (if you can) (should we use inversion of control here?)
3. A developer should use encapsulation whenever possible.
4. A developer should always try to make methods, property getters or setters private to increase the undependability
5. Don't use the "auto magical" properties and explicit actions
6. No memory leaks! Learn how they get there and how to avoid them

Other candidates I found:

"In object-oriented languages, things that will change quickly are cast as black-box polymorphic components. Elements that will change less often may employ white-box inheritance. The abstract classes and components that constitute an object-oriented framework change more slowly than the applications that are built from them" - Big Ball Of Mud

"Lowering quality lengthens development time.

Quality software takes the least amount of time to develop. If you have code that is simple as possible, tests that are complete and a design that fits just right, additions and changes happen in the fastest possible way because the impact is lowest. Consequently, if you hack something out, the more you hack the slower you go because the cost of addition or change grows with each line of code." – First law of programming

Actions:

As a team we need to define code design rules for ReSharper or StyleCode.
We should use these tools to automate the task of checking code design rule violations.

Other actions...?

DeltaShell framework issues:

1. We need an overview or visual map of the high level architecture and the framework(s) and their dependencies being used. This can help developers to see the bigger picture and to quickly identify the context we work in.
2. We need to split up the solution in smaller parts so that they can grow and evolve independently. This means grouping or even merge sub projects.
   1. This encourages a better loosely coupled architecture
   2. Smaller parts should result in quicker builds
3. It's not always clear what a unit test data access or integration test is. Furthermore some tests are slow and some result in "out-of-memory" exceptions.
4. We should simplify existing complex dependent classes when possible. Candidates are:
   1. FunctionBindingList
   2. GuiCommandHandler
   3. (Project)TreeView and their node presenters
   4. ModelBase
   5. Function model API
       

Actions:
Genna will make a high level architecture visual map.

Marc and Barry will start with a reorganization of the test fixtures. Main goal is to speed things up.

FunctionBindingList, GuiCommandHandler and the project tree view will be on the list for improvements in this and (if necessary) the next sprints. This should be done after a design session with team members.

Genna and Martijn will look on how to simplify the function object model.

 Enter labels to add to this page:

 
Looking for a label? Just start typing.