Skip to main content

Home/ Agilesparks/ Group items tagged Design

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
Yuval Yeret

James Shore: The Art of Agile Development: Incremental Design and Architecture - 1 views

www.jamesshore.com/...incremental_design.html

eng-practices-list james shore evolutionary design agilearchitecture

shared by Yuval Yeret on 10 Dec 14 - No Cached
  • when you first create a design element—whether it's a new method, a new class, or a new architecture—be completely specific. Create a simple design that solves only the problem you face at the moment, no matter how easy it may seem to solve more general problems
  • Waiting to create abstractions will enable you to create designs that are simple and powerful.
  • The second time you work with a design element, modify the design to make it more general—but only general enough to solve the two problems it needs to solve. Next, review the design and make improvements. Simplify and clarify the code. The third time you work with a design element, generalize it further—but again, just enough to solve the three problems at hand. A small tweak to the design is usually enough. It will be pretty general at this point. Again, review the design, simplify, and clarify. Continue this pattern. By the fourth or fifth time you work with a design element—be it a method, a class, or something bigger—you'll typically find that its abstraction is perfect for your needs. Best of all, because you allowed practical needs to drive your design, it will be simple yet powerful.
  • ...12 more annotations...
  • This is difficult! Experienced programmers think in abstractions. In fact, the ability to think in abstractions is often a sign of a good programmer. Coding for one specific scenario will seem strange, even unprofessional.
  • Continuous Design Incremental design initially creates every design element—method, class, namespace, or even architecture—to solve a specific problem. Additional customer requests guide the incremental evolution of the design. This requires continuous attention to the design, albeit at different time-scales. Methods evolve in minutes; architectures evolve over months. No matter what level of design you're looking at, the design tends to improve in bursts. Typically, you'll implement code into the existing design for several cycles, making minor changes as you go. Then something will give you an idea for a new design approach, requiring a series of refactorings to support it. [Evans] calls this a breakthrough (see Figure). Breakthroughs happen at all levels of the design, from methods to architectures.
  • Don't let design discussions turn into long, drawn-out disagreements. Follow the ten-minute rule: if you disagree on a design direction for ten minutes, try one and see how it works in practice. If you have a particularly strong disagreement, split up and try both as spike solutions. Nothing clarifies a design issue like working code.
  • Risk-Driven Architecture Architecture may seem too essential not to design up front. Some problems do seem too expensive to solve incrementally, but I've found that nearly everything is easy to change if you eliminate duplication and embrace simplicity. Common thought is that distributed processing, persistence, internationalization, security, and transaction structure are so complex that you must consider them from the start of your project. I disagree; I've dealt with all of them incrementally [Shore 2004a]. Two issues that remain difficult to change are choice of programming language and platform. I wouldn't want to make those decisions incrementally!
    • Yuval Yeret
      Yuval Yeret on 12 Jan 15
       
      Possible exercise - Try to come up with various things that are risky to YAGNI. And then order them according to level of risk. Use the examples here to seed the list
  • Limit your efforts to improving your existing design
  • To apply risk-driven architecture, consider what it is about your design that concerns you and eliminate duplication around those concepts
  • Your power lies in your ability to chooose which refactorings to work on. Although it would be inappropriate to implement features your customers haven't asked for, you can direct your refactoring efforts towards reducing risk. Anything that improves the current design is okay—so choose improvements that also reduce future risk.
  • design is so important in XP that we do it all the time
  • Don't try to use incremental design without a commitment to continuous daily improvement (in XP terms, merciless refactoring.) This requires self-discipline and a strong desire for high-quality code from at least one team member. Because nobody can do that all the time, pair programming, collective code ownership, energized work, and slack are important support mechanisms.
  • Test-driven development is also important for incremental design. Its explicit refactoring step, repeated every few minutes, gives pairs continual opportunities to stop and make design improvements. Pair programming helps in this area, too, by making sure that half of the team's programmers—as navigators—always have an opportunity to consider design improvements.
  • Alternatives If you are uncomfortable with XP's approach to incremental design, you can hedge your bets by combining it with up-front design. Start with an up-front design stage and then commit completely to XP-style incremental design. Although it will delay the start of your first iteration (and may require some up-front requirements work, too), this approach has the advantage of providing a safety net without incurring too much risk.
