Tag Info

New answers tagged

4

Architects, of course, but perhaps not the traditional kinds of architects. I don't mean the lead-surgeon kind of architect who does all the thinking and then leaves the monkeys to do all the typing. I mean an experienced leader programmer who understands the cost/benefit tradeoffs of difficult-to-reverse decisions and who advises teams on what to do. ...


3

I feel that the answer to ""who is responsible for making high-level architecture and design decisions?" depends on the size and number of teams. For one or two teams with 3-7 on each team then the self-organized team can do with lead from the senior members. For 3 or more teams the increased complexity leads to the need for an architecture team that can ...


4

The best architectures, requirements, and designs emerge from self-organizing teams -- Agile Manifesto So the team self-organizes to make architectural decisions in whatever way it sees fit. There's no hard and fast rule, it can range from consensus to a "council" of the most senior members, to designating one particular member as the ...


1

There are some great resources from the Scaled Agile Framework (SAFe) team on their site. It essentially helps you scale out agile across your organization, going above a single release and into portfolio and program planning. Their documentation shows suggestions on how to involve your Enterprise and System Architects in the process to introduce ...


7

"The software architecture is performed by the entire team. This practice does not remove the need for a software architect, it just means that the architect contributes to the discussion with a broader and probably more experienced perspective, nevertheless all members of the team contribute towards the architecture of the software." Source: ...


1

My suggestion is to promote Kanban as an alternative form of Agile development for your new company. Compare and contrast the productivity differences,not from a form of "we did it better", but "this process worked very well for us, woudl you like to try it too". You could find that the parent company is full of disaffected staff similarly annoyed with ...


1

I am very sympathetic to your case. But objectively, it looks like you were less accountable, more working for yourselves in isolation, before the switch. Maybe with small stitches comming loose on delivery. Maybe with mental overload of being constantly active. Now, on Scrum. Theoretically there is no restriction doing more. But I grasp, the different ...


0

If your development plan counted on a shipment that wasn't due for a month, you would be forced to add that time to you plan. Estimating learning curve time and accounting for it is as important as estimating and planning every feature.


0

I think you're thinking too hard. Let's say I come to you and say "please make me a shopping cart for a website". What are you going to to? Ignore all theory and buzzwords and dogma, what are you going to do when you sit down at a keyboard? Tasks are just a list of the things you need to do. Write tests get graphic for the "add to cart" button ...


0

In my opinion it depends on the weight of the user story. If the user story is about only adding the item to cart, first task should be getting the design for this approach. After that you have to break up the tasks according to the design (loggedin scenario, if not loggedin, so on).


1

Yes, user story says what you want to achieve, the tasks say how you go about making that happen. In this case, for example. The tasks could be 'add item to cart UI button', 'check stock levels', 'get user account', 'update temporary cart', 'update user account last-bought list' etc. Its possible some of those shoudl be part of a different user story, but ...


1

When we talk about a vertical slice of functionality, we're talking about the user story only. Tasks are broken down in to whatever the development team feels appropriate, to complete the story.


0

As most other answers i only use the Happy_path or "main success scenario" for the description of the User_story After that I add Scenarios that describe differences to Happy_path as alternatives and errors Example (a) payment with Creditcard (Successfull) alternatives: (b) same as (a) but Creditcard is from a foreign country errors that cancel the ...


3

The handling of errors should be spelled out in the acceptance criteria, not in the story. The user story is all about functionality delivered to the end user, and presumably you aren't delivering errors to the end user. I can see a case for making error handling part of the story for a product that is targeted toward other developers, where error codes and ...


1

The point of taking a story-based approach is to deliver customer value incrementally. Ideally, you'd use practices like pairing and TDD so that the code can evolve incrementally as well. That means that stories should be as minimal as possible, and therefore I'd break the error handling out into a separate story. It's hard to write the details of the ...


1

It Depends :) I don't know the context of this story, but on face value it sounds to me like the only task here is add-item-to-cart. In a typical browsing/shopping application, this would be an AddToCart button, with appropriate button-click logic, where the user/cart identity already exist. If user identity and a cart cannot be assumed, I suggest that you ...



Top 50 recent answers are included