Блог Сергея Борзова

Действительно почему? Почему мы срываем сроки поставки? Собираем изначально бажные системы? О ком это Вы Сергей? В нашей компании все ок. Все как по маслу =). Ну да. Мэй би ай мэй би ю. Конечно причины в людях. В том, что кто-то делает свою работу лучше, а кто-то хуже. Кто-то набирает на клавиатуре слепым методом, а кто-то нажимает кнопку Отправить, а не Ctrl+Enter. Кто-то задерживается, а кто-то уйдет - ведь 8ми часовой рабочий день закончился! Отсюда все эти перекосы в планировании трудозатрат, срыве сроков и прочих авралов. Рассмотрим типичный процесс разработки:

1. Аналитик пишет спецификацию, исходя из требований клиента

2. Программист пишет код, исходя из требований спецификации.

3. Технический писатель пишет тест-план, исходя из того, что напрограммировал программист и  спецификации.

4. Тестировщик тестирует, исходя из тест-плана.

5. ИТшник или программист собирает проект и ставит клиенту, исходя из того что наделали предыдущие четверо.

Баги на каждом этапе. Все ок? Нет - Failed. К чему же я это все веду. К тому что может что-то не так на этих 5ти этапах, может люди не те, или методы? Не знаю…не знаю братцы =) (Гришковец)

Знаю одно: разработка ПО на 99% состоит из взаимоотношений между людьми. Ну и напоследок отличная история под названием - Sofrware Development Cycle:

Software doesn’t just appear on the shelves by magic. That  program shrink-wrapped inside the box along with the  indecipherable manual and 12-paragraph disclaimer notice  actually came to you by way of an elaborate path, through  the most rigid quality control on the planet.   Here, shared for the first time with the general public, are  the inside details of the program development cycle.

1. Programmer produces code he believes is bug-free.
2. Product is tested. 20 bugs are found.
3. Programmer fixes 10 of the bugs and explains to the testing department that the other 10 aren’t really bugs.
4. Testing department finds that five of the fixes didn’t  work and discovers 15 new bugs.
5. See 3.
6. See 4.
7. See 5.
8. See 6.
9. See 7.
10. See 8.
11. Due to marketing pressure and an extremely pre-mature product announcement based on overly-optimistic programming schedule, the product is released.
12. Users find 137 new bugs.
13. Original programmer, having cashed his royalty check, is nowhere to be found.
14. Newly-assembled programming team fixes almost all of the 137 bugs, but introduce 456 new ones.
15. Original programmer sends underpaid testing department a postcard from Fiji. Entire testing department quits.
16. Company is bought in a hostile takeover by competitor using profits from their latest release, which had 783 bugs.
17. New CEO is brought in by board of directors. He hires programmer to redo program from scratch.
18. Programmer produces code he believes is bug-free….