Yuval Yeret

James Shore: The Art of Agile Development: Simple Design - 0 views

www.jamesshore.com/...simple_design.html

james shore art development

shared by Yuval Yeret on 13 Jan 15 - No Cached
  • Simple Design AudienceProgrammers Our design is easy to modify and maintain
  • Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. —Antoine de Saint-Exupéry Any intelligent fool can make things bigger, more complex and more violent. It takes a touch of genius and a lot of courage to move in the opposite direction. —Albert Einstein
  • When writing code, agile developers often stop to ask themselves, "What is the simplest thing that could possibly work?" They seem to be obssessed with simplicity. Rather than anticipating changes and providing extensibility hooks and plug-in points, they create a simple design that anticipates as little as possible, as cleanly as possible. Unintuitively, this results in designs that are ready for any change, anticipated or not.
  • ...10 more annotations...
  • I don't think XP and patterns are conflicting. It's how you use patterns. The XP guys have patterns in their toolbox, it's just that they refactor to the patterns once they need the flexibility
  • You Aren't Gonna Need It (YAGNI) This pithy XP saying sums up an important aspect of simple design: avoid speculative coding. Whenever you're tempted to add something to your design, ask yourself if it supports the stories and features you're currently delivering. If not, well... you aren't gonna need it. Your design could change. Your customers' minds could change.
  • We do this because excess code makes change difficult. Speculative design, added to make specific changes easy, often turns out to be wrong in some way, which actually makes changes more difficult. It's usually easier to add to a design than to fix a design that's wrong. The incorrect design has code that depends on it, sometimes locking bad decisions in place.
  • Once and Only Once
  • avoid duplication. "Once and only once" is the Extreme Programming phrase. The authors of The Pragmatic Programmer [Hunt & Thomas] use "don't repeat yourself," or the DRY principle.
  • Self-Documenting Code Simplicity is in the eye of the beholder. It doesn't matter much if you think the design is simple; if the rest of your team or future maintainers of your software find it too complicated, then it is.
  • What if we know we're going to need a feature? Shouldn't we put in a design hook for it? In XP, the plan can change every week. Unless you're implementing the feature that very week, don't put the hook in. The plan could change, leaving you stuck with unneeded code.
  • Results When you create simple designs, you avoid adding support for any features other than the ones you're working on in the current iteration. You finish work more quickly as a result. When you use simple design well, your design supports arbitrary changes easily. Although new features might require a lot of new code, changes to existing code are localized and straightforward.
  • Simple design requires continuous improvement through refactoring and incremental design and architecture. Without it, your design will fail to evolve with your requirements. Don't use simple design as an excuse for poor design. Simplicity requires careful thought. As the Einstein quote at the beginning of this section says, it's a lot easier to create complex designs than simple ones. Don't pretend "simple" means "fastest" or "easiest.
  • Until recently, the accepted best practice in design followed the advice Erich Gamma now disavows: "The key to maximizing reuse lies in anticipating new requirements and changes to existing requirements, and in designing your systems so they can evolve accordingly."
Yuval Yeret

Is Design Dead? - 0 views

www.martinfowler.com/...designDead.html

eng-practices-list

