Goals for Sprint #121

[maxandersen]

• Define Walking skeleton (Almighty Walking Skeleton #292) and Userstory map
• Architectural goals
  • Sign-off on High level component diagram
  • Outline domain model (system, team, user, project, work items, builds, etc.)
  • Build Service SPI
  • Planner Service, potential SPI for remote work items
• Core
  • Login
  • Support for work item linking
  • Activity/history for work items (missing UX)
• UI
  • Login
  • Realize UX for current list/edit work items
  • Basic linking UI (missing UX)
• Demo goals
  • Login in UI/Core
  • Show UX applied in UI
  • Paging
  • Linking in Ui/Core
  • Activity/history in core

[ALRubinger]

Architectural goals for this sprint:

1. Sign-off on High Level Component Diagram
2. Define Build Service, Domain Model, and SPI
3. Define Planner Service, potential SPI, and how the system interacts with external data providers.

[ALRubinger]

@aslakknutsen @michaelkleinhenz @maxandersen Let's review and discuss the above proposed architectural goals for priority order and feasibility of accomplishment in Sprint 121. I regard them higher than feature development, particularly 3) and 2), as they'll get us to velocity and parallel development.

[tsmaeder]

What is a "walking skeleton"?

[bartoszmajsak]

http://peterkeating.co.uk/walking-skeleton-for-web-applications/

Fits extremely well with ATDD. Hopefully will be applied in this project too :)

[maxandersen]

What is a "walking skeleton"?

a fancy name for having a working system that works end-to-end and put the meat on it over time.
We have more or less that today, what I want to see added in sprint is a bit more bones and from that get userstories map layed out for next 3-5 sprints.

[maxandersen]

Fits extremely well with ATDD

ATDD ?

[bartoszmajsak]

Acceptance Test Driven Development :)

[baijum]

What is "Support for work item linking"? Is this setting for the parent-child relationship between two work items? Something like Story -> Task ?

Or this is about dependency between 1 or more work items?

[ALRubinger]

I'm uncertain about the "work item" linking; as I understand it, work item types are supplied by various services (Planner, Build, Code, etc); in that case something higher-level would need to know about both types involved in the relationship (which is also a typed relationship -- a commit "contains" a fix for an issue, eg). @aslakknutsen How do we want to proceed with working through this conversation, assuming it's in the same state we left off before J1?

[tsmaeder]

What is "J1"?

[ALRubinger]

@tsmaeder Cool-kid-talk for "JavaOne", last week's conference.

[maxandersen]

I'm uncertain about the "work item" linking; as I understand it, work item types are supplied by various services (Planner, Build, Code, etc);

Work items are core in the model of almighty - they have links between each other. They are stored in almighty db, not in the external systems.

[maxandersen]

What is "Support for work item linking"? Is this setting for the parent-child relationship between two work items? Something like Story -> Task ?

Or this is about dependency between 1 or more work items?

Both - but which we would do is something to clarify.
But I would expect the mechanism for wether doing parent/child or associations is the same.

[ALRubinger]

Work items are core in the model of almighty - they have links between each other. They are stored in almighty db, not in the external systems.

@maxandersen I said "work item types". :) And the links between them are also typed. Yes, they're stored in the Almighty DB, but we may have requirements that say a new service is able to define the types, not the Almighty core. And that's something we need to fully reconcile (w/ @aslakknutsen) before moving forward here. Let's be very careful to not say what things are until we go through the proper design; this underpins the entire system and must be done right early on.

[ldimaggi]

We should specify what we mean by "login" - this is login with credentials provided by github - yes?

[michaelvirgil]

@tsmaeder A little more detail and explanation... one thing to note is that the Walking Skeleton is commonly used by Agile teams for framing and vetting the Architectural Approach with Working Code.

Start with a high-level sketch of the architecture, identify the high risks, and high value paths to be vetted. Verify the architectural decisions through working and potentially shippable code. The idea is to take a simplified user goal each Sprint - build a story map that makes up the Walking Skeleton - the "BackBone". Teams select a set of stories that will meet one or more user goals to slice through the system and build out the architecture in PSI's while adding user value - should just focus on the most important - skeleton backbone - pieces needed.

Initially, it is the simplest versions of the stories needed to complete the steps required to meet that goal - creating the skeleton. Bare bones, nothing more…. then it becomes easier to add mussel, flesh etc... across the skeleton... minimum end-2-end for a user goal may not need all the high-level areas to meet the simplest solution for the Sprint/Release goal.

• Build an End-to-End Skeleton, or Steel Frame
• System Which Addresses the Major Technological Risks
• Link Together the Main Architectural Components
• Demo Every 2-4 Weeks

Overtime, a release plan - release plan is a short period of time - a user can go end-2-end with the main success scenario in its simplest form...

Note: A Walking Skeleton, is Permanent Code, Built with Production Coding Habits, Tested, and is Intended to Grow with the System.

Intentional, but emergent Architecture - need a sketch of the intended architecture, a plan and way to vet it while adding value - simple is better during this phase.

Sorry, a little longer explanation then I expected...