- PVSM.RU - https://www.pvsm.ru -
Господа, всем радоваться.
За последнюю неделю прошло несколько переговоров:
Итогами этих переговоров стала продажа Foreign Rights (дают права на перевод) российскому издательству. Ориентировочно, официальный перевод книги может появиться в конце второго квартала 2014. Точной информации пока нет.
Более того, российское издательство поддержало краудсорсинговую инициативу по любительскому переводу этой книги и попросило нас продолжать. Таким образом, скоро мы сможем прочитать качественный официальный перевод, а пока что мы можем переводить сами при согласии правообладателя.
Тем временем, наша краудсорсинговая команда [1] тоже не сидела без дела и совместными усилиями мы подготовили для вас еще больше переводов. Один из них вы можете прочесть ниже. А после присоединяйтесь к нам :)
< 15. Практика, практика, практика [2] | Глава 17 >
«Разработка ПО» — это не просто какое-то абстрактное выражение, эта фраза заключает в себе действие. Это процесс создания вещи. Когда мы пишем код, важно думать не только о конечном результате, но и о процессе его достижения. Если отвлечься от процесса, то сразу возникает риск провалить срок, сделать что-то не то или вообще ничего не сделать. Такие результаты сильно расстроят наших клиентов.
К счастью, много мыслей было изложено о том, как сделать хороший программный продукт (да и любую другую продукцию вообще). Большинство из них превратилось в методологии, которые являются темами множества различных книг: вы можете найти их на просторах интернета или в ближайшем книжном магазине.
Но, к несчастью, очень мало разработчиков выносит что-то полезное из всей этой информации. Для большинства команд процесс разработки — это нечто внедренное сверху. Слово методология в их головах ассоциируется с утомительной бумажной работой и бесконечно длинными бестолковыми встречами и обсуждениями. Слишком часто методология навязывается менеджерами.
Менеджеры интуитивно понимают, что разработка должна следовать какому-то процессу, но зачастую не знают, какие варианты выбора доступны им на данный момент. В результате они стряхивают пыль с тех же самых процессов, которые были навязаны им в 1980-х, цепляют на них модный бантик (пастельный Agile-бантик — неплохой выбор на данный момент) и передают их своим командам. Это происходит до тех пор, пока кто-нибудь не прервёт цикл, сделав анализ того, что на самом деле работает, а что — нет, этот процесс будет повторяться снова и снова, так как участники команды сами со временем станут менеджерами.
Вы наверное думаете, что должны существовать гораздо более эффективные подходы к разработке. И это так, для большинства команд.
Если вы — программист, тестировщик или архитектор, то вы можете думать, что методология разработки — не ваша забота. Возможно, это так в вашей компании. К сожалению, в большинстве случаев никто не несёт за это ответственность. Если же назначить человека, который должен заниматься контролем процесса разработки, то чаще всего все скатывается к «группам процессов» [25] или похожему малопригодному подходу. Правда же заключается в том, что для мало-мальски успешного внедрения методологии, в этот процесс должны быть вовлечены люди, которые ее используют. А это как раз такие люди, как вы.
Лучший способ почувствовать, что вы владеете процессом — это помочь в его внедрении. Если в вашей организации еще нет четкого процесса, то исследуйте различные методологии, которые могли бы быть вам полезны. Устраивайте обеды с командой, обсуждая текущие проблемы разработки и то, как можно было бы их избежать, используя стандартные подходы. Составьте совместный план как применить выбранную методологию в вашей команде, и чтобы каждый участник вносил в него свой вклад. А потом просто начните воплощать этот план в жизнь.
Если хотите почувствовать процесс, помогите его внедрить.
С другой стороны, возможно вы работаете в условиях, когда на одного инженера приходится десять менеджеров. Зачастую, к тому времени, как идеи дойдут непосредственно до разработчиков, они претерпевают массу изменений и могут стать совершенно отличными от первоначальных. Этот процесс страдает теми же недостатками, что и игра в испорченный телефон. Однако, это и возможность взять инициативу в свои руки. Исследуйте методологию, которую вы решили применить и помогите понять, что она на самом деле значит для разработчиков и для менеджмента. Не нужно бороться с этим навязанным процессом, просто используйте его правильно.
Мир методологий также может показаться пустой обёрткой из умных слов. Несмотря на то, что они могут быть не до конца понятны, всегда можно почерпнуть что-то новое в процессе изучения новой методологии разработки — даже если это то, чего не стоит делать. Если же вы комфортно чувствуете себя в данном вопросе, то и ваши аргументы будут более весомыми в спорах о том, какой подход к разработке нужно
использовать.
Даже учитывая все многообразие методологий разработки, вам вряд ли доведется работать в компании, которая полностью использует какую-либо из них. Это нормально, так как лучший подход — это тот, который обеспечит наибольшую продуктивность команды и наилучшее качество продукта на данном этапе.
Так как управление проектом не всегда обязательно связано с методологией разработки программного обеспечения, то вы можете оказаться первым в вашей компании, кто занялся решением этой задачи. Множество методологий управления проектами уже используются в различных компаниях. Возможно самым значимым является подход, разработанный Институтом Управления Проектами — Project Management Book of Knowledge [26], (вместе с их
признанной системой сертификации). Ещё один пример общей методологии, касающейся не только разработки программного обеспечения — Six Sigma [27]. Используемый такими компаниями, как General Electric и Motorola, подход Six Sigma выделяет оценку и анализ процессов и продуктов для обеспечения удовлетворённости клиентов и эффективности. Хотя их решение разработано и не специально для направления разработки программного обеспечения, но его строгость и методичность даёт множество уроков, которые напрямую применимы в работе программиста.
Автор: Flar49
Источник [20]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/news/51777
Ссылки в тексте:
[1] краудсорсинговая команда: https://github.com/Flar49/passionate-programmer-translation
[2] 15. Практика, практика, практика: http://habrahabr.ru/post/207098/
[3] Вступительное слово: http://habrahabr.ru/post/79254/
[4] Благодарности: http://habrahabr.ru/post/79839/
[5] Введение: http://habrahabr.ru/post/79840/
[6] Глава 1. Веди или умри: http://habrahabr.ru/post/80282/
[7] Глава 2. Спрос и предложение: http://habrahabr.ru/post/85922/
[8] Глава 3. Кодинг ещё не всё: http://habrahabr.ru/post/86590/
[9] Глава 4. Будь худшим: http://habrahabr.ru/post/193880/
[10] Глава 5. Инвестируйте в свой интеллект: http://habrahabr.ru/post/195210/
[11] Глава 6. Не слушай своих родителей: http://habrahabr.ru/post/195774/
[12] Как я отказался от $300.000 — рассказ в конце 6-й главы: http://habrahabr.ru/post/196426/
[13] Глава 8. Будь специалистом: http://habrahabr.ru/post/205980/
[14] Глава 9. Не кладите все свои яйца в чужую корзину: http://habrahabr.ru/post/192876/
[15] Глава 10. Полюби это или брось: http://habrahabr.ru/post/206198/
[16] Глава 11. Научись рыбачить.: http://habrahabr.ru/post/206978/
[17] Глава 12. Изучите, как работает бизнес на самом деле: http://habrahabr.ru/post/206682/
[18] Глава 13. Найди ментора: http://habrahabr.ru/post/206968/
[19] Глава 14. Будь ментором: http://habrahabr.ru/post/207188/
[20] Глава 16. Твоя собственная методология: http://habrahabr.ru/post/207728/
[21] Глава 18. Автоматизируй свою работу: http://habrahabr.ru/post/207374/
[22] Глава 19. Прямо сейчас: http://habrahabr.ru/post/207310/
[23] Глава 20. Телепат: http://habrahabr.ru/post/207362/
[24] Глава 31. Не паникуй: http://habrahabr.ru/post/189650/
[25] «группам процессов»: http://en.wikipedia.org/wiki/Project_management#Processes
[26] Project Management Book of Knowledge: http://www.pmi.org/
[27] Six Sigma: http://www.issixsigma.com/
Нажмите здесь для печати.