shared by Yuval Yeret on 10 Dec 14 - Cached
  • In its common usage, evolutionary design is a disaster. The design ends up being the aggregation of a bunch of ad-hoc tactical decisions, each of which makes the code harder to alter. In many ways you might argue this is no design, certainly it usually leads to a poor design. As Kent puts it, design is there to enable you to keep changing the software easily in the long term. As design deteriorates, so does your ability to make changes effectively. You have the state of software entropy, over time the design gets worse and worse. Not only does this make the software harder to change, it also makes bugs both easier to breed and harder to find and safely kill. This is the "code and fix" nightmare, where the bugs become exponentially more expensive to fix as the project goes on
  • the planned design approach has been around since the 70s, and lots of people have used it. It is better in many ways than code and fix evolutionary design. But it has some faults. The first fault is that it's impossible to think through all the issues that you need to deal with when you are programming. So it's inevitable that when programming you will find things that question the design. However if the designers are done, moved onto another project, what happens? The programmers start coding around the design and entropy sets in. Even if the designer isn't gone, it takes time to sort out the design issues, change the drawings, and then alter the code. There's usually a quicker fix and time pressure. Hence entropy (again).
  • One way to deal with changing requirements is to build flexibility into the design so that you can easily change it as the requirements change. However this requires insight into what kind of changes you expect. A design can be planned to deal with areas of volatility, but while that will help for foreseen requirements changes, it won't help (and can hurt) for unforeseen changes. So you have to understand the requirements well enough to separate the volatile areas, and my observation is that this is very hard. Now some of these requirements problems are due to not understanding requirements clearly enough. So a lot of people focus on requirements engineering processes to get better requirements in the hope that this will prevent the need to change the design later on. But even this direction is one that may not lead to a cure. Many unforeseen requirements changes occur due to changes in the business. Those can't be prevented, however careful your requirements engineering process.
  • ...6 more annotations...
  • The fundamental assumption underlying XP is that it is possible to flatten the change curve enough to make evolutionary design work. This flattening is both enabled by XP and exploited by XP. This is part of the coupling of the XP practices: specifically you can't do those parts of XP that exploit the flattened curve without doing those things that enable the flattening. This is a common source of the controversy over XP. Many people criticize the exploitation without understanding the enabling. Often the criticisms stem from critics' own experience where they didn't do the enabling practices that allow the exploiting practices to work. As a result they got burned and when they see XP they remember the fire.
  • XP's advice is that you not build flexible components and frameworks for the first case that needs that functionality. Let these structures grow as they are needed. If I want a Money class today that handles addition but not multiplication then I build only addition into the Money class. Even if I'm sure I'll need multiplication in the next iteration, and understand how to do it easily, and think it'll be really quick to do, I'll still leave it till that next iteration.
  • You don't want to spend effort adding new capability that won't be needed until a future iteration. And even if the cost is zero, you still don't want to add it because it increases the cost of modification even if it costs nothing to put in. However you can only sensibly behave this way when you are using XP, or a similar technique that lowers the cost of change.
  • My advice to XPers using patterns would be Invest time in learning about patterns Concentrate on when to apply the pattern (not too early) Concentrate on how to implement the pattern in its simplest form first, then add complexity later. If you put a pattern in, and later realize that it isn't pulling its weight - don't be afraid to take it out again.
  • begin by assessing what the likely architecture is. If you see a large amount of data with multiple users, go ahead and use a database from day 1. If you see complex business logic, put in a domain model. However in deference to the gods of YAGNI, when in doubt err on the side of simplicity. Also be ready to simplify your architecture as soon as you see that part of the architecture isn't adding anything.
  • XP design looks for the following skills A constant desire to keep code as clear and simple as possible Refactoring skills so you can confidently make improvements whenever you see the need. A good knowledge of patterns: not just the solutions but also appreciating when to use them and how to evolve into them. Designing with an eye to future changes, knowing that decisions taken now will have to be changed in the future. Knowing how to communicate the design to the people who need to understand it, using code, diagrams and above all: conversation.
Yuval Yeret

Alistair.Cockburn.us | Are iterations hazardous to your project? - 0 views

alistair.cockburn.us/s+hazardous+to+your+project%3f

