ÉnKép - takacsot

Extract - Hiring for an Agile Team: Possible Questions

2009.01.16. 17:56 takacsot

Tell me about a time when you participated in a debate on differences of opinion
Tell me about a time when you went along with a team decision you disagreed with
Tell me about a time you needed info from elsewhere but were initially unable to get it
Tell me about a time when you were successful at getting/having the team take a different approach?
Tell me about a time when you challenged the team’s direction.
Tell me about your day to day activities as a scrum master
Tell me about your most challenging impediment on your most recent project
Tell me about a time you received feedback. How did you respond to it?
Tell me about a time you started in one rule and transitioned to another role?
Original

Facebook Tumblr Tweet Pinterest Tetszik

0

Extract - The Cost of Net Negative Producing Programmers

2009.01.14. 14:16 takacsot

I heard once that in Great Britain's MOD if you design software for a plane you go up in the test plane when the software is beta-tested. If all programmers were held with that level of accountability, how many do you think would still be in our field? How many would you want to collaborate with before you went up in the plane together?
...
I do think there are things we can do to help move the industry in the right direction. The good programmers can refuse to work with bad programmers.

Original

Facebook Tumblr Tweet Pinterest Tetszik

0

Extract - What’s your most controversial programming opinion?

2009.01.12. 11:11 takacsot

Nagyon olvasmányos és érdekes vélemények a programozásról. Nekem nagyon tetszettek. Nagyon sok tanulságos is. Érdemes visszatérni és kigyüjteni a legjobb véleményeket.

Link

Facebook Tumblr Tweet Pinterest Tetszik

0

Extract - When Working Software Is Not Enough: A Story of Project Failure

2009.01.10. 21:10 takacsot

Kiválló prezentáció arról, mikor bebukott egy látszólag sikeres Agile projekt. nagyon tanulásgos.

Original

Facebook Tumblr Tweet Pinterest Tetszik

0

Extract - I don’t believe in IPMs

2009.01.08. 15:46 takacsot

At the beginning of the release, you have a backlog of the stories for the release with estimates on them, so you can gauge how long you think the release will take to complete (there is no difference here). Then, you identify which stories are the most risky to play (which will deliver value) and ones which have to be played first and you prioritize the top 10 (at this stage this is just an arbitrary number, depending on the number of pairs you have). You then have a bucket which holds top 5 (again, arbitrary) stories.
When a developer picks up a new story they have to pick up something from the bucket, but what they pick up is their choice - first in first served basis.
Any bugs which arise are added to the bucket (assuming the business wants to fix them).
No new stories can be added to the bucket until it is empty.
The business has the power to replace a story in the bucket if they feel something else will deliver better value.
When the bucket is starting to look empty, the BA can then define the next lot of stories, taken from the original top 10 which will go into the bucket.
5 new stories get added to the prioritized list so that we still have a Top 10.

Original

Facebook Tumblr Tweet Pinterest Tetszik

0

Extract - Wanted: Software Development Leader

2009.01.06. 15:35 takacsot

Experience:
- Development experience - preferably within the last decade

Aptitude:
- Can tell a crappy architecture from a sound architecture
- Can tell a crappy implementation from a sound implementation
- Can tell the difference between someone who is busy and someone who is productive
- Can discern the difference between a good candidate for a position "on paper" and a good candidate for real
- Demonstrates a deep understanding of what quality means for a software product (including non-functional requirements like performance, supportability, and extensibility)
- Can tell when an architect, developer, QA, BA, or business partner is blowing smoke up his hind quarters
- Can speak the dialect of business - ROI, NPV, customer acquisition cost
- Can relate to business stakeholders and build collaborative relationships
- Can connect to team members on a personal level
- Has a good sense of humor
- Understands the difference between a prototype and a production application

