Moved

I have moved.

http://takacsot.blog.hu

Elköltöztem

Elköltöztem. Hamarosanmegy minden blog bejegyzés is.

http://takacsot.blog.hu/

Extract - Agile Risk Management

Extract - Are We There Yet?

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

A hibák forrása

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.

Extract - 101 Ways To Know Your Software Project Is Doomed

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

Extract - A szoftverfejlesztés művészete - 2. rész

• Ha a régi fejemmel gondolkodnék, akkor azt mondanám, hogy állítsuk rá az üzleti elemzőinket, mérjék fel az igényeket, majd specifikálják a feladatot, melyet a fejlesztőcsapatunk majd kivitelez. Ez jól is hangzana, a probléma csak az, hogy a legtöbb esetben a belsős üzleti elemző záros határidőn belül nem képes kellő mélységben átlátni a problémakört. A legtöbb informatikai projekt már az üzleti elemzés fázisánál zátonyra fut úgy, hogy sem a megrendelő, sem a kivitelező nem ismeri fel a fejlesztés valódi rákfenéjét. Gyúrják, pofozzák a szerencsétlen programot, míg végül lesz belőle egy agyonfoltozott sánta óriás, melyre sem bevezetni, sem karbantartani nincs elég erőforrás.
• Jelenlegi szemléletem alapján, az első dolgom az lenne, hogy megkeressem a túloldalon ülő vérbeli szakértőt. Azt a személyt, aki már több éve belülről ismeri az összes ága-bogát a banki ügyvitelnek, aki vezetett már banki irattárat, és saját maga is sok iratot írt alá. Ha nem találok ilyet, akkor tovább keresek: ez az első és legfontosabb erőforrás, melyre mindenképpen szükségem lesz, ha sikerre akarom vinni a projektet. Ha megtaláltam a kívánt személyt, leszerződök vele: be kell hoznom a projektbe ahhoz, hogy száz százalékban nekem dolgozzon, hogy belülről képviselje az ügyfelet. Ő lenne a projekt szakmai gazdája, az első számú üzleti elemző.

A második lépés ennél jóval könnyebb, de egyáltalán nem triviális: a frissen hozott erőforrás bár nagyon ért az adott területhez, informatikailag egyáltalán, vagy csak alig képzett személy. Szükség van mellé egy olyan üzleti elemzőre, aki a fejlesztői csapat élén állva megformálja a program lelkét képező domaint. Ha ezt a két személyt megtaláltam, akkor a kezemben van a projekt szakmai sikerességének garanciája

...
Ideális esetben külön lehet szerződni a követelményspecifikáció elkészítésére, és az abban megfogalmazott követelmények alapján lehet becsülni a fejlesztés, tesztelés, bevezetés stb. költségét. (Rosszabb esetben úgy adsz ajánlatot, hogy nem vagy tisztában a rendszer szkópjával, és csak annyit tudsz, amennyi a pályázati kiírásban szerepelt.)
…
Minden fejlesztőtársamnak azt javaslom, hogy próbáljanak meggyőzni az ügyfél oldaláról egy segítőkész embert, aki rendelkezésre tud állni, hogy segítsen a fejlesztés során. Hihetetlen dolgokat lehet így véghez vinni!
…
Fontos kockázatcsökkentő tényező, ha egy olyan ember legyen képes az ügyfélnél jelen lenni, aki proaktívan, dialógust kezdeményezve próbál olyan előzetes megoldásokat felvázolni, amik csökkenthetik a későbbi ráfordításokat. Valószínűleg nem csak nekem "áll fel a szőr a hátamon", amikor nem egy kövspecben ezt olvasom: "a rendszer naplózzon minden módosítást és módosítási kísérletet". Ha valaki olyan megy oda, akinek fogalma sincs a megvalósítás hátteréről, simán "benyel" egy ehhez hasonló követelményt. Amikor egy ilyen elhangzik, további kérdéseket lehet feltenni az ügyfélnek, hogy valójában mi a célja ezzel, mik a legfontosabb adatkörök, hogyan fogja ezeket felhasználni stb. Így egy pontosabb képet lehet alkotni az elképzelésekről, és ráadásul ésszel lehet neki állni egy ilyen követelmény megvalósításához.
...

Extract - Software Estimates - Managing Expectations via Ranges

 Jó cikk. Nincs mit kiemelni, az egész cikket el kell olvasni. Kicsit sokat száolós, de néha ez az ami kell.

Original

Extract - Top 10 Estimation Best Practices

1. Use more than one person
2. Use more than one approach
3. Agree on what “It” and “Done” means: stimating in the same units. What does “Done” include? Coded, unit tested? How about integrated and system tested? What about refactoring contingencies? User meeting time?
4. Know when to stop
5. Present estimates as a range
6. Defend / explain estimate range probabilities
7. Don’t reserve estimating for when you know least about the project
8. Be aware of common estimation omissions
9. Embrace reality early
10. Review, Revisit, Remove head from sand, Repeat

Original

Extract - Software Development Top 30 Mistakes