shared by Yuval Yeret on 20 Jun 09 - Cached
  • Simply using iterations, user stories and velocity doesn’t mean your project is agile – or on the way to success.
  • why “iterations” may be hazardous to your project: ‘’Danger grows when the results of the iteration are not directly linked to delivering the product to the end user.’’ Without that linkage, iteration results hang in the air
  • What gets in the way is that the project is set up as a pipeline, with programming put somewhere in the middle of the pipeline. In this project setup, there is really nothing the programmers can do to show how their work connects to deliveries, because there are work stations before and after theirs. All they can report is that “some new code is integrated into the code base.” They are doing incremental development but not agile development.
  • ...6 more annotations...
  • magine a project team of between fifteen and four hundred people. There are user representatives, analysts, programmers, database designers, and testers, arranged in a pipeline. The user analysts talk to the users, and then to the analysts, who write down user stories. The analysts write lots of notes on each user story, since it will be a full iteration or two before any programmer will pick up the user story. The notes are between one and ten pages long. Eventually, a programmer picks up a user story along with the supplemental details, code them up in an iteration, integrate them into the growing code base, and mark their velocity. In the same or a later iteration the database designers do the same. Eventually the integration test team comes along, runs tests on the whole thing, and feeds bug reports back into the programmers’ work queues. The users or project sponsors may see the outcome every few months if they are lucky.
  • Collocate the requirements gatherer, the database designer, the programmer, the tester. Lengthen the iteration period to one month. Give the requirements gatherer a week’s head start on the features coming up, but otherwise arrange that all of them are working on the same feature set in the same month.
  • Break the pipeline, lengthen the iterations, lose the machismo, deliver the project.
  • here is no mechanism in the standard agile language that warns about this loss of touch. The currently standard language consists of ‘’iterations, user stories, ‘’and’’ velocity’’. By a perverse relationship between them, it is possible to equally shrink iteration length and story size, with velocity scaling accordingly. Thus, a team can feel as though it is become more agile, when in reality it is simply becoming more cut off from its user base and the feedback it needs to succeed.
  • The repair is simple: connect every activity to a release or delivery to real users (delivering to even one real user makes a difference). Evaluate the team’s work based on how often they deliver to real users and how long it takes a new requirement to reach the users. Replace the fuss around iterations with fuss around deliveries.
  • As an afterthought, if your new iteration length is a month, you can still run one-week planning windows to make sure you don’t get off track during the month.
Yuval Yeret

James Shore: The Art of Agile Development: Spike Solutions - 0 views

www.jamesshore.com/...spike_solutions.html

james shore spike eng-practices-list

shared by Yuval Yeret on 13 Jan 15 - No Cached
  • About Spikes A spike solution, or spike, is a technical investigation. It's a small experiment to research the answer to a problem. For example, a programmer might not know whether Java throws an exception on arithmetic overflow. A quick ten-minute spike will answer the question.
  • Performing the Experiment The best way to implement a spike is usually to create a small program or test that demonstrates the feature in question. You can read as many books and tutorials as you like, but it's my experience that nothing helps me understand a problem more than writing working code. It's important to work from a practical point of view, not just a theoretical one.
  • Writing code, however, often takes longer than reading a tutorial. Reduce that time by writing small, standalone programs.
  • ...2 more annotations...
  • Design Spikes Sometimes you'll need to test some approach to your production code. Perhaps you want to see how a design possibility will work in practice, or you need to see how a persistence framework will work on your production code. In this case, go ahead and work on production code. Be sure to check in your latest changes before you start the spike and be careful not to check any of your spike code.
  • If you anticipate the need for a spike when estimating a story, include the time in your story estimate. Sometimes, you won't be able to estimate a story at all until you've done your research; in this case, create a spike story and estimate that instead
Yuval Yeret

מועדים - 0 views

www.selayouniversity.co.il/...Dates.asp

development training embedded-agile-list

shared by Yuval Yeret on 08 Jul 14 - Cached
  • Design of Distrib. & Multi-Core Systems & SoftwareDuration: 2d; Start dates:21/02/2007; 04/
  • Embedded Linux BasicsDuration: 3d; Start dates:19/03/2007; 20/05/2007;
Yuval Yeret

tips on reviving retrospectives from the retrospectives yahoo group - 0 views

finance.groups.yahoo.com/...1575

agile retrospectives agilesparksblog

