[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] SOA-RM Jan 3: delayed but something to think about
I worked in big companies and Programme/Enterprise level tasks/solutions required, with no doubts, collecting and understanding requirements (at certain level) up-front. Moreover, solutions usually had been accompanied by estimate of cost and resources. At this level DevOps are practically invisible. The work on estimate needs to set a Tolerance Level (TL) - a level of probability that the estimate is incorrect. For example, if TL=25%, the estimate and, therefore, solutions, the requirements, should be very accurate, which takes much longer time to collect and process up-front, even before the project starts. If TL=75%, the estimate may be low the real cost significantly, but this estimate takes much sorter time while giving a certain understanding to architects and managers about potential cost and resources.
In hierarchical organisations, nobody has a replacement for the activities described above. It is a regular practice that proper understanding and solutioning of requirements needs a few interactions and revisions caused by internal interdependencies that are usually hidden in the articulation of business statements. Sometimes (frequently), the final solutions appears as a "third cousin" to the initial one.
The main conclusion from this observation is that before we write the first epic and the first story we have to be aware/know about the last ones though not written yet. Plus, we have to have ideas (experience?) about all stories because otherwise our schedule of Sprints, their topics and duration will be way too wrong.
The second conclusion is that Agile “by the book” can work for relatively small isolated projects/tasks, which we can find in the User Interfaces rather than in a middle- or back-layers of systems. In the small isolated projects/tasks, we can rely on the competence of developers and their ability to understand the task and realise it. However, the GDPR and PSD2 regulations (that were ignored initially by developers as usually), now require a close architectural/managerial control over small tasks as well.
Thus, Agile has not brought any fundamental change in the Enterprise or Programme level development; the changes are at the small project level only. This reflects in Testing as well – if you have a more than one Agile team working on the business task, your have not only coordinate and development between teams, answer their questions about cross-cutting issues, but also provide for the integration testing across the teams. The more teams, the more testing after the team have completed their tasks. DevOps in such case automate deployment in the Testing Environment instead of Production one.
An idea of Continuous Documentation is realised already via Jira/Confluence tool-set. It is filled during each Sprint and by the end of the work, fully represents the process and results of the Agile development. An idea of continuous requirements are realised also via layered abstraction of requirements – coarse-grained first, fine-grained later.
About refactoring – this is good idea, but again, for small isolated projects. If the project includes 5 -7 Sprints, each with its own Story, at the 4th Sprint it is usually necessary to re-factor the outcome of the 1st Sprint. The more Sprints to go, the more refactoring, which is not really planned up-front, is accumulated and, finally, killed the later Sprints. Talking about Microservices, the Testing Environment for them must include all engaged MS along the all invocation line. While external MS are used, the full attention should be on ‘rainy days’ scenario for the external MS. Also, testing of the MS invocation must include full implementations of the MS, not only their interfaces – this is my lesson of 20 years of working with Services.
- Michael
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]