Господа, всем радоваться.
За последнюю неделю прошло несколько переговоров:
- Между мной и обладателями прав на оригинал
- Между обладателями прав на оригинал и российским издательством
- Между мной и российским издательством
Итогами этих переговоров стала продажа Foreign Rights (дают права на перевод) российскому издательству. Ориентировочно, официальный перевод книги может появиться в конце второго квартала 2014. Точной информации пока нет.
Более того, российское издательство поддержало краудсорсинговую инициативу по любительскому переводу этой книги и попросило нас продолжать. Таким образом, скоро мы сможем прочитать качественный официальный перевод, а пока что мы можем переводить сами при согласии правообладателя.
Тем временем, наша краудсорсинговая команда тоже не сидела без дела и совместными усилиями мы подготовили для вас еще больше переводов. Один из них вы можете прочесть ниже. А после присоединяйтесь к нам :)
< 15. Практика, практика, практика | Глава 17 >
Глава 16. Твоя собственная методология
«Разработка ПО» — это не просто какое-то абстрактное выражение, эта фраза заключает в себе действие. Это процесс создания вещи. Когда мы пишем код, важно думать не только о конечном результате, но и о процессе его достижения. Если отвлечься от процесса, то сразу возникает риск провалить срок, сделать что-то не то или вообще ничего не сделать. Такие результаты сильно расстроят наших клиентов.
К счастью, много мыслей было изложено о том, как сделать хороший программный продукт (да и любую другую продукцию вообще). Большинство из них превратилось в методологии, которые являются темами множества различных книг: вы можете найти их на просторах интернета или в ближайшем книжном магазине.
Но, к несчастью, очень мало разработчиков выносит что-то полезное из всей этой информации. Для большинства команд процесс разработки — это нечто внедренное сверху. Слово методология в их головах ассоциируется с утомительной бумажной работой и бесконечно длинными бестолковыми встречами и обсуждениями. Слишком часто методология навязывается менеджерами.
Менеджеры интуитивно понимают, что разработка должна следовать какому-то процессу, но зачастую не знают, какие варианты выбора доступны им на данный момент. В результате они стряхивают пыль с тех же самых процессов, которые были навязаны им в 1980-х, цепляют на них модный бантик (пастельный Agile-бантик — неплохой выбор на данный момент) и передают их своим командам. Это происходит до тех пор, пока кто-нибудь не прервёт цикл, сделав анализ того, что на самом деле работает, а что — нет, этот процесс будет повторяться снова и снова, так как участники команды сами со временем станут менеджерами.
Вы наверное думаете, что должны существовать гораздо более эффективные подходы к разработке. И это так, для большинства команд.
Если вы — программист, тестировщик или архитектор, то вы можете думать, что методология разработки — не ваша забота. Возможно, это так в вашей компании. К сожалению, в большинстве случаев никто не несёт за это ответственность. Если же назначить человека, который должен заниматься контролем процесса разработки, то чаще всего все скатывается к «группам процессов» или похожему малопригодному подходу. Правда же заключается в том, что для мало-мальски успешного внедрения методологии, в этот процесс должны быть вовлечены люди, которые ее используют. А это как раз такие люди, как вы.
Лучший способ почувствовать, что вы владеете процессом — это помочь в его внедрении. Если в вашей организации еще нет четкого процесса, то исследуйте различные методологии, которые могли бы быть вам полезны. Устраивайте обеды с командой, обсуждая текущие проблемы разработки и то, как можно было бы их избежать, используя стандартные подходы. Составьте совместный план как применить выбранную методологию в вашей команде, и чтобы каждый участник вносил в него свой вклад. А потом просто начните воплощать этот план в жизнь.
Если хотите почувствовать процесс, помогите его внедрить.
С другой стороны, возможно вы работаете в условиях, когда на одного инженера приходится десять менеджеров. Зачастую, к тому времени, как идеи дойдут непосредственно до разработчиков, они претерпевают массу изменений и могут стать совершенно отличными от первоначальных. Этот процесс страдает теми же недостатками, что и игра в испорченный телефон. Однако, это и возможность взять инициативу в свои руки. Исследуйте методологию, которую вы решили применить и помогите понять, что она на самом деле значит для разработчиков и для менеджмента. Не нужно бороться с этим навязанным процессом, просто используйте его правильно.
Мир методологий также может показаться пустой обёрткой из умных слов. Несмотря на то, что они могут быть не до конца понятны, всегда можно почерпнуть что-то новое в процессе изучения новой методологии разработки — даже если это то, чего не стоит делать. Если же вы комфортно чувствуете себя в данном вопросе, то и ваши аргументы будут более весомыми в спорах о том, какой подход к разработке нужно
использовать.
Даже учитывая все многообразие методологий разработки, вам вряд ли доведется работать в компании, которая полностью использует какую-либо из них. Это нормально, так как лучший подход — это тот, который обеспечит наибольшую продуктивность команды и наилучшее качество продукта на данном этапе.
Методологии: не только для гиков
Так как управление проектом не всегда обязательно связано с методологией разработки программного обеспечения, то вы можете оказаться первым в вашей компании, кто занялся решением этой задачи. Множество методологий управления проектами уже используются в различных компаниях. Возможно самым значимым является подход, разработанный Институтом Управления Проектами — Project Management Book of Knowledge, (вместе с их
признанной системой сертификации). Ещё один пример общей методологии, касающейся не только разработки программного обеспечения — Six Sigma. Используемый такими компаниями, как General Electric и Motorola, подход Six Sigma выделяет оценку и анализ процессов и продуктов для обеспечения удовлетворённости клиентов и эффективности. Хотя их решение разработано и не специально для направления разработки программного обеспечения, но его строгость и методичность даёт множество уроков, которые напрямую применимы в работе программиста.
Единственный способ найти собственную гибридную методологию (помимо божественного откровения) — это изучение всевозможных подходов, вычленение нужных кусочков, которые имеют отношение к вам и вашей команде, и последующее постепенное оттачивание новой техники на основе полученного опыта. В конце концов, если невозможно наладить процесс, то невозможно создать продукт. Намного проще найти того, кто может заставить программу работать, чем того, кто может заставить процесс создания программ работать. Таким образом, добавление знаний о процессах разработки программного обеспечения в ваш арсенал может быть очень полезным.
Руководство к действию:
- Выберите себе методологию разработки программного обеспечения, найдите книгу, начните читать информацию о ней в интернете, подключитесь к почтовой рассылке по этому вопросу. Оцените эту методологию критически. Какие у неё сильные и слабые стороны? Что может помешать применить её там, где вы работаете? Потом сделайте
такой же анализ следующей методологии. Сравните их. Можно ли их скомбинировать так, чтобы уменьшить их слабые стороны и сделать их более выигрышными?
This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at fivefilters.org/content-only/faq.php#publishers.
Комментариев нет:
Отправить комментарий