shared by Yuval Yeret on 08 Jul 09 - No Cached
  • Has the team made changes that make a difference to them as a result of the retrospective?
  • Has the team explored a variety of different topics/areas, or do they stick to pretty much the same agenda around continuous improvement? What is the balance of change/improvement work vs. working on the product?
  • For example, try looking at technical practices, teamwork, or customer relationships... choose what ever seems most relevant to bound the discussion. That might help the team dig deeper and find issues that have more significance for them (now...I'm sure the other changes were significant at the time).
  • ...14 more annotations...
  • Try a 'speed retrospective'. How quickly can the team get together and find one good, solid improvement to make? Make it exciting and use a stopwatch. I wouldn't do this all the time, but again, what harm to try it once?
  • How about one retrospective where you set yourselves the challenge of generating actions from the "What did we do well" column? In other words, find an action designed to magnify an existing positive rather than remedy an existing negative.
  • How about a 'Show and Tell' retrospective where every team member comes to the meeting with an action item and its explanation already prepared? The retrospective would really be each person presenting their idea in turn.
  • How about a retrospective wherein you challenge yourselves to come with a new approach to retrospectives that is so exciting that people would skip other work activities to attend?
  • I find it very important to revisit the outcome of the past retrospective and celebrate the things the team had been able to do differently.
  • The major thing is to make the changes visible and memorizable for everyone and not assuming that people remember what they decided on in the last retro.
  • Another thing is that I would invite team members to take turns in facilitating the retro. So not always the same person runs the retro (this typically also changes the format and techniques a bit).
  • - Heartbeat Retrospective (google for Boris Gloger)
  • - Temperature Reading
  • - Team Radar Chart
  • - Our project / team / product ship - draw a ship on a flip chart, ask the team what moved the ship forward, what blocked it
  • Just to add a totally different direction: I've made good experiences with having a *long* retrospective every few months. The short retrospectives are great to see the trees and optimize the daily work. A two or even three day retrospective helps the team to step back and watch the forrest instead.
  • It is important to get at least one item done every sprint. If you do the retro, but don't implement any of the actions, this is a tremendous demotivator. Better one thing finished that you can celebrate than 5 unfinished things in the queue.
  • Variety is the spice of life, so some variation is essential to keep the freshnees. Change the moderator, do technical focus once, then organisational, then "improving the fun factor", then go back to a general retro.
Yuval Yeret

Kanban development oversimplified: a simple explanation of how Kanban adds to the ever-... - 0 views

agileproductdesign.com/...kanban_over_simplified.html

lean kanban

shared by Yuval Yeret on 03 Jun 09 - Cached
  • It’s a lot easier to estimate a story that’s small — which can lead to more accurate estimates, and better predictability.
  • It’s easier to plan with smaller stories. With big stories — stories that might take weeks for a developer to implement — it becomes difficult to plan a development time-box — particularly when the iterations are only a couple of weeks. It seems that only a couple stories fit — and there’s often room for half a story — but how do you build half a story? Splitting them into smaller stories makes it easier to plan those time-boxes.
  • Shrinking stories forces earlier elaboration and decision-making. Where product owners could write their stories fairly generally and consider many of the details later, now breaking them down into smaller stories forces more thinking earlier in a planning lifecycle.
  • ...36 more annotations...
  • Managing little stories forces us to keep better track of how they fit together. Product owners are often asked to break down stories to a level where a single story becomes meaningless. To keep track of what’s meaningful to them and other stakeholders, they often need to keep track of bigger items such as the features of the product and how many stories contribute to building up that feature.
  • The result of these herniated time-box activities is a cycle that’s actually 3-4 times longer than our time-box. To get work done, we’ll use a time-box to elaborate stories, one to develop them, another to more thoroughly test them, and if there are bugs, possibly another to fix them.
  • During an ideal Agile time-box we’ll have frequent discussions between developers, testers, and those on a product owner team — like business analysts, user experience people, and business people. We’ll do this to understand what we need to build and describe what we’ll do to validate the story was really done. When time-boxes are short, there’s less time for this conversation. It’s common to move many of the conversations to detail the story and describe acceptance to the time-box before so we can be ready to really get moving with development when the time-box starts.
  • It’s difficult to fit thorough validation of the story into a short time-box as well. So, often testing slips into the time-box after. Which leaves the nasty problem of what to do with bugs� which often get piped into a subsequent time-box.
  • Anyone who’s attended an Agile planning meeting knows they can often last about an hour longer than you can stand it
  • As time-boxes shrink those on the product owner team and testers find themselves in a constant mode of getting ready for a next time-box and evaluating past time-boxes
  • work long hours, attend lots of meetings, and seem to have less time to be available to help developers with the current time-box. Since their focus is on a future or past time-box, questions about this time-box seem like interruptions. Collaboration decreases and tensions increase. Their work load is heavy, bumpy, not smooth or even.
  • Kanban cards are used to limit the amount of inventory the factory builds. It doesn’t do the Toyota factory any good to build doors faster then they can assemble cars. It just wastes money on excess doors, and parts of doors. Excess work in progress is considered to be waste in Lean manufacturing. (It’s probably waste in non-Lean manufacturing too.) In the above completely made up example, you’ll never have more than 15 finished doors hanging around. (Mudha is Japanese for waste. Learn it to impress your Lean friends.)
  • “Kan” means visual, and “ban” means card or board.
  • Kanban thinking in software development attempts to do a similar thing. We want to limit unnecessary work in progress to be no higher than it needs to be to match the throughput of the team.
  • In Kanban development: time-boxed development is out stories are larger and fewer estimation is optional or out completely velocity is replaced by cycle time
  • Exactly what’s left of Agile if we get rid of time-boxes, change the meaning of stories, and stop measuring velocity. And, exactly what do car doors and Kanban cards have to do with software development? Don’t get hung up on process. Remember, agile development isn’t a process.
  • You might have a column where business analysts spend time tracking down technical details that developers need to understand to write code.
  • These columns aren’t set. You should discuss with your team the phases that stories go through to be completed. Some organization may use columns for writing documentation, or preparing customer service people to support the feature in production.
  • The top is used for stories currently in progress in that phase. The bottom is the buffer. When work for that phase of the story is completed, it moves from “in progress” to the “buffer” where it’ll wait to be pulled into the next phase.
  • When we set limits for work in progress, we’ll set a total number for the process step that includes both “in process” and the “finished buffer” for that process step.
  • Stories must be minimal marketable features
  • To be marketable the feature needs to be large enough to be useful — probably larger than the teeny stories that take a couple days to build and seem to be best practice in Agile development today. A MMF may take weeks to build. But the important thing isn’t how long it takes to build, but that it be understandable and valuable to those who’ll receive it. To identify a MMF some folks ask the question “Would I announce it in my company’s product blog?” If it’s too tiny to mention, then it’s not a MMF.
  • To be lean, we’ll limit the number of stories we allow onto the board. A common formula is to add up all the members of the team in all roles and divide by two. All roles includes developers, analysts, user interfaced designers, testers, deployment people — anyone immediately responsible for getting features to market. For example, if team members total 20, we might limit the number of MMF-style stories on the board to 10.
  • Today developers have finished a story, and s they walk to the Kanban board to move it out of development, they notice their single buffer slot is full — and the “testing in progress” column is filled to its limit. What now? The developers talk to the testers. “We’re really struggling to keep up here. It’ll be till tomorrow morning before we can get some of these stories moved out.” “Hmm�” says a developer “Can we help test?” “Of course you can!” says the tester. “With your help we can get these cleared out by the end of the day.“ The tester grins “I just don’t want you validating a story you implemented.”
  • For the limits of the story process steps, the limit is often half the number of people that can perform the work for that phase of development. For instance if you have 6 developers, you might limit the development in progress column to 3. Now, this will force developers to work together on stories. I do find in practice that this may not work out for all teams — so I often see limits that equal the number of developers (or those that can perform the process step) or often 1.5 * the number of people in a role. Of course if you do this, it’ll raise the overall work in progress — and as you might expect, items will take longer to finish.
  • When a column in a Kanban board is full, we know that group is at capacity. We also know that if this keeps happening that that process step is likely where a bottleneck is.
  • If you’ve ever waited in line for the Pirates of the Caribbean in Disneyland you might remember signs along the way that say “Your wait time from here is 30 minutes” — something like that. Now you can post your own wait times on your Kanban board. At the bottom of your story queue post the average cycle time with wait time. It’ll say something like “Your wait time for a story here is approximately 18 days.” At the top of the queue post the average working cycle time. It might say “your wait time from here is 14 days.”
  • When you place focus on how quickly you can get functionality done, and have the ability to measure just that, then the estimates don’t much matter. In fact, many using a Kanban approach have simply stopped estimating at all. Yes story sizes vary, but being able to give a wait time plus or minus a few days is sufficient for many organizations’ concerns.
  • But, since there’s no development time-box in Kanban development, we’ll measure story-by-story how long they took to complete — the “cycle time” of the story.
  • Some do still estimate stories. Then use those estimates in conjunction with cycle time. Using a spreadsheet we can calculate the average cycle time for stories with a given estimate. If you do this, consider placing a handy chart next to your Kanban board showing estimate in one column, and wait times in adjacent columns. With this you’re answering the real question stakeholders are asking for when they get estimates: “when am I going to see this functionality in the software?”
  • If your stakeholders are like mine, they don’t want to know when they’re going to get this functionality, the want to know when they’re going to get all this functionality. I find that if I place stories into a spreadsheet with start and end dates, and calculate cycle time, if I select an arbitrary time period — say a two or three week time period — I can see how many stories where completed during this time period. For instance I might see the team finished 22 stories in 3 weeks — that’s about 7.3 stories per week. Given a backlog of 100 stories I can reasonably infer that it’ll take between 13 and 14 weeks (100/7.3). That’s yesterday’s weather for Kanban — at least the way I calculate it.
  • If I know that during three week time period there where 15 working days and that 5 developers worked the entire time, that’s 75 developer days. Knowing that lets me calculate the average number of developer days per story: 3.4 (75/22) — Which is darn close to pi — which makes me believe it has to be right. ;-) This number, 3.4, is what XP practitioners referred to as load factor.
  • Evaluation cycles, not development time-boxes
  • The only difference is the cycles aren’t used to plan and commit to stories any longer.
  • The daily standup or daily scrum meeting occurs as normal, but now it occurs in front of the Kanban board. Instead of the regular meeting ritual of checking in with each person to find out what they worked on yesterday and will work on today, the discussion revolves around the Kanban board and what will likely move on and off the board today, where “traffic” seems the heaviest, and what we could do to clear bottlenecks.
  • Reflect every few weeks
  • Lean practices help teams increase throughput. They don’t make developers type faster, rather they draw attention to bottlenecks that slow things down, help you see them and respond to them quicker. Using a Kanban board lets you easily visualize work in progress across different roles and lets you see when someone is taking on too much work simultaneously.
  • Demonstrate every few weeks
  • A task board as it’s commonly used in an agile approach can give you the visualization too. But, widening the task board to separate testing from development from acceptance or other process steps helps me better visualize where things are clogging up — helps me better diagnose problems. And, setting hard limits for process steps and respecting them really makes me deal with the problem in a way that dropping a pile of stories into a sprint or iteration didn’t. But, maybe it’s just me who’s lazy and avoids dealing with tough problems. I’m sure you’d never run into a situation where you and your team let lots of finished development work pile up waiting to be tested.
  • There’s no one as zealous as the newly converted There’s a lot of folks pretty excited about Kanban out there. I am too. Sometimes that zeal takes the form of telling people practicing common agile time-boxed development that they’re wrong. But, I guess I’m crusty enough to know that there’s lots of right ways to succeed and anyone who believes they’ve found the best ways is likely wrong. Don’t let those voicing opinions strongly for, or against, Kanban approaches stop you for digging in deeper and understanding the ideas behind it.
  • Yuval Yeret on 03 Jun 09
     
    one of the best articles about Kanban and its relation to Agile I've encountered so far - focusing on Feature development (not maintenance)