1. Not understanding the user's needs. Lack of user input, or not even asking.
2. Underestimating the size of the project.
3. Rushing through the planning stage, or avoiding the planning all together.  Code first, plan later! BAD!
4. Not testing early enough, often, or at all!  Make it a habit!
5. Choosing the "Cool" methodology at the time, vs. one that has worked in the past. Which leads into my next point...
6. Not using a methodology.
7. Letting a software developer run the software development project.
8. Bored, unmotivated team!  You have to motivate your developers!  If you can't motivate, don't bother trying to lead.  Your team will fall asleep, literally.
9. Planning on catching up later.  You won't... don't even think it!
10. Non Source Control!  Ouch.. not good people... and no, just installing a software package is not it...
11. Deciding to switch your development tools when you’re already into the project.
12. Allowing feature creep.  Just say NO!  Everyone will be happier in the end.
13. Omitting necessary tasks to shorten the project plan.  Really, what's the point of doing this?
14. Insufficient management controls in the development project.
15. Lack of high level business sponsorship.
16. Adding people at the end of the project to "speed things up".  You will only slow things down...
17. No unit testing.  Heck if you can do it, use Visual Studio Team Foundation Server and set up some automated testing nightly.
18. Stressed out software developers.  If you have managed to perform even one or two of these software development mistakes, you will have a stressed out bunch of programmers to deal with!
19. Lack of error handling.
20. "Off by one" errors.  These happen a lot during the software development process.. *sigh*.
21. Typos...  Just use option strict and explicit please..  during one software development project, which I was on as a consultant, they were getting ridiculous amounts of errors everywhere... turned out the developer couldn't spell and would declare variables with incorrect spelling.. no big deal, until you use the correct spelling when you're assigning a value to it...  and  you had option explicit off.  Ouch to them...
22. No understand the deployment or hardware the software is to be installed on.  Ohhhh it's for a Macintosh... lol.  Well hopefully not that bad, but you get the point.
23. No naming style or code conventions.  Honestly it doesn't matter what you use... as long as you are consistent with the rest of the team, and hopefully at least yourself.
24. Using global variables everywhere.  These are NOT your friend and hog memory like nothing you have ever seen before!
25. Not asking for help at all during the software development process.  If you’re stuck, don't fight with it for hours on end!  Ask for help!
26. Not commenting your code.
27. Hogging all information to yourself.  You think you're more valuable this way?  You're actually not and there is a plan brewing to get you kicked off the development project, and possibly out of the company.  You might want to brush up your sign "Will code for pizza!". 
28. Performing database operations at the application layer instead of the database layer. Not only is this putting the processing juice on your application instead of your server, but you have put your database at risk of data integrity issues, and getting bad data!  Some of my hipster cool friends are always saying "It's alllll good", well, if your database can be caught saying this... and If everything looks good to your database, then you should be worried.  It is NOT all good!
29. Not validating your data! Yikes...  Yes.. let’s just assume all the data is perfect! NOT!
30. No load testing.  What.. This is supposed to run on 1,000 user's machines through Citrix?  Interesting... Shouldn't be an issue! lol... NOT.

Extract - 10 Tips to Ace a Software Development Interview

1. Arrive Early
2. Dress Professionally
3. Show Your Passion for Software Development
4. Show You Like Them and The Company
5. Avoid Discussing Salary and Compensation
6. Answer Questions From Experience
7. Ask Good Questions
8. Do Not Be Negative
9. Constant Eye Contact
10. Do Not Appear Overconfident and "Know It All"

Original

Extract - How To Finish A Big Software Project And Be The Hero

First, a little history to how the big nasty project starts!  A huge software development project is dreamed up to solve some complex problem.  Great, that's what software is all about!  But things start going bad right on day one!  How?Well, the managers and executives decide that they are going to plan every detail of the software project to the most minute detail.  They then assign a project manager to manage all the developers and let them start building each piece independently one-by-one.  A few weeks before shipping, the project managers try and combine everything, and all is well right?  Wrong... Disaster!  The project is delayed!  Days pass, weeks, months, years!  What the *beep* just happened here! What to do?

... 

How is a skyscraper built?  First lay the foundation, then put in floors, with the elevator shafts, then build floor after floor, then the interior, etc.  Could you imagine what would happen if every piece was built in a different site, and then later everything was dropped off at the construction site to be assembled?  Even if you had the best plan to assemble everything together, you would have problems!  Things wouldn't fit and would have to be re-done, architects would change their minds, pieces would be missing, and the building would look like a bunch of match sticks!

...

1. Source Control
2. Continuous Integration
3. Bug Tracking System
4. Patching System. I'm not going to get into installer issues here, but you need a patching system.  You do not want to deploy installs upon installs to your testers
   
5. Disable Untested Features, Turn off every feature in your application that has not been completely bug tested and approved by your users.  If your project is in trouble, you have hundreds of features implemented at 80%, and you probably think they are at 90% - 95%, but they aren't.
6. List Major Features
7. List Top 20% of Major Features
8. Detail Out Top 20%
9. Plan The Week
10. Create Branch
11. Build Release for Testers
12. Testers Take Flight
13. Software Developers Work on Trunk
14. Approve Patch
15. Continue Steps 9 to 14. Continue your efforts over and over until you get the 20% done, hopefully this is not as far away as you think!

Your goal is to focus on small features, get them done, and send out a release for testers. 

Your team will be extremely motivated to be releasing workable software every week!

When testers find bugs, your developers will fix them faster because the code they wrote is fresh in their minds! 

Original