Attitude:
- Will call out a crappy architecture and drive change
- Will call out a crappy implementation and drive change
- Will call out the busy-bees and the smoke-blowers
- Will demand demonstrable quality (including non-functional requirements)
- Will demand reasonable tests (unit tests, component tests, system tests)
- Does not suffer fools gladly
- Will not sit through a PowerPoint that depicts supposed progress without demanding demonstration of said progress
- Will not abide bubble gum and duct tape solutions to production (or development) defects
- Demands continuous improvement
- Demands root cause analysis (5 why's)
- Demands customer involvement in product development
- Continuously seeks to improve efficiency by asking "why" and "how can we do this more efficiently" (e.g. - PMO requirements for excessive documentation)
- Is willing to fight for the resources required by the team to deliver
- Cares deeply about the team
- Cares about the career development of team members
- Cares deeply about product quality
- Will celebrate true success with the team (no gratuitous applause please)
- Will always give credit to the team for success
- Will remove team members when necessary
- Has a coaching mentality
- Is willing to get hands dirty (writing code, writing/running/debugging tests, fetching pizza)
- Is always available to the team
- Exhibits patience, when appropriate
- Exhibits impatience, when appropriate

Integrity:
- Tells the truth - for instance about project status
- Is clear to team members on expectations and performance on a regular basis (not just at review time)
- Is willing to stand up and fight for the team

Original

Facebook Tumblr Tweet Pinterest Tetszik

0

Extract - TDD: Does it make you slower?

2009.01.04. 14:30 takacsot

One of the problems seems to be that in many organisations only the first release of a piece of software is considered, and in this case then yes maybe it would be quicker to develop code in a non TDD fashion.
The issue you have is that the majority of the overall cost of software does not come in that first release
...
This is where the real cost in software lies
...
The TDD approach to doing this encourages early testing whereas the traditional approach is to do a lot of the testing at the end. The problem with the latter approach is that any bugs are being discovered quite a long time after the code was written which means it will take much longer to try and identify where they came from.
...
code written using a TDD approach takes longer to write originally but puts less bugs in production.

Original

Facebook Tumblr Tweet Pinterest Tetszik

0

Brave Developer

2009.01.03. 19:44 takacsot

Facebook Tumblr Tweet Pinterest Tetszik

0

Emberi produktivitás-fejlődés gátjai 2

2009.01.02. 11:04 takacsot

Korábban írtam már egy postot erről a témáról.

Most új munkásfajta is előkerült. Trükkös fajta, hiszen nehezen megfogható:

Bokszoló: Pontosabban küzdő boxoló. Az a fajta, aki a menetekben alig tesz bármit, de végén belehúz. Ugyan veszít, de a közönség szemében úgy marad meg, mint aki veszített ugyan, de legalább küzdött. Pedig, ha a legelejítől kezdve úgy boxol, mint a végén, akkor nyerhetett is volna.

Facebook Tumblr Tweet Pinterest Tetszik

0

Personal Best of 2007

2009.01.01. 13:09 takacsot

2007

Facebook Tumblr Tweet Pinterest Tetszik

0

Personal Best of 2006

2009.01.01. 13:08 takacsot

2006

Facebook Tumblr Tweet Pinterest Tetszik

0

Personal Best of 2005

2009.01.01. 13:07 takacsot

2005

Facebook Tumblr Tweet Pinterest Tetszik

0

Már jó régen kezdtem blogot írni. Kezdetben a freeblogon, de mostanra mindent átköltöztettem ide, mert itt több olyan szolgáltatás van, mint a másikon. És gondoltam egyet és minden bejegyzésen végigmentem és átfutottam. Eredmény az, hogy bizony rengeteg érdekes és időtálló bejegyzésem van. Imhol a kivonat:

2005

2006

2007

2008-ról majd az év vége után.

Facebook Tumblr Tweet Pinterest Tetszik

0

Szólj hozzá!

Extract - Why Projects Don’t Need Specialists

2008.12.25. 10:30 takacsot

Specialists increase project delays in these ways:
They aren’t available when you need them. Because they are specialists, it’s too easy for the specialist to be busy on another task when you need that specific person. And, because you or the specialist estimate only the time the specialist needed, if you ask anyone else to do the task, the task will take too long.
The work backs up. No, you don’t need a specialist all the time. But when you do, you need them. So, since work doesn’t arrive as an even distribution, but instead arrives more in a Poisson distribution, the specialist has some periods of time when they aren’t busy, and more times when they have a queue of work.
Murphy’s Law will happen. Just when you need a specialist, that person will want a vacation, or want to get married, or go skiing for two weeks, or have a baby. Or, leave the organization.

PMs (and projects) don’t need specialists. They need people who are multi-talented and can finish tasks. Am I saying that we turn GUI designers into kernel developers? No, but there are many more things that a GUI designer or a kernel developer can do, rather than just one specialty.

If you have specialists now, rethink your staffing, and offer people opportunities to learn new skills. Your projects will progress faster and you’ll be more effective.

Original

Facebook Tumblr Tweet Pinterest Tetszik

0

Szólj hozzá!

Extract - Discuss Results, Not Tasks

2008.12.08. 20:38 takacsot

He’s an effective program manager, because he doesn’t tell people to do this or that task. Instead, he tells them the goal and the results he’s after.
...
If you ask people to deliver results, you are likely to get them. If you measure or assess people on how they perform certain tasks, such as yelling at program staff, or how well people work on a task in isolation, you will get what you measure. But it won’t be what you want.
Remember to measure what done means, not the tasks people do. Your tasks might not be my tasks. As long as we agree on done and we both recognize when we’ve achieved done, we will succeed. That’s the idea behind looking for results, not tasks.

Original

Facebook Tumblr Tweet Pinterest Tetszik

0

Szólj hozzá!

Extract - How To Fail With Agile - 20 Tips to Help You Avoid Success

2008.11.30. 09:13 takacsot

Vigyázat! Ennek teljesen az ellenkezőjét kell tenni!

Imádom az ilyen cikkeket, ami a negítv oldaláról mutatja be a dolgokat. Mivel ezek paródiák jót mulatok rajta. Csak akkor szokott síráűsra görbülni a szám, amikor ezeket a Dilberti dolgokat saját magamon és a cégemen tapasztalom.

Don’t trust the team or agile. Micromanage both your team members and the process.
If agile isn’t a silver bullet,blame agile.
Equate self-managing with self-leading and provide no direction to the team whatsoever.
Ignore the agile practices. They don’t apply to management.
Undermine the team’s belief in agile.
Continually fail to deliver what you committed to deliver during iteration planning.
Cavalierly move work forward from one iteration to the next. It’s good to keep the product owner guessing about what will be delivered.
Do not create cross-functional teams. Put all the testers on one team, all the programmers on another, and so on.
Large projects need large teams. Ignore studies that show productivity decreases with large teams due to increased communication overhead. Since everyone needs to know everything, invite all fifty people to the daily standup.
Don’t communicate a vision for the product to the team or to the other stakeholders.
Don’t pay attention to the progress of each iteration and objectively evaluate the value of that progress.
Replace a plan document with a plan “in your head” that only you know.
Have one person share the roles of ScrumMaster (agile coach) and product owner. In fact, have this person also be an individual contributor on the
team
Start customizing an agile process before you’ve done it by the book.
Drop and customize important agile practices before fully understanding them.
Slavishly follow agile practices without understanding their underlying principles
Don’t continually improve.
Don’t change the technical practices.
Rather than align pay, incentives, job titles, promotions, and recognition with agile, create incentives for individuals to undermine teamwork and shared responsibility.
Convince yourself that you’ll be able to do all requested work, so the order of your work doesn’t matter.

Original

Facebook Tumblr Tweet Pinterest Tetszik

0

Szólj hozzá!

Extract - The Elephant in the Server Room

2008.11.28. 20:16 takacsot

50% of all people doing business software development should find a new profession

Original

Facebook Tumblr Tweet Pinterest Tetszik

0

Szólj hozzá!

Extract - That's Not a Bug, It's a Feature Request

2008.11.26. 19:40 takacsot

I wish we could, as an industry, spend less time fighting tooth and nail over definitions, painstakingly placing feedback in the "bug" or "feature request" buckets -- and more time doing something constructive with our users' feedback.

Original

Facebook Tumblr Tweet Pinterest Tetszik

0

Szólj hozzá!

Extract - 10 Principles of Agile Project Time Management

2008.11.21. 21:57 takacsot

Use a Definition of "Done"
Use Timeboxes to Manage Work: Set a start- and end date for a collection of activities, and don't allow changes to those dates.
Don't Add Slack to Task Estimates
Defer Decisions
Reduce Cycle Time
Keep the Pipeline Short and Thin
Keep the Discipline
Limit Task Switching
Prevent Sustained Overtime
Separate Urgency from Importance

Original

Facebook Tumblr Tweet Pinterest Tetszik

0

Szólj hozzá!

Extract - Scrum-ban

2008.11.19. 21:47 takacsot

prefer completing work to starting new work, or you might express that as a rule that says: try to work on only one item at a time, but if you are blocked, then you can work on a second item, but no more.

Original

Facebook Tumblr Tweet Pinterest Tetszik

0

Szólj hozzá!

Extract - Agile Risk Management

2008.11.17. 21:07 takacsot

It seemed like nothing had gone right. The customer had signed the contract far too late, which meant that resource management had to switch to another (inexperienced) team, because the original team was already booked for other projects; the platform to be used turned out to be much older than anticipated; the customer singlehandedly decided on a live release date, and forgot to inform anybody else on the team about it; half of the requirements turned out never to have reached the proper team members, due to some stupidly bad communication; and beta testing was a nightmare because the customer hired a third-party service organization, and the development team was not allowed access to the beta testing environment.

Original

Facebook Tumblr Tweet Pinterest Tetszik

0

Szólj hozzá!

Extract - Are We There Yet?

2008.11.16. 21:28 takacsot

A story is complete when:

Coded/implemented
Peer reviewed (pair programming counts as peer review)
Code is run against current version in source control
Code is commented in source control and checked in
Code is commented with VB Commenter on Public/Friend methods
Story/use case manual test plan updated
Fit test written (with help of SQA person)
UML diagram updated
Unit tests written and passing
90 percent code coverage achieved
Build and package changes are communicated to build master (i.e. introducing a new file or something)
Task list hours are updated and task is closed out
All to-do items in code are completed

Original

Facebook Tumblr Tweet Pinterest Tetszik

0

Szólj hozzá!

Címkék: project management, agile,

A hibák forrása

2008.10.30. 05:06 takacsot

A hibáknak két forrása van: a tudás hiánya és a figyelem hiánya.

A tudás hiánya a kissebb gond, mert pótolható, ha már felismertük. Egy programozási eszköz (nyelv, komponens, ide) megtanulható. A specifikációban és designban lévő hiányosság pótolható. A programozói készség fejleszthető.

A figyelem (én szerintem a fegyelem is jó szó erre) hiánya már nehezebb. Ez atitűd, hozzáállás kérdése.

Jó lenne, ha ez utóbbi dologgal nem kellene foglalkozni, hiszen a hozzááláson változtatni egy felnőtt embenél nehéz dolog. Itt jön be a másik kifejezés, a fegyelem. Fegyelmezett fejlesztő esetén nincs gond az figyelemmel. A lelkes fejlesztőnél sincs, hiszen nagyon akar. De aki nem lelkes és fegyelmezett, annál kell. Ide sorolhatók a kiégett fejlesztők, akiket már nem motivál semmi de nem elég profik ahhoz, hogy akaraterőből legyürjék és a kelégítő vagy alacsonyab szintű munka helyett kiválló munkát tudjanak végezni. Ide tartozik még az nem megbecsült tehetség. Az aki azt gondolja, hogy fenomenális nagyságú tudással, tapasztalattal rendelkezik. Ez tuóbbi rosszabb. Az első legalább tudjamagáról, hogy nem hozza azt amire képes lenne. Az utóbbi viszont nemtduja, hogy nem képes hozni a szinvonalat képzés és alázat nélkül.

Facebook Tumblr Tweet Pinterest Tetszik

0

Szólj hozzá!

Címkék: development

Comics

2008.08.29. 13:42 takacsot

Facebook Tumblr Tweet Pinterest Tetszik

0

Szólj hozzá!

Extract - 101 Ways To Know Your Software Project Is Doomed

2008.07.21. 21:25 takacsot

Management has renamed its Waterfall process to Agile Waterfall
You start hiring consultants so they can take the blame
The Continuous Integration server has returned the error message “Fuck it, I give up”
You have implemented your own Ruby framework that uses XML configuration files
Your eldest team member references Martin Fowler as a ’snot-nosed punk’
Your source code control system is a series of folders on a shared drive
Allocated QA time is for Q and A why your crap is broken
All of your requirements are written on a used cocktail napkin
You start considering a new job so you don’t have to maintain the application you are building
The lead web developer thinks the X in XHTML means ‘extreme’
Ever iteration meeting starts with “Do you want the good news or the bad news…”
Your team still gives a crap about its CMM Level
Progress is now measured by the number of fixed bugs and not completed features
Continuous Integration is getting new employees to read the employee handbook
You are friends with the janitor
The SCRUM master doesn’t really care what you did yesterday or what you will do today
Every milestone ends in a dead sprint
Your best developer only has his A+ Certification
You do not understand the acronyms DRY, YAGNI, or KISS; but you do understand WTF, PHB, and FUBAR
Your manager could be replaced by an email redirection batch file
The only certification your software process has is ISO 9001/2000
Your manager thinks ‘Metrics’ is a type of protein drink
Every bug is prioritized as Critical
Every feature is prioritized as Trivial
Project estimates magically match the budget
Developers use the excuse of ’self documenting code’ for no comments
Your favorite software pattern is God Object
You still believe compiling is a form of testing
Developers still use Notepad as an IDE
Your manager wastes 7 hours a week asking for progress reports (true story)
You do not have your own machine and you are not doing pair programming
Team Rule - No meetings until 10 AM since we were all here until 2 AM
Your team believes ORM is a ‘fad’
Your team believes the transition from VB6 to VB.NET will be ’seamless’
Your manager thinks MS Project is the best management tool the market offers
Your spouse only gets to see you on a webcam
None of your unit tests have asserts in them
FrontPage is your web page editor of choice
You get into flame wars if { should be on new line, but you are impartial to patterns such as MVC
The company motto is ‘Do more with less’
The phrase ‘It works on my machine’ is heard more than once a day
The last conference your .NET team attended was Apple WWDC 2000
Your manager insists that you track all activity but never uses the information to make decisions
All debugging occurs on the live server
Your manager does not know how to check email
Your manager thinks being SOX compliant means not working on baseball nights
The company hires Senetor Ted Stevens to give your project kick-off inspiration speech
The last book you read - Visual InterDev 6 Bible
The overall budget is mistaken for your weekly Mountain Dew bill
Your manager spends his lunch hour crying in his car (another true story)
Your lead web developer defines AJAX as a cleaning product
Your boss expects you to spend the next 2 days creating a purchase request for a $50 component
The sales team decreased your estimates because they believe you can work faster
Requirement - Rank #1 on Google
Everyday you work until Midnight, everyday your boss leaves at 4:30
Your manager loves to say “Why do the developers care? They get paid by the hour.”
The night shift at Starbucks knows you by name
Management can not understand why anyone needs more than a single monitor
Your development team only uses source control as a power failure backup system
Developers are not responsible for any testing
The team does not use SVN because they believe the merge algorithms are black voodoo magic
Your white boards are mostly white (VersionOne)
The client continually mistakes your burn-down chart for a burn-up chart
The project code name is renamed to ‘The Death March’
Now it physically pains you to say the word - Yes
Your teammates don’t refactor, they refuctor
To reward you for all of your overtime your boss purchases a new coffee maker
Your project budget is entered in the company ledger as ‘Corporate Overhead’
You secretly outsource pieces of the project so you can blog at work
A Change Control Board is created and your product isn’t even its first alpha version
Daily you consider breaking your fingers for the short term disability check
The deadline has been renamed a ‘milestone’…just like the last ‘milestone’
Your project managers ‘open door’ policy only applies between 5:01 PM - 7:59 AM
Your boss argues “Why buy it when we can built it!”
You bring beer to the office during your 2nd shift
The project manager is spotted consulting a Ouija board
You give misinformation to your teammates so you look better on your personal review
All code reviews are scheduled a week before product launch
Budget for testing exists as “if we have time”
The client will only talk about the requirements after they receive a fixed estimation
The boss does not find the humor in Dilbert
You start noticing your boss’s poker tells during planning poker
You start wondering if working 2 shifts at Pizza Hut is a better career alternative
All performance issues are resolved by getting larger machines
The project has been demoted to being released as a permanent ‘Beta’ version
Your car is towed from the office parking lot as it was thought to be abandoned
The project manager likes to doodle during requirements gathering meetings
You are using MOSS 2007
Your SCRUM team consists of 1
Your timesheet looks like a Powerball ticket
The web developer thinks being 508 means looking good in her Levi Red Tabs
You think you need Multiple Personality Disorder medication because you are Mort, Elvis, and Einstein
Your manager substitutes professional consultant advice for a Magic 8 Ball
You know exactly how many compile warnings cause an ‘Out of Memory’ exception in your IDE
I have used IDE twice in this list and you still don’t know what it stands for
You have cut and pasted code from The Daily WTF
Broken unit tests are deleted because they are obviously out of date
You are sent to a conference to learn, but you skip sessions to go hunting for swag
QA has nicknamed you Chief Off-By-One
You have been 90% complete 90% of the time
“Oh, oh, and I almost forgot. Ahh, I’m also gonna need you to go ahead and come in on Sunday, too… thanks”

Original

Facebook Tumblr Tweet Pinterest Tetszik

0

HTML