Yuval Yeret

FDA Endorses Agile: What Does that Mean? | MDDI Medical Device and Diagnostic Industry ... - 0 views

www.mddionline.com/...-endorses-agile-what-does-mean

medical agile case study

shared by Yuval Yeret on 08 Dec 14 - No Cached
  • The guidance covers several key topics such as documentation, evolutionary design and architecture, traceability, verification and validation, managing changes and “done” criteria. the document has become a must-have reference document for every professional implementing Agile to develop medical devices software. It focuses on providing the following:
Yuval Yeret

GE Healthcare Goes Agile | Dr Dobb's - 0 views

www.drdobbs.com/...228300298

medical agile case study

shared by Yuval Yeret on 08 Dec 14 - No Cached
  • we operate in a highly regulated environment so there are a number of additional quality and regulatory steps that must be completed before we can accept a "user story"— that scenario written in the business language of the user that captures what he or she wants to achieve. Therefore, our "definition of done" — that is, the list of activities that add value to the product such as unit tests, code coverage, and code reviews — turned out to be lengthy.
  • Yuval Yeret on 08 Dec 14
     
    "Modify: It's OK to use a hybrid approach to agile. GE Imaging Solutions needed more up-front planning and post-sprint testing, for example. "
1 - 20 of 25 Next ›
Showing 20▼ items per page